Using D in Android App
Is it difficult to create a D business like app and connect it to android through java for the interface? I'd rather create all the complex stuff in D and either use it natively through java(I need a UI). If it is workable, can the same be said for IOS(just recompile the D source to the IOS architecture then use it in an IOS app for the ui)?
Free paperback: "Programming in D" by Ali Çehreli. You pick up in San Francisco
Free paperback of "Programming in D" by Ali Çehreli. You'll pick it up in San Francisco. It's a great book, but I prefer to read it in electronic form. Send a message to the account "throwaway389012" on Reddit if you want it. Leave your phone number or email address. If you don't hear back, it means someone has already claimed it.
Re: Is this a bug?
On Saturday, April 16, 2016 00:28:46 ag0aep6g via Digitalmars-d-learn wrote: > On 15.04.2016 20:55, Eric wrote: > > 13 class C : const (I!(J)) > > I think this const is ignored by the compiler. It's definitely ignored, and I'd argue that it's a bug in the compiler that it's even accepted. There's no such thing as a const or immutable class - just a const or immutable instance of a class. Member functions of a class can be const or immutable but not the class itself. Doing so is just equivalent to marking every function in the class as const or immutable. Deriving from a const or immutable class is nonsense. - Jonathan M Davis
Re: Accessing __FILE__ and __LINE__ of caller in combination with varargs?
On Friday, April 15, 2016 20:52:42 WebFreak001 via Digitalmars-d-learn wrote:
> On Friday, 15 April 2016 at 20:43:08 UTC, pineapple wrote:
> > I've written a very handy assertf method whose signature looks
> > like this:
> >
> > void assertf(Args...)(lazy bool condition, in string message,
> > Args args)
> >
> > But I'd also like to access the caller's file and line to use
> > them in constructing a thrown AssertError, and I'm stumbling on
> > how I can get that information where it needs to go. Help?
>
> void assertf(string file = __FILE__, size_t line = __LINE__,
> Args...)(lazy bool condition, in string message, Args args) {
Yes, you can do that, but do _not_ do that unless you really have no other
choice. What you need to realize is that because the file and line number
arguments will be unique for every call to this function, it will generate a
new instantiation of it _every_ time it is called. So, you're going to get a
lot of code bloat. There are rare cases where such bloat would be
acceptable, but in the general case, it's a terrible thing to do. This
particular case might be acceptable given how short it is, but in general,
using __FILE__ or __LINE__ as template arguments should be avoided like the
plague.
> debug {
> if (!condition) {
> writeln(format(message, args) ~ format(" in %s:%s",
> file, line));
> throw new AssertError();
> }
> }
> }
Also, to nitpick your exact implementation, debug blocks and assertions
aren't even vaguely related. debug blocks are used with the -debug flag with
the intention of being used for printing out additional debug information
(and getting around restrictions with pure with those messages while you're
at it). They have nothing to do with -release, which is what controls
assertions. What you really want to be doing is to use version(assert), not
debug.
- Jonathan M Davis
Re: Is this a bug?
On 15.04.2016 20:55, Eric wrote: 13 class C : const (I!(J)) I think this const is ignored by the compiler. 15F!(J) m; A little tip: You can omit the parentheses of template instantiations when the argument is a single identifier. That is, `F!(J)` can be written as `F!J`.
Re: Accessing __FILE__ and __LINE__ of caller in combination with varargs?
On Friday, 15 April 2016 at 20:52:42 UTC, WebFreak001 wrote:
void assertf(string file = __FILE__, size_t line = __LINE__,
Args...)(lazy bool condition, in string message, Args args) {
Aha, you are the best. Thanks!
Re: Accessing __FILE__ and __LINE__ of caller in combination with varargs?
On Friday, 15 April 2016 at 20:43:08 UTC, pineapple wrote:
I've written a very handy assertf method whose signature looks
like this:
void assertf(Args...)(lazy bool condition, in string message,
Args args)
But I'd also like to access the caller's file and line to use
them in constructing a thrown AssertError, and I'm stumbling on
how I can get that information where it needs to go. Help?
void assertf(string file = __FILE__, size_t line = __LINE__,
Args...)(lazy bool condition, in string message, Args args) {
debug {
if (!condition) {
writeln(format(message, args) ~ format(" in %s:%s",
file, line));
throw new AssertError();
}
}
}
---
didn't test it but it should work (replace the content of the
function with what you actually need, this is just some
placeholder)
Accessing __FILE__ and __LINE__ of caller in combination with varargs?
I've written a very handy assertf method whose signature looks like this: void assertf(Args...)(lazy bool condition, in string message, Args args) But I'd also like to access the caller's file and line to use them in constructing a thrown AssertError, and I'm stumbling on how I can get that information where it needs to go. Help?
Re: De Facto standard for D programming language
On Friday, 15 April 2016 at 18:41:23 UTC, Ali Çehreli wrote: Having said that, there are some omissions of how some features interact. I think it is a fantastic resource and have made much use out of it. I hope you keep updating it. It just happens that there are always some random quirks in D that I only notice if I pay really close attention to the spec. For instance, until Andrei pointed it out today I didn't realize that virtual member functions can't be templates. I've probably seen the line in the spec page, but didn't process it fully because the examples they use in there are not the best. At least with your book, everything is very readable with good examples.
Re: Is this a bug?
On Friday, 15 April 2016 at 18:28:58 UTC, Eric wrote:
line 6 can be fixed like this: "const I!(J) i = a;"
Now if I can just figure out how to fix line 15...
This works:
1 alias J = const C;
2
3 void main(string[] args)
4 {
5 J a = new C();
6 const (I!(J)) i = a;
7 }
8
9 interface I(V) { }
10
11 class F(V) if (is(V : const(I!(V { }
12
13 class C : const (I!(J))
14 {
15F!(J) m;
16 }
17
-Eric
Re: De Facto standard for D programming language
On 04/15/2016 11:19 AM, jmh530 wrote: > On Friday, 15 April 2016 at 17:51:41 UTC, Napster wrote: >> I would like to start learning the De Facto standard. which book or >> document would you use? >> >> http://erdani.com/index.php/books/tdpl/ >> >> or >> >> https://dlang.org/spec/intro.html >> >> which one would you call de facto standard? > > If I were learning D from the beginning, I would read Ali's book: > http://ddili.org/ders/d.en/index.html > > I had read TDPL first and then from spec pages before finding his book. > His book probably doesn't cover everything, so it's worth looking at > those other sources as well. Putting Phobos aside, I aim at including every keyword and pseudo keyword and every feature in the book. Even if I decide not to cover a particular keyword or feature, it should exist in the index. If you catch an omission please let me know. The benefit of an online book is that it can be up-to-date very quickly. For example, reduce() has already been replaced with fold() that came with 2.071: :) http://ddili.org/ders/d.en/ranges.html#ix_ranges.fold,%20std.algorithm (The CreateSpace edition has been updated as well but it takes a while for the readers see that change.) Having said that, there are some omissions of how some features interact. Ali
Re: De Facto standard for D programming language
On 04/15/2016 11:31 AM, Napster wrote: I am writing a survey paper about D programming language. I want to use De Facto standard in my paper. I am not sure which one is? Both look the same. https://dlang.org/spec/intro.html is it. TDPL is behind some of D changes at this point. Ali
Re: De Facto standard for D programming language
On Friday, 15 April 2016 at 18:19:44 UTC, jmh530 wrote: On Friday, 15 April 2016 at 17:51:41 UTC, Napster wrote: I would like to start learning the De Facto standard. which book or document would you use? http://erdani.com/index.php/books/tdpl/ or https://dlang.org/spec/intro.html which one would you call de facto standard? If I were learning D from the beginning, I would read Ali's book: http://ddili.org/ders/d.en/index.html I had read TDPL first and then from spec pages before finding his book. His book probably doesn't cover everything, so it's worth looking at those other sources as well. I am writing a survey paper about D programming language. I want to use De Facto standard in my paper. I am not sure which one is? Both look the same.
Re: Is this a bug?
On Friday, 15 April 2016 at 18:22:02 UTC, Eric wrote:
On Friday, 15 April 2016 at 17:43:59 UTC, ag0aep6g wrote:
On 15.04.2016 19:13, Eric wrote:
1 alias J = const C;
2
3 void main(string[] args)
4 {
5 J a = new C();
6 I!(J) i = a;
7 }
8
9 interface I(V) { }
10
11 class F(V) if (is(V : I!(V))) { }
12
13 class C : I!(J)
14 {
15 F!(J) m;
16 }
Line 6 isn't accepted either. If you remove the constraint,
the compiler complains about it. So it's just the next error
in line.
And really const C can't be converted to I!(const C)
implicitly. The former is const, the latter is mutable => no
go.
Thanks. I see that now. Is there any way I can make the
compiler
understand that the interface is const?
-Eric
line 6 can be fixed like this: "const I!(J) i = a;"
Now if I can just figure out how to fix line 15...
Re: Is this a bug?
On Friday, 15 April 2016 at 17:43:59 UTC, ag0aep6g wrote:
On 15.04.2016 19:13, Eric wrote:
1 alias J = const C;
2
3 void main(string[] args)
4 {
5 J a = new C();
6 I!(J) i = a;
7 }
8
9 interface I(V) { }
10
11 class F(V) if (is(V : I!(V))) { }
12
13 class C : I!(J)
14 {
15 F!(J) m;
16 }
Line 6 isn't accepted either. If you remove the constraint, the
compiler complains about it. So it's just the next error in
line.
And really const C can't be converted to I!(const C)
implicitly. The former is const, the latter is mutable => no go.
Thanks. I see that now. Is there any way I can make the compiler
understand that the interface is const?
-Eric
Re: De Facto standard for D programming language
On Friday, 15 April 2016 at 17:51:41 UTC, Napster wrote: I would like to start learning the De Facto standard. which book or document would you use? http://erdani.com/index.php/books/tdpl/ or https://dlang.org/spec/intro.html which one would you call de facto standard? If I were learning D from the beginning, I would read Ali's book: http://ddili.org/ders/d.en/index.html I had read TDPL first and then from spec pages before finding his book. His book probably doesn't cover everything, so it's worth looking at those other sources as well.
De Facto standard for D programming language
I would like to start learning the De Facto standard. which book or document would you use? http://erdani.com/index.php/books/tdpl/ or https://dlang.org/spec/intro.html which one would you call de facto standard?
Re: Is this a bug?
On 15.04.2016 19:13, Eric wrote:
1 alias J = const C;
2
3 void main(string[] args)
4 {
5 J a = new C();
6 I!(J) i = a;
7 }
8
9 interface I(V) { }
10
11 class F(V) if (is(V : I!(V))) { }
12
13 class C : I!(J)
14 {
15 F!(J) m;
16 }
The above code gives the following compile error:
Error:
template instance F!(const(C)) does not match template declaration F(V)
if (is(V : I!V))
on line 15.
If I change line 1 to "alias J = C;" the code will compile. The problem
seems to be
the template constraint on line 11. I think the constraint says, "If V
can be automatically
converted to I!(V) then this template can be used". However, line 6
does not give
an error, and it seems to be automaticaly converting J to I!(J).
Line 6 isn't accepted either. If you remove the constraint, the compiler
complains about it. So it's just the next error in line.
And really const C can't be converted to I!(const C) implicitly. The
former is const, the latter is mutable => no go.
Is this a bug?
1 alias J = const C;
2
3 void main(string[] args)
4 {
5 J a = new C();
6 I!(J) i = a;
7 }
8
9 interface I(V) { }
10
11 class F(V) if (is(V : I!(V))) { }
12
13 class C : I!(J)
14 {
15 F!(J) m;
16 }
The above code gives the following compile error:
Error:
template instance F!(const(C)) does not match template
declaration F(V) if (is(V : I!V))
on line 15.
If I change line 1 to "alias J = C;" the code will compile. The
problem seems to be
the template constraint on line 11. I think the constraint says,
"If V can be automatically
converted to I!(V) then this template can be used". However,
line 6 does not give
an error, and it seems to be automaticaly converting J to I!(J).
-Eric
Re: Internal compiler erorr
On Friday, 15 April 2016 at 16:53:27 UTC, Eric wrote: On Monday, 11 April 2016 at 00:55:44 UTC, Mike Parker wrote: I don't see this specific error in bugzilla. Unfortunately I am getting this error in a large module that has "const string" all over. So I can't come up with a simple test case. The compiler does not seem to have a problem with just using a "const string" declaration. If you want to investigate this is precisely where dustmite would shine.
Re: Internal compiler erorr
On Monday, 11 April 2016 at 00:55:44 UTC, Mike Parker wrote: On Sunday, 10 April 2016 at 17:19:14 UTC, Eric wrote: I am getting this error when I compile: Error: Internal Compiler Error: unsupported type const(string) No line number is given. Does anyone know what causes this? compiler version = v2.071.0 -Eric An ICE should always be considered a bug, no matter its cause. The thing to do here is to search bugzilla to see if your issue has already been reported and, if not, open a new one with a minimal reproducible test case. I don't see this specific error in bugzilla. Unfortunately I am getting this error in a large module that has "const string" all over. So I can't come up with a simple test case. The compiler does not seem to have a problem with just using a "const string" declaration.
Why does Reggae use mixins?
Why does the build system Reggae use mixins everywhere in the D examples? Doesn't this severly limit what the build rules are capable of in terms of run-time flexibility? https://github.com/atilaneves/reggae
Re: DWT Cloning / Build fails
On Thursday, 14 April 2016 at 19:16:30 UTC, Jacob Carlborg wrote: On 2016-04-14 15:56, Chris wrote: I had to add ".a" to `-L-l:dwt-base` and `-L-l:org.eclipse.swt.gtk.linux.x86`, and add `-L-lgnomevfs-2` as well. I added `-L-lgnomevfs-2 to the example. I need to look into way the ".a" was needed. Yeah, it's strange alright. I was surprised that I had to add it.
Re: Dlang UI - making widget extend to the bounds of the window
On Friday, 15 April 2016 at 00:58:58 UTC, stunaep wrote:
I'm trying to make a gui program with dlangui, but no matter
what I do, I cannot get widgets to fill the whole window. The
window is resizable so I cannot just set the widths to static
numbers.
No layoutWidth and layoutHeight set:
http://i.imgur.com/UySt30K.png
layoutWidth/Height set to fill (left widget width 300):
http://i.imgur.com/76tMIFz.png
I need these widgets to extend the width of the window because
it is resizable
http://i.imgur.com/PiL7Y7f.png
You can see this also on DlangUI ML editor:
fill:
http://i.imgur.com/t9DsASt.png
wrap:
http://i.imgur.com/FoTS69g.png
arbitrary number:
http://i.imgur.com/voiYTWZ.png
For parent VerticalLayout, set layoutWidth: fill too
VerticalLayout {
id: main;
layoutWidth: fill;
VerticalLayout {
layoutWidth: fill;
TextWidget { text: "test"; layoutWidth: fill }
}
}
Re: Problem with circular imports of modules with static ctors an immutable variables
On Friday, 15 April 2016 at 05:35:24 UTC, Uranuz wrote: In my program I have error with circular imports of modules with static ctors. So I decided to move ctors in separate file and import it only from the 1st file. But problem is that in the first file I have immutables that should be initialized in shared static ctor. However doing it from another module's ctor gives compilation error: "Error: cannot modify immutable expression". 1. Is it a bug? Not really. The rules are there to avoid cyclic initialization dependencies, but they are a bit coarse at the moment. 2. Could I solve this problem another way? You could put the immutable globals in the the same module as the shared ctors, and publicly import them in the "real" modules they are intended to be in. You might have to play around with `package` protection if you want to make them invisible in the helper module, too.
