Re: How to proceed with learning to code Windows desktop applications?
On Tuesday, 30 January 2018 at 06:25:52 UTC, rikki cattermole wrote: On 30/01/2018 5:47 AM, thedeemon wrote: On Tuesday, 30 January 2018 at 03:07:38 UTC, rikki cattermole wrote: But since Windows is the only platform mentioned or desired for, everything you need is in WinAPI! It's like saying "everything you need is assembly language" when talking about languages and compilers. Pure WinAPI is a cruel advice for a novice. There are libraries such as[0], so it isn't cruel, but it is something worth while at least to look into for someone who might be interested in it, but doesn't know where to begin. [0] https://bitbucket.org/dgui/dgui There's also DWT which has the advantage of being portable.
Re: How to proceed with learning to code Windows desktop applications?
On 30/01/2018 5:47 AM, thedeemon wrote: On Tuesday, 30 January 2018 at 03:07:38 UTC, rikki cattermole wrote: But since Windows is the only platform mentioned or desired for, everything you need is in WinAPI! It's like saying "everything you need is assembly language" when talking about languages and compilers. Pure WinAPI is a cruel advice for a novice. There are libraries such as[0], so it isn't cruel, but it is something worth while at least to look into for someone who might be interested in it, but doesn't know where to begin. [0] https://bitbucket.org/dgui/dgui
Re: How to proceed with learning to code Windows desktop applications?
There are far too many options for Windows GUI programming, so we probably need a bit more information about any constraints that are important to you. For example: - do you specifically want something that works well with D? or are you open to other languages? - are you just wanting to learn desktop programming in general? (Like the concepts involved) Or do you have a specific thing you want to create? I would personally suggest Delphi to somebody who wants to write Windows desktop apps and learn about event-driven development, howeverrr the language (Object Pascal) is insufferably archaic compared to something like D. But it is definitely the cleanest, least-overwhelming method of writing native Win32 applications for somebody with no prior experience. Then there's all the modern Microsoft stuff (WPF/XAML/WinRT/etc), but you pretty much have to use either .NET or C++ for that.
Re: How to proceed with learning to code Windows desktop applications?
On Tuesday, 30 January 2018 at 03:07:38 UTC, rikki cattermole wrote: But since Windows is the only platform mentioned or desired for, everything you need is in WinAPI! It's like saying "everything you need is assembly language" when talking about languages and compilers. Pure WinAPI is a cruel advice for a novice.
Re: How to proceed with learning to code Windows desktop applications?
On 29/01/2018 11:56 PM, welkam wrote: On Monday, 29 January 2018 at 22:55:12 UTC, I Lindström wrote: The other way I've been thinking is to do the thing browser-based, but for some reason that doesn't feel right. Well it didnt felt wrong for Microsoft to use modified internet explorer to make calculator. You can read more on universal windows apps and XAML To learn GUI development first find GUI framework like GTK, QT etc. then watch and/or read tutorials on how to use them. For D language a list of libraries could be found here https://wiki.dlang.org/GUI_Libraries But since Windows is the only platform mentioned or desired for, everything you need is in WinAPI!
Re: Should the "front" range primitive be "const" ?
On Tuesday, January 30, 2018 01:05:54 Drone1h via Digitalmars-d-learn wrote:
> Hello all,
>
>
>
> I am trying to implement a ("struct template" ? what is the
> correct word ?) range that just forwards its primitives ("empty",
> "front", "popFront") to another range, possibly with some very
> limited filtering/alteration, as std.range.Take (just to learn).
>
> Initially, the "front" member function (property) used to be
> declared "const", but that was not accepted when the underlying
> range (denoted "R" in the code below) was std.stdio.File.ByChunk
> ("Error: mutable method std.stdio.File.ByChunk.front is not
> callable using a const object").
>
> Is there any value in having the "front" range primitive declared
> to be a "const" member function ?
>
> And if so, is the following implementation okay ? Could it be
> further simplified ?
>
> struct Taker (R)
> {
> private R _r;
>
> ...
>
> static if (functionAttributes ! (R.front) &
> FunctionAttribute.const_)
> public @property auto front () const { return
> _r.front; }
> else
> public @property auto front () { return
> _r.front; }
>
> ...
> }
>
>
>
> Thank you respectfully !
> Drone1h
If you want to put an attribute on it, inout is better, because then it will
work with any constness, but in general, I'd suggest just avoiding the use
of const or immutable altogether when dealing with ranges. front can return
a const element, and that will happen if you use auto and whatever you're
wrapping is const, but const ranges are utterly useless, because they can't
be mutated and thus can't be iterated. As such, almost no code is ever going
to have a range that is anything but mutable, which means that having front
be anything but mutable is generally pointless.
The design of ranges makes them fundamentally incompatible with const. We'd
had to have gone with the head/tail model where you get an entirely new
object every time you pop elements off if we wanted const or immutable to
work. The fact that popFront pretty much outright kills const.
If tail-const slicing were a thing for ranges, then we'd get something
similar to tail/cdr out of the deal, and const ranges could be made to work,
but it's a royal pain to do tail-const with user-defined types (especially
templated types), and slicing an entire range like that isn't actually part
of the range API. hasSlicing requires slicing indices but not the entire
range. Slicing without indices operation is used on containers to get ranges
but isn't used for ranges themselves.
So, as it stands at least, I'd suggest that you simply not bother using
const with ranges.
- Jonathan M Davis
Should the "front" range primitive be "const" ?
Hello all,
I am trying to implement a ("struct template" ? what is the
correct word ?) range that just forwards its primitives ("empty",
"front", "popFront") to another range, possibly with some very
limited filtering/alteration, as std.range.Take (just to learn).
Initially, the "front" member function (property) used to be
declared "const", but that was not accepted when the underlying
range (denoted "R" in the code below) was std.stdio.File.ByChunk
("Error: mutable method std.stdio.File.ByChunk.front is not
callable using a const object").
Is there any value in having the "front" range primitive declared
to be a "const" member function ?
And if so, is the following implementation okay ? Could it be
further simplified ?
struct Taker (R)
{
private R _r;
...
static if (functionAttributes ! (R.front) &
FunctionAttribute.const_)
public @property auto front () const { return
_r.front; }
else
public @property auto front () { return
_r.front; }
...
}
Thank you respectfully !
Drone1h
Re: How to proceed with learning to code Windows desktop applications?
On Monday, 29 January 2018 at 22:55:12 UTC, I Lindström wrote: The other way I've been thinking is to do the thing browser-based, but for some reason that doesn't feel right. Well it didnt felt wrong for Microsoft to use modified internet explorer to make calculator. You can read more on universal windows apps and XAML To learn GUI development first find GUI framework like GTK, QT etc. then watch and/or read tutorials on how to use them. For D language a list of libraries could be found here https://wiki.dlang.org/GUI_Libraries
How to proceed with learning to code Windows desktop applications?
Hello all! I've been doing console apps for about a year and a half now, but my requirements are reaching the limits of easy to use with ASCII-based UI and typed commands so I'm thinking of moving into GUI-era with my projects. I was wondering if some one could help me into the right direction. I've been Googling a ton these past few days for some kind of a book or a course on how to code desktop applications for Windows, but either there isn't one, or it's very well hidden. I've found bits and pieces but nothing to give me a coherent approach. The other way I've been thinking is to do the thing browser-based, but for some reason that doesn't feel right.
Re: dmd error - unrecognized file extension
On 01/29/2018 12:53 PM, Evan Burkey wrote: On Monday, 29 January 2018 at 19:12:13 UTC, Steven Schveighoffer wrote: version is a keyword, you can't use it here like this. Not sure if this is related to your issue directly, but definitely it will show up as an error when the compiler looks at it properly. So I tried changing the name to "v.txt" and had the same results: PowerShell threw the same errors, but the D2 command prompt worked just fine. It's the other "version". :) You can't use a keyword as a symbol: immutable version = 1;// bad immutable version_ = 1; // good Ali
Re: dmd error - unrecognized file extension
On Monday, 29 January 2018 at 19:12:13 UTC, Steven Schveighoffer wrote: version is a keyword, you can't use it here like this. Not sure if this is related to your issue directly, but definitely it will show up as an error when the compiler looks at it properly. So I tried changing the name to "v.txt" and had the same results: PowerShell threw the same errors, but the D2 command prompt worked just fine.
Re: cast problem about alias this
On Monday, 29 January 2018 at 19:59:31 UTC, Steven Schveighoffer
wrote:
On 1/29/18 2:40 PM, Sobaya wrote:
class Parent {
int x;
alias x this;
}
class Child : Parent {
}
void main() {
Parent p = new Child;
Child c = cast(Child)p; // cannot cast `int` to `Child`
}
In this code, I got a compile error.
How can I cast p to Child?
I'm sure I've seen this bug reported somewhere before. Ah yes:
https://issues.dlang.org/show_bug.cgi?id=6777
What you can do is cast to Object first.
-Steve
I see.
I will continue by casting to Object for now.
Hope the bug is fixed soon.
Thanks!
- Sobaya
Re: cast problem about alias this
On 1/29/18 2:40 PM, Sobaya wrote:
class Parent {
int x;
alias x this;
}
class Child : Parent {
}
void main() {
Parent p = new Child;
Child c = cast(Child)p; // cannot cast `int` to `Child`
}
In this code, I got a compile error.
How can I cast p to Child?
I'm sure I've seen this bug reported somewhere before. Ah yes:
https://issues.dlang.org/show_bug.cgi?id=6777
What you can do is cast to Object first.
-Steve
cast problem about alias this
class Parent {
int x;
alias x this;
}
class Child : Parent {
}
void main() {
Parent p = new Child;
Child c = cast(Child)p; // cannot cast `int` to `Child`
}
In this code, I got a compile error.
How can I cast p to Child?
Re: the behavior of opAssign
On Monday, 29 January 2018 at 10:06:23 UTC, Simen Kjærås wrote:
On Monday, 29 January 2018 at 09:23:55 UTC, Sobaya wrote:
I found a strange behavior.
class A {
void opAssign(int v) {}
}
class Test {
A a;
this() {
a = new A(); // removing this causes compile error.
a = 3; // cannot implicitly convert expression `3` of
`int` to `A`
}
}
void main() {
// this is allowed.
A a;
a = 3;
}
The first assignment in the constructor isn't actually a call
to opAssign, it's a constructor call. In the same way, this
will not compile:
A a = 3;
Also, since classes are reference types, you will need to
construct an instance before assigning an int to it. The code
in your main() will crash at runtime because the 'this'
reference is null inside opAssign.
--
Simen
I have not read https://dlang.org/spec/class.html
In 15.9, there is an explanation about it.
Sorry.
--
Sobaya
Re: dmd error - unrecognized file extension
On Mon, Jan 29, 2018 at 02:12:13PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/29/18 12:25 PM, Evan Burkey wrote:
> > Hi there, I have a problem that is eluding me, hoping someone can
> > help me see the light. I'm on Windows 10 using the latest version of
> > dmd. I have a directory with 2 files: "version.txt" and
> > "versioncheck.d". version.txt contains a single line of text. I
> > have the line:
> >
> > immutable version = import("version.txt");
>
> version is a keyword, you can't use it here like this. Not sure if
> this is related to your issue directly, but definitely it will show up
> as an error when the compiler looks at it properly.
[...]
Granted, though, the error message could have been a lot more helpful
than it is. As it stands, it didn't even occur to me that `version`
being a keyword was the problem here until you pointed it out. That's a
sign that the compiler error message needs improvement. :-)
T
--
Life is too short to run proprietary software. -- Bdale Garbee
Re: dmd error - unrecognized file extension
On 1/29/18 12:25 PM, Evan Burkey wrote:
Hi there, I have a problem that is eluding me, hoping someone can help
me see the light. I'm on Windows 10 using the latest version of dmd. I
have a directory with 2 files: "version.txt" and "versioncheck.d".
version.txt contains a single line of text. I have the line:
immutable version = import("version.txt");
version is a keyword, you can't use it here like this. Not sure if this
is related to your issue directly, but definitely it will show up as an
error when the compiler looks at it properly.
-Steve
Re: rdmd main.d leads to Segmentation fault
On Monday, 29 January 2018 at 15:03:48 UTC, Stefan Koch wrote: On Friday, 26 January 2018 at 22:40:29 UTC, Timoses wrote: Hey, simple hello world crashes with segfault: [...] I can not reproduce this. Well, the cause is not yet uncovered, I suppose... Any more ideas?
Re: dmd error - unrecognized file extension
On Monday, 29 January 2018 at 18:02:47 UTC, rjframe wrote:
On Mon, 29 Jan 2018 17:25:34 +, Evan Burkey wrote:
Hi there, I have a problem that is eluding me, hoping someone
can help me see the light. I'm on Windows 10 using the latest
version of dmd. I have a directory with 2 files: "version.txt"
and "versioncheck.d". version.txt contains a single line of
text. I have the line:
immutable version = import("version.txt");
and my dmd switches are:
dmd -J. .\versioncheck.d
but dmd fails with "Error: unrecognized file extension". I've
searched the internet but found very little about this
problem. Hopefully I'm just missing something simple.
Thanks!
I have the same issue on Windows 10, but Linux works; have you
checked the issue tracker yet?
It looks like just `dmd -J .\versioncheck.d` should work [I
haven't tested this properly with an actual string mixin, but I
don't get that error this way]. On Windows, dmd doesn't seem to
like starting with the period.
So if it was in a different directory, instead of `dmd
-J.\somedir` on Windows you'd need to just do `dmd -Jsomedir`
--Ryan
So I played around with it a bit more and discovered what the
problem was. I normally am a Linux/BSD user but am running a
Win10 machine to test multi-platform compatibility. What I
discovered is that the Windows version has a special command
prompt called D2. I was using PowerShell (as that is this
system's default shell). Once I used the special D2 prompt the
Unix-style switches worked fine.
Re: dmd error - unrecognized file extension
On Mon, 29 Jan 2018 17:25:34 +, Evan Burkey wrote:
> Hi there, I have a problem that is eluding me, hoping someone can help
> me see the light. I'm on Windows 10 using the latest version of dmd. I
> have a directory with 2 files: "version.txt" and "versioncheck.d".
> version.txt contains a single line of text. I have the line:
>
> immutable version = import("version.txt");
>
> and my dmd switches are:
>
> dmd -J. .\versioncheck.d
>
> but dmd fails with "Error: unrecognized file extension". I've searched
> the internet but found very little about this problem. Hopefully I'm
> just missing something simple.
>
> Thanks!
I have the same issue on Windows 10, but Linux works; have you checked the
issue tracker yet?
It looks like just `dmd -J .\versioncheck.d` should work [I haven't tested
this properly with an actual string mixin, but I don't get that error this
way]. On Windows, dmd doesn't seem to like starting with the period.
So if it was in a different directory, instead of `dmd -J.\somedir` on
Windows you'd need to just do `dmd -Jsomedir`
--Ryan
dmd error - unrecognized file extension
Hi there, I have a problem that is eluding me, hoping someone can
help me see the light. I'm on Windows 10 using the latest version
of dmd. I have a directory with 2 files: "version.txt" and
"versioncheck.d". version.txt contains a single line of text. I
have the line:
immutable version = import("version.txt");
and my dmd switches are:
dmd -J. .\versioncheck.d
but dmd fails with "Error: unrecognized file extension". I've
searched the internet but found very little about this problem.
Hopefully I'm just missing something simple.
Thanks!
Re: rdmd main.d leads to Segmentation fault
On Friday, 26 January 2018 at 22:40:29 UTC, Timoses wrote: Hey, simple hello world crashes with segfault: [...] I can not reproduce this.
Re: questions around mutating range algorithms, const, and return ref
On Monday, 29 January 2018 at 11:36:26 UTC, aliak wrote:
On Monday, 29 January 2018 at 06:46:26 UTC, Ali Çehreli wrote:
I think the following trivial wrapper around
std.algorithm.remove() should do:
void removeMatching(R, N)(ref R r, N needles) {
import std.algorithm : remove, canFind;
r = r.remove!(e => needles.canFind(e));
}
Haha awesome! Yes that's much better :)
Note to self: learn to scroll down in the docs to find other
definitions. I was convinced that remove only acted on indices
:p
Not too hard to fix: https://github.com/dlang/phobos/pull/6090
Re: questions around mutating range algorithms, const, and return ref
On Monday, 29 January 2018 at 11:36:26 UTC, aliak wrote: You don't want to mutate const elements anyway. It would be breaking a promise that other parts of the program may be depending on. I would return a filtered-out range: Right, I want to mutate the range though, not the elements. So moving things from one location is not considered as a const violation in c++ for eg, maybe the D way is different though? Consider this case: immutable(int)[] a = [1,2,3]; immutable(int)* b = [1]; You're free to slice the array or pop elements off its front or back, but if you change the order of elements, the value that b points to will change. D does not allow this. You can create a new array with the elements moved into the locations you want, and with another layer of indirections (int*[]) you can move the elements of the array without mutating the values. Any reading material there? https://dlang.org/const-faq.html Also hasMobileElements!(const int[]) is true, so that means I can move elements around right? hasMobileElements checks if the value of front can be moved as in move constructors, not as in 'can be moved to a different spot in the range'. I will admit the name does little to unconfuse this point. -- Simen
Re: questions around mutating range algorithms, const, and return ref
On Monday, 29 January 2018 at 06:46:26 UTC, Ali Çehreli wrote:
I think the following trivial wrapper around
std.algorithm.remove() should do:
void removeMatching(R, N)(ref R r, N needles) {
import std.algorithm : remove, canFind;
r = r.remove!(e => needles.canFind(e));
}
Haha awesome! Yes that's much better :)
Note to self: learn to scroll down in the docs to find other
definitions. I was convinced that remove only acted on indices :p
I'm not convinced that unfoundElements is needed at all. :)
Can't argue with that :)
> 6) It will not work when I pass in a range that has const
elements.
>
> ie:
>
> const(int)[] arr = [1, 2, 3, 4, 5];
> arr.pull([2, 3]);
>
> This I guess makes sense because moveEmplaceAll depends on
isInputRange
> and from my understanding, a const range cannot be one (is
that
> correct?).
Yes but your range is not const, the elements are. So, although
const(int)[] is a range, it does not have mutable elements.
Ah right, yes the range is not const indeed.
You don't want to mutate const elements anyway. It would be
breaking a promise that other parts of the program may be
depending on. I would return a filtered-out range:
Right, I want to mutate the range though, not the elements. So
moving things from one location is not considered as a const
violation in c++ for eg, maybe the D way is different though? Any
reading material there?
Also hasMobileElements!(const int[]) is true, so that means I can
move elements around right?
If I can move elements, that means I should be able to move the
ones I want to the beginning, of the range, but then I'm also
unsure about how to go about changing the size of a range.
popBack on a mutable range with const data might cause
destructors to be called, so I'm going to say that should be ok
because as a user, if you're calling a range that mutates by
removing things, and if you try and access those things later
that's probably along the same lines as removing elements from a
range that you're "foreach"ing over.
And your second approach is definitely more practical I'd say,
but I'm going to go about this as a learning exercise in dealing
with mutations, and const with ranges in D.
Thanks you for the comments!
Re: the behavior of opAssign
On Monday, 29 January 2018 at 09:23:55 UTC, Sobaya wrote:
I found a strange behavior.
class A {
void opAssign(int v) {}
}
class Test {
A a;
this() {
a = new A(); // removing this causes compile error.
a = 3; // cannot implicitly convert expression `3` of
`int` to `A`
}
}
void main() {
// this is allowed.
A a;
a = 3;
}
The first assignment in the constructor isn't actually a call to
opAssign, it's a constructor call. In the same way, this will not
compile:
A a = 3;
Also, since classes are reference types, you will need to
construct an instance before assigning an int to it. The code in
your main() will crash at runtime because the 'this' reference is
null inside opAssign.
--
Simen
Re: the behavior of opAssign
On Monday, January 29, 2018 09:23:55 Sobaya via Digitalmars-d-learn wrote:
> I found a strange behavior.
>
> class A {
> void opAssign(int v) {}
> }
>
> class Test {
> A a;
> this() {
> a = new A(); // removing this causes compile error.
> a = 3; // cannot implicitly convert expression `3` of
> `int` to `A`
> }
> }
>
> void main() {
> // this is allowed.
> A a;
> a = 3;
> }
>
> Is it a compiiler's bug?
I don't think so. The first "assignment" is actually initialization, not
assignment. opAssign is for assigning to a value that was already
initialized.
- Jonathan M Davis
the behavior of opAssign
I found a strange behavior.
class A {
void opAssign(int v) {}
}
class Test {
A a;
this() {
a = new A(); // removing this causes compile error.
a = 3; // cannot implicitly convert expression `3` of
`int` to `A`
}
}
void main() {
// this is allowed.
A a;
a = 3;
}
Is it a compiiler's bug?
