Re: Is This a Solution For the Const/Rebindable Issue?
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > What is the type of s.o? Hint, it can't be final, because final isn't part > of the type. > What is the type of &s.o? > If the type of s.o is T (let's say) and the type of &s.o is not T*, then I > think we have a problem. > I just think it doesn't work. Maybe you can figure out a way it can, but I > don't think it can be done without severe confusing semantics. > -Steve Type of s.o: const(Object), like before. Can be reassigned. Type of &s.o: Pointer to a const(Object)... yeah I think I finally see. x_x Gosh, that sucks... thanks for the explanation, I appreciate it. :) I'll see if I can figure out a way (though I doubt I can, lol)...
Re: Is This a Solution For the Const/Rebindable Issue?
On Mon, 13 Jun 2011 01:38:17 -0400, Mehrdad wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Mon, 13 Jun 2011 01:09:57 -0400, Steven Schveighoffer wrote: > No. final is not a type constructor, so it does not get carried around > with the type. > > final int i; > > assert(typeof(i) == int); // after the declaration, the storage class is > gone from the type! > > int * ip = &i; Note, you might be able to forbid this line, but I don't think this works well. -Steve I completely realize that final is not a type constructor (I don't want it to be one either), but I'm failing to what that has to do with anything. How does that fact affect my previous answer? What is the type of s.o? Hint, it can't be final, because final isn't part of the type. What is the type of &s.o? If the type of s.o is T (let's say) and the type of &s.o is not T*, then I think we have a problem. I just think it doesn't work. Maybe you can figure out a way it can, but I don't think it can be done without severe confusing semantics. -Steve
Re: Is This a Solution For the Const/Rebindable Issue?
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Mon, 13 Jun 2011 01:09:57 -0400, Steven Schveighoffer > wrote: > > No. final is not a type constructor, so it does not get carried around > > with the type. > > > > final int i; > > > > assert(typeof(i) == int); // after the declaration, the storage class is > > gone from the type! > > > > int * ip = &i; > Note, you might be able to forbid this line, but I don't think this works > well. > -Steve I completely realize that final is not a type constructor (I don't want it to be one either), but I'm failing to what that has to do with anything. How does that fact affect my previous answer?
Re: Is This a Solution For the Const/Rebindable Issue?
On Mon, 13 Jun 2011 01:09:57 -0400, Steven Schveighoffer wrote: No. final is not a type constructor, so it does not get carried around with the type. final int i; assert(typeof(i) == int); // after the declaration, the storage class is gone from the type! int * ip = &i; Note, you might be able to forbid this line, but I don't think this works well. -Steve
Re: Is This a Solution For the Const/Rebindable Issue?
On Mon, 13 Jun 2011 01:06:43 -0400, Mehrdad wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Sun, 12 Jun 2011 23:58:01 -0400, Mehrdad
wrote:
I'll see if it's in my sent mail...
OK, I found it, it was actually the same logic but applied to shared
objects. But Walter convinced me that the issues are the same (at least
for this problem).
Consider this type:
struct S
{
Object o;
}
now, we have these two variables:
const(S) s;
const(Object) o;
finally, the issue:
void kryptonite(ref const(Object) o)
{
o = new Object();
}
kryptonite(o); // fine
kryptonite(s.o);// oops!
The problem is, there isn't a way to distinguish a tail-const object
reference from a fully const object reference, yet both types can exist.
If you want to pass a reference to such a reference, then you run into
sticky issues like this one.
I understand that you want final to mean "head const", but final is a
storage class, not a type modifier -- it cannot be used as part of the
type info.
-Steve
Hm... that's a reason, but it seems like we can get around it relatively
easily.
It seems like it could be solved by making it so that const(S) also
makes the fields of S final. That way,
you could no longer do `kryptonite(s.o)` because it's final.
You could then say "final ref const Object o" to allow for passing that
field, because that would mean the
callee cannot modify o.
Wouldn't that work?
No. final is not a type constructor, so it does not get carried around
with the type.
final int i;
assert(typeof(i) == int); // after the declaration, the storage class is
gone from the type!
int * ip = &i;
*ip = 4; // can't be forbidden.
final can only apply to the storage of the variable, and I'm not actually
sure the above is valid in today's D2. I think it's only a storage class
in D1. In D2, I think it's only use is to declare a function as
not-virtual.
-Steve
Re: Is This a Solution For the Const/Rebindable Issue?
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Sun, 12 Jun 2011 23:58:01 -0400, Mehrdad wrote:
> I'll see if it's in my sent mail...
> OK, I found it, it was actually the same logic but applied to shared
> objects. But Walter convinced me that the issues are the same (at least
> for this problem).
> Consider this type:
> struct S
> {
> Object o;
> }
> now, we have these two variables:
> const(S) s;
> const(Object) o;
> finally, the issue:
> void kryptonite(ref const(Object) o)
> {
> o = new Object();
> }
> kryptonite(o); // fine
> kryptonite(s.o);// oops!
> The problem is, there isn't a way to distinguish a tail-const object
> reference from a fully const object reference, yet both types can exist.
> If you want to pass a reference to such a reference, then you run into
> sticky issues like this one.
> I understand that you want final to mean "head const", but final is a
> storage class, not a type modifier -- it cannot be used as part of the
> type info.
> -Steve
Hm... that's a reason, but it seems like we can get around it relatively easily.
It seems like it could be solved by making it so that const(S) also makes the
fields of S final. That way,
you could no longer do `kryptonite(s.o)` because it's final.
You could then say "final ref const Object o" to allow for passing that field,
because that would mean the
callee cannot modify o.
Wouldn't that work?
(Note that this does **NOT** require that "final" be a type constructor. That
would be ugly. It can remain
a storage class, a property of the variable rather than the object.)
Re: Is This a Solution For the Const/Rebindable Issue?
On Sun, 12 Jun 2011 23:58:01 -0400, Mehrdad wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Sun, 12 Jun 2011 23:36:21 -0400, Mehrdad
wrote:
> An idea came to my mind for fixing the const/rebindable issue, and I'm
> not sure if it's a good idea or not but I thought I'd mention it. I'm
> not sure if it's been mentioned before, but a quick search didn't make
> it seem like it has been.
It has been brought up, a long time ago, by me on the phobos mailing
list
(the idea to just assume const(Object) is rebindable, not the final
thing). I think it was on the ML that Andrei maintained, so it's
archive
is gone.
I had the exact same thoughts as you, and Walter found a perfectly
iron-clad reason why it doesn't work. I can't say I remember the exact
reason (maybe he does off the top of his head), but it definitely killed
the idea quite well. So it doesn't work unfortunately :( I know the
lack
of reference/reason is unsatisfying, but I hope you can trust me that to
pursue this is not going to go anywhere, and I don't want to re-argue it
again...
-Steve
No problem, I won't. :) But if you remember the reason, please post it
since I'm curious!
I'll see if it's in my sent mail...
OK, I found it, it was actually the same logic but applied to shared
objects. But Walter convinced me that the issues are the same (at least
for this problem).
Consider this type:
struct S
{
Object o;
}
now, we have these two variables:
const(S) s;
const(Object) o;
finally, the issue:
void kryptonite(ref const(Object) o)
{
o = new Object();
}
kryptonite(o); // fine
kryptonite(s.o);// oops!
The problem is, there isn't a way to distinguish a tail-const object
reference from a fully const object reference, yet both types can exist.
If you want to pass a reference to such a reference, then you run into
sticky issues like this one.
I understand that you want final to mean "head const", but final is a
storage class, not a type modifier -- it cannot be used as part of the
type info.
-Steve
Re: Is This a Solution For the Const/Rebindable Issue?
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Sun, 12 Jun 2011 23:36:21 -0400, Mehrdad wrote: > > An idea came to my mind for fixing the const/rebindable issue, and I'm > > not sure if it's a good idea or not but I thought I'd mention it. I'm > > not sure if it's been mentioned before, but a quick search didn't make > > it seem like it has been. > It has been brought up, a long time ago, by me on the phobos mailing list > (the idea to just assume const(Object) is rebindable, not the final > thing). I think it was on the ML that Andrei maintained, so it's archive > is gone. > I had the exact same thoughts as you, and Walter found a perfectly > iron-clad reason why it doesn't work. I can't say I remember the exact > reason (maybe he does off the top of his head), but it definitely killed > the idea quite well. So it doesn't work unfortunately :( I know the lack > of reference/reason is unsatisfying, but I hope you can trust me that to > pursue this is not going to go anywhere, and I don't want to re-argue it > again... > -Steve No problem, I won't. :) But if you remember the reason, please post it since I'm curious!
Re: Is This a Solution For the Const/Rebindable Issue?
On Sun, 12 Jun 2011 23:36:21 -0400, Mehrdad wrote: An idea came to my mind for fixing the const/rebindable issue, and I'm not sure if it's a good idea or not but I thought I'd mention it. I'm not sure if it's been mentioned before, but a quick search didn't make it seem like it has been. It has been brought up, a long time ago, by me on the phobos mailing list (the idea to just assume const(Object) is rebindable, not the final thing). I think it was on the ML that Andrei maintained, so it's archive is gone. I had the exact same thoughts as you, and Walter found a perfectly iron-clad reason why it doesn't work. I can't say I remember the exact reason (maybe he does off the top of his head), but it definitely killed the idea quite well. So it doesn't work unfortunately :( I know the lack of reference/reason is unsatisfying, but I hope you can trust me that to pursue this is not going to go anywhere, and I don't want to re-argue it again... -Steve
Re: Is This a Solution For the Const/Rebindable Issue?
On 6/13/11 5:36 AM, Mehrdad wrote: An idea came to my mind for fixing the const/rebindable issue, and I'm not sure if it's a good idea or not but I thought I'd mention it. I'm not sure if it's been mentioned before, but a quick search didn't make it seem like it has been. Right now, the trouble seems to be from the fact that a piece of code like: const(Object) obj; prevents obj from being assigned a new object. You might be interested in Michel's const(Object)ref proposal: https://github.com/D-Programming-Language/dmd/pull/3 David
Is This a Solution For the Const/Rebindable Issue?
An idea came to my mind for fixing the const/rebindable issue, and I'm not sure if it's a good idea or not but I thought I'd mention it. I'm not sure if it's been mentioned before, but a quick search didn't make it seem like it has been. Right now, the trouble seems to be from the fact that a piece of code like: const(Object) obj; prevents obj from being assigned a new object. For the solution: Why not just relax this restriction for reference types? After all, references are just pretty much pointers, and it's not we disallow pointers to const value types from being rebindable, right? Value types (e.g. structs) would still not be rebindable (that makes sense, since it would really be changing the value) but reference types like Object would be rebindable by default. ### NOTEt: This will **NOT** break any existing code! ### We could then allow the "final" keyword to be used for members that are reference types (but this would NOT be allowed for value types), to simply prevent their rebinding (although they need not be const). Examples: int i; //variable const int j = 5; //constant final int k; //compiler ERROR (should say const instead, since int is a value type) const Object obj1; //rebindable reference, but contents are all const final Object obj2; //non-rebindable reference to a regular object final const Object obj3; //non-rebindable reference to a const object Does this sound like a good idea?
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Hey I've just realized something (well, it was in the docs, doh!), we
can use already use "switch case;" to fallthrough to the next label
without explicitly using goto:
void main()
{
int x = 2;
switch (x)
{
case 2:
goto case; // goto case 3;
break;
case 3:
writeln("case 3");
default:
}
}
So the pain of updating the code is minimal with the new changes in place.
Re: Struct Interface Implementation?
Yeah I was referring to something similar to what C# has (aside from the lack of boxing). On 6/12/2011 6:46 PM, Andrei Alexandrescu wrote: On 6/12/11 8:28 PM, Jonathan M Davis wrote: They aren't virtual. For an interface to work, it has to be virtual. structs are value types, not reference types. They have no virtual table and have no polymorphism. Why would they need to be virtual? They obviously aren't in C#, but they still work pretty well (e.g. foreach loops work with List.Enumerator, which is a struct but which can be treated as the IEnumerator interface), right? He must be referring to nominal conformance. It's been discussed many times. There are important disadvantages (e.g. you can't "implement" a type alias) but there are advantages too. Ultimately we never got around to it. Andrei Haha ok, that's a good reason in its own way, thanks. :)
Re: Daniel Murphy (yebblies)
It looks like accessibility is everything. From the other discussions I wonder if a D package/library manager would make a similar impact to adoption rates and productivity of D.
Re: Daniel Murphy (yebblies)
On 6/12/11 9:22 PM, Steven Schveighoffer wrote: I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! -Steve Yes, he's doing quite heavyweight stuff. I'd add that the other contributors are no slouches either. Generally I must say the door of opportunity has not just opened - it's been blown off its hinges ever since we migrated on github. Since Jan 14 when we started there, we've had on average more than two pull requests PER DAY, and that's not properly reflecting the accelerating pace in the recent couple of months. This momentum is stronger than the most optimistic expectations. It seems to me that at this point it is crucial for the core team to be effective at reviewing merging pull requests quickly, with the help of the community. By this I'm suggesting anyone who has an interest in D to give a hand with reviewing and improving pull requests, and of course to create more of them. Thanks, Andrei
Daniel Murphy (yebblies)
I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! -Steve
Re: Undefined (Win32) Externals
On 2011-06-13 01:53, Andrej Mitrovic wrote:
Well most API functions stay the same for a long time on Windows.
Examples compiled in 1998 for Windows 98 will compile in 2011 for
Windows 7, and they will both run fine. At least the simple ones will.
The bindings /might/ be missing some new vista/win7 function
prototypes but I'm not sure if that's true or not. And if you use
vista/win7 features exclusively, you can say goodbye to compatibility
with pre-vista systems (if you care about that).
I'm not sure why your example is not compiling for you, it does for me:
import std.c.windows.windows;
extern (Windows)
{
int GWL_USERDATA;
LONG SetWindowLong(HWND, int, LONG);
LONG GetWindowLong(HWND, int);
}
void main()
{
}
But try replacing the prototypes with this (notice the A at the end):
LONG SetWindowLongA(HWND, int, LONG);
LONG GetWindowLongA(HWND, int);
Which DMD version are you running?
Replacing them with their ASCII variants worked flawlessly! Though
GWL_USERDATA is apparently undefined (0). To solve this I had to declare
the variable explicitly:
const int GWL_USERDATA = -21;
About the WindowsAPI binding, is it fully functional for D2, since it
seems to have been inactive for so long?
Even though I've solved this error (Set-/GetWindowLong) I've got stuck
with another error (this might be off topic, perhaps a new thread?)
related to DirectX. At the moment I'm using the DDirectX9 binding (at
dsource.org). So far it's been working perfectly fine, everything
compiles and no linker errors, but I do have problems with creating the
Direct3D9 Device.
The reason I am asking this here (and not in a forum related to DirectX)
is because there are no debug outputs, even with the DirectX debug DLLs,
I guess this is related to the D debugger or the wrapper?
To get to the problem, in my code, I set up a Win32 Window like this:
// Window Properties
WNDCLASSA wnd;
// Setup The Properties
wnd.style = CS_HREDRAW | CS_VREDRAW;
wnd.lpfnWndProc = &WindowProc;
wnd.hInstance = hInstance;
wnd.lpszClassName = "CWindow";
// Register Class
RegisterClassA(&wnd);
// Create Window
m_hWnd = CreateWindowA("CWindow", "Win32&DirectX Test",
WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 800, 600, null, null,
hInstance, null);
// Used for static WindowProc
SetWindowLongA(m_hWnd, GWL_USERDATA, cast(LONG)(cast(void*) this));
// Show & Update The Window
ShowWindow(m_hWnd, SW_SHOW);
UpdateWindow(m_hWnd);
After this, I set up the direct3d environment with this code:
// Create Direct3D Interface
m_d3d = Direct3DCreate9(D3D_SDK_VERSION); // <--- This is successful
// Present Parameters
D3DPRESENT_PARAMETERS d3dpp = {0};
// Setup the options
d3dpp.Windowed = true;
d3dpp.SwapEffect = D3DSWAPEFFECT.D3DSWAPEFFECT_DISCARD;
d3dpp.hDeviceWindow = m_hWnd;
// Create Direct3D Device
HRESULT hr = m_d3d.CreateDevice(D3DADAPTER_DEFAULT,
D3DDEVTYPE.D3DDEVTYPE_HAL, m_hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING,
&d3dpp, &m_d3dDevice);
if(FAILED(hr)) MessageBoxA(null, "Failurre", "Majs", MB_ICONERROR);
The HRESULT from CreateDevice always returns the following:
HRESULT: 0x8876086c (2289436780)
Name: D3DERR_INVALIDCALL
Description: Invalid call
Severity code: Failed
Facility Code: FACILITY_D3D (2166)
Error Code: 0x086c (2156)
I've googled this a lot with no avail, and since my code is so small,
I'm afraid it's related to D or the DirectX Wrapper. I've tried to play
a bit with the d3dpresent parameters without success...
Once again, I'm sorry if it's inconvenient to post this here, although
this seems like the most appropriate place.
(if worth noticing, I'm using DMD Version 2.052 and the wrapper is D1)
Re: Struct Interface Implementation?
On 6/12/11 8:28 PM, Jonathan M Davis wrote: On 2011-06-12 18:20, Mehrdad wrote: Is there any particular reason that structs and unions can't implement interfaces? If that was possible, template conditions could become much simpler for a variety of cases, such as for checking if something is a particular type of range or container. Thoughts? They aren't virtual. For an interface to work, it has to be virtual. structs are value types, not reference types. They have no virtual table and have no polymorphism. He must be referring to nominal conformance. It's been discussed many times. There are important disadvantages (e.g. you can't "implement" a type alias) but there are advantages too. Ultimately we never got around to it. Andrei
Re: Flag proposal [OT]
Alix Pexton Wrote: > On 12/06/2011 16:11, Steven Schveighoffer wrote: > > On Sun, 12 Jun 2011 04:36:55 -0400, Alix Pexton > > wrote: > > > >> On 12/06/2011 02:40, Steven Schveighoffer wrote: > >>> On Sat, 11 Jun 2011 13:04:47 -0400, Andrej Mitrovic > >>> wrote: > >>> > On 6/11/11, Alix Pexton wrote: > > On 11/06/2011 06:18, Andrej Mitrovic wrote: > >> We should rename Yes and No to Yay and Nay to make them alignable, > >> and > >> even more importantly to make us appear as old Englishmen! > > > > "Yay" and "Nay" are too similar looking, but luckily, "Yay" is not > > actually a old English word :) A more correct alternative would be > > "Aye" (pronounced the same as "eye"), which (along with "Nay") is > > still > > used for some voting actions (such as councillors deciding where to go > > for lunch). I myself say it al least 20 times a day :) > > > > A... > > > > Oh damn, yay is what teenage girls would say, not old Englishmen. My > bad, it really is "Aye". :p > >>> > >>> You were phonetically right :) It's yea or nay. > >>> > >>> http://dictionary.cambridge.org/dictionary/british/yea-or-nay > >>> > >>> My son's most recent birthday (3 years old) was a farm-themed birthday, > >>> and we asked people to RSVP yay or neigh :P > >>> > >>> So I guess there's all kinds of kooky fun you can have with flags... > >>> > >>> -Steve > >> > >> Nope, its definitely Aye when used for voting, (at least it is round > >> here) as in "all those in favour, say aye", "ayes to the right" and > >> "the ayes have it". Maybe southerners say this "yea" word of which you > >> speak, we don't hold with their strange customs in these parts ^^ > > > > I don't deny that aye is used frequently for voting. All I was saying > > is, the correct expression is yea or nay, not yay or nay. Andrej thought > > it was actually aye or nay, which I've never heard as an expression. > > > > I'm not sure it's used anymore, but it's definitely an expression that > > was used for voting (see my dictionary reference). > > > > -Steve > > True, "yea-or-nay" is quite a common, if old fashioned phrase, but "yea" > on its own is exceptionally rare (to the point where I doubt ever > hearing anyone make such a noise and mean it to indicate the affirmative). > > A... Then you must not have heard the King James Version of the Bible read aloud, or been to a Shakespeare play. Admittedly the KJV and Shakespeare's works don't count as modern English, but I doubt you've never "heard such a noise"! :-) p.s. The word appears 209 times in Shakespeare's plays. There's a website for everything!
Re: Struct Interface Implementation?
On 2011-06-12 18:20, Mehrdad wrote: > Is there any particular reason that structs and unions can't implement > interfaces? > > If that was possible, template conditions could become much simpler > for a variety of cases, such as for checking if something is a > particular type of range or container. > > Thoughts? They aren't virtual. For an interface to work, it has to be virtual. structs are value types, not reference types. They have no virtual table and have no polymorphism. At best, there could be a way to indicate that a struct happens to have functions which match what the interface has, which could then be used for static instrospection, but you could never actually use a struct as an interface. But there is not currently any way to use an interface to check whether a struct implements a particular set of functions. And while eponymous templates such as isForwardRange could be simplified with such a feature, their usage would be the same, so it might help, but it wouldn't really help with template constraints. Not to mention, interfaces are likely to be far stricter about types than templates are, so it might be difficult to get that to work generically. Regardless, I'm very leery of associating interfaces and structs in any way shape or form, because they are _very_ different things. - Jonathan M Davis
Re: Improvements to std.string
Jonathan M Davis wrote: > Would it be better to rename toStringz to toCString when fixing it I think it should stay just how it is: toStringz, with a lowercase z. The reason is a "stringz" is actually a proper name of sorts - the z at the end isn't a new word, but part of the first one. At least that's the way it was in assembly! Also, it ain't broke. I've sometimes gotten tolower wrong due to case. I've never made a mistake on toStringz. I'd be surprised if anyone has.
Struct Interface Implementation?
Is there any particular reason that structs and unions can't implement interfaces? If that was possible, template conditions could become much simpler for a variety of cases, such as for checking if something is a particular type of range or container. Thoughts?
Improvements to std.string
https://github.com/D-Programming-Language/phobos/pull/101 I made several improvements to std.string, std.uni, and std.ctype - primarily with the aim of fixing function names to be properly camelcased and improving unicode support - and while the changes are generally fairly simple and generally well-organized, there are quite a few of them, and I think that the changes could use some extra eyes. Also, there are probably a few changes which deserve some discussion. For instance, a couple of items which already came up 1. Would it be better to rename toStringz to toCString when fixing it so that it's properly camelcased (in my changes I just did toStringZ since it was the straightforward fix to the naem, but it's not exactly a great name to begin with). 2. Should std.ctype be renamed (or at least the updated functions be put into another module which will replace it) - e.g. std.ascii? I don't want want a bikeshedding discussion, but it is a fairly large commit, and it could use a looking over by more than just a couple of Phobos devs, and some of the changes likely do merit some discussion. So, feel free to look over the pull request and make appropriate suggestions. - Jonathan M Davis
Re: imports in functions
On 6/12/11 5:08 PM, Andrej Mitrovic wrote: This seems like a way to simulate namespaces in C++, right? I wouldn't know, but it looks similar to that 'using foo' trick. I hope not :o). C++ namespaces are quite lacking. Andrei
Re: Flag proposal
On 6/12/11 2:19 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:it32j8$2gfq$1...@digitalmars.com...
On 6/12/11 1:45 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:it1c0f$1uup$1...@digitalmars.com...
On 06/11/2011 03:52 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu"wrote in message
news:it07ni$1pvj$1...@digitalmars.com...
Anyway, that was the first thing "grep yes std/*" found. Let's see the
next one:
/**
Specifies whether the output of certain algorithm is desired in sorted
format.
*/
enum SortOutput {
no, /// Don't sort output
yes, /// Sort output
}
This already is very unpleasant because "certain" is as imprecise as
it
gets. Plus one for Flag, I hope you agree.
Flag -= 1
s/output of certain algorithm/output of an algorithm/ += 1
That one-word doc change makes it all perfectly clear.
Not at all. The typo in the original text must have confused you: it
should be "certain algorithms" because SortOutput is used in four
distinct
algorithms (one of which has two overloads). Grep std/algorithm.d.
Flag += 2
Not that I consider quibbling over small English wording differences a
major
thing, but I fail to see how:
"Specifies whether the output of an algorithm is desired in sorted
format."
is significantly different from:
"Specifies whether the output of certain algorithms are desired in sorted
format."
In either case, I don't see anything problematically imprecise.
Still means I need to jump back and forth in the documentation.
And you don't like the "///ditto" suggestion for handling that?
That actually does help, but not for enums used by more than one
function. The other issues remain too.
Andrei
Re: core.sys/core.stdc vs. std.c?
The windows bit was more an issue of that we needed the code somewhere and it was windows-specific, so sys.windows seemed a passable choice. The alternative would be core.internal, though I'm trying to avoid the need for that approach. If you have suggestions for how to handle this, please let me know :-) Sent from my iPhone On Jun 12, 2011, at 8:37 AM, David Nadlinger wrote: > On 6/12/11 5:06 PM, Andrei Alexandrescu wrote: >> On 6/12/11 1:38 AM, David Nadlinger wrote: >>> core.stdc is the place for C standard library modules, core.sys.* are >>> where the C operating system header translations reside – this is our >>> current policy, right? If so (I can't actually remember any formal >>> decision or discussion), is there a reason we still have so much code in >>> std.c? >>> >>> David >> >> The reason is a smart GSoC student didn't yet come and deprecate them :o). > > Smart? Can't possibly be me… ;) > > On a closer look, I discovered that contrary to core.sys.posix and > core.sys.osx, which only have C header translations, core.sys.windows.* also > contains support code like backtrace.d, thradaux.d, etc. > > Is the »official« package structure actually documented anywhere? > > David
Re: Undefined (Win32) Externals
On Jun 13, 11 07:16, Jonathan M Davis wrote:
On 2011-06-12 15:39, Loopback wrote:
Hi!
Let me begin by saying, that I haven't used Usenet newsgroup at all, so
please excuse me for any errors or misunderstandings of the guidelines.
I recently begun programming a win32 application though I instantly got
stuck with a problem. As you might know, win32 applications require that
you define the WindowProc function for processing window messages.
I've used a object-oriented approach for this, and that requires that
you declare the WindowProc function as static, and bind your own class
(hWnd) to GWL_USERDATA, to be able to call your own, class defined,
message handler (WindowProc). To do this, you have to access the two
functions GetWindowLong and SetWindowLong.
For some reason, these functions do not exist in the windows module
(std.c.windows.windows), neither does the GWL_USERDATA constant.
To solve this I've used this alternative code:
extern (Windows)
{
int GWL_USERDATA;
LONG SetWindowLong(HWND, int, LONG);
LONG GetWindowLong(HWND, int);
}
When I then try to compile this application, the GWL_USERDATA constant
compiles without any errors, but the Get-/SetWindowLong produces linker
errors.
To solve the linker errors, I checked which library they were contained
in, on MSDN it said User32.lib. Therefore I linked to this library -
without any success.
So to summarize, how do I solve these linker errors:
Error 42: Symbol Undefined _SetWindowLong@12
Error 42: Symbol Undefined _GetWindowLong@8
Sorry for such a long message!
Any help is greatly appreciated!
I believe that you need extern(C) around those functions. They're C functions,
not D functions.
- Jonathan M Davis
extern(Windows) is correct since they have WINAPI calling convention.
The problem is their actual names are Get/SetWindowLongW/A...
Re: Undefined (Win32) Externals
Well most API functions stay the same for a long time on Windows.
Examples compiled in 1998 for Windows 98 will compile in 2011 for
Windows 7, and they will both run fine. At least the simple ones will.
The bindings /might/ be missing some new vista/win7 function
prototypes but I'm not sure if that's true or not. And if you use
vista/win7 features exclusively, you can say goodbye to compatibility
with pre-vista systems (if you care about that).
I'm not sure why your example is not compiling for you, it does for me:
import std.c.windows.windows;
extern (Windows)
{
int GWL_USERDATA;
LONG SetWindowLong(HWND, int, LONG);
LONG GetWindowLong(HWND, int);
}
void main()
{
}
But try replacing the prototypes with this (notice the A at the end):
LONG SetWindowLongA(HWND, int, LONG);
LONG GetWindowLongA(HWND, int);
Which DMD version are you running?
Small article about Scala, tuples
A small intro to basic Scala programming, it shows nothing of the advanced
Scala features. It seems Scala too use Python-style tuples:
http://www.artima.com/weblogs/viewpost.jsp?thread=328540
I've created a small test of Scala tuples:
http://ideone.com/9wrJc
object Main {
def main(args: Array[String]) {
val t2 = (1, 2)
println(t2) // (1,2)
// It's just syntax sugar for:
val t2b = new Tuple2(1, 2)
println(t2 == t2b) // true
val t3 = (1, 2, 3)
println(t3) // (1,2,3)
// unpacking syntax:
val (x, _) = t2
println(x) // 1
// alternative tuple literal syntax:
val t2c = 1 -> 2
println(t2 == t2c) // true
// the alternative tuple syntax allows to
// define maps as not built-ins:
val d = Map(1->2, 3->4)
println(d) // Map(1 -> 2, 3 -> 4)
// The single item "tuple" seems to not have literal sugar:
val t1 = Tuple1(1)
println(t1) // (1)
//val t1b = (1,) // syntax error
val t1c = (1)
val i = 1
println(t1c == 1) // true
}
}
Output:
(1,2)
true
(1,2,3)
1
true
Map(1 -> 2, 3 -> 4)
(1)
true
The tuple literals when printed don't show the types of the single items, I
think it's better for D tuples to do the same, despite the little loss of
precision, because they become more readable.
In D tuples are useful in other situations too:
forach ((a, b); zip([1,2,3], "abc")) {...
auto t2 = tuple(1, 100);
switch (t2) {
case tuple(1, _):
default:
}
Bye,
bearophile
Re: imports in functions
On 6/13/11, Jonathan M Davis wrote: < snip> So much for my blurry recollection of C++ features. :-)
Re: Undefined (Win32) Externals
On 2011-06-13 00:50, Andrej Mitrovic wrote: Use the WindowsAPI bindings from here: http://dsource.org/projects/bindings/wiki/WindowsApi Pass -version=Unicode and various other version specifiers based on what you need. Otherwise, a typical Win32 example looks like this: http://codepad.org/cP2XrrHS For what it's worth, I will (hopefully) soon publish D translated examples from the Programming Windows book, by Charles Petzold. It contains about 145 examples (a few dozen were left out in the D translation because they covered 8-bit displays which don't exist anymore). But I have yet to receive an e-mail back from Petzold regarding the copyright/licensing of his code. Until I get back from him, I can't publish the code. Great, thanks for the link! Though I do have to ask, are these bindings any mature? Most of the files in the SVN repository are about 4 years old.
Re: Undefined (Win32) Externals
On 2011-06-13 01:16, Jonathan M Davis wrote:
On 2011-06-12 15:39, Loopback wrote:
Hi!
Let me begin by saying, that I haven't used Usenet newsgroup at all, so
please excuse me for any errors or misunderstandings of the guidelines.
I recently begun programming a win32 application though I instantly got
stuck with a problem. As you might know, win32 applications require that
you define the WindowProc function for processing window messages.
I've used a object-oriented approach for this, and that requires that
you declare the WindowProc function as static, and bind your own class
(hWnd) to GWL_USERDATA, to be able to call your own, class defined,
message handler (WindowProc). To do this, you have to access the two
functions GetWindowLong and SetWindowLong.
For some reason, these functions do not exist in the windows module
(std.c.windows.windows), neither does the GWL_USERDATA constant.
To solve this I've used this alternative code:
extern (Windows)
{
int GWL_USERDATA;
LONG SetWindowLong(HWND, int, LONG);
LONG GetWindowLong(HWND, int);
}
When I then try to compile this application, the GWL_USERDATA constant
compiles without any errors, but the Get-/SetWindowLong produces linker
errors.
To solve the linker errors, I checked which library they were contained
in, on MSDN it said User32.lib. Therefore I linked to this library -
without any success.
So to summarize, how do I solve these linker errors:
Error 42: Symbol Undefined _SetWindowLong@12
Error 42: Symbol Undefined _GetWindowLong@8
Sorry for such a long message!
Any help is greatly appreciated!
I believe that you need extern(C) around those functions. They're C functions,
not D functions.
- Jonathan M Davis
Thanks for you reply though linker errors (Symbol Undefined) are still
generated even though I've specified the functions as external C.
Re: Undefined (Win32) Externals
On 2011-06-12 15:39, Loopback wrote:
> Hi!
>
> Let me begin by saying, that I haven't used Usenet newsgroup at all, so
> please excuse me for any errors or misunderstandings of the guidelines.
>
> I recently begun programming a win32 application though I instantly got
> stuck with a problem. As you might know, win32 applications require that
> you define the WindowProc function for processing window messages.
>
> I've used a object-oriented approach for this, and that requires that
> you declare the WindowProc function as static, and bind your own class
> (hWnd) to GWL_USERDATA, to be able to call your own, class defined,
> message handler (WindowProc). To do this, you have to access the two
> functions GetWindowLong and SetWindowLong.
>
> For some reason, these functions do not exist in the windows module
> (std.c.windows.windows), neither does the GWL_USERDATA constant.
>
> To solve this I've used this alternative code:
>
> extern (Windows)
> {
> int GWL_USERDATA;
> LONG SetWindowLong(HWND, int, LONG);
> LONG GetWindowLong(HWND, int);
> }
>
> When I then try to compile this application, the GWL_USERDATA constant
> compiles without any errors, but the Get-/SetWindowLong produces linker
> errors.
>
> To solve the linker errors, I checked which library they were contained
> in, on MSDN it said User32.lib. Therefore I linked to this library -
> without any success.
>
> So to summarize, how do I solve these linker errors:
>
> Error 42: Symbol Undefined _SetWindowLong@12
> Error 42: Symbol Undefined _GetWindowLong@8
>
> Sorry for such a long message!
> Any help is greatly appreciated!
I believe that you need extern(C) around those functions. They're C functions,
not D functions.
- Jonathan M Davis
Re: imports in functions
On 2011-06-12 15:08, Andrej Mitrovic wrote: > This seems like a way to simulate namespaces in C++, right? I wouldn't > know, but it looks similar to that 'using foo' trick. C++ namespaces are completely different. Everything in a namespace has to be referenced by its namespace explicitly unless you use using. So, without using, you need to do stuff like std::vector v; whereas with using namespace std; vector v; you don't need the std:: tag anymore. Using namespace affects _everything_ after it, which is why it's pretty much verboten in header files (otherwise it would pollute the global namespace). And whether you have a using statement or not, as soon as you #include a file, everything in it is visible in the current file. Namespaces just segregate the names so that they don't clash. D modules are very different. As soon as you import a module, everything in that module is visible (though you can't use anything in it unless it's public or the current module is in the same package and it's package or if you're deriving from class in that module and the symbol in question is protected). You don't have to use the module name when using _any_ of its symbols unless names clash or you imported the module statically. It's kind of like you automatically have a using statement all of the time, except that it's much more sophisticated and handles name clashes much better. By importing within a function, you're saying that only that function has access to the symbols within the module being imported. As for as the rest of the module is concerned, the imported module does not actually exist. You're restricting what can see it. So, I'm not quite sure what you mean by this simulating C++ namespaces. They both deal with how symbols are brought into and viewable in the current file, but they're very different. - Jonathan M Davis
Re: Undefined (Win32) Externals
Use the WindowsAPI bindings from here: http://dsource.org/projects/bindings/wiki/WindowsApi Pass -version=Unicode and various other version specifiers based on what you need. Otherwise, a typical Win32 example looks like this: http://codepad.org/cP2XrrHS For what it's worth, I will (hopefully) soon publish D translated examples from the Programming Windows book, by Charles Petzold. It contains about 145 examples (a few dozen were left out in the D translation because they covered 8-bit displays which don't exist anymore). But I have yet to receive an e-mail back from Petzold regarding the copyright/licensing of his code. Until I get back from him, I can't publish the code.
Re: imports in functions
On 13.06.2011 1:15, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in
functions. These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially
when using mixins, versioning and other conditional compilation
constructs.
Also very helpful for unittests, thanks.
--
Dmitry Olshansky
Re: Flag proposal [OT]
On 12/06/2011 16:11, Steven Schveighoffer wrote: On Sun, 12 Jun 2011 04:36:55 -0400, Alix Pexton wrote: On 12/06/2011 02:40, Steven Schveighoffer wrote: On Sat, 11 Jun 2011 13:04:47 -0400, Andrej Mitrovic wrote: On 6/11/11, Alix Pexton wrote: On 11/06/2011 06:18, Andrej Mitrovic wrote: We should rename Yes and No to Yay and Nay to make them alignable, and even more importantly to make us appear as old Englishmen! "Yay" and "Nay" are too similar looking, but luckily, "Yay" is not actually a old English word :) A more correct alternative would be "Aye" (pronounced the same as "eye"), which (along with "Nay") is still used for some voting actions (such as councillors deciding where to go for lunch). I myself say it al least 20 times a day :) A... Oh damn, yay is what teenage girls would say, not old Englishmen. My bad, it really is "Aye". :p You were phonetically right :) It's yea or nay. http://dictionary.cambridge.org/dictionary/british/yea-or-nay My son's most recent birthday (3 years old) was a farm-themed birthday, and we asked people to RSVP yay or neigh :P So I guess there's all kinds of kooky fun you can have with flags... -Steve Nope, its definitely Aye when used for voting, (at least it is round here) as in "all those in favour, say aye", "ayes to the right" and "the ayes have it". Maybe southerners say this "yea" word of which you speak, we don't hold with their strange customs in these parts ^^ I don't deny that aye is used frequently for voting. All I was saying is, the correct expression is yea or nay, not yay or nay. Andrej thought it was actually aye or nay, which I've never heard as an expression. I'm not sure it's used anymore, but it's definitely an expression that was used for voting (see my dictionary reference). -Steve True, "yea-or-nay" is quite a common, if old fashioned phrase, but "yea" on its own is exceptionally rare (to the point where I doubt ever hearing anyone make such a noise and mean it to indicate the affirmative). A...
Undefined (Win32) Externals
Hi!
Let me begin by saying, that I haven't used Usenet newsgroup at all, so
please excuse me for any errors or misunderstandings of the guidelines.
I recently begun programming a win32 application though I instantly got
stuck with a problem. As you might know, win32 applications require that
you define the WindowProc function for processing window messages.
I've used a object-oriented approach for this, and that requires that
you declare the WindowProc function as static, and bind your own class
(hWnd) to GWL_USERDATA, to be able to call your own, class defined,
message handler (WindowProc). To do this, you have to access the two
functions GetWindowLong and SetWindowLong.
For some reason, these functions do not exist in the windows module
(std.c.windows.windows), neither does the GWL_USERDATA constant.
To solve this I've used this alternative code:
extern (Windows)
{
int GWL_USERDATA;
LONG SetWindowLong(HWND, int, LONG);
LONG GetWindowLong(HWND, int);
}
When I then try to compile this application, the GWL_USERDATA constant
compiles without any errors, but the Get-/SetWindowLong produces linker
errors.
To solve the linker errors, I checked which library they were contained
in, on MSDN it said User32.lib. Therefore I linked to this library -
without any success.
So to summarize, how do I solve these linker errors:
Error 42: Symbol Undefined _SetWindowLong@12
Error 42: Symbol Undefined _GetWindowLong@8
Sorry for such a long message!
Any help is greatly appreciated!
Re: Fixing the imaginary/complex mess
Andrei:
> Don, instead of this fix, could be at best phase everything built-in
> about complex out?
Two usages of complex numbers in the RosettaCode site.
Acommon place where you find complex numbers is to plot Mandelbrot/Julia sets:
http://rosettacode.org/wiki/Mandelbrot_set#D
import std.stdio, std.math;
void main() {
enum maxIter = 1000;
foreach (y; -39 .. 39) {
foreach (x; -39 .. 39) {
auto c = y/40.0 - 0.5 + x/40.0i,
z = 0.0 + 0.0i,
i = 0;
for (; i < maxIter && abs(z) < 4; i++)
z = z ^^ 2 + c;
write(i == maxIter ? '#' : ' ');
}
writeln();
}
}
Version using std.complex:
import std.stdio, std.complex;
void main() {
enum maxIter = 1000;
foreach (y; -39 .. 39) {
foreach (x; -39 .. 39) {
auto c = Complex!double(y/40.0 - 0.5, x/40.0),
z = Complex!double(0, 0),
i = 0;
for (; i < maxIter && z.abs() < 4; i++)
z = z ^^ 2 + c;
write(i == maxIter ? '#' : ' ');
}
writeln();
}
}
I think it's worth adding to std.complex module few examples of usage, plus a
complex() function so you are allowed to write (the imaginary part defaults to
zero if the real part is set to zero):
auto z = complex(5);
Instead of:
auto z = Complex!double(5, 0);
complex(5) probably has to create a Complex!double and not a Complex!int (that
is not even supported, std.complex.Complex support floating point values only).
---
Another common usage of D complex numbers is to represent generic 2D points.
http://rosettacode.org/wiki/Constrained_random_points_on_a_circle#D
Original code (to plot some points in a circle):
import std.stdio, std.random, std.math;
void main() {
char[31][31] table = ' ';
foreach (i; 0 .. 100) {
int x, y;
do {
x = uniform(-15, 16);
y = uniform(-15, 16);
} while(abs(12.5 - abs(x + y * 1i)) > 2.5);
table[x + 15][y + 15] = '*';
}
foreach (row; table)
writeln(row);
}
Version using std.complex:
import std.stdio, std.random, std.complex, std.math;
void main() {
char[31][31] table = ' ';
foreach (i; 0 .. 100) {
int x, y;
do {
x = uniform(-15, 16);
y = uniform(-15, 16);
} while(abs(12.5 - Complex!double(x, y).abs) > 2.5);
table[x + 15][y + 15] = '*';
}
foreach (row; table)
writeln(row);
}
---
Regarding the printing of Complex values, this program:
import std.stdio, std.complex;
void main() {
writeln(Complex!double(0, -1));
}
Prints:
0-1i
While Python prints the same complex number as:
>>> 0-1j
-1j
Bye,
bearophile
Re: imports in functions
On Sun, 12 Jun 2011 14:15:27 -0700, Walter Bright wrote:
> Nobody seems to have noticed yet, but yesterday I removed the
> restriction preventing import declarations from being used in functions.
> These now work:
>
> void test1()
> {
> import std.c.stdio;
> printf("hello world\n");
> }
>
> void test2()
> {
> static import std.c.stdio;
> std.c.stdio.printf("hello world\n");
> }
>
> https://github.com/D-Programming-Language/dmd/commit/
d5fbd53aa8d8452dce2514944575e654d387477a
>
> I believe this can lead to better encapsulation of code, especially when
> using mixins, versioning and other conditional compilation constructs.
Cool! This is a definite improvement. :)
-Lars
Re: imports in functions
This seems like a way to simulate namespaces in C++, right? I wouldn't know, but it looks similar to that 'using foo' trick.
Re: imports in functions
On 06/12/2011 04:33 PM, Adam D. Ruppe wrote: This is awesome! Another benefit here is code running programs are simplified. For "D script" kind of things, a technique I use is to simply wrap some code inside a main function. Almost every feature worked there - nested functions, structs, classes, etc. Now imports do too! Yay! This bodes well for your "run this online" thing, too. All we need to do is wrap a main() around the example code and it should work. Andrei
Re: imports in functions
This is awesome! Another benefit here is code running programs are simplified. For "D script" kind of things, a technique I use is to simply wrap some code inside a main function. Almost every feature worked there - nested functions, structs, classes, etc. Now imports do too! Yay!
Re: imports in functions
On 06/12/2011 04:15 PM, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.
Fabulous. std.benchmark already uses the feature, and from a mixin no less:
https://github.com/andralex/phobos/commit/c5f2778a0fc393d6bd17ebec4765b28937575c31
One interesting aspect of the feature is that if import is used from
within a template, it's not actually imported unless the template is
instantiated.
Andrei
imports in functions
Nobody seems to have noticed yet, but yesterday I removed the restriction
preventing import declarations from being used in functions. These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when using
mixins, versioning and other conditional compilation constructs.
Re: Flag proposal
On 6/12/2011 1:54 PM, Andrei Alexandrescu wrote: On 06/12/2011 03:55 PM, foobar wrote: People here already noted most advantages and disadvantages of this proposal so I'll just add one more: KISS. I too am against this proposal since it's very unKISS. I agree that KISS is important and that Flag is failing it. Set phasers to "vaporize".
Re: Fixing the imaginary/complex mess
On 04/30/2009 02:20 PM, Don wrote: D currently allows some conversions between complex/imaginary types and real types, which are highly dubious. Given creal z, ireal y, these casts are legal: real x = cast(real)z; x = cast(real)y; // always sets x==0, regardless of the value of y. But I believe that should not be legal. For the first case, it should be written as: real x = z.re; (which is shorter and clearer), and the second case is probably a bug, and should be x = y.im; (unless the intention really was to set x=0!). By the same logic, we could have sqrt(-1)==0, since the real part is 0. The most important effect of disallowing these casts would be to fix a host of bugs and wierd behaviour. All the A op= B operations involve a cast to A. If those nonsensical casts become illegal, the nonsensical op= operations become illegal automatically. Eg, ireal y; y *= y; // mathematically nonsense, y*y is real, so can't be stored in a pure imaginary type! There are a few segfault/ICE bugs (eg 718, 2839) which involve int/=complex, an operation which never makes any sense anyway. I think we're just making problems for ourselves by allowing these useless operations. I think they should be killed. Does anyone object? (If not, I'll create a patch to do it; it's not very difficult). Don, instead of this fix, could be at best phase everything built-in about complex out? Thanks, Andrei
Re: Flag proposal
On 06/12/2011 03:55 PM, foobar wrote: People here already noted most advantages and disadvantages of this proposal so I'll just add one more: KISS. I too am against this proposal since it's very unKISS. I agree that KISS is important and that Flag is failing it. Andrei
Re: Flag proposal
People here already noted most advantages and disadvantages of this proposal so I'll just add one more: KISS. I too am against this proposal since it's very unKISS. I think, that either you really need a separate enum type to document the different values and hence use *should* define the enum or you don't really need it and hence KISS it with a plain boolean. I see zero benefit from adding so much complexity here. Are we trying to kill a fly with a hammer (and by that i mean the vehicle)? I see no benefit in adding redundant "Yes" / "No" values. Regarding named arguments, I don't like this "feature" and believe that it's more trouble than its worth. For example, Ruby managed to live without it and Rails uses AAs instead. And finally, Andrei's complain about scrolling up and down because of this so called boilerplate (7 lines of code in all of phobos): Even though D has a far superior module system compared to c++ (which has no such system whatsoever) you still chose to implement library-in-a-file. You even went so far as to add "groups" to DDoc. Is there some sort of weird metric at Facebook that gives you a bigger bonus if you manage to cram more code per file? Are you getting deducted per the amount of files you've added?
Tokenized Strings -- Are Arbitrary Characters Valid?
I'm a little confused on tokenized strings -- are the following valid?
Are they supposed to be?
q{\u000A}
q{"}
q{\}
Thanks!
Re: htod converts C long to int?
Den 12-06-2011 20:05, David Nadlinger skrev: While having a look at etc.curl which has a »converted by htod« comment in its header, I noticed that values having type »long« in the original C headers are declared as »int« there – shouldn't this rather be c_long from core.stdc.config to avoid problems on non-LLP64 (i.e. non-Windows) 64 bit systems? Does htod generally behave like this? I just ran htod without any special tricks so I guess this is the default behavior. I will fix this asap. thx. /Jonas
Re: Should GC.malloc be considered 'pure'?
On Jun 10, 11 01:51, KennyTM~ wrote: Given that the 'new' expression can be used in 'pure', should it be that GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be weakly pure also? And should it apply to other managed allocators as well, e.g. the proposed TempAlloc? I'm asking this as one of the specializations of std.conv.toImpl calls GC.malloc, which is one of the 11 causes preventing std.conv.to from being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) are used by std.array.appender (of pure range), and appender is also a major reason why std.conv.to is not pure. Thanks everyone for commenting. I've turned this into a bug 6151 (http://d.puremagic.com/issues/show_bug.cgi?id=6151) so the discussion won't be lost :).
Re: pragma(mangle)
On 6/12/11 9:21 PM, Andrej Mitrovic wrote: If you take a diff of DMD's parse.c and DDMD's parser.d, you'll see that they're almost identical. So yeah, I think what DDMD devs probably do is take a diff of two DMD versions and then manually upgrade DDMD's frontend to match. I don't think it's way too much work (I'm just assuming though), simple C++ code tends to translate nicely into D and I think DMD's C++ sources are nice and readable. ddmd is obviously a different story, but just merging the commits one-by-one manually has worked quite well for me when doing LDC frontend updates. Merging a whole release worth of changes at once might be more efficient, but I found it a lot more difficult to reason about the changes that way. David
Re: pragma(mangle)
"Andrej Mitrovic" wrote in message news:mailman.849.1307906475.14074.digitalmar...@puremagic.com... > On 6/12/11, Nick Sabalausky wrote: >> "Andrei Alexandrescu" wrote in message >> news:it2l1n$1alh$2...@digitalmars.com... >>> >>> I've always wondered what's the methodology of changing ddmd from diffs >>> in >>> >>> dmd. I can only imagine it as a difficult manual process. >>> >> >> I've recently asked about that on the DDMD forum. No response yet, but >> it's >> not really a high-traffic forum anyway: >> http://www.dsource.org/forums/viewtopic.php?t=5946&sid=4ece5dbd7a2352d5de1f61b14452733f >> >> As I said there: "I would guess that right strategy would be to compare >> two >> versions of DMD (ie, the one DDMD is currently based on, and the one >> you're >> trying to update to), and then recreate the changes in DDMD." >> > > If you take a diff of DMD's parse.c and DDMD's parser.d, you'll see > that they're almost identical. So yeah, I think what DDMD devs > probably do is take a diff of two DMD versions and then manually > upgrade DDMD's frontend to match. I don't think it's way too much work > (I'm just assuming though), simple C++ code tends to translate nicely > into D and I think DMD's C++ sources are nice and readable. The AST is different though. I haven't compared the contents of the files, but a quick comparison of the directory contents suggests that DMD has many different AST classes in a single .h/.c combo (with a separate .h/.c combo for each "category" of AST class types), wheras DDMD splits all the AST types into their own separate .d files. Also, since C++ and D syntax is naturally different, a file compare between a .c and .d would come up with a lot of "changes" that are just syntax differences and not real changes at all. I'd imagine there'd be a lot of that to sort through.
Re: Flag proposal
"Timon Gehr" wrote in message
news:it0oee$ehu$1...@digitalmars.com...
> Jonathan M Davis wrote:
>> ...
>> The complaints about this generally seem to be one of these:
>>
>> 1. Dislike of the yes/no enum idiom in the first place. Regardless of how
>> Flag
>> does it, it's a problem, because it's promoting an idiom that the poster
>> dislikes in the first place.
>>
>> 2. Flag!"enumName".yes and Flag!"enumName".no are ugly.
>>
>> 3. The use of a template such as Flag results in ugly error messages when
>> it's
>> mistyped. EnumName.yes gets _much_ better errors when mistyped than
>> Flag!"enumName".yes.
>>
>> 4. Flag is seen as a narrow attempt at named arguments which would be far
>> better served by actually implementing named arguments.
>> [snip.]
>
> 5. The approach is too sophisticated and does not pull its own weight.
> Imagine what you would have to explain to somebody new to the language who
> wondered how Yes.sortOutput works... instant turn-off!
>
Not only that, but just simply trying to explain why you sometimes do
"enumName.value" and sometimes do "value.enumName". It introduces a big
inconsistency for callers, just for the sake of a trivial decrease in
boilerplate for the callee.
Also, one thing I'm unclear on:
If you do:
void foo(Flag!"bar" a) {}
Can the caller do something like this?:
bar barValue = yes.bar;
foo(barValue);
Re: pragma(mangle)
On 6/12/11, Nick Sabalausky wrote: > "Andrei Alexandrescu" wrote in message > news:it2l1n$1alh$2...@digitalmars.com... >> On 6/12/11 4:23 AM, Nick Sabalausky wrote: >>> "Andrej Mitrovic" wrote in message >>> news:mailman.828.1307833235.14074.digitalmar...@puremagic.com... On 6/12/11, Nick Sabalausky wrote: > Are you working on updating DDMD to a newer DMD, or just simply trying > to > use the newer backend? If the former, then that's fantastic and I look > forward to it. I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size. >>> >>> Actually, what I meant was this: DDMD is currently based on DMD 2.040. >>> Ie, >>> ATM, it's DMD 2.040 ported to D. You said you were trying to use the >>> 2.053 >>> backend with DDMD, so I was just wondering if you were also updating DDMD >>> frontend to be a D port of something newer than 2.040. >> >> I've always wondered what's the methodology of changing ddmd from diffs in >> >> dmd. I can only imagine it as a difficult manual process. >> > > I've recently asked about that on the DDMD forum. No response yet, but it's > not really a high-traffic forum anyway: > http://www.dsource.org/forums/viewtopic.php?t=5946&sid=4ece5dbd7a2352d5de1f61b14452733f > > As I said there: "I would guess that right strategy would be to compare two > versions of DMD (ie, the one DDMD is currently based on, and the one you're > trying to update to), and then recreate the changes in DDMD." > If you take a diff of DMD's parse.c and DDMD's parser.d, you'll see that they're almost identical. So yeah, I think what DDMD devs probably do is take a diff of two DMD versions and then manually upgrade DDMD's frontend to match. I don't think it's way too much work (I'm just assuming though), simple C++ code tends to translate nicely into D and I think DMD's C++ sources are nice and readable.
Re: Flag proposal
"Andrei Alexandrescu" wrote in message news:it32kq$2gfq$2...@digitalmars.com... > On 6/12/11 1:59 PM, Nick Sabalausky wrote: >> "Andrei Alexandrescu" wrote in message >> news:it1cvf$21d4$1...@digitalmars.com... >>> >>> It's the namespace pollution and the non-self-containedness of the >>> function that's most troublesome. Also see Steve's point about methods. >>> It's just untenable - to use the idiom with a class/struct method, you >>> need to go all the way _outside_ of it an plant a symbol there. >>> >> >> You can't put an enum in a class/struct? >> >>> What I find most interesting is that the lack of strong counterarguments >>> has not stood in the way of a strong emotional response. >> >> Correction: Andrei's staunch dismissal of all counterarguments has not >> stood >> in the way of a strong emotional response. >> >>> This mood has made it difficult for exchange of rational arguments. >>> Funny >>> thing is, the change is tiny. >>> >>> "Here, I'll add a handful of yes/no enums here and there in the standard >>> library, just to help some algorithms. More to come." >>> >>> "Yeah, sure, whatevs." >>> >>> "Here, there's a way to define them once so we don't need to define them >>> everywhere." >>> >> >> Correction: "Here, there's a way to solve a barely-existant problem by >> botching up syntax (and error messages) for the user." >> >>> "Gaa!!!" >>> > > I'm not sure, but I think I see a sarcasm in there. > I guess it could be taken that way, but it wasn't really my point to be sarcastic. My intent was just to summarize the way I see the situation.
Re: Flag proposal
"Andrei Alexandrescu" wrote in message
news:it32j8$2gfq$1...@digitalmars.com...
> On 6/12/11 1:45 PM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu" wrote in message
>> news:it1c0f$1uup$1...@digitalmars.com...
>>> On 06/11/2011 03:52 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:it07ni$1pvj$1...@digitalmars.com...
>
> Anyway, that was the first thing "grep yes std/*" found. Let's see the
> next one:
>
> /**
> Specifies whether the output of certain algorithm is desired in sorted
> format.
>*/
> enum SortOutput {
> no, /// Don't sort output
> yes, /// Sort output
> }
>
> This already is very unpleasant because "certain" is as imprecise as
> it
> gets. Plus one for Flag, I hope you agree.
>
Flag -= 1
s/output of certain algorithm/output of an algorithm/ += 1
That one-word doc change makes it all perfectly clear.
>>>
>>> Not at all. The typo in the original text must have confused you: it
>>> should be "certain algorithms" because SortOutput is used in four
>>> distinct
>>> algorithms (one of which has two overloads). Grep std/algorithm.d.
>>>
>>> Flag += 2
>>>
>>
>> Not that I consider quibbling over small English wording differences a
>> major
>> thing, but I fail to see how:
>>
>> "Specifies whether the output of an algorithm is desired in sorted
>> format."
>>
>> is significantly different from:
>>
>> "Specifies whether the output of certain algorithms are desired in sorted
>> format."
>>
>> In either case, I don't see anything problematically imprecise.
>
> Still means I need to jump back and forth in the documentation.
>
And you don't like the "///ditto" suggestion for handling that?
Re: Flag proposal
"Andrei Alexandrescu" wrote in message
news:it1cd7$1vv2$1...@digitalmars.com...
> On 06/11/2011 04:58 PM, Timon Gehr wrote:
>> Jonathan M Davis wrote:
>>> ...
>>> The complaints about this generally seem to be one of these:
>>>
>>> 1. Dislike of the yes/no enum idiom in the first place. Regardless of
>>> how Flag
>>> does it, it's a problem, because it's promoting an idiom that the poster
>>> dislikes in the first place.
>>>
>>> 2. Flag!"enumName".yes and Flag!"enumName".no are ugly.
>>>
>>> 3. The use of a template such as Flag results in ugly error messages
>>> when it's
>>> mistyped. EnumName.yes gets _much_ better errors when mistyped than
>>> Flag!"enumName".yes.
>>>
>>> 4. Flag is seen as a narrow attempt at named arguments which would be
>>> far
>>> better served by actually implementing named arguments.
>>> [snip.]
>>
>> 5. The approach is too sophisticated and does not pull its own weight.
>> Imagine what you would have to explain to somebody new to the language
>> who
>> wondered how Yes.sortOutput works... instant turn-off!
>>
>>
>> What about allowing anonymous enums in parameter lists? Unfortunately
>> that would
>> be a language feature. :)
>>
>> T someAlgorithm(..., enum {unsorted, sorted} sortOutput);
>>
>> To call: someAlgorithm(..., sorted); / someAlgorithm(..., unsorted);
I like the basic idea, and it's a change that falls into the "removing
restrictions" category.
But the issue "so" brought up with this about not being able to pass in a
variable would need to be solved for the general case. It's trivial in the
case of two options:
bool useSorted = ...;
someAlgorithm(..., useSorted? sorted : unsorted);
Although, really, that just shifts the boilerplate from the callee to the
caller, so it's really a net loss.
You could maybe do:
T someAlgorithm(..., enum Sorted {yes, no} sortOutput);
Which would be equivalent to:
enum Sorted {yes, no}
T someAlgorithm(..., Sorted sortOutput);
But I don't now if Andrei would like that (it makes the func signature kinda
verbose, too).
>
> I proposed this to Walter some years ago, around the time I was
> anticipating the nascent yes/no enum proliferation. The problem with this
> is it defines a type in a function parameter specification, which is
> unprecedented and therefore surprising.
>
Your Flag idiom essentially defines a type in a function parameter
specification.
Re: Flag proposal
On 6/12/11 1:59 PM, Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:it1cvf$21d4$1...@digitalmars.com... It's the namespace pollution and the non-self-containedness of the function that's most troublesome. Also see Steve's point about methods. It's just untenable - to use the idiom with a class/struct method, you need to go all the way _outside_ of it an plant a symbol there. You can't put an enum in a class/struct? What I find most interesting is that the lack of strong counterarguments has not stood in the way of a strong emotional response. Correction: Andrei's staunch dismissal of all counterarguments has not stood in the way of a strong emotional response. This mood has made it difficult for exchange of rational arguments. Funny thing is, the change is tiny. "Here, I'll add a handful of yes/no enums here and there in the standard library, just to help some algorithms. More to come." "Yeah, sure, whatevs." "Here, there's a way to define them once so we don't need to define them everywhere." Correction: "Here, there's a way to solve a barely-existant problem by botching up syntax (and error messages) for the user." "Gaa!!!" I'm not sure, but I think I see a sarcasm in there. Andrei
Re: Flag proposal
"Andrei Alexandrescu" wrote in message news:it1cvf$21d4$1...@digitalmars.com... > > It's the namespace pollution and the non-self-containedness of the > function that's most troublesome. Also see Steve's point about methods. > It's just untenable - to use the idiom with a class/struct method, you > need to go all the way _outside_ of it an plant a symbol there. > You can't put an enum in a class/struct? > What I find most interesting is that the lack of strong counterarguments > has not stood in the way of a strong emotional response. Correction: Andrei's staunch dismissal of all counterarguments has not stood in the way of a strong emotional response. > This mood has made it difficult for exchange of rational arguments. Funny > thing is, the change is tiny. > > "Here, I'll add a handful of yes/no enums here and there in the standard > library, just to help some algorithms. More to come." > > "Yeah, sure, whatevs." > > "Here, there's a way to define them once so we don't need to define them > everywhere." > Correction: "Here, there's a way to solve a barely-existant problem by botching up syntax (and error messages) for the user." > "Gaa!!!" >
Re: Flag proposal
On 6/12/11 1:45 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:it1c0f$1uup$1...@digitalmars.com...
On 06/11/2011 03:52 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:it07ni$1pvj$1...@digitalmars.com...
Anyway, that was the first thing "grep yes std/*" found. Let's see the
next one:
/**
Specifies whether the output of certain algorithm is desired in sorted
format.
*/
enum SortOutput {
no, /// Don't sort output
yes, /// Sort output
}
This already is very unpleasant because "certain" is as imprecise as it
gets. Plus one for Flag, I hope you agree.
Flag -= 1
s/output of certain algorithm/output of an algorithm/ += 1
That one-word doc change makes it all perfectly clear.
Not at all. The typo in the original text must have confused you: it
should be "certain algorithms" because SortOutput is used in four distinct
algorithms (one of which has two overloads). Grep std/algorithm.d.
Flag += 2
Not that I consider quibbling over small English wording differences a major
thing, but I fail to see how:
"Specifies whether the output of an algorithm is desired in sorted format."
is significantly different from:
"Specifies whether the output of certain algorithms are desired in sorted
format."
In either case, I don't see anything problematically imprecise.
Still means I need to jump back and forth in the documentation.
Andrei
Re: Flag proposal
"Andrei Alexandrescu" wrote in message
news:it1c0f$1uup$1...@digitalmars.com...
> On 06/11/2011 03:52 PM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu" wrote in message
>> news:it07ni$1pvj$1...@digitalmars.com...
>>>
>>> Anyway, that was the first thing "grep yes std/*" found. Let's see the
>>> next one:
>>>
>>> /**
>>> Specifies whether the output of certain algorithm is desired in sorted
>>> format.
>>> */
>>> enum SortOutput {
>>> no, /// Don't sort output
>>> yes, /// Sort output
>>> }
>>>
>>> This already is very unpleasant because "certain" is as imprecise as it
>>> gets. Plus one for Flag, I hope you agree.
>>>
>>
>> Flag -= 1
>> s/output of certain algorithm/output of an algorithm/ += 1
>>
>> That one-word doc change makes it all perfectly clear.
>
> Not at all. The typo in the original text must have confused you: it
> should be "certain algorithms" because SortOutput is used in four distinct
> algorithms (one of which has two overloads). Grep std/algorithm.d.
>
> Flag += 2
>
Not that I consider quibbling over small English wording differences a major
thing, but I fail to see how:
"Specifies whether the output of an algorithm is desired in sorted format."
is significantly different from:
"Specifies whether the output of certain algorithms are desired in sorted
format."
In either case, I don't see anything problematically imprecise.
Re: Flag proposal
"Jonathan M Davis" wrote in message news:mailman.841.1307850316.14074.digitalmar...@puremagic.com... > but the > difference between EnumName.yes and Yes.EnumName for the user is pretty > much > nonexistant except for the fact that Yes.EnumName will have worse error > messages. It also creates an awkward inconsistency. Most enums are X.Y, but then callint certain functions it's Y.X
Re: Flag proposal [OT]
TBH I've only ever heard it used in Ali G Indahouse, so what do I know.. :p
Re: pragma(mangle)
"Andrei Alexandrescu" wrote in message news:it2l1n$1alh$2...@digitalmars.com... > On 6/12/11 4:23 AM, Nick Sabalausky wrote: >> "Andrej Mitrovic" wrote in message >> news:mailman.828.1307833235.14074.digitalmar...@puremagic.com... >>> On 6/12/11, Nick Sabalausky wrote: Are you working on updating DDMD to a newer DMD, or just simply trying to use the newer backend? If the former, then that's fantastic and I look forward to it. >>> >>> I'd like to really work on it properly (it would seem like an exciting >>> project to work on!), and update DDMD to be more D2-like, e.g. that >>> entire main.d module seems to re-implement argument passing via C APIs >>> just like DMD's C++ code, but this seems unnecessary to me? Replacing >>> that with getopt() would cut that module down to a tiny fragment of >>> its original size. >>> >> >> Actually, what I meant was this: DDMD is currently based on DMD 2.040. >> Ie, >> ATM, it's DMD 2.040 ported to D. You said you were trying to use the >> 2.053 >> backend with DDMD, so I was just wondering if you were also updating DDMD >> frontend to be a D port of something newer than 2.040. > > I've always wondered what's the methodology of changing ddmd from diffs in > dmd. I can only imagine it as a difficult manual process. > I've recently asked about that on the DDMD forum. No response yet, but it's not really a high-traffic forum anyway: http://www.dsource.org/forums/viewtopic.php?t=5946&sid=4ece5dbd7a2352d5de1f61b14452733f As I said there: "I would guess that right strategy would be to compare two versions of DMD (ie, the one DDMD is currently based on, and the one you're trying to update to), and then recreate the changes in DDMD."
Re: htod converts C long to int?
htod doesn't know anything about c_long afaik. And since it runs on Windows only, I guess it was hardcoded to think that long would always be an int.
Re: [OT] D's community is awesome!
Andrej Mitrovic wrote: > Holy hell Chrome loads it in a blink of an eye, no lag whatsoever and > there's no laggy scrollbar either. Kudos to Google, I guess. Google did an awesome job with webkit and v8 (plus loads of caching). I'm running firefox 5 beta however and it's catching up with IE9 and chrome in performance. std.algorithm loads in 1-2 seconds and scrolling is fine.
htod converts C long to int?
While having a look at etc.curl which has a »converted by htod« comment in its header, I noticed that values having type »long« in the original C headers are declared as »int« there – shouldn't this rather be c_long from core.stdc.config to avoid problems on non-LLP64 (i.e. non-Windows) 64 bit systems? Does htod generally behave like this? David
Re: core.sys/core.stdc vs. std.c?
On 6/12/11 5:06 PM, Andrei Alexandrescu wrote: On 6/12/11 1:38 AM, David Nadlinger wrote: core.stdc is the place for C standard library modules, core.sys.* are where the C operating system header translations reside – this is our current policy, right? If so (I can't actually remember any formal decision or discussion), is there a reason we still have so much code in std.c? David The reason is a smart GSoC student didn't yet come and deprecate them :o). Smart? Can't possibly be me… ;) On a closer look, I discovered that contrary to core.sys.posix and core.sys.osx, which only have C header translations, core.sys.windows.* also contains support code like backtrace.d, thradaux.d, etc. Is the »official« package structure actually documented anywhere? David
Re: Flag proposal
On 6/11/11 8:49 PM, Steven Schveighoffer wrote:
On Sat, 11 Jun 2011 17:32:56 -0400, David Nadlinger
wrote:
On 6/11/11 11:20 PM, Jonathan M Davis wrote:
1. Programmers following this idiom (including the Phobos devs) end up
creating enums with yes and no values and are effectively identical
to other
enums except for their names. So, we end up with a fair bit of
boilerplate
code just to pass a strict boolean value.
s/fair/tiny/, imho:
---
/// ditto.
enum SomeFlag { enable, disable }
---
A big problem with this (and enums in general), what if your flag
function is defined inside a struct or class?
struct MyStruct
{
/// This function ROCKS!
void someKickAssFunction(MoreBitchin moreBitchin) {}
/// ditto
enum MoreBitchin { yes, no }
}
// the call, not so much.
s.someKickAssFunction(MyStruct.MoreBitchin.yes);
In other words, in order for your doc trick to work, member functions
have to require an additional namespace to the enum.
IMO, however, we need a better way to access the enum values without
specifying the entire namespace. The difficult part is to do it in a way
which doesn't conflict with normal symbols.
Of course, such an improvement would pull the rug from this Flag
proposal...
-Steve
Thanks, Steve, this is an excellent point - as are all you made in this
discussion (pro and con)!
Andrei
Re: Flag proposal
On 6/12/11 7:26 AM, so wrote: My take on this is that we shouldn't try to reinvent the boolean in the standard library. I think this characterization is wrong. Let me replace the meaningless Abc with an actual example, e.g. OpenRight in std.algorithm. OpenRight is not a Boolean. Its *representation* is Boolean. It is categorical data with two categories. You can represent it with an unstructured Boolean the same way you can represent an automaton state with an unstructured integer or temperature with an unstructured double, but then you'd have the disadvantages that dimensional analysis libraries are solving. Quite contrary i think it is pretty much spot on, if it is not but just its representation is boolean so is every other usage of boolean. The only reason we use an enum instead of simple bool is self documentation "fun(OpenRight.yes)". You simply can't deny the named arguments solve not only this particular issue but the entire area nicely "fun(openRight:true, width:4, height:3, depth:5)". Never did. Andrei
Re: Flag proposal [OT]
On Sun, 12 Jun 2011 04:36:55 -0400, Alix Pexton wrote: On 12/06/2011 02:40, Steven Schveighoffer wrote: On Sat, 11 Jun 2011 13:04:47 -0400, Andrej Mitrovic wrote: On 6/11/11, Alix Pexton wrote: On 11/06/2011 06:18, Andrej Mitrovic wrote: We should rename Yes and No to Yay and Nay to make them alignable, and even more importantly to make us appear as old Englishmen! "Yay" and "Nay" are too similar looking, but luckily, "Yay" is not actually a old English word :) A more correct alternative would be "Aye" (pronounced the same as "eye"), which (along with "Nay") is still used for some voting actions (such as councillors deciding where to go for lunch). I myself say it al least 20 times a day :) A... Oh damn, yay is what teenage girls would say, not old Englishmen. My bad, it really is "Aye". :p You were phonetically right :) It's yea or nay. http://dictionary.cambridge.org/dictionary/british/yea-or-nay My son's most recent birthday (3 years old) was a farm-themed birthday, and we asked people to RSVP yay or neigh :P So I guess there's all kinds of kooky fun you can have with flags... -Steve Nope, its definitely Aye when used for voting, (at least it is round here) as in "all those in favour, say aye", "ayes to the right" and "the ayes have it". Maybe southerners say this "yea" word of which you speak, we don't hold with their strange customs in these parts ^^ I don't deny that aye is used frequently for voting. All I was saying is, the correct expression is yea or nay, not yay or nay. Andrej thought it was actually aye or nay, which I've never heard as an expression. I'm not sure it's used anymore, but it's definitely an expression that was used for voting (see my dictionary reference). -Steve
Re: pragma(mangle)
On 6/12/11 4:23 AM, Nick Sabalausky wrote: "Andrej Mitrovic" wrote in message news:mailman.828.1307833235.14074.digitalmar...@puremagic.com... On 6/12/11, Nick Sabalausky wrote: Are you working on updating DDMD to a newer DMD, or just simply trying to use the newer backend? If the former, then that's fantastic and I look forward to it. I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size. Actually, what I meant was this: DDMD is currently based on DMD 2.040. Ie, ATM, it's DMD 2.040 ported to D. You said you were trying to use the 2.053 backend with DDMD, so I was just wondering if you were also updating DDMD frontend to be a D port of something newer than 2.040. I've always wondered what's the methodology of changing ddmd from diffs in dmd. I can only imagine it as a difficult manual process. Andrei
Re: core.sys/core.stdc vs. std.c?
On 6/12/11 1:38 AM, David Nadlinger wrote: core.stdc is the place for C standard library modules, core.sys.* are where the C operating system header translations reside – this is our current policy, right? If so (I can't actually remember any formal decision or discussion), is there a reason we still have so much code in std.c? David The reason is a smart GSoC student didn't yet come and deprecate them :o). Andrei
Re: Dynamic loading of shared libraries.
AFAIK, the situation is the same as when you asked last time. Still on the list.
Re: Flag proposal
so: > Quite contrary i think it is pretty much spot on, if it is not but just > its representation is boolean so is every other usage of boolean. This is an unusual teacher that use functional languages, the blog post is about booleans and related matters: http://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ (Often I don't agree with this author, but I try to read some of his posts.) Bye, bearophile
Re: article comppetition
On Sat, 11 Jun 2011 15:48:19 +0300, alan marble wrote: I'm goingg back to C++ and C# since D was staying in the spheres of irrelevancy. D away! I love this phrase, "going back to", your going back to them is the evidence you didn't come from them. And i am going back to... Erlang! (no offense Erlangens, just an analogy) It would be stupid for me to talk about freedom if i haven't earned "mine". Now you could argue that you born into one, or earning it too much of a trouble, or you didn't sign up for it, or it is just your job and the quality of the primary tool of your job doesn't matter, or... I did feed one, didn't i? Well thanks to anonymity on the interwebs!
Dynamic loading of shared libraries.
Can DMD D2/Linux do this yet?
Re: Flag proposal
On Sun, 12 Jun 2011 15:33:00 +0300, Daniel Murphy
wrote:
"Timon Gehr" wrote in message
news:it0oee$ehu$1...@digitalmars.com...
What about allowing anonymous enums in parameter lists? Unfortunately
that
would
be a language feature. :)
T someAlgorithm(..., enum {unsorted, sorted} sortOutput);
To call: someAlgorithm(..., sorted); / someAlgorithm(..., unsorted);
Wow - I actually really like this! It would provide an even _better_
solution than named arguments for this type of thing!
The best part is that it could degrade to the enum's base type when
taking a
function pointer, mangling the function's name and even inside the
function's body!
void myfunction(enum : int { option1, option2, option3 } options)
{
static assert(is(typeof(options) == int));
}
static assert(is(typeof(&myfunction) == void function(int));
myfunction(option2);
This also means you can use it only once. Not knowing the type, you can't
pass as a variable either.
The loss is too big compared to the gain.
fun_step_one(enum whatever)
fun_step_two(enum?)
enum type? val
fun(val)
Re: Flag proposal
"Timon Gehr" wrote in message
news:it0oee$ehu$1...@digitalmars.com...
>
> What about allowing anonymous enums in parameter lists? Unfortunately that
> would
> be a language feature. :)
>
> T someAlgorithm(..., enum {unsorted, sorted} sortOutput);
>
> To call: someAlgorithm(..., sorted); / someAlgorithm(..., unsorted);
>
Wow - I actually really like this! It would provide an even _better_
solution than named arguments for this type of thing!
The best part is that it could degrade to the enum's base type when taking a
function pointer, mangling the function's name and even inside the
function's body!
void myfunction(enum : int { option1, option2, option3 } options)
{
static assert(is(typeof(options) == int));
}
static assert(is(typeof(&myfunction) == void function(int));
myfunction(option2);
Re: Flag proposal
My take on this is that we shouldn't try to reinvent the boolean in the standard library. I think this characterization is wrong. Let me replace the meaningless Abc with an actual example, e.g. OpenRight in std.algorithm. OpenRight is not a Boolean. Its *representation* is Boolean. It is categorical data with two categories. You can represent it with an unstructured Boolean the same way you can represent an automaton state with an unstructured integer or temperature with an unstructured double, but then you'd have the disadvantages that dimensional analysis libraries are solving. Quite contrary i think it is pretty much spot on, if it is not but just its representation is boolean so is every other usage of boolean. The only reason we use an enum instead of simple bool is self documentation "fun(OpenRight.yes)". You simply can't deny the named arguments solve not only this particular issue but the entire area nicely "fun(openRight:true, width:4, height:3, depth:5)".
Re: Flag proposal
It's the namespace pollution and the non-self-containedness of the function that's most troublesome. Also see Steve's point about methods. It's just untenable - to use the idiom with a class/struct method, you need to go all the way _outside_ of it an plant a symbol there. What I find most interesting is that the lack of strong counterarguments has not stood in the way of a strong emotional response. This mood has made it difficult for exchange of rational arguments. Funny thing is, the change is tiny. "Here, I'll add a handful of yes/no enums here and there in the standard library, just to help some algorithms. More to come." "Yeah, sure, whatevs." "Here, there's a way to define them once so we don't need to define them everywhere." "Gaa!!!" Andrei (Trying the 3rd time, something wrong with newsreader) As you might know i prefer library solutions to language changes any day even the change is additive, yet this one i don't like. Library solutions, especially those affect user must be IMO both elegant and generic, this one is not. I think we are agree on this. There might be 7 in only std.algorithm but it is after all belongs to the std library, with the importance of phobos we can't change anything that is not accepted by majority. These are i think pretty strong arguments, though i believe it is you that needs to come up with strong arguments and i can't see any from you either :) Introducing an idiom to phobos means it is the D way, there should be many other frameworks that would use such a solution much more frequently. They will either dismiss this solution (most likely) or populate it. The former means the failure of the change, the latter is ugly code (again, when it is used more frequently). Named arguments both clean and generic. On one drawback (?) that variable names being part of library definition, i don't see how it is a drawback.
Re: pragma(mangle)
"Andrej Mitrovic" wrote in message news:mailman.828.1307833235.14074.digitalmar...@puremagic.com... > On 6/12/11, Nick Sabalausky wrote: >> Are you working on updating DDMD to a newer DMD, or just simply trying to >> use the newer backend? If the former, then that's fantastic and I look >> forward to it. > > I'd like to really work on it properly (it would seem like an exciting > project to work on!), and update DDMD to be more D2-like, e.g. that > entire main.d module seems to re-implement argument passing via C APIs > just like DMD's C++ code, but this seems unnecessary to me? Replacing > that with getopt() would cut that module down to a tiny fragment of > its original size. > Actually, what I meant was this: DDMD is currently based on DMD 2.040. Ie, ATM, it's DMD 2.040 ported to D. You said you were trying to use the 2.053 backend with DDMD, so I was just wondering if you were also updating DDMD frontend to be a D port of something newer than 2.040. > What I'm really interested in doing is building interfaces to DDMD via > various functions so it can be used by tools on demand. If I get > something rolling I might put it up on github or somewhere, will let > you know.. That does sounds cool, too :)
Re: [Submission] D Slices
> I hereby challenge you to write some real-world D code and show me a > single instance where the open-right slicing syntax would be a problem > in this regard – personally, I didn't encounter one yet after writing > several tens of thousands of lines of D code. > David besides, that's a fallacy. because, one could also challenge to write in D something that cannot be achieved in C. the fact that it can be done does not mean that there are better ways to do it. and i speak about that syntax. finally, I couldn't care less about writing "some real-world D code". I am simply not paid for that. when D will impose itself as a major language and will be required to my job, I'm gonna teach it (btw, it is the job of the students to write code, not mine). until then... oh.
Re: Flag proposal [OT]
On 12/06/2011 02:40, Steven Schveighoffer wrote: On Sat, 11 Jun 2011 13:04:47 -0400, Andrej Mitrovic wrote: On 6/11/11, Alix Pexton wrote: On 11/06/2011 06:18, Andrej Mitrovic wrote: We should rename Yes and No to Yay and Nay to make them alignable, and even more importantly to make us appear as old Englishmen! "Yay" and "Nay" are too similar looking, but luckily, "Yay" is not actually a old English word :) A more correct alternative would be "Aye" (pronounced the same as "eye"), which (along with "Nay") is still used for some voting actions (such as councillors deciding where to go for lunch). I myself say it al least 20 times a day :) A... Oh damn, yay is what teenage girls would say, not old Englishmen. My bad, it really is "Aye". :p You were phonetically right :) It's yea or nay. http://dictionary.cambridge.org/dictionary/british/yea-or-nay My son's most recent birthday (3 years old) was a farm-themed birthday, and we asked people to RSVP yay or neigh :P So I guess there's all kinds of kooky fun you can have with flags... -Steve Nope, its definitely Aye when used for voting, (at least it is round here) as in "all those in favour, say aye", "ayes to the right" and "the ayes have it". Maybe southerners say this "yea" word of which you speak, we don't hold with their strange customs in these parts ^^ A...
Re: Flag proposal
On 12.06.2011 10:31, KennyTM~ wrote: On Jun 12, 11 11:18, Andrei Alexandrescu wrote: On 06/11/2011 04:20 PM, Jonathan M Davis wrote: 2. He proposed a template wrapper which would allow you to type yes!"enumName" and no!"enumName" instead of the full Flag!"enumName".yes and Flag!"enumName".no. Some people feel that this resolves complaint #2. Others think that it's still quite ugly. Those were since replaced with No.enumName and Yes.enumName by Dmitry's idea: https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330 Andrei Yes.X and No.X looks grammatically wrong. In D you usually have 'Aggregate.member', not 'Member.aggregate'. Well, you can do only as much staying within the language. Personally, I think the biggest stumbling block is error messages, maybe we can do something about them. Like make Flag struct with alias this and provide this(Flag!s) constructor, opAssign etc. that static assert something sensible on mismatch. -- Dmitry Olshansky
Re: core.sys/core.stdc vs. std.c?
On Jun 12, 11 14:44, Daniel Gibson wrote: Am 12.06.2011 08:38, schrieb David Nadlinger: core.stdc is the place for C standard library modules, core.sys.* are where the C operating system header translations reside – this is our current policy, right? If so (I can't actually remember any formal decision or discussion), is there a reason we still have so much code in std.c? David And why is core.stdc not listed on http://www.digitalmars.com/d/2.0/phobos/phobos.html and http://d-programming-language.org/phobos/index.html ? Furthermore it'd be nice if the functions contained there were documented or at least listed. Cheers, - Daniel http://d.puremagic.com/issues/show_bug.cgi?id=5872
