Re: The problem with @properties in D
On Tuesday, December 13, 2011 07:28:18 F i L wrote: > Can someone please explain why @property and @disabled have a '@' > symbol in front of them? So that they don't have to be keywords. - Jonathan M Davis
Re: If I had my way
On 12/12/2011 3:31 AM, Manu wrote: I'd like to hear your comment on my last big email in this thread. Eh, I need more help with which one you're talking about.
Re: D1 to be discontinued on December 31, 2012
On 12/12/2011 10:26 PM, Jesse Phillips wrote: On Sun, 11 Dec 2011 22:57:02 +, Jesse Phillips wrote: I haven't used D1 for a long time so I can't claim a bad choice here. Actually I think I can state an opinion here. The two things that stand out in my mind are. * There has been a statement of supporting D1 while it is in use (or at least has a decent number of users). Maybe there aren't any, I don't see replies claiming such. There don't seem to be many anymore. * One argument against dropping it was that the bugs were common between both languages, so the effort isn't that great to maintain both. Did that change with the increase in issues being fixed? Not really, but the code bases steadily diverge and it's getting steadily harder. It was more a matter of focus.
Re: A benchmark, mostly GC
Don: > OTOH looks like this is a case where it'd be much faster to use fixed > length integers rather than BigInt (I think that's true of nearly > everything in RosettaCode) -- strict upper bounds are known on the > length of the integers, they aren't arbitrary precision. Two problems with this idea: 1) The Python version of this coins program has found a bug in the C version that uses 128 bit integers. When you use fixed sized numbers you risk overflows. If the overflows are silent (like the ones in the built-in D integral numbers) you don't know if your code is giving bogus results, you need to work and think to be sure there are no overflows. This work and thinking requires time, that often I'd like to use for something else. This is why multiprecision numbers (or not silent overflows) are handy. In this program the upper bounds are known if you compute them first with Python or with multiprecision numbers, like C GMP :-) 2) What if I want coins for a big larger number of euros like 200_000? Maybe the result or some intermediate value don't fit in 128 bits, so the C program becomes useless again, while the Python code is useful still. Multiprecision numbers sometimes are more useful. Bye, bearophile
Re: D1 to be discontinued on December 31, 2012
On 12/12/2011 10:26 PM, Jesse Phillips wrote: PS. The reddit discussion about Python3's UTF support is interesting. Sounds like D got it right, and Python 3 failed. I had the huge advantage of having done two UTF implementations previously (a Java compiler and a Javascript compiler). Interestingly, C++11 has adopted fundamentally the same design as D. "Python also uses the environment variables (which as you know where garbage) to decide on the default encoding of files." That can never end well :-)
Re: A benchmark, mostly GC
Robert Jacques Wrote: > Second, being a systems language means that D can not implement a lot of > >>> GC algorithms including copying, generational and the good concurrent > >>> collectors. I disagree, as there are other system languages with better GC algorithms as D, because they offer more safe features than D, lack of inline assembler being one of them. And regardless of what you may think about these languages suitability for doing systems programming, there are research operating systems written in them with lots of papers to read from. Something that I am yet to see from D. Yet when reading how Singularity was implemented, there are lots of parallels between what Sing# offers and what D does. So I really see that there is quite some possibilities to improve D's GC still.
Re: Some standard protocols in Phobos
Brad Roberts: > The best way to get something done is to do it. I think the point of view about your opinion differers across different nations of the world. That POV leads to results like: http://delight.sourceforge.net/ Before doing things some people want to discuss if it's a good idea, and to know if others are interested in its results/consequences. Bye, bearophile
Re: A benchmark, mostly GC
Don: > OTOH looks like this is a case where it'd be much faster to use fixed > length integers rather than BigInt There's a fixed length integers version too: http://rosettacode.org/wiki/Count_the_coins#128-bit_version But it's slower than the Java code still, maybe because of the DMD back-end :-) > I think these are toy examples, though, they're completely > unrepresentative of real-world code. It's a toy example, but I have seen several times the low performance of D BigInts compared to Python flexible ints, so I think this toy example shows a more general pattern. Bye, bearophile
Re: A benchmark, mostly GC
On 11.12.2011 17:33, Andrei Alexandrescu wrote: On 12/11/11 9:23 AM, dsimcha wrote: My optimizations make very little difference on this benchmark, but for good reason: It's not a very good GC benchmark. I ran it with my GC profiling code enabled and it only spends around 10% of its execution time in GC. We need to figure out why else this benchmark may be so slow. I'll venture an opinion (without having profiled the code). The code uses BigInt, which makes eager allocations and custom work for each operation. But a good portion of the loop is spent using small numbers, so using the small integer optimization and native operations helps a lot. I think we need to add reference counting and small int optimization to BigInt to make it competitive. Andrei Yeah. Also important to note that BigInt was written assuming that something like TempAlloc would become available. Its GC usage is terrible without it. OTOH looks like this is a case where it'd be much faster to use fixed length integers rather than BigInt (I think that's true of nearly everything in RosettaCode) -- strict upper bounds are known on the length of the integers, they aren't arbitrary precision. I think these are toy examples, though, they're completely unrepresentative of real-world code.
Re: The problem with @properties in D
Can someone please explain why @property and @disabled have a '@' symbol in front of them?
Re: D1 to be discontinued on December 31, 2012
On Sun, 11 Dec 2011 22:57:02 +, Jesse Phillips wrote: > I haven't used D1 for a long time so I can't claim a bad choice here. Actually I think I can state an opinion here. The two things that stand out in my mind are. * There has been a statement of supporting D1 while it is in use (or at least has a decent number of users). Maybe there aren't any, I don't see replies claiming such. * One argument against dropping it was that the bugs were common between both languages, so the effort isn't that great to maintain both. Did that change with the increase in issues being fixed? So I tried a thought experiment. What if this was D2. If D3 was taking its place? If D just got up and died one year from now? How is the Python users handling it? http://www.reddit.com/tb/n3q7q And I'd be ok with it. I guess that makes sense, I have been using D2 even with it breaking code every couple steps. But the truth is, I'm using it for what it is now, not what it will be. What I use right now will still be here, and all the code I'm using is available. Sure getting better *cough* tool *coff* support and shared libraries is something to look forward to, but I'm not using them now. (So in one year, D will live on, and lets hope this improvement continues) PS. The reddit discussion about Python3's UTF support is interesting. Sounds like D got it right, and Python 3 failed.
Re: relax inout rules?
On 12/12/2011 10:56 AM, Steven Schveighoffer wrote: If this ends up being viable, this is actually easier to explain than the current rules for inout. We just have to make sure the rules are sound before doing something like this. I don't understand the point of doing this. Just make it const.
Re: relax inout rules?
On Mon, 12 Dec 2011 13:56:43 -0500, Steven Schveighoffer wrote:
> The example we were discussing on the other thread was this:
>
> void foo(ref inout(int)* a, inout(int)* b) { a = b;}
Is this just so it is easier to explain inout and won't have to explain
that const will do the same thing? Or does this actually do something
using const there doesn't?
void f(ref const(int)* a, const(int)* b) {a = b; }
void main() {
const(int)* a;
immutable(int)* b;
auto c = (new int[](5)).ptr;
f(a, c);
f(b, c); //test.d(7): Error: cast(const(int)*)b is not an lvalue
}
Re: If I had my way
On Monday, December 12, 2011 21:17:10 Mehrdad wrote: > On 12/12/2011 8:25 PM, Jonathan M Davis wrote: > > There have been a variety of suggestions on how to do it - including one > > similar to what you're suggesting with the this keyword. However, it > > still leaves the problem of disambiguation that I mentioned. What > > happens when there's a free function and a member function with the > > same name and same parameters? Which one gets called? > > Member functions always take precedence in C#, and it works perfectly > well. There's really no problem in practice. I'm not saying that it can't be done. I'm just saying that all of the corner cases and the like have to be sorted out such that the feature is completely defined, and we don't have ambiguities that are going to cause problems. Things are complicated enough with alias this and opDispatch and the like. Adding yet another way to add functions to a type complicates things that much further. So, UFCS needs to be carefully designed, and that's more of an issue IMHO than the exact syntax used to determine if a function is supposed to work with UFCS. - Jonathan M Davis
Re: If I had my way
On 12/12/2011 8:25 PM, Jonathan M Davis wrote: There have been a variety of suggestions on how to do it - including one similar to what you're suggesting with the this keyword. However, it still leaves the problem of disambiguation that I mentioned. What happens when there's a free function and a member function with the same name and same parameters? Which one gets called? Member functions always take precedence in C#, and it works perfectly well. There's really no problem in practice.
Re: The problem with @properties in D
On Mon, 12 Dec 2011 19:25:33 -0500, Mehrdad wrote: In every language I've seen that has "properties" (C#, Python), they are: - _Defined_ like methods - _Used_ like variables The trouble is, this isn't true with D. Neither is it true (by your definition) in a lot of other languages (Ruby, Eiffel) which have properties. D originally implemented a concept called Methods-as-Properties, which in terms of paradigms lies somewhere between "properties" and the "Uniform access principle". This naturally caused a bunch of cognitive dissonance for people coming from C#/python, which lead to the introduction of @property. Originally, @property and MaP were suppose to co-exist. As this was a compromise, the property can-of-worms occasionally gets re-opened in these forums.
Re: Some standard protocols in Phobos
On 12/12/2011 8:46 PM, bcs wrote: > Let me clarify what I was trying to say: What he said. :o) Let me rephrase your clarification. :) The best way to get something done is to do it. Throwing out an idea and hoping someone else does it for you is fairly ineffective.
Re: Some standard protocols in Phobos
On 12/12/2011 08:17 PM, Jonathan M Davis wrote: On Monday, December 12, 2011 20:07:37 bcs wrote: On 12/12/2011 04:55 AM, bearophile wrote: I think it will eventually become important to have some standard protocols in Phobos, like one for images like this: http://www.python.org/dev/peps/pep-0368/ Do you like? and similar ones for: - matrices - basic 2D pixel-oriented graphics. - basic database usage Bye, bearophile Likely the easiest way to ram that in in would be to pick one, design an interface, implement 3-5 concrete examples and submit a pull request. I.e. create a de-facto standard. I think there is already one in the works for DBs . A pull request would not be sufficient. Any major additions to Phobos must go through a review process on the newsgroup and be voted into Phobos. Pull requests are generally for smaller additions and bug fixes rather than whole new modules and the like. So, unless you're talking about just a function or two here, then this kind of stuff is likely to require a formal review. OK, so maybe I over simplified a bit and omitted to mention some of the later steps. :b That being said, the main way to get this kind of stuff into Phobos is to just buckle down and do it. If you're the first to come up with a new piece of functionality and are willing to work it through the review process, then you can get stuff added that way. If you sit around, hoping that someone else will do it, it may never happen. Let me clarify what I was trying to say: What he said. :o)
Re: A benchmark, mostly GC
On Mon, 12 Dec 2011 10:44:27 -0500, Timon Gehr wrote: On 12/12/2011 04:17 PM, Robert Jacques wrote: On Mon, 12 Dec 2011 01:06:14 -0500, Brad Anderson wrote: On Sun, Dec 11, 2011 at 10:55 PM, Robert Jacques wrote: Second, being a systems language means that D can not implement a lot of GC algorithms including copying, generational and the good concurrent collectors. What about being a systems language prevents generational? The page on garbage collection on the D website says while it doesn't use a generational GC it will some day and gives tips on what to avoid so you don't fall victim to the behavior of a moving GC. Regarding moving collectors. D supports semi-precise collection. Therefore D can support some types of moving collectors, i.e. compactors, which is what the website is talking about. Copying collectors, on the other hand, require full precision to work; you must be able to fully evacuate a region of memory. D doesn't support full precision, for a couple of performance (unions, The compiler could insert small code fragments that track whether or not an union contains a pointer. the call stack, What is the problem with the call stack? Can't the compiler just generate reference offset information for all the function frames and then the GC generates a backtrace to identify the references? C/C++ interop) There should be multiple options for GC. If C/C++ interop is unimportant, a better GC that does not support it well is still handy. and technical reasons (the inline assembler). inline assembler does not always move around GC heap references. I think that in the cases it does, reference stores could be annotated manually. Solving these problems is a little more complicated than this, but the existence of solutions wasn't the problem; performance of those solutions was. Unions can be instrumented, but the instrumentation must be harmonized with the GC as pointer bit masks must be changed. And changeable bitmasks present their own overhead problem (i.e. a 1/32 or 1/64 memory overhead). Personally, I'm in favor of a precise heap, so I'd like this, but it does require a compiler, not runtime, change. The call stack is more complicated because you have to view the function frame as a bunch of unions as space in the function frame is heavily reused to minimize cache effects and the change of a stack overflow. So, before every function call you'd have to flush the current reference offsets of the function frame. *opps* I was remembering why dual stacks doesn't work, and the same logic applies to function frames. So a dual stack approach would use one stack for references and one stack for values. However, pointers to unions/structs/classes on the dual stack don't work because to values and pointers in the objects are not together anymore. Similarly, pointers to unions on a precise/framed stack are troublesome because the the assignment wouldn't know where the meta-data was. Hmm... The GC could have a pointer bitmask for each stack, which the stack frame flushes prior to each function call. C/C++ interop is never unimportant; at a minimum all OS calls work through C/C++ interop. So while it may not be use directly by most D programs, under the hood, the libraries we use all depend on it. We'd have to be able to annotate C functions with their marshaling requirements and change how we handle them based on the GC we're using. Things get even more icky when one considers registering D callbacks or C functions calling into D DLLs. As for the inline assembler, we'd have to annotate changes to both the GC heap and the call stack, and since this would have to be done manually, it would become a source of nasty memory bugs. Technically, the performance of certain fundamental operations is an implementation detail, but there's a certain expectation of 'system' languages to be lean and mean, either optionally or by default and as pointer tracking eliminates that option. Furthermore, pointer tracking interferes with language interop in rather nasty ways and may even necessitate changes to the ABI. But that doesn't mean a D dialect couldn't do a nice modern GC; indead the .net D compiler already did, and IIRC LDC/LLVM has a JIT backend. Regarding generational collectors. Both generational and concurrent collectors require that every pointer assignment is known to the compiler, which then instruments the assignment to flag mark bits, etc. For generational collectors, you need this information to know which objects/memory pages to search for roots into the young generation. Without this information, you have to search the entire heap, i.e. do a full collection. Again, both performance and technical reasons come into play here. Instrumentation represents a performance cost, which even if it pays for itself, looks bad in newsgroups posting. Indeed, concurrent collectors are mostly about trading throughput for latency. So, like JAVA, you'd want to use versi
Re: If I had my way
On Tuesday, December 13, 2011 05:13:29 F i L wrote:
> On Monday, 12 December 2011 at 21:57:36 UTC, Jonathan M Davis
>
> wrote:
> > There has been discussion of UFCS (universal function call
> > syntax), which would then expand that beyond arrays to _all_
> > types - int, float, any user-
> > defined type, etc. However, there are a number of issues with
> > that (particularly with user-defined types; e.g. what if a
> > member function and a free function have the same name?), and
> > it has yet to be implemented. It may never be implemented.
>
> C# easily avoids member confusion with pseudo methods by using
> the 'this' keyword as a parameter attribute in the pseudo method
> (http://msdn.microsoft.com/en-us/library/bb383977.aspx). Any
> function(this a, b) can be invoked as: a.function(b) in C#. I
> understand using the 'this' keyword as a parameter attribute
> already serves a different purpose in D, but I'm sure another
> keyword ('pseudo' perhaps?) or equivalent syntax could be
> reached. At which point, any external pseudo method conflicting
> with an objects internal members could simply result in a
> compiler error (or, member functions could take priority over
> pseudo methods).
There have been a variety of suggestions on how to do it - including one
similar to what you're suggesting with the this keyword. However, it still
leaves the problem of disambiguation that I mentioned. What happens when
there's a free function and a member function with the same name and same
parameters? Which one gets called? It's issues like that which are more of a
problem than the exact syntax for declaring it IMHO. And all of those details
need to be sorted out in a satisfactory manner before we can add UFCS to the
language in any form.
For arrays, all you need to do is have the first argument be an array, and that
works great for arrays, but arrays don't have much in the way of functions
built in, so there's no conflict.
Realistically, at this point, I'd expect that if UFCS gets added any time
soon, it's going to require that someone other than Walter do it and that they
have do it very solidly, otherwise it could be a long time before it stands
any chance of happening, simply because Walter is focused on fixing major bugs
and stabilizing the compiler and isn't likely to look at adding new features
anytime soon if there's no dire need (even if they're backwards compatible).
- Jonathan M Davis
Re: Some standard protocols in Phobos
On Monday, December 12, 2011 20:07:37 bcs wrote: > On 12/12/2011 04:55 AM, bearophile wrote: > > I think it will eventually become important to have some standard > > protocols in Phobos, like one for images like this: > > http://www.python.org/dev/peps/pep-0368/ > > > > Do you like? > > > > and similar ones for: > > - matrices > > - basic 2D pixel-oriented graphics. > > - basic database usage > > > > Bye, > > bearophile > > Likely the easiest way to ram that in in would be to pick one, design an > interface, implement 3-5 concrete examples and submit a pull request. > I.e. create a de-facto standard. > > I think there is already one in the works for DBs . A pull request would not be sufficient. Any major additions to Phobos must go through a review process on the newsgroup and be voted into Phobos. Pull requests are generally for smaller additions and bug fixes rather than whole new modules and the like. So, unless you're talking about just a function or two here, then this kind of stuff is likely to require a formal review. That being said, the main way to get this kind of stuff into Phobos is to just buckle down and do it. If you're the first to come up with a new piece of functionality and are willing to work it through the review process, then you can get stuff added that way. If you sit around, hoping that someone else will do it, it may never happen. - Jonathan M Davis
Re: If I had my way
On Monday, 12 December 2011 at 21:57:36 UTC, Jonathan M Davis
wrote:
There has been discussion of UFCS (universal function call
syntax), which would then expand that beyond arrays to _all_
types - int, float, any user-
defined type, etc. However, there are a number of issues with
that (particularly with user-defined types; e.g. what if a
member function and a free function have the same name?), and
it has yet to be implemented. It may never be implemented.
C# easily avoids member confusion with pseudo methods by using
the 'this' keyword as a parameter attribute in the pseudo method
(http://msdn.microsoft.com/en-us/library/bb383977.aspx). Any
function(this a, b) can be invoked as: a.function(b) in C#. I
understand using the 'this' keyword as a parameter attribute
already serves a different purpose in D, but I'm sure another
keyword ('pseudo' perhaps?) or equivalent syntax could be
reached. At which point, any external pseudo method conflicting
with an objects internal members could simply result in a
compiler error (or, member functions could take priority over
pseudo methods).
I understand this isn't exactly a priority, but IMO it could
really help the overall syntax feel more consistent in some areas.
import std.conv;
void main()
{
string encoded = "1324.03";
double actual = encoded.to!string; // similar to
Object.toString()
}
More importantly, pseudo methods could be used to bend the rules
of member access, and to implement module-specific functionality
for imported objects without breaking OOP syntax.
module a;
class A {
int data;
}
~~
module b;
pseudo void foo(A a, B b) {
// A can access B's private members
a.data = b._data;
}
class B {
private int _data;
}
~~
import a, b;
void main() {
auto a = new A();
auto b = new B();
a.foo(b); // cool!
}
So, I think that there's a decent chance that you just
misunderstood what that section in TDPL was really saying (it
really should be clearer on whether it meant just arrays or all
types), but there are definitely folks who want it to be
extended to all types, so it may be eventually, but we'll have
to wait and see.
Undoubtedly a misunderstanding on my end. Still, +1 for seeing
Pseudo Members for all types.
- Philip
Re: Some standard protocols in Phobos
On 12/12/2011 04:55 AM, bearophile wrote: I think it will eventually become important to have some standard protocols in Phobos, like one for images like this: http://www.python.org/dev/peps/pep-0368/ Do you like? and similar ones for: - matrices - basic 2D pixel-oriented graphics. - basic database usage Bye, bearophile Likely the easiest way to ram that in in would be to pick one, design an interface, implement 3-5 concrete examples and submit a pull request. I.e. create a de-facto standard. I think there is already one in the works for DBs .
Re: The problem with @properties in D
On 12/12/2011 4:52 PM, Steven Schveighoffer wrote: On Mon, 12 Dec 2011 19:42:48 -0500, Jonathan M Davis wrote: -property makes it so that properties must be used like variables and non- property functions cannot be. In theory, that will become the default behavior of the compiler eventually, but we couldn't enable it immediately due to a combination of bugs with @property and the fact that it would break code. For now, people can build with -property to make sure that their code uses properties properly. To clarify, Jonathan is talking about using the -property command line switch for dmd. -Steve Oh shoot, I hadn't heard of that switch. That's awesome, thanks!
Re: Fixing const arrays
On 13.12.2011 02:39, Jonathan M Davis wrote:
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
It's actually not 'save' being a noun that's the problem. I just
thought of a counter-example:
--- struct Foo { // the data Bar data[];
// save data on shutdown? @property bool save() { return save_; }
@property bool save(bool shouldShave) { return save_ = shouldSave;
}
private: bool save_; } --- Not meant to be a realistic example, but
save is fine as a property here.
You can pretty much always come up with another function with a
completely different purpose wit the same name.
Personally, the _only_ issue that I have with save is the fact that
it's a property. The name save works well enough, and I can't think
of anything that's better.
Yes, that's my opinion too.
Re: Fixing const arrays
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
> It's actually not 'save' being a noun that's the problem. I just
> thought of a counter-example:
>
> ---
> struct Foo {
> // the data
> Bar data[];
>
> // save data on shutdown?
> @property bool save() { return save_; }
> @property bool save(bool shouldShave) { return save_ = shouldSave; }
>
> private:
> bool save_;
> }
> ---
> Not meant to be a realistic example, but save is fine as a property here.
You can pretty much always come up with another function with a completely
different purpose wit the same name.
Personally, the _only_ issue that I have with save is the fact that it's a
property. The name save works well enough, and I can't think of anything
that's better.
- Jonathan M Davis
Re: Second Round CURL Wrapper Review
On Tuesday, 13 December 2011 at 00:47:26 UTC, David Nadlinger wrote: I don't know if you already have a solution in the works, but maybe the future interface I did for Thrift is similar to what you are looking for: http://klickverbot.at/code/gsoc/thrift/docs/thrift.util.future.html David Doesn't std.parallelism's task parallelism API work for this? (Roughly speaking a task in std.parallelism == a future in your Thrift API.) If not, what can I do to fix it so that it can? Looking briefly at your API, one thing I notice is the ability to cancel a future. This would be trivial to implement in std.parallelism for tasks that haven't yet started executing, but difficult if not impossible for tasks that are already executing. Does your Thrift API allow cancelling futures that are already executing? If so, how is that accomplished? The TFutureAggregatorRange could be handled by a parallel foreach loop if I understand correctly, though it would look a little different.
Re: Fixing const arrays
On 12.12.2011 20:03, Jonathan M Davis wrote:
On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote:
On 12/12/11 9:09 AM, torhu wrote:
> On 12.12.2011 15:43, Andrei Alexandrescu wrote:
>> On 12/12/11 6:24 AM, torhu wrote:
>>> save being a property is a stupid inconsistency.
>>
>> I'm not so sure.
>>
>> Andrei
>
> Why? As far as I can tell, it's inconsistent with what properties are
> used like in other programming languages.
Why?
> Saving something is an action,
> which to me is a different concept.
So if we called .save .state or .current things would be any different?
> If it was called currentState
> instead, that's what I'd call a property.
Ah. So now we're wasting time not on @property (as I'd predicted), but
instead on what _names_ are suitable to work with it. I rest my case.
> Making something a property gives it certain connotations that break
> when it's called 'save'. That you can save the state of the range is a
> property, if you will. But the action of doing so is not a property.
> People are going to be surprised when save() doesn't compile. Isn't
> there something called the principle of least surprise?
I think we should only worry about surprising the uninitiated with how
poorly designed the whole @property thing is.
A property is essentially an abstraction to treat a function like a member
variable. As such, the naming conventions for a property should be equivalent
to those for a variable - and that generally means nouns. save is not a noun.
It's an action verb. So, yes, I think that it's a completely inappropriate
name for a property. Something ilke state or current _would_ be appropriate
names. However, at this point, I really don't think that it's worth arguing
about.
If I were to change it, I'd probably just make save a function rather than
renaming it, but if we did it, then there would be quite a bit of code that
would have to be changed essentially over an argument over whether save is
valid property name because it's not a noun. And while I _don't_ think that
it's a valid property name, that's getting a bit petty given how much code
would break.
It's actually not 'save' being a noun that's the problem. I just
thought of a counter-example:
---
struct Foo {
// the data
Bar data[];
// save data on shutdown?
@property bool save() { return save_; }
@property bool save(bool shouldShave) { return save_ = shouldSave; }
private:
bool save_;
}
---
Not meant to be a realistic example, but save is fine as a property here.
Re: Why D const is annoying
On Sun, 11 Dec 2011 19:40:42 +0100
Mafi wrote:
> void f(ref const(int)* a, const(int)* b) {a = b; }
> void main() {
>immutable(int)* a;
>auto b = (new int[](5)).ptr;
>f(a, b);
>//if this compiles I have just assigned a mutable pointer
>//to an immutable one
> }
>
> With the above definition using inout, such a call would be
> disallowed.
Just gave this code a try:
void f(ref const(int)* a, const(int)* b) {a = b; }
void main() {
const(int)* a;
immutable(int)* b;
auto c = (new int[](5)).ptr;
f(a, c);
f(b, c); //test.d(7): Error: cast(const(int)*)b is not an lvalue
}
Re: The problem with @properties in D
"Mehrdad" wrote in message
news:jc661t$2mo5$1...@digitalmars.com...
> In every language I've seen that has "properties" (C#, Python), they are:
>
> - _Defined_ like methods
> - _Used_ like variables
>
> The trouble is, this isn't true with D.
>
> Consider:
>
> struct Struct
> {
> int delegate() randgen1 = ...;
> @property
> int delegate() randgen2() { ... }
> }
>
> Struct s;
> auto result = s.randgen2();// This doesn't do the user expects
>
> It is *not* possible, in D, to transparently use either one -- you have to
> treat properties, like methods, not like variables. Except that this is
> inconsistent -- in most other cases, you don't need to do that.
>
> Or for example:
>
> Struct s;
> auto a = &s.randgen1;
> auto b = &s.randgen2; // Should be an error
>
> IMO, properties should not be callable with parentheses at all. Something
> like C# -- they should generate getter and setter methods instead, or the
> like.
> Furthermore, taking the address of a property should only work if you can
> take the address of its _value_. If you need the address of the actual
> function, then I think a corresponding getter method might be easier to
> use.
>
> It gets even /worse/ in templated code, because you have no idea whether
> an alias is referring to a property or to a variable or whatever.
>
> Making this change would obviously break code, but the break is obviously
> _trivial_ to fix: just remove extra parentheses. It won't exactly be the
> kind of breakage that causes headaches.
>
> So should this be fixed?
At the moment, you have to give DMD the "-property" switch to make it
actually enforce the correct syntax/semantics for properties. When the
feature was first put in a few releases ago, it was done like this to avoid
breaking lots of code and to give people a chance to transition to it before
finally forcing it (properties used to be done differently, and the problems
with delegates, like you noticed, were a major reason for this @property
stuff in the first place). Not sure when they were planning on finally
flipping the switch and turning it on permanently, or at least on by
default.
Has it maybe been long enough now?
Re: The problem with @properties in D
On Mon, 12 Dec 2011 19:42:48 -0500, Jonathan M Davis wrote: -property makes it so that properties must be used like variables and non- property functions cannot be. In theory, that will become the default behavior of the compiler eventually, but we couldn't enable it immediately due to a combination of bugs with @property and the fact that it would break code. For now, people can build with -property to make sure that their code uses properties properly. To clarify, Jonathan is talking about using the -property command line switch for dmd. -Steve
Re: Suggestion for std.process upgrade
> There is a completely revamped version of std.process. It is being held > up right now because DMD on windows depends on DMC for it's C runtime, and > DMC has issues supporting pipes. I have recently opened a pull request > for Walter to merge, I'm going to ping him about it right after 2.057 is > released. > > For more info, see the docs Lars posted here: > > http://kyllingen.net/code/ltk/doc/process.html > > Once the DMC issue is fixed, you should see this improvement getting much > more attention. It's very low hanging fruit. > > -Steve Nice piece of work. I am looking forward for it becoming part of Phobos. I find multi-process work interesting alternative to multi-threaded, sometimes more stable and robust solution.
Re: Second Round CURL Wrapper Review
On 12/12/11 1:18 PM, jdrewsen wrote: On Monday, 12 December 2011 at 10:26:52 UTC, Somedude wrote: Just an idea: would it be possible/useful to use the signals/slots mechanism for this kind of synch ? This would be most useful if there were some kind of main loop. This is needed because the request is done in another thread and the response should be handled in the main thread. Without an main loop in the main thread or a destinct call to e.g. a poll() method the signal/slot s would not work. I don't know if you already have a solution in the works, but maybe the future interface I did for Thrift is similar to what you are looking for: http://klickverbot.at/code/gsoc/thrift/docs/thrift.util.future.html David
Re: The problem with @properties in D
On Monday, December 12, 2011 16:25:33 Mehrdad wrote:
> In every language I've seen that has "properties" (C#, Python), they are:
>
> - _Defined_ like methods
> - _Used_ like variables
>
> The trouble is, this isn't true with D.
>
> Consider:
>
> struct Struct
> {
> int delegate() randgen1 = ...;
> @property
> int delegate() randgen2() { ... }
> }
>
> Struct s;
> auto result = s.randgen2(); // This doesn't do the user expects
>
> It is *not* possible, in D, to transparently use either one -- you have
> to treat properties, like methods, not like variables. Except that this
> is inconsistent -- in most other cases, you don't need to do that.
>
> Or for example:
>
> Struct s;
> auto a = &s.randgen1;
> auto b = &s.randgen2; // Should be an error
>
> IMO, properties should not be callable with parentheses at all.
> Something like C# -- they should generate getter and setter methods
> instead, or the like.
> Furthermore, taking the address of a property should only work if you
> can take the address of its _value_. If you need the address of the
> actual function, then I think a corresponding getter method might be
> easier to use.
>
> It gets even /worse/ in templated code, because you have no idea whether
> an alias is referring to a property or to a variable or whatever.
>
> Making this change would obviously break code, but the break is
> obviously _trivial_ to fix: just remove extra parentheses. It won't
> exactly be the kind of breakage that causes headaches.
>
> So should this be fixed?
Originally, it was the case that there was no @property, and any function with
no arguments could be used like a property. It was decided to add @property to
enforce that certain functions be treated as properties and some not. But the
fact that @property was not how properties were initially implemented has
caused issues in migrating.
-property makes it so that properties must be used like variables and non-
property functions cannot be. In theory, that will become the default behavior
of the compiler eventually, but we couldn't enable it immediately due to a
combination of bugs with @property and the fact that it would break code. For
now, people can build with -property to make sure that their code uses
properties properly.
- Jonathan M Davis
Re: Suggestion for std.process upgrade
On 13/12/11 09:13, Steven Schveighoffer wrote: On Mon, 12 Dec 2011 17:08:53 -0500, Bane wrote: I have been playing with std.process (D2) lately, and have 2 suggestions and more or less tested code if somebody other than my self have use for it. One is shell() function (not mentioned in the docs, curious), I see it can be made more efficient on Windows. It executes shell command and returns standard output as string. Current implementation do it by piping stdout to temporary file on disk and reading that file back. Using CreateProccess Windows API it can do same job 3 times faster and remove need for temporary files and disk writes. I think that is beneficial gain for some applications. Other is fork-exec implementation eg. starting a program using command line and detaching it from parent, so it continues to run after parent is dead. On Posix it is implemented using fork() and exec() calls, on Windows using CreateProcess. There is a completely revamped version of std.process. It is being held up right now because DMD on windows depends on DMC for it's C runtime, and DMC has issues supporting pipes. I have recently opened a pull request for Walter to merge, I'm going to ping him about it right after 2.057 is released. For more info, see the docs Lars posted here: http://kyllingen.net/code/ltk/doc/process.html Once the DMC issue is fixed, you should see this improvement getting much more attention. It's very low hanging fruit. -Steve I took a look at the link, and it looks very nice. I am currently trying to port an application over from Linux to Windows and the lack of wait(pid) is currently a blocker. -- Graham St Jack
The problem with @properties in D
In every language I've seen that has "properties" (C#, Python), they are:
- _Defined_ like methods
- _Used_ like variables
The trouble is, this isn't true with D.
Consider:
struct Struct
{
int delegate() randgen1 = ...;
@property
int delegate() randgen2() { ... }
}
Struct s;
auto result = s.randgen2();// This doesn't do the user expects
It is *not* possible, in D, to transparently use either one -- you have
to treat properties, like methods, not like variables. Except that this
is inconsistent -- in most other cases, you don't need to do that.
Or for example:
Struct s;
auto a = &s.randgen1;
auto b = &s.randgen2; // Should be an error
IMO, properties should not be callable with parentheses at all.
Something like C# -- they should generate getter and setter methods
instead, or the like.
Furthermore, taking the address of a property should only work if you
can take the address of its _value_. If you need the address of the
actual function, then I think a corresponding getter method might be
easier to use.
It gets even /worse/ in templated code, because you have no idea whether
an alias is referring to a property or to a variable or whatever.
Making this change would obviously break code, but the break is
obviously _trivial_ to fix: just remove extra parentheses. It won't
exactly be the kind of breakage that causes headaches.
So should this be fixed?
Re: Fixing const arrays
On Mon, 12 Dec 2011 19:00:35 -0500, Andrei Alexandrescu wrote: On 12/12/11 1:12 PM, Jonathan M Davis wrote: On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote: Insisting on the current property semantics was a sizeable mistake of this community, and I am sorry we gave into it. Aside from the fact that the behavior of -property isn't the default, what's the problem with @property? Other than it being completely useless, requiring more rote memorization, and fomenting time-wasting discussion? None. Wait, are we talking about @property or .save? -Steve
Re: d-programming-language.com
On 13 December 2011 01:59, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 12/12/11 1:03 PM, Jonathan M Davis wrote: > >> On Monday, December 12, 2011 20:39:11 Manu wrote: >> >>> On 12 December 2011 20:09, Hans Uhlig wrote: >>> On 12/11/2011 1:26 PM, Peter Alexander wrote: > On 11/12/11 1:52 AM, Walter Bright wrote: > >> On 12/10/2011 4:46 PM, Peter Alexander wrote: >> >>> I think either would be fine, but having to use the command line >>> for >>> anything on >>> Windows is a no-no these days in terms of usability. >>> >> >> Since dmd is a command line tool anyway, why is it a usability >> problem >> to use dman? >> > > Why do you think so many people ask for IDEs? :-) > > Windows people are used to Visual Studio doing everything for them. > Hit > F7 to compile, F5 to run under debugger, click on lines to set > breakpoints. > That's because cmd sucks. MS Powershell isn't much better. I have to use mintty just to be able to have a sane environment. Linux is a very shell oriented OS still even with Kde and Gnome. Microsoft did everything in its power to kill off the shell for "useability" reasons. >>> >>> And they did a great job. Visual Studio is a fantastically productive >>> coding environment. >>> >> >> Having a great GUI and a great shell are not mutually exclusive. >> >> - Jonathan M Davis >> > > Look at the Mac... > > Andrei > Have you actually tried to use XCode professionally? ... ;)
Re: Fixing const arrays
On 12/12/11 1:12 PM, Jonathan M Davis wrote: On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote: Insisting on the current property semantics was a sizeable mistake of this community, and I am sorry we gave into it. Aside from the fact that the behavior of -property isn't the default, what's the problem with @property? Other than it being completely useless, requiring more rote memorization, and fomenting time-wasting discussion? None. Andrei
Re: d-programming-language.com
On 12/12/11 1:03 PM, Jonathan M Davis wrote: On Monday, December 12, 2011 20:39:11 Manu wrote: On 12 December 2011 20:09, Hans Uhlig wrote: On 12/11/2011 1:26 PM, Peter Alexander wrote: On 11/12/11 1:52 AM, Walter Bright wrote: On 12/10/2011 4:46 PM, Peter Alexander wrote: I think either would be fine, but having to use the command line for anything on Windows is a no-no these days in terms of usability. Since dmd is a command line tool anyway, why is it a usability problem to use dman? Why do you think so many people ask for IDEs? :-) Windows people are used to Visual Studio doing everything for them. Hit F7 to compile, F5 to run under debugger, click on lines to set breakpoints. That's because cmd sucks. MS Powershell isn't much better. I have to use mintty just to be able to have a sane environment. Linux is a very shell oriented OS still even with Kde and Gnome. Microsoft did everything in its power to kill off the shell for "useability" reasons. And they did a great job. Visual Studio is a fantastically productive coding environment. Having a great GUI and a great shell are not mutually exclusive. - Jonathan M Davis Look at the Mac... Andrei
Re: Sitemap
On 12/12/11 4:42 PM, Andrew Wiley wrote: For the last few days, www.dlang.org has always worked for me, but just dlang.org has been working sporadically. Not sure what the deal is. Not sure whether that's related, but we're in the process of transferring domain ownership to DigitalMars. I'll make sure both dlang.org and www.dlang.org work. Andrei
Re: What should be done with the domain, dlang.org?
Walter Bright wrote: > On 12/10/2011 11:11 AM, Andrei Alexandrescu wrote: > >On 12/10/11 4:43 AM, Oscar Brynolf wrote: > >[snip] > > > >Hi Oscar, > > > > > >Thanks for writing! I also prefer dlang.org to the other domains we have. > >CNAME > >works great at least for the time being, but I think it's unfair to have you > >pay > >for it. > > > >I'll talk to Walter about transferring registration, either to his company's > >or > >my name, then I'll email you privately to your gmail address. I'd also be > >glad > >to personally pay back whatever registration fees you have incurred until > >now, > >and I'm glad that you're not selling the domain to the highest bidder :o). > > Let me chime in and thank Oscar, and I agree with everything Andrei said. Many Thanks, Oscar. This is so very kind of you. If we ever meet remind me to buy you a drink or similar. And since Berlin is my hometown chances are quite good. Jens
Re: Suggestion for std.process upgrade
There is a completely revamped version of std.process. It is being held up right now because DMD on windows depends on DMC for it's C runtime, and DMC has issues supporting pipes. Walter should just release the few parts of the source code that according to Mehrdad are needed to get rid of it: Right, but my point is, I could work around (I've gotten within inches of it!) it if simply Walter released a TINY part of snn.lib -- just a handful of tiny source files regarding the TLS-related stuff, EXE segment markers, and whatnot. (I've already raised this issue before, and precisely what we would need, but it seemed to go completely ignored.)
Re: Suggestion for std.process upgrade
On Mon, 12 Dec 2011 17:08:53 -0500, Bane wrote: I have been playing with std.process (D2) lately, and have 2 suggestions and more or less tested code if somebody other than my self have use for it. One is shell() function (not mentioned in the docs, curious), I see it can be made more efficient on Windows. It executes shell command and returns standard output as string. Current implementation do it by piping stdout to temporary file on disk and reading that file back. Using CreateProccess Windows API it can do same job 3 times faster and remove need for temporary files and disk writes. I think that is beneficial gain for some applications. Other is fork-exec implementation eg. starting a program using command line and detaching it from parent, so it continues to run after parent is dead. On Posix it is implemented using fork() and exec() calls, on Windows using CreateProcess. There is a completely revamped version of std.process. It is being held up right now because DMD on windows depends on DMC for it's C runtime, and DMC has issues supporting pipes. I have recently opened a pull request for Walter to merge, I'm going to ping him about it right after 2.057 is released. For more info, see the docs Lars posted here: http://kyllingen.net/code/ltk/doc/process.html Once the DMC issue is fixed, you should see this improvement getting much more attention. It's very low hanging fruit. -Steve
Re: Sitemap
On Mon, Dec 12, 2011 at 4:09 PM, Andrei Alexandrescu wrote: > On 12/12/11 2:06 PM, Peter Alexander wrote: >> >> On 12/12/11 7:52 PM, Andrei Alexandrescu wrote: >>> >>> I've added a sitemap to the website: >>> >>> http://dlang.org/sitemap.html >>> >>> I've already removed a bunch of obsolete documents. Feel free to look >>> around and report bugs for various pages. >>> >>> >>> Thanks, >>> >>> Andrei >> >> >> Bug: that link is broken. >> >> :-) > > > worksforme > > Andrei For the last few days, www.dlang.org has always worked for me, but just dlang.org has been working sporadically. Not sure what the deal is.
Re: d-programming-language.com
On 12/12/2011 8:57 AM, Vladimir Panteleev wrote: Anyway, it's probably worth doing the work of using the d-p-l.org files. I could use the opportunity to move some of the hacks out of chmgen into the docs as proper fixes. I do appreciate the effort you're putting into this. I think chmgen will be a valuable addition.
Re: D kicks ass.
Trass3r Wrote: > > Well, it is a nice to reinspect ones own decision after some time and > > confirm it was and is totally correct. > > To do that just try going back to C++ ;) Just did. Things lacking: - library - easy to use maps and arrays Things that should lack: - bloody header files and forward declarations - preprocessor perversions - cryptic signs like <> :: -> Things that are easier or more fun: - good compiler support - easy linking with C code - RAII tinkering & smaller memory footprint (GC just kills all the fun :(
Re: Suggestion for std.process upgrade
One question. Is std.c.windows.windows lacking for most API definitions or am I looking on wrong place? Yep, this one is more complete: http://dsource.org/projects/bindings/wiki/WindowsApi But for some reason we still keep that old version, sigh.
Re: .dmg installer for OSX?
On 12/12/11 3:09 PM, Jacob Carlborg wrote: On 2011-12-12 17:11, Andrei Alexandrescu wrote: On 12/12/11 9:44 AM, Jacob Carlborg wrote: On 2011-12-12 15:59, Andrei Alexandrescu wrote: Would you consider authoring a pull request for D-Programming-Language/Installer? The installer is already THERE and it's still working (I just tried it on DMD 1.072). I understand. The thing is, if we use your installer we'll have our pipeline depend on an external project. If we get your code into D-Programming-Language/Installer then we own the code, can make adjustments to it, etc. Please advise. As I said, it is already THERE. Please read the link: https://github.com/D-Programming-Language/installer/tree/master/osx It says "D-Programming-Language/installer". It was uploaded to dsource two years ago and was moved with the rest of the code to github. Got it, thanks. I'll follow up on this. Andrei
Suggestion for std.process upgrade
I have been playing with std.process (D2) lately, and have 2 suggestions and more or less tested code if somebody other than my self have use for it. One is shell() function (not mentioned in the docs, curious), I see it can be made more efficient on Windows. It executes shell command and returns standard output as string. Current implementation do it by piping stdout to temporary file on disk and reading that file back. Using CreateProccess Windows API it can do same job 3 times faster and remove need for temporary files and disk writes. I think that is beneficial gain for some applications. Other is fork-exec implementation eg. starting a program using command line and detaching it from parent, so it continues to run after parent is dead. On Posix it is implemented using fork() and exec() calls, on Windows using CreateProcess. One question. Is std.c.windows.windows lacking for most API definitions or am I looking on wrong place?
Re: Sitemap
On 12/12/11 2:06 PM, Peter Alexander wrote: On 12/12/11 7:52 PM, Andrei Alexandrescu wrote: I've added a sitemap to the website: http://dlang.org/sitemap.html I've already removed a bunch of obsolete documents. Feel free to look around and report bugs for various pages. Thanks, Andrei Bug: that link is broken. :-) worksforme Andrei
Re: D kicks ass.
Well, it is a nice to reinspect ones own decision after some time and confirm it was and is totally correct. To do that just try going back to C++ ;)
Re: d-programming-language.com
On 2011-12-12 20:03, Jonathan M Davis wrote: On Monday, December 12, 2011 20:39:11 Manu wrote: On 12 December 2011 20:09, Hans Uhlig wrote: On 12/11/2011 1:26 PM, Peter Alexander wrote: On 11/12/11 1:52 AM, Walter Bright wrote: On 12/10/2011 4:46 PM, Peter Alexander wrote: I think either would be fine, but having to use the command line for anything on Windows is a no-no these days in terms of usability. Since dmd is a command line tool anyway, why is it a usability problem to use dman? Why do you think so many people ask for IDEs? :-) Windows people are used to Visual Studio doing everything for them. Hit F7 to compile, F5 to run under debugger, click on lines to set breakpoints. That's because cmd sucks. MS Powershell isn't much better. I have to use mintty just to be able to have a sane environment. Linux is a very shell oriented OS still even with Kde and Gnome. Microsoft did everything in its power to kill off the shell for "useability" reasons. And they did a great job. Visual Studio is a fantastically productive coding environment. Having a great GUI and a great shell are not mutually exclusive. - Jonathan M Davis Mac OS X is the perfect example of that. -- /Jacob Carlborg
Re: D kicks ass.
Trass3r Wrote: > Am 12.12.2011, 19:21 Uhr, schrieb Bane : > > > Sorry, but it's true. > > Compared to C++, it has much friendlier syntax, important built in types > > and all the goodies. And let us not forget - big standard library ready > > to go. > > > > But it is still rough on the edges, needs polishing and fixing little > > bugs. Now it needs tender care to grow big (and lose some weight from > > executables :). > > We know :) Well, it is a nice to reinspect ones own decision after some time and confirm it was and is totally correct.
Re: If I had my way
On Monday, December 12, 2011 19:48:11 F i L wrote: > My biggest disappointment was(/is) with the lack of the alleged > Pseudo Methods (section 5.9.1). It's one thing to play around > with a language you understand is growing and under development. > It's another to boast about the language to your co-workers, only > to receive unexpected errors when they ask for demonstrations :/ > Bad for publicity, that. I think that that section was not clear enough. Calling free functions as if they were member functions on a type works with arrays and has only ever worked with arrays. TDPL doesn't actually say that it works with anything other than arrays. It talks about adding them to built-in types and specifically talks about arrays, but it's not particularly clear about anything other than arrays. My guess is that it was never intended to mean anything other than arrays, but I don't know. Only Andrei would know that. There has been discussion of UFCS (universal function call syntax), which would then expand that beyond arrays to _all_ types - int, float, any user- defined type, etc. However, there are a number of issues with that (particularly with user-defined types; e.g. what if a member function and a free function have the same name?), and it has yet to be implemented. It may never be implemented. So, I think that there's a decent chance that you just misunderstood what that section in TDPL was really saying (it really should be clearer on whether it meant just arrays or all types), but there are definitely folks who want it to be extended to all types, so it may be eventually, but we'll have to wait and see. - Jonathan M Davis
Re: D kicks ass.
On 12 December 2011 20:53, Robert Clipsham wrote: > On 12/12/2011 20:08, Iain Buclaw wrote: >> >> Bigger == Better. :o) > > > Biggest rock is best rock. > That's a whole lotta rox. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: .dmg installer for OSX?
On Mon, 12 Dec 2011 09:59:49 -0500, Andrei Alexandrescu wrote: On 12/12/11 6:51 AM, Jacob Carlborg wrote: Anyway, it's available at github: https://github.com/D-Programming-Language/installer/tree/master/osx Would you consider authoring a pull request for D-Programming-Language/Installer? I also glossed over this too, Andrei, but reading this part of the thread again is almost comical :) I think we need a line in here about TPS reports... -Steve
Re: D kicks ass.
Am 12.12.2011, 19:21 Uhr, schrieb Bane : Sorry, but it's true. Compared to C++, it has much friendlier syntax, important built in types and all the goodies. And let us not forget - big standard library ready to go. But it is still rough on the edges, needs polishing and fixing little bugs. Now it needs tender care to grow big (and lose some weight from executables :). We know :)
Re: .dmg installer for OSX?
On 2011-12-12 17:11, Andrei Alexandrescu wrote: On 12/12/11 9:44 AM, Jacob Carlborg wrote: On 2011-12-12 15:59, Andrei Alexandrescu wrote: Would you consider authoring a pull request for D-Programming-Language/Installer? The installer is already THERE and it's still working (I just tried it on DMD 1.072). I understand. The thing is, if we use your installer we'll have our pipeline depend on an external project. If we get your code into D-Programming-Language/Installer then we own the code, can make adjustments to it, etc. Please advise. As I said, it is already THERE. Please read the link: https://github.com/D-Programming-Language/installer/tree/master/osx It says "D-Programming-Language/installer". It was uploaded to dsource two years ago and was moved with the rest of the code to github. -- /Jacob Carlborg
Re: What can be done to reduce executable size?
Am 12.12.2011, 20:33 Uhr, schrieb Martin Nowak : The symbol table. Probably you also had debug infos for phobos? Possible. By the way if I strip this, my executable is only 292K. 32bits?
Re: D kicks ass.
On 12/12/2011 20:08, Iain Buclaw wrote: Bigger == Better. :o) Biggest rock is best rock. http://www.youtube.com/watch?v=i_APoSfCYwU -- Robert http://octarineparrot.com/
Re: Why D const is annoying
On Monday, December 12, 2011 12:13:54 Kai Meyer wrote:
> On 12/10/2011 03:52 AM, Timon Gehr wrote:
> > On 12/10/2011 11:45 AM, bearophile wrote:
> >> Timon Gehr:
> >>> Just slice the const array to get a range. The specialization for
> >>> ranges does not have the bug.
> >>>
> >>> import std.algorithm;
> >>> void main() {
> >>> const arr = [1, 2, 3];
> >>> reduce!"a*b"(arr[]); // It works.
> >>> }
> >>
> >> Wasn't arr a range already?
> >>
> >> Bye,
> >> bearophile
> >
> > No, popFront is mutating and const(int[]) cannot be mutated.
>
> Seems to me like popFront isn't the right tool for the job.
??? That's how you iterate a range. Without it, a range is essentially
useless. There _is_ no other tool for the job.
Ranges _could_ have been designed more like slists and use head and tail and
avoid needing to be mutated, but that's less efficient, since you have to copy
the range every time that you iterate to the next item.
Generally, the way to solve the issue of a const or immutable range is to get
a tail-const copy of it. With arrays, that's easy - just slice it. With user-
defined ranges, it requires that opSlice be defined that way, which it may or
may not be.
But you can't iterate over a const range anymore than you can iterate over a
const iterator in C++. In both cases, you need a non-const copy if you want to
iterate. There's nothing odd about it really. It's just that templates take
the _exact_ type with IFTI and so don't generally work with const or immutable
ranges. The proposed change to make arrays instantiate templates with their
tail-const type with IFTI will fix that for arrays though.
- Jonathan M Davis
Re: A benchmark, mostly GC
On Monday, December 12, 2011 17:59:54 Manu wrote: > Totally off topic... I have a question. > > If I pass a pointer to a C library... how does the GC know when it's safe > to collect? It assumes that it's safe to collect it. If you pass a pointer to a C library and it keeps it, then you need to make sure that your D code maintains a reference to that data so that the GC doesn't collect it. - Jonathan M Davis
Re: d-programming-language.com
On Monday, December 12, 2011 20:39:11 Manu wrote: > On 12 December 2011 20:09, Hans Uhlig wrote: > > On 12/11/2011 1:26 PM, Peter Alexander wrote: > >> On 11/12/11 1:52 AM, Walter Bright wrote: > >>> On 12/10/2011 4:46 PM, Peter Alexander wrote: > I think either would be fine, but having to use the command line > for > anything on > Windows is a no-no these days in terms of usability. > >>> > >>> Since dmd is a command line tool anyway, why is it a usability > >>> problem > >>> to use dman? > >> > >> Why do you think so many people ask for IDEs? :-) > >> > >> Windows people are used to Visual Studio doing everything for them. > >> Hit > >> F7 to compile, F5 to run under debugger, click on lines to set > >> breakpoints. > > > > That's because cmd sucks. MS Powershell isn't much better. I have to use > > mintty just to be able to have a sane environment. Linux is a very shell > > oriented OS still even with Kde and Gnome. Microsoft did everything in > > its power to kill off the shell for "useability" reasons. > > And they did a great job. Visual Studio is a fantastically productive > coding environment. Having a great GUI and a great shell are not mutually exclusive. - Jonathan M Davis
Re: Fixing const arrays
On Monday, December 12, 2011 17:24:38 Jakob Ovrum wrote: > I'm still a beginner with ranges, but by my understanding and by > what some people made it sound like, reasonable uses of save > include some which are non-trivial. If this is true, then > removing @property from save encourages people to think more > about what using it might mean for the code they are writing, > which is definitely important. Both save and postblit are supposed to be trivial. Algorithms generally assume that copying a range is O(1). There's nothing stopping save and postblit from costing more than that, but it's going to harm performance. - Jonathan M Davis
Re: Fixing const arrays
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote: > Insisting on the current property semantics was a sizeable mistake of > this community, and I am sorry we gave into it. Aside from the fact that the behavior of -property isn't the default, what's the problem with @property? - Jonathan M Davis
Re: Fixing const arrays
On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote: > On 12/12/11 9:09 AM, torhu wrote: > > On 12.12.2011 15:43, Andrei Alexandrescu wrote: > >> On 12/12/11 6:24 AM, torhu wrote: > >>> save being a property is a stupid inconsistency. > >> > >> I'm not so sure. > >> > >> Andrei > > > > Why? As far as I can tell, it's inconsistent with what properties are > > used like in other programming languages. > > Why? > > > Saving something is an action, > > which to me is a different concept. > > So if we called .save .state or .current things would be any different? > > > If it was called currentState > > instead, that's what I'd call a property. > > Ah. So now we're wasting time not on @property (as I'd predicted), but > instead on what _names_ are suitable to work with it. I rest my case. > > > Making something a property gives it certain connotations that break > > when it's called 'save'. That you can save the state of the range is a > > property, if you will. But the action of doing so is not a property. > > People are going to be surprised when save() doesn't compile. Isn't > > there something called the principle of least surprise? > > I think we should only worry about surprising the uninitiated with how > poorly designed the whole @property thing is. A property is essentially an abstraction to treat a function like a member variable. As such, the naming conventions for a property should be equivalent to those for a variable - and that generally means nouns. save is not a noun. It's an action verb. So, yes, I think that it's a completely inappropriate name for a property. Something ilke state or current _would_ be appropriate names. However, at this point, I really don't think that it's worth arguing about. If I were to change it, I'd probably just make save a function rather than renaming it, but if we did it, then there would be quite a bit of code that would have to be changed essentially over an argument over whether save is valid property name because it's not a noun. And while I _don't_ think that it's a valid property name, that's getting a bit petty given how much code would break. I'm all for fixing names for camelcasing, because that really affects the consistency of the library and is almost always completely objective, but this is essentially an argument over the best name for a function, and that never has a clear answer. Yes, it's an issue of consistency on some level with regards to how we treat and name properties, but that's subjective enough that I don't expect us to ever be completely consistent on that. - Jonathan M Davis
Re: Fixing const arrays
On 12/12/11 3:16 PM, Andrei Alexandrescu wrote: On 12/12/11 9:09 AM, torhu wrote: On 12.12.2011 15:43, Andrei Alexandrescu wrote: On 12/12/11 6:24 AM, torhu wrote: save being a property is a stupid inconsistency. I'm not so sure. Andrei Why? As far as I can tell, it's inconsistent with what properties are used like in other programming languages. Why? My understanding is the properties are essentially meant to be indistinguishable from fields (hence the syntax). save() doesn't really act like a field. Honestly though, I don't like properties at all (in any language). Function calls should not be hidden in syntax. IMO if your code contains so many get/set functions that properties save you time then you have bigger issues.
Re: D kicks ass.
On 12 December 2011 18:21, Bane wrote: > Sorry, but it's true. > Compared to C++, it has much friendlier syntax, important built in types and > all the goodies. And let us not forget - big standard library ready to go. > > But it is still rough on the edges, needs polishing and fixing little bugs. > Now it needs tender care to grow big (and lose some weight from executables > :). Bigger == Better. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: If I had my way
Am 12.12.2011 14:56, schrieb Manu: Yes, there are engines which implement /game logic/ using GC based scripts/JIT-ers, but both the ENGINES you mention are still written in C/C++, and have very tight control of the hardware. Given this example, are you suggesting D is a scripting language to sit above some C/C++ app? For me, that's the opposite of what D is. No, because those scripts as you call it, are compiled to native code as well. I see no difference from C/C++ code.
Re: Sitemap
On 12 December 2011 19:52, Andrei Alexandrescu wrote: > I've added a sitemap to the website: > > http://dlang.org/sitemap.html > > I've already removed a bunch of obsolete documents. Feel free to look around > and report bugs for various pages. > > > Thanks, > > Andrei When did it change to dlang.org? That's much easier to remember than d-l-p.org. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Sitemap
On 12/12/11 7:52 PM, Andrei Alexandrescu wrote: I've added a sitemap to the website: http://dlang.org/sitemap.html I've already removed a bunch of obsolete documents. Feel free to look around and report bugs for various pages. Thanks, Andrei Bug: that link is broken. :-)
Sitemap
I've added a sitemap to the website: http://dlang.org/sitemap.html I've already removed a bunch of obsolete documents. Feel free to look around and report bugs for various pages. Thanks, Andrei
Re: If I had my way
On Monday, 12 December 2011 at 13:56:22 UTC, Manu wrote: Yes, there are engines which implement *game logic* using GC based scripts/JIT-ers, but both the ENGINES you mention are still written in C/C++, and have very tight control of the hardware. Given this example, are you suggesting D is a scripting language to sit above some C/C++ app? For me, that's the opposite of what D is. I've thought before how well suited D is for a Unity-style game engine. D's an obvious choice for the engine internals, but why not use it in replacement of game logic "scripts" as well? SafeD is just as easy to understand as C# or Unity's Javascript (relatively). Only you'd get the added benefit of native performance on game logic blocks, which could easily be packaged with the engine for release. For an editor, it should be easy enough to utilize DMD to compile game-logic files into their own temporary executable dynamically (or dynamic library?) which would pass messages to the engine running in-editor.
Re: dfeed/gravatar issue
On 12/12/11 4:53 PM, Vladimir Panteleev wrote: On Monday, 12 December 2011 at 06:15:02 UTC, Nick Sabalausky wrote: Spam filters (much like just about anything Google is big into) are a fundamentally broken approach. From a practical perspective, the hassle of being paranoid about spam is overweighted by the insignificant inconveniences of a good spam filter. Also, not publishing your e-mail address is not fool-proof. Two of the people who have contacted me previously have had their accounts hacked, so I started receiving spam from them (these are the rare false negatives I mentioned). I think it's safe to say that my address was also added to those spammers' general lists. And that's not to mention the occasional technically incompetent person from some organization/event you had contact with that will publish your address on the web for you. In Andrei's particular case, his email is already out there in plain text. I get 85 pages on Google when I search for it in double-quotes, the majority from this newsgroup. My email gets 8780 hits on Google, and I don't think I've seen any spam get through Gmail's filter (I get about 1-2 spam messages in the spam folder a day). Make of that what you will.
Re: What can be done to reduce executable size?
The symbol table.
Probably you also had debug infos for phobos?
By the way if I strip this, my executable is only 292K.
On Sat, 10 Dec 2011 20:16:54 +0100, Trass3r wrote:
import std.stdio;
int main(){
writefln("Hello Bloat!");
return 0;
}
dmd -release -O hello.d
On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb
$ dmd -release -O test.d
867K
$ strip -s test
572K
I don't know where the 300KB come from.
The map files are equal:
dmd -release -O -map test.d
dmd -release -O -L-s -map test.d
This is what Hello World looks like on x64 Linux:
http://thecybershadow.net/d/mapview/view.php?id=4ee3af86c32f2
Re: If I had my way
F i L: > and I look forward to I'm sure is a bright future for the language. http://www.youtube.com/watch?v=meRgT5Nmogw Yeah yeah yeah, bearophile
Re: Why D const is annoying
On 12/10/2011 03:52 AM, Timon Gehr wrote:
On 12/10/2011 11:45 AM, bearophile wrote:
Timon Gehr:
Just slice the const array to get a range. The specialization for ranges
does not have the bug.
import std.algorithm;
void main() {
const arr = [1, 2, 3];
reduce!"a*b"(arr[]); // It works.
}
Wasn't arr a range already?
Bye,
bearophile
No, popFront is mutating and const(int[]) cannot be mutated.
Seems to me like popFront isn't the right tool for the job.
Re: .dmg installer for OSX?
On 12/11/2011 8:15 PM, Michel Fortin wrote: How is it installed on Linux? Hello, dmd deb packages from http://www.digitalmars.com/d/download.html installs files as follow: - binaries at "/usr/bin" - modules at "/usr/include/d/dmd" - libraries on 32 bit system "/usr/bin", "/usr/bin64" and "/usr/lib32" symlink to "/usr/bin" - libraries on 64 bit system "/usr/bin32", "/usr/bin" and "/usr/lib64" symlink to "/usr/bin" - dmd configuration file as "/etc/dmd.conf" - html and samples folders at "/usr/share/dmd" - commands man pages at "/usr/share/man/man1" - dmd.conf man page at "/usr/share/man/man5" This try to follow the debian rules as you can see here: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRBINMOSTUSERCOMMANDS You can't have both dmd1 and dmd2 installed together. To have multiple dmd versions installed in a single system, there is a nice project that does: https://bitbucket.org/doob/dvm Best regards, -- Jordi Sayol
relax inout rules?
Currently, the rules of inout say you cannot put inout on a parameter
without putting it on the return type as well. This makes sense, it gives
the compiler one place to worry about whether implicit casting rules will
properly work.
But Timon Gehr brought up in another thread (started by Merdhad) that we
can separate the resolution of inout from the applicability of the
parameters. Essentially, calling an inout function goes through two
phases:
1. determine what inout resolves to
2. try and call the function.
inout rules don't have to change regarding resolving inout's actual
value. In other words, if all inout places are matched as int, immutable,
or inout, then inout resolves to that value. Otherwise inout resolves to
const.
But what's different is (at least in my mind) the function call might not
necessarily succeed even when the resolution is completed.
Take for example:
inout(int)* foo(inout(int)** a, inout(int)* b);
Now, if we call foo like this:
int a;
int b;
int* pa = &a;
foo(&pa, &b);
This means foo is called with (int **, int *). This means inout resolves
to mutable (no qualifier). *NOW* we try calling foo as if it were written:
int *foo(int **a, int *b)
And it can be done. Not only that, but there is nothing bad that could be
happening in foo that should be disallowed by the compiler.
Now let's see what happens were we *could* do something bad:
immutable(int) c;
auto pc = &c;
foo(&pc, &b);
Now, foo is being called with (immutable(int)**, int *). Inout resolves
to const (due to the mix of mutable and immutable). *NOW* we try calling
foo as if it were written:
const(int)* foo(const(int)** a, const(int)* b);
And it *FAILS*. This is because you cannot implicitly convert
immutable(int)** to const(int)** (well, at least it *shouldn't* compile,
I'm not sure if it does currently).
What this does is allow more possibilities for inout than we currently
do. Because inout is not now tied to returning something, we can create
functions that have inout parameters but no inout return value.
The example we were discussing on the other thread was this:
void foo(ref inout(int)* a, inout(int)* b) { a = b;}
This would compile as long as you call with const(int)* as the first
parameter, or if both parameters matched in constancy (i.e. both were
immutable, both were mutable, or both were inout).
This gives us more cases where you don't have to repeat functions for the
sake of handling different types of constancy, particularly when we have
mutable references 2 levels deep. I can't see anything technically wrong
with this, can anyone else?
The one thing that I think still should be required is if you have inout
on the return value, there *must* be an inout on a parameter. Otherwise,
the compiler has no idea what it should be (since we don't overload on
return type in D).
If this ends up being viable, this is actually easier to explain than the
current rules for inout. We just have to make sure the rules are sound
before doing something like this.
-Steve
Re: d-programming-language.com
On Monday, 12 December 2011 at 18:43:43 UTC, Hans Uhlig wrote: Actually it might be nice instead of ddoc creating HTML if it created an intermediate XML or JSON format of documentation that could be transformed via XSLT+CSS into the final product be it html, chm, manpages etc. The macro system lets you do that pretty well already (my program just treats the html as xml basically anyway). dmd -X also includes the documentation comments in the json it generates for each item. Though, this is unparsed doc comments so it's not as useful as the html you output.
Re: If I had my way
On Saturday, 10 December 2011 at 19:23:02 UTC, Andrei Alexandrescu wrote: Sure, we can label Mehrdad as a whiny baby, but I suspect his experience is representative for the out-of-the-box experience of many others: they see D's cool features, they download the compiler to try it out on their own terms, and as soon as they deviate from what is tried and works, or they combine features in an unusual yet meaningful manner, it all comes unglued. As a new member myself, I can testify to this. After stumbling upon D (via TIOBE top 20) I was very excited to find an open-source language with a focus on productivity AND efficiency. I bought TDPL book and dove in. However, I sunk a bit when I realized some features listed in the book where either missing or broken. My biggest disappointment was(/is) with the lack of the alleged Pseudo Methods (section 5.9.1). It's one thing to play around with a language you understand is growing and under development. It's another to boast about the language to your co-workers, only to receive unexpected errors when they ask for demonstrations :/ Bad for publicity, that. With that said, I think 2.057 should be released soon, and major bug resolution should be a focus of 2.058. Beyond bugs and missing features, D's weakest area with many of my co-workers, and with myself, is it's platform support. The company I work for chose C#/WPF as foundations of a major product a few years ago and now we are paying for that choice with so much of the market focused on cross-platform, web, and mobile platforms. Mac OSX x86_64 support is very needed in D and I hope Window x86_64 and ARM support will be the major focus going forward. D's ambitions far exceed other languages I've come across and I look forward to I'm sure is a bright future for the language. -Philip
Re: d-programming-language.com
On 12/10/2011 9:52 PM, Adam D. Ruppe wrote: Jonathan M Davis Wrote: In fact, as much of the documentation- generation as possible should be in ddoc IMHO. That way, anyone can get reasonable documentation for their own projects. I agree to an extent, but at the same time, I like keeping ddoc itself fairly simple. Correct anchors from ddoc are a no-brainer, it definitely should be doing that. I'd also like for it to mark off any D names it sees, so we can link them right into a search engine or something to do automatic cross referencing. (I want to add this to my program too, but regardless, the compiler would do a much better job at it than a regular expression or whatever I can do with the text.) I'm still meaning to revamp the compiler's default set of macros too, when I get around to it. But, I'm mixed on things like tables of contents. On one hand, it's definitely a useful thing to have, but on the other, how much can ddoc do without getting a lot more complicated? I'd hate to add a bunch of special cases in there, or worse yet, a whole bloody scripting language, to cover everyone's use-case. If we do tables, what's next? Though a nice content listing probably *is* worth it... Keeping ddoc simple and running the generated document through an additional program gives you all the flexibility of D - or whatever - without adding to the compiler. If you take a look at my program: http://arsdnet.net/d-web-site/improveddoc.d you can see that it isn't terribly complex, but part of that is that it uses my html dom library and std.algorithm to help out; of we replicated that inside the compiler it might be a lot messier. Actually it might be nice instead of ddoc creating HTML if it created an intermediate XML or JSON format of documentation that could be transformed via XSLT+CSS into the final product be it html, chm, manpages etc.
Re: d-programming-language.com
On 12 December 2011 20:09, Hans Uhlig wrote: > On 12/11/2011 1:26 PM, Peter Alexander wrote: > >> On 11/12/11 1:52 AM, Walter Bright wrote: >> >>> On 12/10/2011 4:46 PM, Peter Alexander wrote: >>> I think either would be fine, but having to use the command line for anything on Windows is a no-no these days in terms of usability. >>> >>> Since dmd is a command line tool anyway, why is it a usability problem >>> to use dman? >>> >> >> Why do you think so many people ask for IDEs? :-) >> >> Windows people are used to Visual Studio doing everything for them. Hit >> F7 to compile, F5 to run under debugger, click on lines to set >> breakpoints. >> >> > That's because cmd sucks. MS Powershell isn't much better. I have to use > mintty just to be able to have a sane environment. Linux is a very shell > oriented OS still even with Kde and Gnome. Microsoft did everything in its > power to kill off the shell for "useability" reasons. > And they did a great job. Visual Studio is a fantastically productive coding environment.
Re: Why D const is annoying
On Mon, 12 Dec 2011 12:49:11 -0500, Timon Gehr wrote:
On 12/12/2011 05:46 PM, Steven Schveighoffer wrote:
I still am uneasy with
allowing applying a wildcard to a reference underneath to mutable
references. I know it doesn't work for const.
There is nothing being applied, inout is just matched. After the
matching, inout vanishes (it is replaced by nothing, const or immutable)
and if that _inout-free_ parameter list still typechecks with the
arguments, then it can be invoked. It is simply a case of parametric
polymorphism.
void good(ref inout(int)* a, ref inout(int)* b);
is simultaneously these three functions: (duplicating the code that way
is the poor man's inout)
void good(ref int* a, ref int* b){ a = b; }
void good(ref immutable(int)* a, ref immutable(int)* b){ a = b; }
void good(ref const(int)* a, ref const(int)* b){ a = b; }
None of these applies any type modifier at any level.
It suffices if any of those three typechecks for the call to the
polymorphic one to succeed safely. (because the body of 'good' treats
its arguments like const).
This is a great way to think about inout in general:
1. all inout parmeters are matched against int, immutable, and inout. If
all of them match that qualifier, then that qualifier is substituted for
inout.
2. If 1. does not match any of those, const substituted for inout.
3. Normal function call rules apply. That is, just because a match is
found doesn't mean the function can be called (as you have demonstrated).
4. Anything that is inout inside a function is treated the same as it is
now (similarly to immutable, except for const(inout(...)) ).
I always thought of inout as being something performed by the compiler,
while calling the function. But it's almost just a way to repaint the
parameters/return type of an existing function before applying normal
function call rules.
I'm cautiously optimistic about this. I want to see what Kenji thinks, at
this point he probably understands inout better than me. I think actually
his first patch did not require inout on the return type, and I insisted
it was required, that might have been a mistake to do that (removing this
requirement indirectly fixes 6809 as well).
-Steve
D kicks ass.
Sorry, but it's true. Compared to C++, it has much friendlier syntax, important built in types and all the goodies. And let us not forget - big standard library ready to go. But it is still rough on the edges, needs polishing and fixing little bugs. Now it needs tender care to grow big (and lose some weight from executables :).
Re: d-programming-language.com
On 12/11/2011 1:26 PM, Peter Alexander wrote: On 11/12/11 1:52 AM, Walter Bright wrote: On 12/10/2011 4:46 PM, Peter Alexander wrote: I think either would be fine, but having to use the command line for anything on Windows is a no-no these days in terms of usability. Since dmd is a command line tool anyway, why is it a usability problem to use dman? Why do you think so many people ask for IDEs? :-) Windows people are used to Visual Studio doing everything for them. Hit F7 to compile, F5 to run under debugger, click on lines to set breakpoints. That's because cmd sucks. MS Powershell isn't much better. I have to use mintty just to be able to have a sane environment. Linux is a very shell oriented OS still even with Kde and Gnome. Microsoft did everything in its power to kill off the shell for "useability" reasons.
Re: Why D const is annoying
On 12/12/2011 05:46 PM, Steven Schveighoffer wrote:
On Mon, 12 Dec 2011 10:21:35 -0500, Timon Gehr wrote:
On 12/12/2011 04:08 PM, Timon Gehr wrote:
On 12/12/2011 03:46 PM, Timon Gehr wrote:
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or
e.g.
here, a
matrix)? Copy/paste the code for const- and non-const versions?
Internal to a function, inout behaves like 'const'. You won't be
able to
modify the data. Therefore, if there is no inout in the return type,
use
'const' in the parameter list instead.
The purpose of inout is to transmit the 'constness' of the function
argument type to the return type, using only one implementation of
that
function. That requires the function to internally regard inout as
const.
But what about:
void f(ref inout(int)* a, inout(int)* b) { a = b; }
This cant work with const because that would violate the const
system.
I think the rule should be that either the return type must be inout
or at least one ref/out parameter.
Am I overlooking something?
That was brought up during discussion on adding the feature. One of
the
reasons inout is viable is because a) the source and result of
where the
constancy flows is well defined and b) the exit point is an rvalue
Allowing ref parameters fails both those rules.
Consider this:
void bad(ref inout(int)* a, ref inout(int)* b);
which is the entry and which is the exit? Is a set to b, or b set
to a?
Now, also consider that you can't affect the constancy of the result,
because the type of the parameter is already defined. e.g.:
// note that your example shouldn't even be valid, because you can't
implicitly cast through two mutable references
int a;
auto pa = &a;
immutable int b;
auto pb = &b;
f(a, b);
How can this affect a? its type is already decided. Compare that to:
inout(int)* g(inout(int)* b) { return b;}
auto pa = g(pb);
clean and simple.
-Steve
This currently compiles:
inout(void) very_bad(ref inout(int)* a, ref inout(int)* b){a = b;}
void main(){
immutable int a=2;
int *x;
immutable(int)* y=&a;
very_bad(x,y);
*x=1;
assert(*y==a); // fail
}
How does the design catch this error? Will inout** = inout**
assignments
be disallowed?
Probably it is better to catch it at the call site. But if that is
implemented then the requirement to have inout on the return value gets
nonsensical.
OK, got it.
What you call 'bad' should compile:
void bad(ref inout(int)* a, ref inout(int)* b);
int* x;
immutable(int)* y;
const(int)* z;
bad(x,x); // fine
bad(y,y); // fine
bad(z,z); // fine
bad(x,y); // inout is deduced to const, ergo neither x nor y convert
to the parameter type -> compile error
bad(x,z); // now only error for x
...
The requirement of having inout on the return type should be removed
for more expressiveness.
I've thought about this for a few minutes, and I can't find a flaw in
it. But I'm not seeing a huge benefit to it either. Why is it
advantageous to use a ref parameter for something that should be a
return? Can you show a good use case for this?
For anything that is both input and output, for example:
void swap(T)(ref inout(T)[] x, ref inout(T)[] y);
void apply(T)(inout(T)[] delegate(inout(T)[]) dg, ref inout(T)[] arg);
I think it should be a no-brainer, all that is needed is to remove the
check if inout is present on the return type. Every other part of the
type checking is identical to when it is there (this is shown by the
fact that qualifying void with inout makes the examples compile.)
I still am uneasy with
allowing applying a wildcard to a reference underneath to mutable
references. I know it doesn't work for const.
-Steve
There is nothing being applied, inout is just matched. After the
matching, inout vanishes (it is replaced by nothing, const or immutable)
and if that _inout-free_ parameter list still typechecks with the
arguments, then it can be invoked. It is simply a case of parametric
polymorphism.
void good(ref inout(int)* a, ref inout(int)* b);
is simultaneously these three functions: (duplicating the code that way
is the poor man's inout)
void good(ref int* a, ref int* b){ a = b; }
void good(ref immutable(int)* a, ref immutable(int)* b){ a = b; }
void good(ref const(int)* a, ref const(int)* b){ a = b; }
None of these applies any type modifier at any level.
It suffices if any of those three typechecks for the call to the
polymorphic one to succeed safely. (because the body of 'good' treats
its arguments like const).
Re: Some standard protocols in Phobos
On Mon, 12 Dec 2011 13:55:53 +0100, bearophile wrote: I think it will eventually become important to have some standard protocols in Phobos, like one for images like this: http://www.python.org/dev/peps/pep-0368/ Do you like? and similar ones for: - matrices - basic 2D pixel-oriented graphics. - basic database usage These would be nice, but are by no means a necessity.
Re: .dmg installer for OSX?
On Mon, 2011-12-12 at 08:57 -0600, Andrei Alexandrescu wrote: [...] > Totally agreed. In fact I myself don't have MacPorts installed. > Furthermore, I've had some trouble installing it and gave up. Now > whenever I see a MacPorts-installable program I'm curious about, I just > move on. Conversely, I install MacPorts and only use Apple stuff or MacPorts stuff -- if I use the MacBook ever of course. The only thing I install from a dmg is MacPorts. Oh and MacTeX. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: d-programming-language.com
On Monday, 12 December 2011 at 06:57:52 UTC, Walter Bright wrote: On 12/11/2011 9:46 PM, Vladimir Panteleev wrote: Yes, that was what I was going to do. However, the layout of files generated for d-programming-language.org differs substantially from those included in the zip file, so I'm asking if there's a way to avoid having to modify chmgen to work with the d-p-l.org version. You could add a parameter to chmgen to tell it where the files are. Certainly, but that goes against the idea of a chm makefile target. Anyway, it's probably worth doing the work of using the d-p-l.org files. I could use the opportunity to move some of the hacks out of chmgen into the docs as proper fixes.
Re: If I had my way
On Mon, 12 Dec 2011 10:00:28 -0500, Timon Gehr wrote: On 12/12/2011 03:00 PM, Steven Schveighoffer wrote: On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr wrote: On 12/11/2011 10:12 PM, Timon Gehr wrote: On 12/11/2011 06:49 PM, Paulo Pinto wrote: Am 11.12.2011 17:40, schrieb so: On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto wrote: Really? Tell that to all game studios developing games in Java/C#/Flash. Do you know that many games in iPhone are done in Unity, which makes use of C#/Boo/Javascript compiled to native code? I don't understand sorry, are you arguing against the argument i made on GCs failure on some specific areas? Yes I am, since I know many areas where GC enabled languages have been replacing non-GC languages for better or worse. But then again, I am only a lurker here, so take my arguments with a grain of salt. As a non user of D, I cannot really say much. GC does not scale if an application has to be responsive. In all other cases it is a valid choice. (if you have enough spare memory) Don't confuse druntime's GC with the concept of a GC. Better implemented GCs work quite well in practice, even for making responsive apps. I certainly don't confuse them (GC wouldn't be very interesting if the two were the same), and as I understand it there exist very few GC implementations that _guarantee_ responsiveness over a long time period. This effect gets a lot bigger as memory usage and reference mutation rate grow. It is very easy for a sufficiently big Java application, for instance, to get responsiveness problems. Oh, I've seen it first hand, I use netbeans. But I'm not sure it's due to the GC, and not due to it requiring 2x or more memory than an equivalent manually managed application requires. I honestly don't konw. Generally bad things happen when memory gets low, no matter what the memory management system or language. -Steve
Re: dfeed/gravatar issue
On Monday, 12 December 2011 at 06:15:02 UTC, Nick Sabalausky wrote: Spam filters (much like just about anything Google is big into) are a fundamentally broken approach. From a practical perspective, the hassle of being paranoid about spam is overweighted by the insignificant inconveniences of a good spam filter. Also, not publishing your e-mail address is not fool-proof. Two of the people who have contacted me previously have had their accounts hacked, so I started receiving spam from them (these are the rare false negatives I mentioned). I think it's safe to say that my address was also added to those spammers' general lists. And that's not to mention the occasional technically incompetent person from some organization/event you had contact with that will publish your address on the web for you. I actually use Gravitar and I'm convinced it's really not that great of a site in the first place. The whole approach is all wrong. How is it wrong and how would you make it better? The idea is great for average netizens.
Re: Why D const is annoying
On Mon, 12 Dec 2011 10:21:35 -0500, Timon Gehr wrote:
On 12/12/2011 04:08 PM, Timon Gehr wrote:
On 12/12/2011 03:46 PM, Timon Gehr wrote:
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or
e.g.
here, a
matrix)? Copy/paste the code for const- and non-const versions?
Internal to a function, inout behaves like 'const'. You won't be
able to
modify the data. Therefore, if there is no inout in the return type,
use
'const' in the parameter list instead.
The purpose of inout is to transmit the 'constness' of the function
argument type to the return type, using only one implementation of
that
function. That requires the function to internally regard inout as
const.
But what about:
void f(ref inout(int)* a, inout(int)* b) { a = b; }
This cant work with const because that would violate the const
system.
I think the rule should be that either the return type must be inout
or at least one ref/out parameter.
Am I overlooking something?
That was brought up during discussion on adding the feature. One of
the
reasons inout is viable is because a) the source and result of where
the
constancy flows is well defined and b) the exit point is an rvalue
Allowing ref parameters fails both those rules.
Consider this:
void bad(ref inout(int)* a, ref inout(int)* b);
which is the entry and which is the exit? Is a set to b, or b set to
a?
Now, also consider that you can't affect the constancy of the result,
because the type of the parameter is already defined. e.g.:
// note that your example shouldn't even be valid, because you can't
implicitly cast through two mutable references
int a;
auto pa = &a;
immutable int b;
auto pb = &b;
f(a, b);
How can this affect a? its type is already decided. Compare that to:
inout(int)* g(inout(int)* b) { return b;}
auto pa = g(pb);
clean and simple.
-Steve
This currently compiles:
inout(void) very_bad(ref inout(int)* a, ref inout(int)* b){a = b;}
void main(){
immutable int a=2;
int *x;
immutable(int)* y=&a;
very_bad(x,y);
*x=1;
assert(*y==a); // fail
}
How does the design catch this error? Will inout** = inout**
assignments
be disallowed?
Probably it is better to catch it at the call site. But if that is
implemented then the requirement to have inout on the return value gets
nonsensical.
OK, got it.
What you call 'bad' should compile:
void bad(ref inout(int)* a, ref inout(int)* b);
int* x;
immutable(int)* y;
const(int)* z;
bad(x,x); // fine
bad(y,y); // fine
bad(z,z); // fine
bad(x,y); // inout is deduced to const, ergo neither x nor y convert to
the parameter type -> compile error
bad(x,z); // now only error for x
...
The requirement of having inout on the return type should be removed for
more expressiveness.
I've thought about this for a few minutes, and I can't find a flaw in it.
But I'm not seeing a huge benefit to it either. Why is it advantageous to
use a ref parameter for something that should be a return? Can you show a
good use case for this? I still am uneasy with allowing applying a
wildcard to a reference underneath to mutable references. I know it
doesn't work for const.
-Steve
Re: Fixing const arrays
On Monday, 12 December 2011 at 16:09:03 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:29 AM, Jakob Ovrum wrote: On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:07 AM, Jakob Ovrum wrote: If the programmer sees just "r.save", he doesn't know whether it's a field or a property, and he shouldn't need to know, it should be fast and cheap, and return a consistent value. As far as I know, this isn't always true for save Why? Save does behave like a field for the vast majority of structs. Andrei But save is an abstract interface function, its signature should reflect all possible implementations. Same goes for many properties. Andrei This is true, and many functions marked @property arguably shouldn't be. I think it's a little like the reason std.container.SList doesn't have a `length` property: the O(n) complexity doesn't match the interface `length` exposes (although formalised only in documentation/convention, not code). If the standard library is allowed to assume `r.save` is a cheap operation, in the same fashion it's allowed to assume this(this) is cheap, then by all means, it makes sense as a property. The only remaining arguments against it are purely about the name, and I actually don't think that's relevant. And just like you can still make a computationally expensive this(this) when absolutely necessary, you can do the same with save. If most reasonable uses of save have trivial performance, it might as well be a property. I'm still a beginner with ranges, but by my understanding and by what some people made it sound like, reasonable uses of save include some which are non-trivial. If this is true, then removing @property from save encourages people to think more about what using it might mean for the code they are writing, which is definitely important.
Re: .dmg installer for OSX?
On 12/12/11 9:44 AM, Jacob Carlborg wrote: On 2011-12-12 15:59, Andrei Alexandrescu wrote: Would you consider authoring a pull request for D-Programming-Language/Installer? The installer is already THERE and it's still working (I just tried it on DMD 1.072). I understand. The thing is, if we use your installer we'll have our pipeline depend on an external project. If we get your code into D-Programming-Language/Installer then we own the code, can make adjustments to it, etc. Please advise. Thanks, Andrei
Re: A benchmark, mostly GC
On Monday, 12 December 2011 at 16:00:04 UTC, Manu wrote: Totally off topic... I have a question. If I pass a pointer to a C library... how does the GC know when it's safe to collect? It doesn't, you should add it to the GC with GC.addRoot or GC.addRange unless you're absolutely sure the pointer is never taken off the stack (the call stack is shared between the C and D code). Once you're sure the memory is no longer referenced on the C heap, you can remove the root or range with GC.removeRoot and GC.removeRange.
Re: Fixing const arrays
On 12/12/11 9:29 AM, Jakob Ovrum wrote: On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:07 AM, Jakob Ovrum wrote: If the programmer sees just "r.save", he doesn't know whether it's a field or a property, and he shouldn't need to know, it should be fast and cheap, and return a consistent value. As far as I know, this isn't always true for save Why? Save does behave like a field for the vast majority of structs. Andrei But save is an abstract interface function, its signature should reflect all possible implementations. Same goes for many properties. Andrei
Re: A benchmark, mostly GC
On 12 December 2011 17:44, Timon Gehr wrote: > On 12/12/2011 04:17 PM, Robert Jacques wrote: > >> On Mon, 12 Dec 2011 01:06:14 -0500, Brad Anderson wrote: >> >> On Sun, Dec 11, 2011 at 10:55 PM, Robert Jacques >>> wrote: >>> Second, being a systems language means that D can not implement a lot of >>> GC algorithms including copying, generational and the good concurrent >>> collectors. >>> >>> What about being a systems language prevents generational? The page on >>> garbage collection on the D website says while it doesn't use a >>> generational GC it will some day and gives tips on what to avoid so you >>> don't fall victim to the behavior of a moving GC. >>> >> >> Regarding moving collectors. >> D supports semi-precise collection. Therefore D can support some types >> of moving collectors, i.e. compactors, which is what the website is >> talking about. Copying collectors, on the other hand, require full >> precision to work; you must be able to fully evacuate a region of >> memory. D doesn't support full precision, for a couple of performance >> (unions, >> > > The compiler could insert small code fragments that track whether or not > an union contains a pointer. > > the call stack, >> > > What is the problem with the call stack? Can't the compiler just generate > reference offset information for all the function frames and then the GC > generates a backtrace to identify the references? > > C/C++ interop) >> > > There should be multiple options for GC. If C/C++ interop is unimportant, > a better GC that does not support it well is still handy. > > > and technical reasons (the inline >> assembler). >> > > inline assembler does not always move around GC heap references. I think > that in the cases it does, reference stores could be annotated manually. > > >> Regarding generational collectors. >> Both generational and concurrent collectors require that every pointer >> assignment is known to the compiler, which then instruments the >> assignment to flag mark bits, etc. For generational collectors, you need >> this information to know which objects/memory pages to search for roots >> into the young generation. Without this information, you have to search >> the entire heap, i.e. do a full collection. Again, both performance and >> technical reasons come into play here. Instrumentation represents a >> performance cost, which even if it pays for itself, looks bad in >> newsgroups posting. Indeed, concurrent collectors are mostly about >> trading throughput for latency. So, like JAVA, you'd want to use version >> statements to select your GC style, but you'd also have to make sure >> your entire codebase was compiled with the same flags; with 3rd party >> DLLs and objects, this can become non-trivial. From a technical >> perspective, complete pointer assignment instrumentation is a >> non-starter because the D compiler doesn't have complete access to all >> >> the code; both C/C++ and assembler code can modify pointers and are not >> subject to instrumentation. Now, if we supported C/C++ through >> marshaling, like JAVA and C# do, and made the assembler a bit more smart >> or required manual pointer instrumentation of asm code, we could use >> these types of collectors. >> >> * Note that the above doesn't take into account the types of virtual >> memory tricks C4 can do, which may open these algorithms up to D and >> other system programming languages. >> > > I think we'll definitely need a generational/concurrent collector > eventually. Could some of the problems be worked around by having more than > one GC implementation in the same executable? > Totally off topic... I have a question. If I pass a pointer to a C library... how does the GC know when it's safe to collect?
Re: Fixing const arrays
On 12.12.2011 16:16, Andrei Alexandrescu wrote: On 12/12/11 9:09 AM, torhu wrote: On 12.12.2011 15:43, Andrei Alexandrescu wrote: On 12/12/11 6:24 AM, torhu wrote: save being a property is a stupid inconsistency. I'm not so sure. Andrei Why? As far as I can tell, it's inconsistent with what properties are used like in other programming languages. Why? Saving something is an action, which to me is a different concept. So if we called .save .state or .current things would be any different? Yes, completely. The whole property concept is basically a naming convention. Except that parentheses are now involved. x = obj.foo(); // do the foo thing, then return something x = obj.bar; // get bar obj.bar = 42; // set bar x = obj.save; // get save... hm, that doesn't sound right If it was called currentState instead, that's what I'd call a property. Ah. So now we're wasting time not on @property (as I'd predicted), but instead on what _names_ are suitable to work with it. I rest my case. Making something a property gives it certain connotations that break when it's called 'save'. That you can save the state of the range is a property, if you will. But the action of doing so is not a property. People are going to be surprised when save() doesn't compile. Isn't there something called the principle of least surprise? I think we should only worry about surprising the uninitiated with how poorly designed the whole @property thing is. I'm not trying to defend @property, I think it adds about as much pain as it does gain. But it's there, and your ranges are using it :)
