Re: [OT] Region-Based Storage Management: ParaSailing without a (Garbage) Chute
Paulo Pinto: A presentation about the ParaSail, system programming language based on Ada. https://air.mozilla.org/region-based-storage-management-parasailing-without-a-garbage-chute/ Seems interesting, almost 90 minutes of talk. Do you know if there is a link to download the slides? It makes use of regions and compiler inference to automatically manage memory, instead of using a GC. It sounds similar to what Rust does. Maybe some ideas for D types with custom allocators. To manage the regions Rust uses specific features of the type system (and a specific built-in syntax to parametrize types according to their region with a T/region syntax). Bye, bearophile
Mono-D v0.4.9.9 Bug fixes
Hi everyone, Just released another bunch of bug fixes solved issues http://mono-d.alexanderbothe.com/?p=840 May I ask you how long you have to wait for phobos stuff to pop up in the completion list after you launched Mono-D? I've just installed a non-virtual Mint and had to experience wait very long until stuff like std showed up.. but here on my Windows machine, it just takes ~3 seconds to parse everything + UFCS preparation, so at least as half as long as it takes on the Linux installation..wth? I've compiled all the stuff manually to check where some fundamental reasons are located for this - it ran faster (but still not fast enough) after I disabled multi-threading! Whereas on Windows, I actually established a multi-threaded environment for all the analysis tasks!? -- Mad stuff. What's really interesting is that it takes about 170-200 ms to parse std.datetime on both platforms - so not really different at all. Again, mad stuff. Anyway I've always thought everything would be fine with the analysis performance - even on my small Netbook rig from 2011 that is driven by a tiny 1.66 GHz Atom CPU with Win7 on it only takes 5 seconds for everything - even less than Mono takes for parsing phobos with 2(!) threads.. Still troubleshooting so far.. Oh, and please keep reporting issues - just raging silently and immediately uninstalling the addin isn't making it better at all! https://github.com/aBothe/Mono-D/issues
Re: Mono-D v0.4.9.9 Bug fixes
On Monday, 11 February 2013 at 03:18:41 UTC, F i L wrote: Yeah it takes probably 20-40 seconds on my Phenom II X4 920 (Arch Linux 64). Haven't MonoD on Windows (or Mac) in awhile, so I haven't noticed any difference. I think MonoDevelop on Windows actually uses MS .NET (not Mono).. could be wrong about that, but if it's true, that could be the reason for the slow down (Mono is much slower than MS .Net). Thanks for the update! I've got to step deeper into this, I guess. Parsing phobos druntime ufcs args in MonoDevelop took 1.8 seconds, a last test in D-IDE resulted in 1.7 seconds..awkwardly strange!
win64 vararg bug?
I have this small test program, it will crash when compiled on x64
windows, but it works fine on 32bit windows. What am I doing wrong?
import core.vararg;
import std.stdio;
void print(string fmt, ...)
{
auto arg = va_arg!(const(char)[])(_argptr);
writefln(fmt ~ arg);
}
void main(string[] args)
{
print(+++,---);
}
Kind Regards
Benjamin Thaut
--
Kind Regards
Benjamin Thaut
Re: Possible regression (2.060 - 2.061) with member access
On Saturday, 9 February 2013 at 22:54:09 UTC, Jacob Carlborg wrote: On 2013-02-09 21:51, Nick Sabalausky wrote: I think that's asking for confusion to have different visibility rules inside and outside typeof(). The typical way to access private members when really needed is via a reflection mechanism, and we already have a way to do that as two people have mentioned. Couldn't typeof() be considered part of a reflection mechanism? May be, but definitely not an advanced librar'ish one - contrary to .tupleof and some __traits is is a pretty common guest in user code.
Re: Possible regression (2.060 - 2.061) with member access
Am 10.02.2013 11:21, schrieb Dicebot: On Saturday, 9 February 2013 at 22:54:09 UTC, Jacob Carlborg wrote: On 2013-02-09 21:51, Nick Sabalausky wrote: I think that's asking for confusion to have different visibility rules inside and outside typeof(). The typical way to access private members when really needed is via a reflection mechanism, and we already have a way to do that as two people have mentioned. Couldn't typeof() be considered part of a reflection mechanism? May be, but definitely not an advanced librar'ish one - contrary to .tupleof and some __traits is is a pretty common guest in user code. Really? I'm using typeof all over the place in my user code.
Re: DIP26: properties defined
// this is a property
int foo() {...}
It is, if you consider properties to be functions that can be called
without parentheses. Which is quite a lame definition of property if you
ask me.
But yeah my proposal makes properties to be considered functions, just
with some guarantees regarding encapsulation and the special syntax that
prop=a;
means: prop(a);
Actually Michel Fortin summarizes the DIP quite to the point:
So in short, this proposal is that @property does only two things
when
applied to a function: it enables the setter syntax and it changes
the
overload rules.
In addition it restricts the setter syntax (prop=a) to be interpreted in
a non UFCS way, meaning there will be no setter methods with two
parameters. (Not accounting for the implicit this parameter)
Re: DIP26 updated
On Saturday, February 09, 2013 13:50:18 Robert wrote: I added sections - Upgrade path - Conclusion to better prove my point and the concept as such. I can unequivocally say that I think that this DIP is a horrible idea. While it may need some work, DIP 23 is worlds better. I definitely think that @property should be implemented as originally intended save for the unfortunate fact that we have to keep parenless function calls around. And this DIP definitely isn't going in that direction at all. I'm completely against anything which would involve not having @property on front, and I think that it's a complete disaster to try and disallow UFCS properties. - Jonathan M Davis
Re: Possible regression (2.060 - 2.061) with member access
On Sunday, 10 February 2013 at 10:22:59 UTC, Benjamin Thaut wrote: Really? I'm using typeof all over the place in my user code. That is exactly what I have just said :) And reason why it should behave according to usual protection attribute rules.
Re: DIP26: properties defined
You must be able to rely on front always being used without parens, and you must be able to rely on front() doing a call on the return value rather than simply calling front. Why? Think about it, this thinking comes from the fact that it was considered to be a good idea that front could be anything including a field or even an enum. The question is why would we want to allow this in the first place. It is never used in the standard library, it breaks encapsulation and every field or enum can easily be turned into a trivial function. Maybe you are still referring to an early version of the DIP where I put there a sentence, (with a bad feeling already) that properties must not be called with (). I fixed this very bad mistake very soon afterwards, maybe you want to have another look?
Re: DIP26: properties defined
On Fri, 2013-02-08 at 22:00 -0800, Jonathan M Davis wrote: It would be simple enough to make it so that the compiler used auto ref in the lowered version and just make the variable itself int, though the DIP obviously doesn't say that. That would be impossible for virtual functions in a class. What the compiler could do, is simply provide both. This has to be thought through, what is important is that it is very clear what the compiler produces. As properties are meant to be assigned (which implies a copy at some point), you usually try to keep them small anyway or making them a class so that you only have to assign a reference. So I think it is not a bad choice to have the compiler simply generate the most simple trivial form, taking the argument by value. If you really want something different in some special application, you may still provide the functions on your own. Having said that, I really don't mind having the compiler produce both, if people think this is a good idea.
Re: Taking address of properties
Ok, at the very first I have to make clear that my DIP is about changing
the actual specification, not trying to make the implementation to match
the specification, because in my view of things, the specification is
the problem.
Properties in my proposal are no longer about optional parentheses ore
forbidden parentheses. Properties are a concept hat benefits from the
fact, that parentheses are optional, but would work either way.
Reducing properties to functions with no parentheses is just not getting
it right as we can see with the problems we have.
In the grand scheme of things, the fact that a range's front accessor is a
property or a function is not technically important. But front being a
property IS important for specific uses. You can't have it so that front
is a function only when using it as a range, and a property when using it
as a delegate getter.
In my DIP a property is a function and they behave the same, except that
prop=5; calls prop(5); if prop is a property.
In fact, the only case where a properly-implemented @property would be
required on a getter is for delegate properties. I would argue that if
@property worked correctly, it would be possible and correct to require
r.front to be a property in that template.
I don't understand, what is the exact problem with: r.front()()? Despite
not matching the specification regarding no parentheses for properties?
The problem is, isInputRange does not require that it is a function, but
you ARE requiring that by specifying arbitrary rules.
I think this has to be fixed, because it solves all ambiguities and
encourages good design.
Imagine an infinite range (one which never ends), that returns exactly a
specific delegate. Such a range could be implemented:
struct infiniteDelegate
{
int delegate() front;
enum empty = false;
void popFront() {};
}
It would, based on the current definition, yes. But what is it good for?
Why not simply write:
struct infiniteDelegate
{
int delegate() front();
bool empty() @property { return false; }
void popFront() {};
}
Where the body of front for example can ensure that the delegate is
actually set and not null or can change it if necessary, ...
I haven't applied @property to front in this example, because it would
not change anything, it would be required though if you provided a
setter and wanted to have front=something; work. Whether or not you
apply @property to read-only functions, depends on your use case, if you
want proper encapsulation, you would add @property and in case you want
a writable front at some time, you would add a setter. If you don't
consider encapsulation necessary, you would probably do not add
@property and return a ref if it has to be writable sometime.
Actually, that is not true. Check out the definition of
hasAssignableElements:
http://dlang.org/phobos/std_range.html#.hasAssignableElements
By your requirements, hasAssignableElements!(T[]) would necessarily always
be false, since UFCS properties are banned, so array.front is not a
property. You are saying, I can't assign to the front element of an
array. That doesn't sit well with the rest of array's API.
Not true, the current definition of front for arrays is:
@property ref T front(T)(T[] a);
which would still work just the same, if you removed @property.
Strings are interesting as front returns a non ref dchar (obviously),
but they have no writable front anyway. If you would really have a use
case where you need an actual setter/getter for an array for example,
just do proper encapsulation in a struct/class. If you don't do that,
your setter could be bypassed anyway so the design is questionable at
best. (Which you could still achieve via alias this, if you really
wanted that.)
void foo()
{
int x; // allowed
x = 5; // applies to local scope, not module
{
int x; // error! shadows outer scope x.
}
}
So the point is, a global property could possibly be obscured if you
declared a local variable with the same name.
Same for instance variables and member functions.
Note also that you can have struct-qualified properties (at least you
should be able to, it seems Andrei's DIP does not allow it, but it's not
at odds with UFCS). Those are just about equivalent to module-level
properties, they just require specifying the struct name (and people have
used this in clever ways to achieve good readable results).
Hmm, no real difference to struct/class properties:
import std.stdio;
int i;
void main() {
int i;
i=8;
writeln(.i: , .i);
writeln(.i: , testglobal.i);
}
Prints 0 both times. (The file was named testglobal.d)
It certainly is true. They can be treated like fields for getting and
setting, and I think syntactically means you access them like you would
access a field.
You might say yeah, but you can't do ++ on them!, but you can't do that
to a
Re: win64 vararg bug?
Am 10.02.2013 09:18, schrieb Benjamin Thaut:
import core.vararg;
import std.stdio;
void print(string fmt, ...)
{
auto arg = va_arg!(const(char)[])(_argptr);
writefln(fmt ~ arg);
}
void main(string[] args)
{
print(+++,---);
}
This only seems to happen when the argument before the variadic argument
list is bigger then 8 byte. This works:
void print(int fmt, ...)
{
auto arg = va_arg!(const(char)[])(_argptr);
writefln(%s %s,fmt,arg);
}
void main(string[] args)
{
print(1,---);
}
Re: DIP23 draft: Fixing properties redux
On Wednesday, 6 February 2013 at 01:40:37 UTC, Andrej Mitrovic
wrote:
On 2/6/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
That's why some of us have suggested
making it so that you can mark variables with @property.
What Jonathan means is this:
struct S
{
int var; // modifiable, can take address
}
Now suppose later you want to turn var into a property:
struct S
{
@property int var();
@property void var(int);
}
This potentially breaks code if the user-code was using a
pointer to
the public var field in the previous version of your library.
So instead we should have the ability to annotate fields with
@property:
struct S
{
@property int var; // modifiable, can *not* take address
}
There's no run-time cost, but it disallows taking the address
of var,
and it allows you to introduce property functions in the future
without breaking user-code.
It is also possible to first start with setters/getters and then
switch to a public field(!)
Which leads to the conclusion, in order for the property
abstraction to be complete, address taking of *anything*
annotated with @property should either NOT be allowed...
@property int var(); // can *not* take address
@property void var(int); // can *not* take address
@property int var; // can *not* take address
... or we have to guarantee that the type remains unchanged...
which is problematic due to different types of the getter and
setter, which would force one to always specify the expected type
rather than relying on auto.
@property int var;
int delegate()d_get = var;
void delegate(int) d_set = var;
Re: DIP26 updated
I can unequivocally say that I think that this DIP is a horrible idea. While it may need some work, DIP 23 is worlds better. I definitely think that @property should be implemented as originally intended save for the unfortunate fact that we have to keep parenless function calls around. And this DIP definitely isn't going in that direction at all. I'm completely against anything which would involve not having @property on front, and I think that it's a complete disaster to try and disallow UFCS properties. - Jonathan M Davis If you really think this way, then I really don't understand why you embraced my idea of: @property int a; so much. It does not make any sense at all, if property has not the meaning you seem to think it should have, when embracing this idea. If you allow @property qualified functions returning ref, then you basically consider public int a; a valid property and what should this @property int a; be good for? In fact, for the people who don't consider properties a means of encapsulation, but just about convenience syntax and forbidden parentheses, I completely understand why they think that @property int a; would be bullshit. If property does not mean encapsulation, then why should an @property qualified field mean encapsulation?!
Re: Taking address of properties
On 02/10/2013 01:09 PM, Robert wrote: ... In my DIP a property is a function and they behave the same, except that prop=5; calls prop(5); if prop is a property. ... Why does this justify a keyword? I think Walter's initial proposal of getting rid of @property has more merit than this.
Re: Taking address of properties
On Sun, 2013-02-10 at 13:40 +0100, Timon Gehr wrote: Why does this justify a keyword? I think Walter's initial proposal of getting rid of @property has more merit than this. Read the DIP? It is about encapsulation and making set functions callable with = in order to be compatible with ref returning functions: (Compatible from set function to ref returning function, not the other way round) and for the more expressive syntax: a=something; instead of a(something); and so that tools can easily extract what's a property. (For enabling access from scripting languages for example, like Qt does.) The one reason why we can not drop it, is that = calls the set function on properties. The reason why we should not, is that having such a cool straight forward feature for providing proper no-boilerplate encapsulation seems valuable in an OOP enabled language.
Re: Taking address of properties
The reason why we should not, is that having such a cool straight forward feature for providing proper no-boilerplate encapsulation seems valuable in an OOP enabled language. Provided we actually give properties this meaning in D, which is currently not the case.
Re: Should D1 only bugs be closed?
On Sunday, 10 February 2013 at 07:06:47 UTC, Marco Leise wrote: I'm far from a core DMD developer, so I don't understand your dependence on Walter's full attention to D2. I'm just saying it seems legit to me, to keep Don Co. on board. I'd just drop making D1 releases as a compromise. It seems legit to me, too. I fully understand the desire to continue supporting D1: there are still real users with real needs. I'm just confused since we were told that D1 would be discontinued at the start of this year. Walter and Andrei's time is precious because they are the only people that can make final decisions about the language, and there's many, many decisions that still need to be made: property syntax, shared semantics, copy constructors, ref semantics, auto ref, accessibility vs. visibility, allocator design etc. Any time spent merging changes into D1 is time not spent fixing issues with D2. Anyway, I'm flogging a dead horse here. Clearly D1 is still going to be supported, and me ranting on the forums isn't going to change that.
Alias syntax removal
Now I have a good amount of code broken by: alias x = 5; alias this = foo; I don't expect all changes of a beta to be kept in a final compiler version, but I think the removal of a syntax should be announced (and discussed) in this newsgroup (if the removal of such syntax was discussed in this newsgroup, then I have missed it): https://github.com/D-Programming-Language/dmd/issues/1413 Bye, bearophile
Re: Taking address of properties
On 02/10/2013 01:53 PM, Robert wrote: On Sun, 2013-02-10 at 13:40 +0100, Timon Gehr wrote: Why does this justify a keyword? I think Walter's initial proposal of getting rid of @property has more merit than this. Read the DIP? Stop trolling. It is about encapsulation Perfectly possible without DIP26 and encapsulation can be violated using @property as given in DIP26 just as easily as without it. and making set functions callable with = in order to be compatible with ref returning functions: (Compatible from set function to ref returning function, not the other way round) setter(2); and for the more expressive syntax: a=something; That's not more expressive. instead of You mean as well as. a(something); and so that tools can easily extract what's a property. (For enabling access from scripting languages for example, like Qt does.) Use UDAs. The one reason why we can not drop it, is that = calls the set function on properties. So does ( ). And both are the case already. The reason why we should not, is that having such a cool straight forward feature for providing proper no-boilerplate Boilerplate can be trivially automated. encapsulation seems valuable in an OOP enabled language.
Re: Taking address of properties
Read the DIP? Stop trolling. Agreed, sorry. But by reading some arguments that are posted over and over again, I just get the feeling that people don't even read it, which is kinda frustrating, as it was a lot of work. It is about encapsulation Perfectly possible without DIP26 and encapsulation can be violated using @property as given in DIP26 just as easily as without it. How?! I mean yeah, you can return a pointer to a field, that is correct. But apart from that, which might get forbidden too for properties (I have to think about it first), what do you mean? and making set functions callable with = in order to be compatible with ref returning functions: (Compatible from set function to ref returning function, not the other way round) setter(2); Fine with me. What is the problem? and for the more expressive syntax: a=something; That's not more expressive. If you want to state that the property should assume the given value, it is. Arguably not more than setA(something), but well it is a nice syntax and we stay compatible with ref returning functions and with the current implementation. Use UDAs. True if this was the only reason. The one reason why we can not drop it, is that = calls the set function on properties. So does ( ). And both are the case already. Yeah, which actually is a good thing, because we won't break much code. People have their code written according to the implementation not some specification, so if we keep most currently existing code running and get sane behaviour, I think this is a good thing, but ok there are people who seem to disagree. The reason why we should not, is that having such a cool straight forward feature for providing proper no-boilerplate Boilerplate can be trivially automated. Also true, but integrating it into the language makes the property feature complete and well integrated.
Re: Taking address of properties
How?! I mean yeah, you can return a pointer to a field, that is correct. But apart from that, which might get forbidden too for properties (I have to think about it first), what do you mean? I mean of course you can. Always. There are many ways: - alias this - some other function which returns the variable by ref/pointer - make the field public But the @property marked functions won't break it.
Re: Alias syntax removal
On Sunday, 10 February 2013 at 13:13:12 UTC, bearophile wrote: Now I have a good amount of code broken by Thanks to (absence of) D development model. I don't expect ... Expecting something from how D is developed is not always a good idea:) https://github.com/D-Programming-Language/dmd/issues/1413 Bye, bearophile I am also not aware of any discussion except for that. For this particular case, I honestly also considered that killing old syntax would not do much harm, but it is hard to estimate. In general, until D has a stable and clear development policy, I expect similar problems would happen over and over.
Re: Alias syntax removal
2013/2/10 bearophile bearophileh...@lycos.com
Now I have a good amount of code broken by:
alias x = 5;
This syntax never been valid in past, because alias declaration cannot make
alias of an expression.
alias this = foo;
This syntax was introduced very recent, in 2.061.
==
From 2.061, we have get new alias syntax by fixing issue 3011.
http://d.puremagic.com/issues/show_bug.cgi?id=3011
Now we can write alias declaration as follows:
alias Integer = int;
alias IntArray = int[];
These syntax are continuously valid in 2.062.
But, while a discussion for the compiler fix, a wrong syntax change, which
has similar look but definitely different meaning, had been introduced.
https://github.com/D-Programming-Language/dmd/pull/1187
struct S {
int value;
alias value this; // old syntax
alias this = value; // new syntax, from 2.061
}
I opened the pull request #1413 in the beta term for 2.061, but it had
_accidentally_ released without deeply discussion.
https://github.com/D-Programming-Language/dmd/pull/1413
I think and believe that we MUST reset things.
Kenji Hara
Re: Alias syntax removal
kenji hara:
This syntax never been valid in past, because alias declaration
cannot make alias of an expression.
Right, sorry, my mistake.
Now we can write alias declaration as follows:
alias Integer = int;
alias IntArray = int[];
These syntax are continuously valid in 2.062.
OK. So they aren't going away as I have feared.
But, while a discussion for the compiler fix, a wrong syntax
change, which
has similar look but definitely different meaning, had been
introduced.
https://github.com/D-Programming-Language/dmd/pull/1187
struct S {
int value;
alias value this; // old syntax
alias this = value; // new syntax, from 2.061
}
I opened the pull request #1413 in the beta term for 2.061, but
it had
_accidentally_ released without deeply discussion.
https://github.com/D-Programming-Language/dmd/pull/1413
I think and believe that we MUST reset things.
I see. Thank you for the work.
Bye,
bearophile
Re: Alias syntax removal
2013/2/10 kenji hara k.hara...@gmail.com
I opened the pull request #1413 in the beta term for 2.061, but it had
_accidentally_ released without deeply discussion.
https://github.com/D-Programming-Language/dmd/pull/1413
I think and believe that we MUST reset things.
Why I argue that the syntax `alias this = sym;` is wrong? Because:
1. A normal alias declaration (creating aliased name for existing symbol)
and alias this feature
(making a *subtyped* struct through implicit access to its field) are
entirely different and has distinct semantics.
They merely share a keyword 'alias'.
2. Instead, we can have much more consistent, useful, and scalable syntax.
At the same time, I proposed a new syntax `alias this : ident;` for alias
this feature.
https://github.com/D-Programming-Language/d-programming-language.org/pull/200
struct S {
int value;
alias this : value; // proposed syntax
}
Benefits of the proposed syntax are:
2a. It is consistent with class inheritance syntax `class C : B {}`.
2b. It is scalable for multiple alias this feature, as like `alias this
: sym1, sym2, ...;` .
If D community highly require the syntax `alias this = sym`, I'll agree to
adding it again.
But for that, we should discuss about its cost and benefit.
Sorry for my poor writing.
Regards.
Kenji Hara
Re: Taking address of properties
On Sun, 10 Feb 2013 07:09:52 -0500, Robert jfanati...@gmx.at wrote:
Ok, at the very first I have to make clear that my DIP is about changing
the actual specification, not trying to make the implementation to match
the specification, because in my view of things, the specification is
the problem.
Properties in my proposal are no longer about optional parentheses ore
forbidden parentheses. Properties are a concept hat benefits from the
fact, that parentheses are optional, but would work either way.
We don't need a feature to implement encapsulation, it's quite possible
without property specification. And your proposal does not guarantee
encapsulation anyway.
In the grand scheme of things, the fact that a range's front accessor
is a
property or a function is not technically important. But front being a
property IS important for specific uses. You can't have it so that
front
is a function only when using it as a range, and a property when using
it
as a delegate getter.
In my DIP a property is a function and they behave the same, except that
prop=5; calls prop(5); if prop is a property.
Then why do we need special syntax? I don't see the point. This is just
back to D1 properties.
In fact, the only case where a properly-implemented @property would
be
required on a getter is for delegate properties. I would argue that
if
@property worked correctly, it would be possible and correct to
require
r.front to be a property in that template.
I don't understand, what is the exact problem with: r.front()()?
Despite
not matching the specification regarding no parentheses for
properties?
The problem is, isInputRange does not require that it is a function, but
you ARE requiring that by specifying arbitrary rules.
I think this has to be fixed, because it solves all ambiguities and
encourages good design.
And who says what good design is? What if good design means low
performance? What if performance is more important? How can you say you
know the goals of every possible implementable object and whether
encapsulation is entirely necessary for it? You are holding hostage a
syntax feature on the concession that it play nice with your requiring
function call rules.
I don't think D should be dictating everything about how you write your
properties and methods. This is a systems language, not a nanny language.
Imagine an infinite range (one which never ends), that returns exactly a
specific delegate. Such a range could be implemented:
struct infiniteDelegate
{
int delegate() front;
enum empty = false;
void popFront() {};
}
It would, based on the current definition, yes. But what is it good for?
I think you miss the point then. You can't dismiss arguments because they
don't fit your narrative. This is a corner case, and not a far-fetched
one.
Why not simply write:
struct infiniteDelegate
{
int delegate() front();
bool empty() @property { return false; }
void popFront() {};
}
Because then I have to do:
id.front()();
To call the delegate. Not what I wanted to design. You are calling into
question my design because it doesn't suit your DIP. Why is your DIP more
important than my design?
Actually, that is not true. Check out the definition of
hasAssignableElements:
http://dlang.org/phobos/std_range.html#.hasAssignableElements
By your requirements, hasAssignableElements!(T[]) would necessarily
always
be false, since UFCS properties are banned, so array.front is not a
property. You are saying, I can't assign to the front element of an
array. That doesn't sit well with the rest of array's API.
Not true, the current definition of front for arrays is:
@property ref T front(T)(T[] a);
You are right, I did not look it up.
which would still work just the same, if you removed @property.
Right, the setter is not the reason we need @property on this, it's the
getter. And only for delegate arrays. I should not have brought this
example as a reason for UFCS setter properties.
Strings are interesting as front returns a non ref dchar (obviously),
but they have no writable front anyway. If you would really have a use
case where you need an actual setter/getter for an array for example,
just do proper encapsulation in a struct/class. If you don't do that,
your setter could be bypassed anyway so the design is questionable at
best. (Which you could still achieve via alias this, if you really
wanted that.)
Right, strings are an exception, because they are not treated like
arrays. A setter for front would be incorrect for strings.
Note also that you can have struct-qualified properties (at least you
should be able to, it seems Andrei's DIP does not allow it, but it's not
at odds with UFCS). Those are just about equivalent to module-level
properties, they just require specifying the struct name (and people
have
used this in clever ways to achieve good readable results).
Hmm, no
Re: Alias syntax removal
`alias this : sym1, sym2, ...;` . +1 clean and simple and consistent.
Re: Alias syntax removal
On Sunday, 10 February 2013 at 14:42:50 UTC, kenji hara wrote:
2013/2/10 kenji hara k.hara...@gmail.com
Why I argue that the syntax `alias this = sym;` is wrong?
Because:
Benefits of the proposed syntax are:
2a. It is consistent with class inheritance syntax `class C : B
{}`.
2b. It is scalable for multiple alias this feature, as like
`alias this
: sym1, sym2, ...;` .
2a. I agree.
2b. I always assumed multiple alias would be introduced like
this...
alias this = sym1;
alias this = sym2;
... which also is needed if you use a 3rd party library mixin
in your struct(which internally uses alias this), so even with
the ':' syntax it's anyway required to support being able to use
it multiple times:
alias this : sym1;
alias this : sym2;
So I don't think 2b speaks in favor of the new syntax.
Re: Alias syntax removal
On 2/10/13, Tove t...@fransson.se wrote: ... which also is needed if you use a 3rd party library mixin in your struct(which internally uses alias this), so even with the ':' syntax it's anyway required to support being able to use it multiple times: alias this : sym1; alias this : sym2; I've argued that it should be rare that someone uses multiple subtyping, so I don't see the need to introduce more syntax into the language when they can simply do this for the special occasion when they need it: alias this = this; alias this = bar;
Re: Taking address of properties
On Sun, 2013-02-10 at 10:43 -0500, Steven Schveighoffer wrote:
On Sun, 10 Feb 2013 07:09:52 -0500, Robert jfanati...@gmx.at wrote:
Ok, at the very first I have to make clear that my DIP is about changing
the actual specification, not trying to make the implementation to match
the specification, because in my view of things, the specification is
the problem.
Properties in my proposal are no longer about optional parentheses ore
forbidden parentheses. Properties are a concept hat benefits from the
fact, that parentheses are optional, but would work either way.
We don't need a feature to implement encapsulation, it's quite possible
without property specification. And your proposal does not guarantee
encapsulation anyway.
We don't need it. - Yes.
Would it be nice to have. - Discuss-able.
Does it solve the issues we have. - Yes.
Properties as such do guarantee encapsulation, if you access the fields
through the property methods. There is no way to forbid the programmer
to break it by other members, alias this, or what ever. But as you said
D is a systems programming language.
Then why do we need special syntax? I don't see the point. This is just
back to D1 properties.
Actually only two hard requirements:
1. Downwards-Compatibility with functions returning ref. (Downwards
means that you can replace a property with a function returning ref, but
not the other way round)
2. Backwards compatibility.
Not mandatory:
3. Nice syntax
Why do we need properties to be radically different than functions? This
breaks templates, except we try to make almost everything a property,
what DIP23 seems to do. All I do is strive for a clean concept what a
property actually is, instead of making everything a property just so
that templates work, but by giving up any meaning property could have.
And who says what good design is? What if good design means low
performance? What if performance is more important? How can you say you
know the goals of every possible implementable object and whether
encapsulation is entirely necessary for it? You are holding hostage a
syntax feature on the concession that it play nice with your requiring
function call rules.
I believe the principles of OOP are very well established and accepted.
And once again, you don't have to use properties if they don't match
your requirements. Also performance does not suffer from a trivial
get/set functions. (For classes make them final if needed)
I don't think D should be dictating everything about how you write your
properties and methods. This is a systems language, not a nanny language.
It does not dictate anything. You do accept that you can not do floating
point arithmetic with an integer? What's the difference with properties?
If the tool does not fit your need, don't use it.
Because then I have to do:
id.front()();
To call the delegate. Not what I wanted to design. You are calling into
question my design because it doesn't suit your DIP. Why is your DIP more
important than my design?
You are questioning my DIP, because it does not match your design. How
is that better? Seriously this is just my point of view, you can agree
or not, all I am trying is to make sure that you understand why I think
it is good and to find possible flaws in it, by discussing it.
It establishes some semantics for properties, instead of simply making
basically everything a property, just so that templates work somehow.
The DIP increases uniformity among language features, instead of
decreasing it. Also I am obviously convinced that my DIP is a good
solution, otherwise I would not have proposed it.
which would still work just the same, if you removed @property.
Right, the setter is not the reason we need @property on this, it's the
getter. And only for delegate arrays. I should not have brought this
example as a reason for UFCS setter properties.
Not if we simply accept: front()(); as the syntax to go. It might not
look as beautiful as front(), so if you think the syntax for this corner
case is just so utterly ugly that it has to be fixed, well then my
proposal is rubbish.
import std.stdio;
int i;
void main() {
int i;
i=8;
writeln(.i: , .i);
writeln(.i: , testglobal.i);
}
Prints 0 both times. (The file was named testglobal.d)
I don't know what this example is trying to prove. I don't see any
properties here.
Hmm, maybe I misunderstood your argument against module level
properties. (The example works the same if i was a property)
So what did you mean by:
So the point is, a global property could possibly be obscured
if you declared a local variable with the same name.
A ref property pretty much behaves EXACTLY like a field.
Exactly that is why I don't consider it a property. :-)
If it's not a property, it does not behave like a field. If it is a
function, then it can behave like a field for all cases
Re: Possible regression (2.060 - 2.061) with member access
Am 10.02.2013 11:55, schrieb Dicebot: On Sunday, 10 February 2013 at 10:22:59 UTC, Benjamin Thaut wrote: Really? I'm using typeof all over the place in my user code. That is exactly what I have just said :) And reason why it should behave according to usual protection attribute rules. Oh ok, then I misunderstood your argument.
We forgot to define a MIME-type for D!
Oh noes... Now Mono-Develop used text/x-d and Pygments uses text/x-dsrc. -- Marco
Re: We forgot to define a MIME-type for D!
On Sunday, 10 February 2013 at 17:15:40 UTC, Marco Leise wrote: Oh noes... Now Mono-Develop used text/x-d and Pygments uses text/x-dsrc. Yep, I chose text/x-d mainly because the type for c#-files had been text/x-sharp, and since there probably is no other program that uses .d or .di files, I kept that one :) - But yeah, define one and I'll take it over! Isn't there a bigger registration process required in terms of ISO or such?
Re: We forgot to define a MIME-type for D!
text/x-csharp sry, there really should be a way to edit posts..
Re: We forgot to define a MIME-type for D!
On 02/10/2013 11:22 AM, alex wrote: Yep, I chose text/x-d mainly because the type for c#-files had been text/x-sharp, and since there probably is no other program that uses .d or .di files, I kept that one :) vim occasionally thinks .d files are 'dtrace' files. I have no idea what that is though.
Re: We forgot to define a MIME-type for D!
On 2013-02-10 18:22, alex wrote: Yep, I chose text/x-d mainly because the type for c#-files had been text/x-sharp, and since there probably is no other program that uses .d or .di files, I kept that one :) - But yeah, define one and I'll take it over! Isn't there a bigger registration process required in terms of ISO or such? DTrace uses .d files. Tracing programs (also referred to as scripts) are written using the D programming language (not to be confused with other programming languages named D) http://en.wikipedia.org/wiki/DTrace -- /Jacob Carlborg
Re: We forgot to define a MIME-type for D!
On 2013-02-10 18:43, 1100110 wrote: vim occasionally thinks .d files are 'dtrace' files. I have no idea what that is though. It can be used for debugging, tracking system calls and similar. -- /Jacob Carlborg
Re: We forgot to define a MIME-type for D!
On Sunday, 10 February 2013 at 17:47:54 UTC, Jacob Carlborg wrote: On 2013-02-10 18:43, 1100110 wrote: vim occasionally thinks .d files are 'dtrace' files. I have no idea what that is though. It can be used for debugging, tracking system calls and similar. So, which mime is there (left) to take? And how does one occupy a mime type? Is there legal registration stuff to do, as I asked before? Anyone who knows..ah ok I'll google this.. :)
Re: We forgot to define a MIME-type for D!
Am Sun, 10 Feb 2013 18:57:12 +0100 schrieb alex i...@alexanderbothe.com: On Sunday, 10 February 2013 at 17:47:54 UTC, Jacob Carlborg wrote: On 2013-02-10 18:43, 1100110 wrote: vim occasionally thinks .d files are 'dtrace' files. I have no idea what that is though. It can be used for debugging, tracking system calls and similar. So, which mime is there (left) to take? And how does one occupy a mime type? http://www.iana.org/cgi-bin/mediatypes.pl If you want it to be implemented on linux, probably ask on a FreeDesktop mailing list, freedesktop.org maintains the linux mime database.
Re: We forgot to define a MIME-type for D!
On 2/10/13, alex i...@alexanderbothe.com wrote: So, which mime is there (left) to take? dlang? x-dlang? or something like that.
Re: We forgot to define a MIME-type for D!
On Sunday, 10 February 2013 at 18:43:58 UTC, Johannes Pfau wrote: If you want it to be implemented on linux, probably ask on a FreeDesktop mailing list, freedesktop.org maintains the linux mime database. On my system (Fedora 18) there's /usr/share/mime/text/x-dsrc.xml that contains these lines: sub-class-of type=text/x-csrc/ glob pattern=*.d/ Given that this was installed by default, it seems that someone already made a decision on this.
Re: We forgot to define a MIME-type for D!
Am Sun, 10 Feb 2013 19:47:31 +0100 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: On 2/10/13, alex i...@alexanderbothe.com wrote: So, which mime is there (left) to take? dlang? x-dlang? or something like that. For C it is actually text/x-c on Linux, so it is tempting to use text/x-d. But since D isn't the god language that C is to Unix, and there was already another D language, I'd vote for x-dlang. 1100110, does vim tell you the MIME type it thinks dtrace files have? If it is text/x-d, it would void this option anyway. -- Marco
Re: We forgot to define a MIME-type for D!
On 02/10/2013 12:59 PM, Marco Leise wrote: Am Sun, 10 Feb 2013 19:47:31 +0100 schrieb Andrej Mitrovicandrej.mitrov...@gmail.com: On 2/10/13, alexi...@alexanderbothe.com wrote: So, which mime is there (left) to take? dlang? x-dlang? or something like that. For C it is actually text/x-c on Linux, so it is tempting to use text/x-d. But since D isn't the god language that C is to Unix, and there was already another D language, I'd vote for x-dlang. 1100110, does vim tell you the MIME type it thinks dtrace files have? If it is text/x-d, it would void this option anyway. I don't know, I opened the file out of curiosity. I don't even know how to get vim to show MIME rather than filetype.
Re: We forgot to define a MIME-type for D!
Am Sun, 10 Feb 2013 20:00:44 +0100 schrieb Brian Schott briancsch...@gmail.com: On Sunday, 10 February 2013 at 18:43:58 UTC, Johannes Pfau wrote: If you want it to be implemented on linux, probably ask on a FreeDesktop mailing list, freedesktop.org maintains the linux mime database. On my system (Fedora 18) there's /usr/share/mime/text/x-dsrc.xml that contains these lines: sub-class-of type=text/x-csrc/ glob pattern=*.d/ Given that this was installed by default, it seems that someone already made a decision on this. Oh I see it now, I just have to run update-mime-database again. Alright then, I'll ask them to add *.di and we are set. -- Marco
Re: We forgot to define a MIME-type for D!
Am Sun, 10 Feb 2013 20:18:27 +0100 schrieb Marco Leise marco.le...@gmx.de: Alright then, I'll ask them to add *.di and we are set. https://bugs.freedesktop.org/show_bug.cgi?id=60605 -- Marco
Re: DIP25 draft available for destruction
Am Wed, 06 Feb 2013 22:11:40 -0800 schrieb Walter Bright newshou...@digitalmars.com: On 2/6/2013 4:23 PM, Andrej Mitrovic wrote: On 2/6/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Pointers are what they are, and they're not appropriate for code that offers guarantees. But we're talking about @system here. I would probably be fine with these rules if they only applied to @safe. I feel like someone is trying to put training wheels on my mountain bike. One reason why @safe is not the default. It would also be very very nice, if we could at least write Hello, world! in @safe D. -- Marco
Re: Correctness bug in TDPL
On Friday, 13 May 2011 at 13:36:13 UTC, Andrei Alexandrescu wrote: On 5/13/11 3:25 AM, Timon Gehr wrote: On p368 the CheckedInt struct does not check for overflow in the unary minus operator. Unary minus never overflows. That being said, there is the oddity that -x is x when x == int.min. Even in that case there is no loss of information. Andrei BULLSHIT
Re: We forgot to define a MIME-type for D!
On Sun, 10 Feb 2013 18:22:56 +0100 alex i...@alexanderbothe.com wrote: Isn't there a bigger registration process required in terms of ISO or such? Not for the stuff that starts with x- (much like http headers).
Re: win64 vararg bug?
On Sun, 10 Feb 2013 09:18:58 +0100
Benjamin Thaut c...@benjamin-thaut.de wrote:
I have this small test program, it will crash when compiled on x64
windows, but it works fine on 32bit windows. What am I doing wrong?
import core.vararg;
import std.stdio;
void print(string fmt, ...)
{
auto arg = va_arg!(const(char)[])(_argptr);
writefln(fmt ~ arg);
}
void main(string[] args)
{
print(+++,---);
}
Kind Regards
Benjamin Thaut
Might be related to these:
http://d.puremagic.com/issues/show_bug.cgi?id=6576
http://d.puremagic.com/issues/show_bug.cgi?id=7893
Re: DIP25 draft available for destruction
On Wednesday, 6 February 2013 at 21:40:00 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
Also the DIP argues that addressOf solves the @property issue
w.r.t.
return values. I've proposed we use an .addressOf property
which only
works on @property functions, and I saw no arguments against
it.
There aren't, but a library approach is better than a magic
work, all other things being equal.
Andrei
struct S
{
@property int var();
@property void var(int);
}
The .addressOf property gave me the idea of solving the
getter/setter issue, by having two properties...
var.getter
var.setter
maybe it could be added to your library approach though?
Re: win64 vararg bug?
On Sunday, 10 February 2013 at 08:18:50 UTC, Benjamin Thaut wrote:
I have this small test program, it will crash when compiled on
x64 windows, but it works fine on 32bit windows. What am I
doing wrong?
import core.vararg;
import std.stdio;
void print(string fmt, ...)
{
auto arg = va_arg!(const(char)[])(_argptr);
writefln(fmt ~ arg);
}
void main(string[] args)
{
print(+++,---);
}
Kind Regards
Benjamin Thaut
This works for me when using
https://github.com/ldc-developers/ldc/pull/287 and LLVM 3.2.
LDC currently uses the incompatible System V ABI for Win64...
Re: win64 vararg bug?
Sorry about that, I thought I was browsing the LDC newsgroup. ;)
Re: Status of Dynamically Loadable D Libraries
Is supporting dynamically loadable libraries a priority for the developers, or something that might not happen for a while? Judging by this thread: http://forum.dlang.org/thread/kf1223$oo8$1...@digitalmars.com It has just become a priority.
Re: auto ref - again
I would suggest that it should work this way, and that maybe this should be part of the new process focus. This isn't intended to be demanding -- it could be fairly simple to provide SOME guide to timeframes. For example, with redmine, you can attach issues to milestones/releases, and give an estimate of time involved. Redmine will then project time to finish that milestone, drawing a nice chart of issues closed vs. open vs. total time. If that milestone is three releases away, not being actively worked on, and you have two milestones between, with time estimates for each, then users can STILL see a reasonable timeframe for things, even if it's still updating. Obviously, no one is interested in such a thing. ;) But I like the Idea.
Re: Status of Dynamically Loadable D Libraries
On Sunday, 10 February 2013 at 22:11:52 UTC, Nick Ulle wrote: What's the current status of dynamic loading (and/or linking) for D libraries? I've been playing with this a bit in hopes of calling a D shared library from R through the C ABI, and noticed that on Windows it seems fine, but on Linux dmd won't build my library unless it includes main(), and it segfaults if I call writeln(). I've seen this thread: http://forum.dlang.org/thread/hmhaldyfziejrplgz...@forum.dlang.org And also this one: http://forum.dlang.org/thread/k3vfm9$1tq$1...@digitalmars.com What I gather is that right now, DLLs work on Windows, but on *nix, shared libraries cannot yet use anything from Phobos. Am I correct that it's safe to dynamically load a D library on Windows? How out-of-date is the information in the tutorial for making DLLs on dlang? Is supporting dynamically loadable libraries a priority for the developers, or something that might not happen for a while For shared libraries (linux) I'd use ldc . It's just works.
Re: Status of Dynamically Loadable D Libraries
On Sunday, 10 February 2013 at 23:41:54 UTC, John Colvin wrote: For shared libraries (linux) I'd use ldc . It's just works. Not quite. Using ldc2 -shared -relocation-model=pic mylib.d Compiles and links, but on loading there are undefined symbols (_Dmain). Including a main() function gets me a loadable library, but much like the case with dmd, it segfaults if I call writeln.
Re: Status of Dynamically Loadable D Libraries
On Sunday, 10 February 2013 at 22:46:29 UTC, jerro wrote: Judging by this thread: http://forum.dlang.org/thread/kf1223$oo8$1...@digitalmars.com It has just become a priority. Thanks! This is great to hear. I didn't come across that thread while searching the forums before.
Re: Status of Dynamically Loadable D Libraries
On Sunday, 10 February 2013 at 23:41:54 UTC, John Colvin wrote: For shared libraries (linux) I'd use ldc . It's just works. You are living a dangerous life. ;) It appears to work at first, but the test suite is known to segfault in random places with druntime/Phobos being built as a shared library, most probably because the GC/threading code doesn't really handle dynamic libraries at all. David
Re: Taking address of properties
On Sun, 10 Feb 2013 11:52:47 -0500, Robert jfanati...@gmx.at wrote: On Sun, 2013-02-10 at 10:43 -0500, Steven Schveighoffer wrote: On Sun, 10 Feb 2013 07:09:52 -0500, Robert jfanati...@gmx.at wrote: Ok, at the very first I have to make clear that my DIP is about changing the actual specification, not trying to make the implementation to match the specification, because in my view of things, the specification is the problem. Properties in my proposal are no longer about optional parentheses ore forbidden parentheses. Properties are a concept hat benefits from the fact, that parentheses are optional, but would work either way. We don't need a feature to implement encapsulation, it's quite possible without property specification. And your proposal does not guarantee encapsulation anyway. We don't need it. - Yes. Would it be nice to have. - Discuss-able. Does it solve the issues we have. - Yes. Properties as such do guarantee encapsulation, if you access the fields through the property methods. There is no way to forbid the programmer to break it by other members, alias this, or what ever. But as you said D is a systems programming language. It does not. @property as you have designed it does not solve any issues. It does not enforce or guarantee encapsulation. Only the author can do that. One thing I have learned from D's design philosophies is that a guarantee is not a guarantee unless the compiler guarantees it. Like const. Walter constantly derides C++ const as convention, not enforced. This would be the same thing, if someone uses @property, then you assume they have encapsulated. Unless they haven't, in which case, the compiler still happily compiles, and your guarantee is gone. How is your DIP any different from a statement that non-ref returning @properties guarantee encapsulation? Answer: it's no different. And neither statement is true. Why do we need properties to be radically different than functions? This breaks templates, except we try to make almost everything a property, what DIP23 seems to do. All I do is strive for a clean concept what a property actually is, instead of making everything a property just so that templates work, but by giving up any meaning property could have. They aren't *radically* different from functions, the syntax is different. Under the hood, they are identical to functions. Well, a certain form of functions. And who says what good design is? What if good design means low performance? What if performance is more important? How can you say you know the goals of every possible implementable object and whether encapsulation is entirely necessary for it? You are holding hostage a syntax feature on the concession that it play nice with your requiring function call rules. I believe the principles of OOP are very well established and accepted. And once again, you don't have to use properties if they don't match your requirements. Also performance does not suffer from a trivial get/set functions. (For classes make them final if needed) It is true that properties are mostly in OOP languages. But D is not strictly OOP. structs are not OOP, and you can have properties on them. Static properties can exist, and they have absolutely nothing to do with OOP. It is a syntax modification. Encapsulation, an OOP design, does not require a special property syntax to implement them. I don't think D should be dictating everything about how you write your properties and methods. This is a systems language, not a nanny language. It does not dictate anything. You do accept that you can not do floating point arithmetic with an integer? What's the difference with properties? If the tool does not fit your need, don't use it. Actually, floating point is 2 integers. And yes, you can do floating point math with integers. I do it all the time to avoid the issues with floating point. But beside that point, your properties bring nothing to the table, so I can actually do without them completely. They are a tool that fixes problems that are already fixed. Because then I have to do: id.front()(); To call the delegate. Not what I wanted to design. You are calling into question my design because it doesn't suit your DIP. Why is your DIP more important than my design? You are questioning my DIP, because it does not match your design. How is that better? Seriously this is just my point of view, you can agree or not, all I am trying is to make sure that you understand why I think it is good and to find possible flaws in it, by discussing it. The issue is, my design is limited to MY library, your DIP affects EVERY library (or would if implemented). The bar is much higher that you have to pass, since everyone will have to play by your rules. Without your DIP, I can have my library, and others can have their libraries which might require you to use id.front()(). Freedom of
dmd -O produces incorrect code?
I've taken std.mmfile, and been playing with it.
I won't lie, mostly I've just been messing with it.
The idea was originally to fix opDollar for mmfile (which I can push if
it will be accepted.)
I turned it into a template for funsies.
And a struct. For funsies.
And it Works! mostly.
But only if you don't compile with -O.
-release works, -inline works, -noboundscheck works.
heres an example:
---
import std.conv, std.stdio;
void main()
{
auto mm = mmFile!string(mmTest.d);
string mt = mm[0..50];
string ms = mt[0..50];
string ss = mm.data;
writeln(mm[0..$]);//prints the entire file.
writeln(ms);//prints the first 50 characters.
writeln(mm.data.ptr);//data is the internal string.
writeln(ms.ptr);//all of these should be equal.
writeln(mt.ptr);//But this one and the one above are not.
writeln(ss.ptr);//also nothing gets printed with -O, it segfaults.
return;
}
--
Here is an example output with rdmd mmTest.d:
//the above file[0..$]
//the about file[0..50]
7F47535F5000
7F47535F5000
7F47535F5000
7F47535F5000
Here is outut with rdmd -O mmTest.d:
�
�
7FEA61B77000
406470
406470
7FEA61B77000
What's up with that?
Re: Status of Dynamically Loadable D Libraries
You can arrange to have d's runtime initialized when dlopen loads
the shared lib by adding a small shim that uses gcc attributes,
as follows:
// shim.c
__attribute__((constructor))
static void dinit() {
rt_init();
}
__attribute__((destructor))
static void dfini() {
rt_term();
}
// end of shim.c
Compile this to a .o with gcc, then include the .o in the build.
Note that I've only tried this trick with a simple hello world
shared lib, so I apologize in advance if it doesn't work for
real-world uses.
Re: dmd -O produces incorrect code?
On 02/10/2013 09:26 PM, 1100110 wrote:
On 02/10/2013 07:14 PM, 1100110 wrote:
I've taken std.mmfile, and been playing with it.
I won't lie, mostly I've just been messing with it.
The idea was originally to fix opDollar for mmfile (which I can push if
it will be accepted.)
I turned it into a template for funsies.
And a struct. For funsies.
And it Works! mostly.
But only if you don't compile with -O.
-release works, -inline works, -noboundscheck works.
heres an example:
---
import std.conv, std.stdio;
void main()
{
auto mm = mmFile!string(mmTest.d);
string mt = mm[0..50];
string ms = mt[0..50];
string ss = mm.data;
writeln(mm[0..$]);//prints the entire file.
writeln(ms);//prints the first 50 characters.
writeln(mm.data.ptr);//data is the internal string.
writeln(ms.ptr);//all of these should be equal.
writeln(mt.ptr);//But this one and the one above are not.
writeln(ss.ptr);//also nothing gets printed with -O, it segfaults.
return;
}
--
Here is an example output with rdmd mmTest.d:
//the above file[0..$]
//the about file[0..50]
7F47535F5000
7F47535F5000
7F47535F5000
7F47535F5000
Here is outut with rdmd -O mmTest.d:
�
�
7FEA61B77000
406470
406470
7FEA61B77000
What's up with that?
Found it! I was destroy(class) manually allocated class.
That was my fault. Completely. I knew I would be embarrassed if I posted
this. =P
I am now in love with cgdb.
Go get it. It's beautiful.
Well, mostly. It still has different output on -O, but no longer crashes.
Re: dmd -O produces incorrect code?
On 02/10/2013 07:14 PM, 1100110 wrote:
I've taken std.mmfile, and been playing with it.
I won't lie, mostly I've just been messing with it.
The idea was originally to fix opDollar for mmfile (which I can push if
it will be accepted.)
I turned it into a template for funsies.
And a struct. For funsies.
And it Works! mostly.
But only if you don't compile with -O.
-release works, -inline works, -noboundscheck works.
heres an example:
---
import std.conv, std.stdio;
void main()
{
auto mm = mmFile!string(mmTest.d);
string mt = mm[0..50];
string ms = mt[0..50];
string ss = mm.data;
writeln(mm[0..$]);//prints the entire file.
writeln(ms);//prints the first 50 characters.
writeln(mm.data.ptr);//data is the internal string.
writeln(ms.ptr);//all of these should be equal.
writeln(mt.ptr);//But this one and the one above are not.
writeln(ss.ptr);//also nothing gets printed with -O, it segfaults.
return;
}
--
Here is an example output with rdmd mmTest.d:
//the above file[0..$]
//the about file[0..50]
7F47535F5000
7F47535F5000
7F47535F5000
7F47535F5000
Here is outut with rdmd -O mmTest.d:
�
�
7FEA61B77000
406470
406470
7FEA61B77000
What's up with that?
Found it! I was destroy(class) manually allocated class.
That was my fault. Completely. I knew I would be embarrassed if I
posted this. =P
I am now in love with cgdb.
Go get it. It's beautiful.
Re: dmd -O produces incorrect code?
On 02/10/2013 09:26 PM, 1100110 wrote:
On 02/10/2013 07:14 PM, 1100110 wrote:
I've taken std.mmfile, and been playing with it.
I won't lie, mostly I've just been messing with it.
The idea was originally to fix opDollar for mmfile (which I can push if
it will be accepted.)
I turned it into a template for funsies.
And a struct. For funsies.
And it Works! mostly.
But only if you don't compile with -O.
-release works, -inline works, -noboundscheck works.
heres an example:
---
import std.conv, std.stdio;
void main()
{
auto mm = mmFile!string(mmTest.d);
string mt = mm[0..50];
string ms = mt[0..50];
string ss = mm.data;
writeln(mm[0..$]);//prints the entire file.
writeln(ms);//prints the first 50 characters.
writeln(mm.data.ptr);//data is the internal string.
writeln(ms.ptr);//all of these should be equal.
writeln(mt.ptr);//But this one and the one above are not.
writeln(ss.ptr);//also nothing gets printed with -O, it segfaults.
return;
}
--
Here is an example output with rdmd mmTest.d:
//the above file[0..$]
//the about file[0..50]
7F47535F5000
7F47535F5000
7F47535F5000
7F47535F5000
Here is outut with rdmd -O mmTest.d:
�
�
7FEA61B77000
406470
406470
7FEA61B77000
What's up with that?
Found it! I was destroy(class) manually allocated class.
That was my fault. Completely. I knew I would be embarrassed if I posted
this. =P
I am now in love with cgdb.
Go get it. It's beautiful.
And It turns out that I f'd up my opSlice as well.
And it seems to be working perfectly now.
Thanks for all the help! I couldn't have done it without you guys!
(that is a light-hearted joke, please take it as such.)
Re: Trying to follow Preparing a new major release instructions
On Friday, 8 February 2013 at 18:24:00 UTC, Walter Bright wrote: On 2/8/2013 7:58 AM, Johannes Pfau wrote: == For 2.062 release === * For this release, merge master into staging now (5.3 Preparing a new major release, first code block). * Delete the wrong tag: git tag -d v2.062-b1 git push upstream :refs/tags/v2.062-b1 * Create the tag with the correct commit: git checkout staging git pull upstream staging git tag v2.062-b1 #b1=first beta git push upstream v2.062-b1 Ok, this is done. I don't know what is the state of -b1 now, but it doesn't compile my code. dmd: func.c:1206: virtual void FuncDeclaration::semantic3(Scope*): Assertion `type == f' failed. It seemed fixed in previous state of master, so either the tag is wrong or we have a regression. What is the state of 2.062-b1 ?
Re: Trying to follow Preparing a new major release instructions
On Friday, 8 February 2013 at 16:20:14 UTC, Johannes Pfau wrote: Am Fri, 08 Feb 2013 17:05:32 +0100 schrieb deadalnix deadal...@gmail.com: As of regression bugs ? It is unclear what they are (as by definition, the proposed process make no sense to fix regressions). Maybe the definition should be made clearer. The main idea is to never introduce new bugs in maintenance releases. In the end the contributor / release manager makes the judgement call. We are far away from having a release manager. And it doesn't make things clearer on subject. You basically avoided giving any answer to that question by saying someone else should decide. To me a regression is a bug that exist in version N+1 but doesn't in version N. I though this definition was widespread, but apparently it isn't as the described process make no sense in case of regression.
Re: Status of Dynamically Loadable D Libraries
On Sunday, 10 February 2013 at 22:11:52 UTC, Nick Ulle wrote: What's the current status of dynamic loading (and/or linking) for D libraries? I've been playing with this a bit in hopes of calling a D shared library from R through the C ABI, and noticed that on Windows it seems fine, but on Linux dmd won't build my library unless it includes main(), and it segfaults if I call writeln(). Dynamic linking works in linux (at least observed features work, see example http://forum.dlang.org/thread/k3vfm9$1tq$1...@digitalmars.com?page=2). Dynamic loading does not work. Is supporting dynamically loadable libraries a priority for the developers, or something that might not happen for a while? Yes, couple of days ago Walter announced that shared libraries is priority and he will get into this after releasing new dmd version.
About ref used for performance reasons with struct
Ok, We have 2 usages of ref : when you actually need to modify
informations, and for performance reasons. Let's talk about the
second one.
Passing by ref to improve performance is not ideal. First this is
quite hard to know when it is actually faster to pass by ref and
to pass by value, especially in generic code. Secondly it is easy
to forget to use ref at some location, and a lot of small
performance improvement are lost in the process. Finally, this
may be error prone.
I'm thinking about it for a while now and I'm now convinced that
we should allow the compiler to do that job for us. Let me
explain.
When a function accept a struct, the compiler is free to use that
function, or an altered one taking a reference as parameter. Here
are some rules the compiler can use to know which one to call
from callee side :
The caller is free to call the ref version of the function unless
(rules evaluate in order) :
- The argument is an rvalue (in such case, no postblit is
executed as well).
- The argument is shared.
- The argument's postblit in not pure (weakly).
The callee isn't modified for the vanilla function, but must
create a local copy of the argument in the following reasons in
the ref version :
- The argument is binded to a mutable ref.(even as hidden
argument as for member method).
- The argument is actually modified.
- address of anything coming from the struct is taken.
The compiler is free to apply such treatment only in a branch of
the callee, ie :
// Compiler choose to create an alternative ref version for
performance.
void foo(MyStruct s) {
if(condition) {
// Operation require a copy to not alter what the caller
see.
// A s is copied on stack and postblit is called.
s.field = 5;
} else {
// No operation requiring local copy is performed.
// No local copy is created.
}
}
The compiler is however disallowed to create multiple copies in
the callee. If several branches requires it, then the copy have
to be made in a common branch.
Note that the compiler don't HAVE to do this, but is allowed to.
Modifying the spec in such way allow the compiler to avoid many
copies of struct let us get rid of most ref parameters, keeping
them for what they really are for.
Re: About ref used for performance reasons with struct
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
Ok, We have 2 usages of ref : when you actually need to modify
informations, and for performance reasons. Let's talk about the
second one.
Passing by ref to improve performance is not ideal. First this
is quite hard to know when it is actually faster to pass by ref
and to pass by value, especially in generic code. Secondly it
is easy to forget to use ref at some location, and a lot of
small performance improvement are lost in the process. Finally,
this may be error prone.
I'm thinking about it for a while now and I'm now convinced
that we should allow the compiler to do that job for us. Let me
explain.
When a function accept a struct, the compiler is free to use
that function, or an altered one taking a reference as
parameter. Here are some rules the compiler can use to know
which one to call from callee side :
The caller is free to call the ref version of the function
unless (rules evaluate in order) :
- The argument is an rvalue (in such case, no postblit is
executed as well).
- The argument is shared.
- The argument's postblit in not pure (weakly).
The callee isn't modified for the vanilla function, but must
create a local copy of the argument in the following reasons in
the ref version :
- The argument is binded to a mutable ref.(even as hidden
argument as for member method).
- The argument is actually modified.
- address of anything coming from the struct is taken.
The compiler is free to apply such treatment only in a branch
of the callee, ie :
// Compiler choose to create an alternative ref version for
performance.
void foo(MyStruct s) {
if(condition) {
// Operation require a copy to not alter what the
caller see.
// A s is copied on stack and postblit is called.
s.field = 5;
} else {
// No operation requiring local copy is performed.
// No local copy is created.
}
}
The compiler is however disallowed to create multiple copies in
the callee. If several branches requires it, then the copy have
to be made in a common branch.
Note that the compiler don't HAVE to do this, but is allowed
to. Modifying the spec in such way allow the compiler to avoid
many copies of struct let us get rid of most ref parameters,
keeping them for what they really are for.
EDIT: I forgot one condition for the callee, it is disallowed to
copy the struct or any part of it that contain reference/pointer
is the postblit isn't strongly pure.
Re: search of a workaround
On Saturday, 9 February 2013 at 22:14:45 UTC, Namespace wrote:
Why isn't there 'const' in ParameterStorageClass?
How could I detect that my Parameter storage class is 'in'?
It's an ambiguity in the term StorageClass in D, which is
different from TypeQualifier. Const is part of the type.
StorageClass means modifiers when you pass to a function.
As for in (or inout):
Apparently, they aren't true StorageClass, because the compiler
re-writes them to const ref or scope something anyways,
that's why they don't appear in the list.
On Saturday, 9 February 2013 at 22:54:23 UTC, Namespace wrote:
On Saturday, 9 February 2013 at 22:23:07 UTC, Namespace wrote:
It seems your template has problems with this:
struct A { }
class B {
public:
const int bar(ref A a) {
return 42;
}
mixin(rvalue!(bar));
}
remove the 'const' and it works fine.
It seems that D has no functionality, to detect if a method is
const.
Well, I did mention Also, I didn't code the FunctionAttribute
part, but that's just because it's late and I want to sleep. I
even left a big todo in there :)
On Sunday, 10 February 2013 at 00:01:32 UTC, Namespace wrote:
This works so far:
auto funcAttr = functionAttributes!(fun);
if (FunctionAttribute.pure_ funcAttr) s ~= pure;
if (FunctionAttribute.nothrow_ funcAttr) s ~= nothrow;
if (FunctionAttribute.ref_ funcAttr) s ~= ref;
if (!isMutable!(typeof(fun))) s ~= const;
But it's curious that FunctionAttributes has no const,
immutable, inout or shared...
I I have no idea. File a bug maybe?
Either it'll be valid, or you'll get the it would be redundant
reply, in which case the docs would *need* to be upgraded.
Re: Creating an array of default-constructed class instances
On 10-2-2013 7:14, Simon wrote:
Hi, I'm new to the D programming language. Overall I'm liking
things very much, but I'm still getting the hang of a few things.
Here's a basic programming pattern: I have a class called Thing,
and while I'm coding I decide I need N Thing instances.
In C++ that's a matter of
std::vectorThing things(N);
In python, I can use a list comprehension.
things = [Thing() for _ in range(N)]
However, the obvious D version doesn't work.
auto things = new Thing[N];
Because Thing.init is null, this produces an array of null
references. Of course, I can write a for loop to fill in the
array after creation, but this feels very un-D-like. Is there a
straightforward way to create a bunch of class instances?
import std.stdio, std.algorithm;
class Thing {
int i;
this(int i) {
this.i = i;
}
}
void main()
{
auto things = new Thing[10];
fill(things, new Thing(5));
foreach (t; things)
writef(%d , t.i);
}
Re: search of a workaround
Well, I did mention Also, I didn't code the FunctionAttribute
part, but that's just because it's late and I want to sleep. I
even left a big todo in there :)
I've overlooked that. :)
Here is the complete code. If you have to improve something, say
it please.
One last question: why 'ss' as function name? :o
[code]
template rvalue(alias fun) {
private string ss() {
enum Func = __traits(identifier, fun);
enum Ret = ReturnType!(fun).stringof;
alias Args = ParameterTypeTuple!(fun);
alias ParameterStorageClassTuple!(fun) pstc;
enum names = [ParameterIdentifierTuple!(fun)];
string s;
s ~= Ret ~ ~ Func ~ (;
foreach(i, Type; Args[0 .. $]) {
if (pstc[i] ParameterStorageClass.scope_) s ~=
scope ;
if (pstc[i] ParameterStorageClass.out_) s ~= out ;
if (pstc[i] ParameterStorageClass.lazy_) s ~= lazy
;
s ~= Args[i].stringof ~ ;
s ~= names[i];
if (i + 1 != Args.length) s ~= , ;
}
s ~= );
auto funcAttr = functionAttributes!(fun);
if (funcAttr FunctionAttribute.pure_) s ~= pure;
if (funcAttr FunctionAttribute.nothrow_) s ~= nothrow;
if (funcAttr FunctionAttribute.ref_) s ~= ref;
if (!isMutable!(typeof(fun))) s ~= const; // no idea why
FunctionAttribute has no const...
s ~= {\n\treturn ~ Func ~ (;
if (Args.length) {
s ~= names[0];
foreach(i, Type; Args[1 .. $]) {
s ~= , ~ names[i + 1];
}
}
s ~= );\n}\n;
return s;
}
enum rvalue = ss();
}
[/code]
Re: Creating an array of default-constructed class instances
On Sunday, 10 February 2013 at 09:48:04 UTC, Jos van Uden wrote:
On 10-2-2013 7:14, Simon wrote:
Hi, I'm new to the D programming language. Overall I'm liking
things very much, but I'm still getting the hang of a few
things.
Here's a basic programming pattern: I have a class called
Thing,
and while I'm coding I decide I need N Thing instances.
In C++ that's a matter of
std::vectorThing things(N);
In python, I can use a list comprehension.
things = [Thing() for _ in range(N)]
However, the obvious D version doesn't work.
auto things = new Thing[N];
Because Thing.init is null, this produces an array of null
references. Of course, I can write a for loop to fill in the
array after creation, but this feels very un-D-like. Is there
a
straightforward way to create a bunch of class instances?
import std.stdio, std.algorithm;
class Thing {
int i;
this(int i) {
this.i = i;
}
}
void main()
{
auto things = new Thing[10];
fill(things, new Thing(5));
foreach (t; things)
writef(%d , t.i);
}
HELL NO
What you did just right there is allocate a *single* thing
_instance_ and then place 10 _references_ to that same thing in
the array.
Re: Creating an array of default-constructed class instances
On Sunday, 10 February 2013 at 06:14:37 UTC, Simon wrote: Hi, I'm new to the D programming language. Overall I'm liking things very much, but I'm still getting the hang of a few things. Here's a basic programming pattern: I have a class called Thing, and while I'm coding I decide I need N Thing instances. In C++ that's a matter of std::vectorThing things(N); In python, I can use a list comprehension. things = [Thing() for _ in range(N)] However, the obvious D version doesn't work. auto things = new Thing[N]; Because Thing.init is null, this produces an array of null references. Of course, I can write a for loop to fill in the array after creation, but this feels very un-D-like. Is there a straightforward way to create a bunch of class instances? The difference is that C++ will *place* the instances inside the vector. A *true* C++ equivalent would be to declare: std::vectorThing* things(N); As you can see, same problem. Honestly, there are a lot of fancy ways to go around the problem, but quite frankly,I think simple is best: // auto myThings = new Thing[](N); foreach(ref aThing; myThings) aThing = new Thing(); //- It's not fancy, but it gets the job done. You won't confuse anyone with the code, and there is very little risk of subtle bugs (appart from forgetting the ref in the foreach loop.
Missing attributes in FunctionAttribute
Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know.
Re: For DLLs, what does export actually do?
Am 10.02.2013 13:36, schrieb Ben Davis: With the def, I get lines like DriverProc = _DriverProc@20. Without it, I get lines like _DriverProc@20 = _DriverProc@20. Then you did hit this 3 year old bug: http://d.puremagic.com/issues/show_bug.cgi?id=3956
Re: For DLLs, what does export actually do?
On 10/02/2013 08:17, Benjamin Thaut wrote:
Am 10.02.2013 03:03, schrieb Ben Davis:
My functions are export extern (Windows) - I think they're global...?
For example:
export extern(Windows) LRESULT DriverProc(DWORD_PTR dwDriverId, HDRVR
hdrvr, UINT msg, LONG lParam1, LONG lParam2) nothrow { ... }
Do you have a copy of visual studio around? If so you can use
dumpbin /EXPORTS your.dll
From a visual studio command shell to see the symbols the dll actually
exports. Just compare the version where you manually listed them in the
exports section with the version where you don't manually list exports.
Thanks, that helped expose what's going on.
With the def, I get lines like DriverProc = _DriverProc@20.
Without it, I get lines like _DriverProc@20 = _DriverProc@20.
So the difference is that the export is done under a slightly mangled
name if I only mark it in the code, and I need to use the def file to
specify the exact name to export by. I suppose this is only necessary
for weird things like driver entry points, and not for normal exported
functions.
A bit more Googling reveals that the @n is the number of bytes taken by
arguments, and is part of the stdcall == extern(Windows) convention. So
Windows is making me use stdcall and then making me throw that
information away in the export table. But hey - it wouldn't be the worst
thing I've encountered with the Windows API. (._.' :P)
DllMain is a weird one - it creates all sorts of linker errors if I try
it with extern(C) instead of extern(Windows) (which is different from
the other methods, which compile fine with extern(C) and then crash at
runtime). Also it doesn't matter what name I export it by or whether I
export it at all. I'm getting the feeling this is what was implied by
The presence of DllMain() is recognized by the compiler. Good to know
anyway - I like to keep stuff clean :)
Re: Looking for writing parallel foreach kind of statement for nested for-loops
Think again if you need that. Things start getting pretty ugly. :) Yes, it is not at all intuitive. Indeed... Sparsh, any reason you need the calculation to be done on 2d blocks instead of independent slots? For my problem, original answer was fine, since parallel calculations are not at all dependent on each others. Sometime there are calculations to be done on 2d grid, where calculations are not uniform across the grid(see paper An overview of parallel visualisation methods for Mandelbrot and Julia sets where you can see Julia sets parallelization), and hence, dividing in a particular way leads to better load-balancing than others. Thanks a lot for your answer and time.
Re: For DLLs, what does export actually do?
On 10/02/2013 12:39, Benjamin Thaut wrote: Am 10.02.2013 13:36, schrieb Ben Davis: With the def, I get lines like DriverProc = _DriverProc@20. Without it, I get lines like _DriverProc@20 = _DriverProc@20. Then you did hit this 3 year old bug: http://d.puremagic.com/issues/show_bug.cgi?id=3956 I don't think I did. That bug applies to cases WITHOUT a .def file, and in that bug, the actual vs expected output is: _DriverProc@mangledinsomeway (correct) modMessage@mangledinsomeway (should be _modMessage@mangledinsomeway) midMessage@mangledinsomeway (should be _midMessage@mangledinsomeway) In my case, when I build without a .def file, I get: _DriverProc@mangledinsomeway _modMessage@mangledinsomeway _midMessage@mangledinsomeway not what I want, but correct as per the spec (I assume). Which would imply the bug was fixed at some point. My example of DriverProc = (without the _) was WITH a .def file, AND is what I want - there is no bug as far as I'm aware. For reference, when Andrej mentioned in earlier bug involving not having a .def, I thought of this one: http://www.digitalmars.com/d/archives/digitalmars/D/Windows_DLLs_and_TLS_177871.html Hope it's clear now? Ben :)
Re: For DLLs, what does export actually do?
On 10/02/2013 14:11, Ben Davis wrote: Which would imply the bug was fixed at some point. ...though of course it would need verifying with the example actually quoted in the bug, since there may be subtle differences. (Hopefully I'm just stating the obvious.)
Re: Invisible console
On Sunday, 10 February 2013 at 14:17:14 UTC, SaltySugar wrote: how to make console invisible? See this thread for two solutions: http://forum.dlang.org/thread/xkvdpdsfzevanucrg...@forum.dlang.org You can use a .def file (my post in it) or a linker switch (Jordi Sayol's post).
Re: Invisible console
On 2013-02-10 15:17, SaltySugar wrote: how to make console invisible? Seems to be a recurring question here. :) Search archives. You probably want: dmd.exe -L/SUBSYSTEM:WINDOWS app.d
Re: search of a workaround
On Sunday, 10 February 2013 at 08:38:23 UTC, monarch_dodra wrote: On Saturday, 9 February 2013 at 22:14:45 UTC, Namespace wrote: Why isn't there 'const' in ParameterStorageClass? How could I detect that my Parameter storage class is 'in'? It's an ambiguity in the term StorageClass in D, which is different from TypeQualifier. Const is part of the type. StorageClass means modifiers when you pass to a function. Parameter storage classes are in, out, ref, lazy, const, immutable, shared, inout or scope. http://dlang.org/function.html
Re: D timer
On Sunday, 10 February 2013 at 14:49:15 UTC, SaltySugar wrote: Can i do my own timer in D console application? like in C# timer_Tick event. There is no Timer in D as you know it from C# and also there are no events. You must rely on SetTimer WinAPI and write your own TimerProc.
Re: Creating an array of default-constructed class instances
On 02/10/2013 03:18 AM, monarch_dodra wrote: On Sunday, 10 February 2013 at 09:48:04 UTC, Jos van Uden wrote: auto things = new Thing[10]; fill(things, new Thing(5)); What you did just right there is allocate a *single* thing _instance_ and then place 10 _references_ to that same thing in the array. And in case that is what we really wanted, there is the simpler but sometimes confusing array-wise syntax: auto things = new Thing[10]; things[] = new Thing(5); Ali
Re: Missing attributes in FunctionAttribute
On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. You can always do something like is(func == const). You may check recently pulled update to fullyQualifiedName (should be in next release) to see how it works for function types. Not obvious part probably is delegate handling. https://github.com/D-Programming-Language/phobos/pull/863
Re: Missing attributes in FunctionAttribute
On 2/10/13, Dicebot m.stras...@gmail.com wrote: On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. In the spec they're listed as member function attributes.
Re: Missing attributes in FunctionAttribute
On Sunday, 10 February 2013 at 18:25:25 UTC, Andrej Mitrovic wrote: On 2/10/13, Dicebot m.stras...@gmail.com wrote: On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. In the spec they're listed as member function attributes. Which part? Probably it refers to delegates, because it has both type qualifiers and attribute that qualifies hidden context pointer.
double[][] to double**
I need to call some C code which takes a double**
In D I have a dynamic array X, Whats a good way of doing this ?
#SNIP
extern(C){
void toCall(double** X, size_t d1, size_t d2);
}
void main(){
double[][] X;
// How to be able to:
toCall(X, X.length, X[0].length);
}
#/SNIP
Danny Arends
http://www.dannyarends.nl
Re: double[][] to double**
On 02/10/2013 11:38 AM, Danny Arends wrote:
I need to call some C code which takes a double**
In D I have a dynamic array X, Whats a good way of doing this ?
#SNIP
extern(C){
void toCall(double** X, size_t d1, size_t d2);
}
void main(){
double[][] X;
// How to be able to:
toCall(X, X.length, X[0].length);
}
#/SNIP
Danny Arends
http://www.dannyarends.nl
You need to use two properties of slices:
.ptr: Pointer to the first element
.length: The number of elements
import std.stdio;
import std.algorithm;
import std.range;
extern(C)
{
void toCall(double** X, size_t d1, size_t d2)
{
for (size_t row = 0; row != d1; ++row) {
for (size_t column = 0; column != d2; ++column) {
writefln(%s,%s: %s, row, column, X[row][column]);
}
}
}
}
void main(){
double[][] X = [ [ 1, 2, 3 ], [ 10, 20, 30 ] ];
double*[] X_c = X.map!(d = d.ptr).array;
toCall(X_c.ptr, X_c.length, X[0].length);
}
The line with map is the equivalent of the following:
double*[] X_c;
foreach (slice; X) {
X_c ~= slice.ptr;
}
Ali
Re: double[][] to double**
Thanks so much ! Why is this not easy 2 find :P
Re: double[][] to double**
On 02/10/2013 12:05 PM, Danny Arends wrote: Thanks so much ! Why is this not easy 2 find :P We all know the feeling. :) For future reference: The spec: http://dlang.org/arrays.html#array-properties TDPL: 4.6 Arrays' Maverick Cousin: The Pointer Programming in D: http://ddili.org/ders/d.en/pointers.html (The .ptr property of arrays section.) Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Re: search of a workaround
On Sunday, 10 February 2013 at 14:41:04 UTC, Namespace wrote: On Sunday, 10 February 2013 at 08:38:23 UTC, monarch_dodra wrote: On Saturday, 9 February 2013 at 22:14:45 UTC, Namespace wrote: Why isn't there 'const' in ParameterStorageClass? How could I detect that my Parameter storage class is 'in'? It's an ambiguity in the term StorageClass in D, which is different from TypeQualifier. Const is part of the type. StorageClass means modifiers when you pass to a function. Parameter storage classes are in, out, ref, lazy, const, immutable, shared, inout or scope. http://dlang.org/function.html Hum. The bug report is here: http://d.puremagic.com/issues/show_bug.cgi?id=8695 I got confused by Kenji's explanation. Still, I find it strange that const, immutable and shared are part of the storage class. I figured they were (they are) just part of the plain type.
[Issue 9493] New: std.algorithm.canFind returns true for empty string in array of integers
http://d.puremagic.com/issues/show_bug.cgi?id=9493
Summary: std.algorithm.canFind returns true for empty string in
array of integers
Product: D
Version: D2
Platform: x86_64
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: monkeywork...@hotmail.com
--- Comment #0 from monkeywork...@hotmail.com 2013-02-09 23:58:48 PST ---
It seems that std.algorithm.canFind returns true when checking for the empty
string within an array of integers. This seems like unintended behaviour to me,
so I'm reporting it as a bug. This bug is present on at least DMD 2.061.
Example:
import std.algorithm;
void main()
{
//This assertion should fail, but doesn't
assert(canFind([1, 2, 3, 4], ));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9494] New: compiler stack overflow on invalid associative array
http://d.puremagic.com/issues/show_bug.cgi?id=9494
Summary: compiler stack overflow on invalid associative array
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: vertig...@gmx.net
--- Comment #0 from Tobias Pfaff vertig...@gmx.net 2013-02-10 01:37:12 PST ---
Compiler crashes with stack overflow on this invalid piece of code:
int[test] test;
void main(string[] args) { }
This only happens if 'test' is used for both index type and array name.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
http://d.puremagic.com/issues/show_bug.cgi?id=9493
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2013-02-10 03:34:19 PST ---
(In reply to comment #0)
It seems that std.algorithm.canFind returns true when checking for the empty
string within an array of integers. This seems like unintended behaviour to
me,
so I'm reporting it as a bug. This bug is present on at least DMD 2.061.
Example:
import std.algorithm;
void main()
{
//This assertion should fail, but doesn't
assert(canFind([1, 2, 3, 4], ));
}
I think this is inteded behavior. You are basically looking for instances of
*nothing*, which, by definition, can be found inside everything (*). I'd expect
a true returned here, and this would be consistent with the rest of the finds
(AFAIK).
Are you getting a different behavior for, say arrays? eg canFind([1, 2, 3],
(int[]).init) I don't have access to my compiler, so that's an actual
question. If you *are* getting a different behavior, then I'd argue *that's* a
bug.
*: The only ambiguous case I see is if hasytack is empty, in which case I could
see it both ways, but I'd still lean for true, since empty is empty, so
empty can be found inside empty.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9456] decodeFront is inconsistent in whether it pops elements off of the range or not
http://d.puremagic.com/issues/show_bug.cgi?id=9456 --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2013-02-10 03:47:54 PST --- New pull request: https://github.com/D-Programming-Language/phobos/pull/1129 It makes it so that decodeFront takes its argument by ref, since that's the only way to make it consistent across range types, much as it would ideally act like decode and never pop off any elements. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
http://d.puremagic.com/issues/show_bug.cgi?id=9493 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2013-02-10 03:46:42 PST --- I think that there's a good chance that it's intended behavior that looking for an empty range with canFind always returns true. However, the fact that canFind is accepting a _string_ as the needle when the haystack is int[] seems very wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
