Re: TIOBE october

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 7 October 2015 at 04:00:02 UTC, Israel wrote:
On Wednesday, 7 October 2015 at 03:26:37 UTC, Laeeth Isharc 
wrote:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

d up from 31 in march.  Just below scala, sas, and fortran.  
No doubt noisy, and possibly news about Andrei leaving 
Facebook had an influence.  They changed the algorithm to be 
more tolerant of noise, which has had an impact on the results 
(which might also be a hint about the degree of precision in 
such an exercise) but don't say how that affected D, if at all.


By noisy you mean hype?


Having a high element that doesn't relate to the underlying 
phenomenon one is trying to measure.  That's intrinsic to the 
problem domain, at least if you approach it in this way.

Re: Bug? 0 is less than -10

[Laeeth Isharc via Digitalmars-d-learn]

On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven 
Schveighoffer wrote:

On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code 
ends up

being portable ;) (It's trivial to do, obviously).


ptrdiff_t

-Steve


It seems unnatural to use such a name when the variable has 
nothing to do with pointers - it doesn't contribute to the 
readability.  Yes, it's trivial, but small things cumulatively 
matter.  Adam tends to use int and when that gets mixed up with 
an auto size_t (eg via length) then his code doesn't compile on 
64 bit.  And if it happens with his code, you can imagine this 
isn't a problem that inexperienced users never encounter.

Re: D 2015/2016 Vision?

[Meta via Digitalmars-d]

On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote:
-again, alias this allows class references to escape their RAII 
containers and can cause access violations as show here:

http://forum.dlang.org/post/zfggjsjmfttbcekqw...@forum.dlang.org


This isn't really a problem as it can be easily fixed. It's just 
that the original writer of Scoped made the mistake of allowing 
implicit conversion of a Scoped!C to a C, which when you think 
about it doesn't make any sense and is actually quite dangerous 
(as my post that you cited shows). All that has to be done to fix 
that is to disallow implicit conversion to the wrapped type while 
retaining the interface, which we can do today with a myriad of 
different methods (mixins, opDispatch, std.typecons.Proxy, etc.). 
It's just that nobody has done it.

Re: D 2015/2016 Vision?

[Walter Bright via Digitalmars-d]

On 10/6/2015 7:57 PM, bitwise wrote:

What can a stream do that a range cannot?


I was trying to make my case for polymorphism, so I haven't thought much about
streams specifically, but one obvious thing that stands out is growing on 
demand.

Stream s = new Stream(4);
s.write(1);
s.write(2); // underlaying buffer grows automatically

I don't see how you would do something like this with a range.


It's what an OutputRange does.



Again though, if I have to restate what I've been arguing for as simply as
possible, it's that I want to use RAII and polymorphism at the same time, as a
natural language solution. DIP74 would satisfy everything I'm asking for.


Yes. We need to do that.

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 6 October 2015 at 17:07:27 UTC, Chris wrote:
Ok, and do you have a plan or a concrete wish list that you 
could hand over to the core developers? What features would be 
indispensable or are of utmost importance, in your opinion?


1. Define the target, then you can figure out the features.
2. Solid non-gc memory management and ownership.
3. Clean up the type system.
4. Complete the language spec.
5. Clean up the syntax.
6. Extend support to critical platforms like WebAssembly/asm.js


Do you have prototypes or made pull requests?


I have some prototypes for my own use, but not sure what 
relevance that has? Pull requests would require decision making 
and policy changes, and be utterly pointless without it. 
Design/policy changes will have to start with the project 
leaders, that's the only way. End-users do not directly affect 
language features.

Re: What is the postfix for min long value?

[anonymous via Digitalmars-d-learn]

On Tuesday 06 October 2015 17:39, Ali Çehreli wrote:

> I would expect the following to work:
> 
>  writeln( -9_223_372_036_854_775_808L);
> 
> But it doesn't compile:
> 
>Error: signed integer overflow
> 
> It looks like a compiler bug to me. If so, a very embarrassing one. :)

https://issues.dlang.org/show_bug.cgi?id=8929

What is the postfix for min long value?

[tcak via Digitalmars-d-learn]

While writing max ulong value, I added the "u" postfix. So 
compiler accepted it as ulong value (That's my interpretation if 
correct on compiler's side).


writeln( 18_446_744_073_709_551_615u );

But when I try to print out minimum value of long, compiler says
Error: signed integer overflow

writeln( -9_223_372_036_854_775_808 );

In case that is the wrong value, I checked it with writeln( 
long.min ); already.


Do I need to put a postfix for that number? I checked 
documentation by searching "dlang integer" etc, but couldn't have 
found any information/anything about postfix at all.

Re: What keeps you from using gtkd or dlangui

[Johannes Pfau via Digitalmars-d]

Am Mon, 05 Oct 2015 14:21:55 -0400
schrieb Nick Sabalausky :

> > Lots of us use GNOME and are proud to do so.
> >  
> 
> GNOME3? I'm surprised to hear that. My (perhaps inaccurate) 
> understanding was that it landed with quite a thud and alienated a
> lot of its userbase (and even many of it's developers), moreso than
> the early days of KDE4 did. And I've never personally known anyone
> who did use GNOME3 (to my knowledge), so I figured it had become very
> much fringe.

As of 2015, critical reception is much more positive.[48] Debian, a
Linux distribution that had historically used GNOME 2, switched to Xfce
when GNOME 3 was released. However, Debian readopted GNOME 3 in time
for the release of Debian 8 "Jessie".[49][48] Linus Torvalds, the
creator of the Linux kernel, switched back to GNOME 3 in 2013.[48]
https://en.wikipedia.org/wiki/GNOME#GNOME_3

Fedora and RHEL also use gnome 3 by default.

Gnome 3 was kinda annoying but has improved with every release. If
you use the keyboard shortcuts, virtual desktops and some nice
extensions it's a nice DE. And with proper icons (numix) it also looks
great.

Re: What keeps you from using gtkd or dlangui

[Johannes Pfau via Digitalmars-d]

Am Tue, 06 Oct 2015 13:41:48 +
schrieb Jonathan M Davis :

> On Tuesday, 6 October 2015 at 13:38:28 UTC, Gerald wrote:
> > My limited experience with gtkd has been very positive, while 
> > the documentation is primarily reference material it's not very 
> > difficult to figure out how things work with GTK based on 
> > examples from C or pyGTK. I do use Linix and Gnome Shell so I'm 
> > fully wedded to the Gnome HIG so no issues for me in terms of 
> > using GTK as a toolkit since it's native to my environment.
> 
> A major advantage to D is that you can declare bindings to C 
> libraries such that using them in D is pretty much identical to 
> using them in C. Having more D-like wrappers around such bindings 
> can be really nice, but when you need to know how to use the 
> bindings, all you have to do is look up how you use those 
> functions in C, and you know how to use them in D. The only major 
> hurdle is having the bindings in the first place. But once you 
> have them, there isn't much reason to program in C rather than D. 
> :)
> 
> - Jonathan M Davis

True, but you wouldn't really want to use the GTK/GLIB C API in D ;-)

GTKd is a complete class-based wrapper, although mainly auto-generated.

Bug? 0 is less than -10

[tcak via Digitalmars-d-learn]

Maybe I am just too stressed out to see the problem.

[code]
import std.stdio;

void main(){
size_t dec = 0;

	writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec <= 
-10) || (dec >= 10)) );

}
[/code]

[output]
0 true false true
[/output]

How is it generating "true" for (dec <= -10) ? Is there a special 
casting or something?


DMD 2.068.2, Ubuntu 64-bit

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 13:31:25 UTC, krzaq wrote:
For example: you can't rely on Clock.currTime.toString() (or 
ISO string overloads) to provide a reliable fixed-length 
representation for logging purposes and the class mysteriously 
lacks any kind of .format() function that's available pretty 
much everywhere else.


The ISO standard doesn't really say what to do with the number of 
decimal places, and it's usually cleanest to not have a bunch of 
trailing zeroes, which is why the to*String functions are the way 
they are. I was thinking about adding a way to tell it the number 
of digits though, since std.experimental.logger had to deal with 
that. It's not something that's generally come up though. I 
really should have gotten the custom formatting done before now, 
but it is on the todo list. For most stuff though, it's best to 
just use toISOExtString, since it's a standard format and quite 
legible (unlike straight ISO - I don't know why they even have 
the ISO format in addition to the extended ISO format; it's 
pretty much impossible to read).


- Jonathan M Davis

Re: std.data.json formal review

[Sebastiaan Koppe via Digitalmars-d]

On Tuesday, 6 October 2015 at 10:05:46 UTC, Alex wrote:
I wonder if it would be better to write a more abstract 
serialisation/persistance module that could use either 
json,xml,some binary format and future formats.


I think there are too many particulars making an abstract 
(de)serialization module unworkable.


If that wasn't the case it would be easy to transform any format 
into another, by simply deserializing from format A and 
serializing to format B. But a little experiment will show you 
that it requires a lot of complexity for the non-trivial case. 
And the format's particulars will still show up in your code.


At which point it begs the question, why not just write simple 
primitive (de)serialization modules that only do one format? 
Probably easier to build, maintain and debug.


I am reminded of a binary file format I once wrote which 
supported referenced objects and had enough meta-data to allow 
garbage collection. It was a big ugly c++ template monster. Any 
abstract deserializer is going to stay away from that.

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Monday, 5 October 2015 at 16:40:06 UTC, Jan Johansson wrote:
Yes, I know WCF more than well, doing my own bindings, 
federated security bindings, you name it. I also know that WCF 
works with attribute values during runtime, through reflections 
and extract aspect oriented instructions on how to treat types. 
It would be slick to do the same in D.


Yes, but that's only because C# doesn't support DbI, it also 
doesn't mean WCF accepts arbitrary types in contracts: 
http://stackoverflow.com/questions/7444851/why-knowntypeattribute-need-in-wcf

Re: Bug? 0 is less than -10

[anonymous via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:

Maybe I am just too stressed out to see the problem.

[code]
import std.stdio;

void main(){
size_t dec = 0;

	writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec 
<= -10) || (dec >= 10)) );

}
[/code]

[output]
0 true false true
[/output]

How is it generating "true" for (dec <= -10) ? Is there a 
special casting or something?


DMD 2.068.2, Ubuntu 64-bit


dec is a size_t. size_t is unsigned. -10 is cast to unsigned for 
the comparison, resulting in some huge value.

Re: Bug? 0 is less than -10

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:

void main(){
size_t dec = 0;


How is it generating "true" for (dec <= -10) ? Is there a 
special casting or something?


size_t is unsigned, so the -10 is cast to unsigned too for the 
comparison which yields some huge number.


Comparing signed to unsigned is almost always a mistake... but 
one D inherited from C.


This is a reason why I prefer to use int instead of size_t where 
I can but that might require casts and truncation too.

[Issue 15167] [REG2.069-devel] conflicting error with repeated alias declaration

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15167

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
Is there a compelling reason to allow:

   alias a = int;
   alias a = int;

? I can't think of one. The CARD64 example also looks like invalid code that
happened to be accepted.

--

TIOBE october

[Laeeth Isharc via Digitalmars-d]

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

d up from 31 in march.  Just below scala, sas, and fortran.  No 
doubt noisy, and possibly news about Andrei leaving Facebook had 
an influence.  They changed the algorithm to be more tolerant of 
noise, which has had an impact on the results (which might also 
be a hint about the degree of precision in such an exercise) but 
don't say how that affected D, if at all.

[Issue 15167] [REG2.069-devel] conflicting error with repeated alias declaration

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15167

--- Comment #3 from Kenji Hara  ---
(In reply to Walter Bright from comment #2)
> Is there a compelling reason to allow:
> 
>alias a = int;
>alias a = int;
> 
> ? I can't think of one. The CARD64 example also looks like invalid code that
> happened to be accepted.

Because today, two different alias declarations aliasing an identical type are
allowed if they're accessed beyond the import boundaries.

module a;
alias ulong CARD64;

module b;
alias ulong CARD64;

module test;
import a, b;
pragma(msg, CARD64);   // OK, ulong is printed

(It's handled in ScopeDsymbol.search.)

So, if there's no ambiguous, I think accepting such the code would be
reasonable.

--

Re: TIOBE october

[Israel via Digitalmars-d]

On Wednesday, 7 October 2015 at 03:26:37 UTC, Laeeth Isharc wrote:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

d up from 31 in march.  Just below scala, sas, and fortran.  No 
doubt noisy, and possibly news about Andrei leaving Facebook 
had an influence.  They changed the algorithm to be more 
tolerant of noise, which has had an impact on the results 
(which might also be a hint about the degree of precision in 
such an exercise) but don't say how that affected D, if at all.


By noisy you mean hype?

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

--- Comment #12 from Walter Bright  ---
(In reply to Martin Nowak from comment #10)
> (In reply to Walter Bright from comment #5)
> > Or, (2) can be accomplished by overloading isDir() to accept string
> > arguments. But this implies adding an overload to every function that
> > accepts an InputRange. This is out of the question.
> 
> What's the problem with that? It's rather good to precompile the common
> template instantiations into phobos.

The problem is that it pretty much doubles the number of functions in Phobos.
And means that everyone who writes a reusable library has to have double
functions.

--

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

--- Comment #13 from Walter Bright  ---
(In reply to Rainer Schuetze from comment #8)
> It still fails, so instead of emitting an error message the compiler could
> change the type of the function arguments to the aliased type and retry
> deduction and constraint check. For multiple arguments with alias this, this
> could lead to a large number of possible combinations to try, though.

Given how overloading even now can lead to inexplicable seeming results, I view
such an additional layer of complexity as a looming disaster, especially with
the combinatorial aspect of it.

I have thought about something like:

struct foo(T : isInputRange) { ... }

where the constraint would become part of the type deduction logic, but that's
a major addition to the language, not something we can just throw in.

--

[Issue 15169] New: Add more trig functions to std.math

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15169

  Issue ID: 15169
   Summary: Add more trig functions to std.math
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

The following functions should be included in std.math, even if they can be
made from the existing functions, it makes code more readable and easier to
write if they are in the std lib:

inverse sine
inverse cosine
inverse tangent
secant
inverse secant
cosecant
inverse cosecant
cotangent
inverse cotangent

--

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

You don't need RC, just use Unique. In most cases you don't want 
to use RC, because you never have control over the ownership.

[Issue 15169] Add more trig functions to std.math

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15169

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to Jack Stouffer from comment #0)
> inverse sine
> inverse cosine
> inverse tangent

asin, acos, atan?

--

Re: D and microservices

[Russel Winder via Digitalmars-d]

On Tue, 2015-10-06 at 16:21 +, Dejan Lekic via Digitalmars-d wrote:
> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> > Has anyone got a small example of microservices using D, with 
> > Vibe.d or otherwise, that I can make use of? I need some 
> > examples of small microservices for a session at μCon 2015.
> 
> As far as I know, there is no implementation of microservices as 
> we see in the Java world. IMHO, D community should come up with a 
> good microservices architecture. As you pointed out, it could be 
> based on vibed.

Pity, microservices is a very fashionable thing just now, and Go is wiping
the floor with Node and Java. Well that bit is opinion but… many people are
getting into all this non-blocking, event-driven, shared memory stuff and
boiling their brains, whereas the Go folk are doing blocking stuff using
dataflow which is much easier to program. 

-- 
Russel.
=
Dr Russel Winder t:+44 20 7585 2200   voip:sip:
russel.win...@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:rus...@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder



signature.asc
Description: This is a digitally signed message part

Re: What keeps you from using gtkd or dlangui

[Nick Sabalausky via Digitalmars-d]

On 10/06/2015 02:21 AM, Russel Winder via Digitalmars-d wrote:

On Mon, 2015-10-05 at 14:21 -0400, Nick Sabalausky via Digitalmars-d
wrote:



[…]

GNOME3? I'm surprised to hear that. My (perhaps inaccurate)
understanding was that it landed with quite a thud and alienated a
lot
of its userbase (and even many of it's developers), moreso than the
early days of KDE4 did. And I've never personally known anyone who
did
use GNOME3 (to my knowledge), so I figured it had become very much
fringe.



Your understanding is indeed inaccurate. Yes there was a huge kerfuffle
when the GNOME2 → GNOME3 thing happened. Many very vocal people
screamed that the GNOME people were a bunch of w## and all that
sort of stuff. Many GNOME2 users abandoned GNOME and rewrote GNOME2.
Many people though got over the marketing (and other) stupidity of the
GNOME developers, and actually tried the revolutionary GNOME3 and liked
it.


Fair enough. Of course that doesn't account for *all* those who were 
unhappy with GNOME3 (but I know you're not implying it does): My dislike 
of GNOME3 *is* from after trying it first. Just seemed wacky to me, and 
I didn't feel much point in bothering to adjust to it, what with all the 
other alternatives out there.


Actually didn't mind GNOME2 *too* much back at the time: My main beefs 
with GNOME2 were just the overly-padded GTK widgets/rendering and it 
seemed to be going for more of an OSX experience for my tastes (Plus I 
never really liked the Nautilus-based file managers: Like Finder, they 
just make me feel like my hands are tied behind my back).



I know I went to XFCE but couldn't make it work.


Y'know, I've always had a fair amount of respect for XFCE, but their big 
problem has always been polish. It's always had a lot of promise and 
potential, and I still respect it for that. But it's been in strong need 
of a big heavy dose of polish for a looong time.


(Ex: Just try adjusting the taskbar. And then go back and see how slick, 
intuitive and "just works" MS (go figure!) managed to make taskbar 
adjusting a full twenty years ago, back in Win95. Even KDE still hasn't 
managed to match that either, although it's still way ahead of XFCE in 
that regard).




This does not excuse some of the appalling behaviours of the GNOME
developers, some of which continue to happen. This is sad.



Yea, :( They've even lost major developers over some of it, AIUI. It's 
too bad. Gnome may not be my cup of tea, but its community does deserve 
better.



[…]
Wait, is there a distinction between "wx" and "wxWidgets"?


No, just bad phrasing on my part.

And wxWidgets is the old wxWindows.



Ahh, ok.

Re: D and microservices

[Dicebot via Digitalmars-d]

On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
Has anyone got a small example of microservices using D, with 
Vibe.d or otherwise, that I can make use of? I need some 
examples of small microservices for a session at μCon 2015.


What do you mean by microservice examples? It is infrastructure 
methodology, not specific code thing, any simple network service 
can be viewed as microservice.

Re: What keeps you from using gtkd or dlangui

[Nick Sabalausky via Digitalmars-d]

On 10/06/2015 02:53 PM, Jonathan M Davis wrote:

On Tuesday, 6 October 2015 at 18:40:17 UTC, Nick Sabalausky wrote:

Well that's good to hear. KDE4 went through the same path. After
spending time with KDE4, I found it to be it a terrible blunder of an
upgrade even after, several point releases in, people were saying it
had finally been fixed. It still has some warts that annoy me (and
some things I just gave in on), but it's finally won me back from my
hiatus with XFCE/LXDE. Looking forward to v5 stabilizing further.


IIRC, KDE 4 really became properly usable around 4.2


?!?

It must've been REALLY bad before that! I think I first tried it around 
v4.4-v4.6-ish and thus became an immediate fan of the TrinityDE project 
;) At that point, KDE4 just felt to me very clumsy, unpolished, sluggish 
and borderline broken.



, and of course,
around that time, kmail when to hell in a handbasket, because they added
that akonadi trash to kdepim and switched to that for kmail's backend.
*bleh*


> kmail has a great UI, but its backend sucks big time, and since AFAIK,
> they've never acknowledged that it's a horrible design, they're probably
> never going to fix it... :(

One of the projects still on my bucket list (and will likely remain 
there indefinitely, the way things seem to go...) is a desktop GUI 
mail/ng client. It pains me that I've wound up settling for Thunderbird :(


Desktop mail clients pretty much evaporated once everyone jumped on the 
webmail bandwagons. And now everyone hates email because it's "such a 
pain", but...uhh...yea...if you're webmailing it, it's no freaking wonder!




Oh, well. On the whole, KDE 4 has been quite solid for quite a long time
now, and nothing else even comes close to what I'm looking for.
Fortunately, the transition to KDE 5 should be much smoother, because
they don't have to redesign all of the guts this time. But still, I'd
just as soon not jump on it very quickly.



///ditto to all that ;)

Re: What keeps you from using gtkd or dlangui

[karabuta via Digitalmars-d]

On Sunday, 4 October 2015 at 13:38:04 UTC, Manu wrote:
On 4 October 2015 at 23:24, karabuta via Digitalmars-d 
 wrote:
For some time now I have been trying various GUIs options in 
D. I came to settle on gtkd and dlangui(stability is not my 
current priority).


In YHO, what keeps you from using any of those fully(mostly)? 
Gtkd first, followed by dlangui.  I need to know what I am 
signing up for.


Qt is the defacto portable standard, including mobile devices. 
Sadly, there is no substitute, so as far as I'm concerned, D 
waits for a Qt5 binding.


Can someone please tell me what is wrong dlangui? It might not be 
stable and it mighint u()

{
  int m = 35, bar = 5;
  bar--;
  m /= bar;
  return m;
}t have some few bugs, but is it something I can rely on for a 
windows-linux GUI app. Surely it might get better somehow.



Any unfiltered opinion on this? It hurts so bad that tkd does not 
look convincing.

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:
I'm not sure what else I can say. The example I posted says it 
all, and it can't be done properly in D (or C#, but why lower 
the bar because of their mistakes? ;)


It's a side effect of having the lifetime of an object managed by 
the GC. There's no way around that except to use something else 
like manual memory management or reference counting. In D, it's a 
good reason to use structs to manage resources like that, and 
since most objects really have no need of inheritance and have no 
business being classes, it's usually fine. But in the cases where 
you do have to use a class, it can get annoying.


I'm not sure exactly how C# and Java handle destruction for 
non-memory resources, but I'm guessing it's something like 
calling GC.collect() manually every couple of seconds. If the 
textures aren't released in the destructor, I don't really see 
any other way to tell when they're referenced or not.


Of course though, mobile devices are the new PC, and battery 
life is very much a concern, so this is a total 
waste...especially if I'm doing very little GC allocation 
anyways. Also, of course, there are the performance issues.


You simply do not rely on the GC or the destruction of the object 
to free system resources. You manually call a function on the 
object to free those resources when you're done with it. In the 
case of C#, they have a construct to help with it that (IIRC) is 
something like


using(myObj)
{
} // myObj.dispose() is called when exiting this scope

In Java, you'd have no choice but to call dispose manually. And 
yes, that sucks, but it's life with a GC-managed object. The GC 
has a number of benefits to it, but it does not come without its 
costs.


Having the option to have properly ref-counted classes in 
addition to classes managed by the GC would definitely be an 
improvement, and I expect that we'll get there at some point, but 
there _are_ ways to deal with the problem in the interim, even if 
it's not ideal.


In most cases though, just don't use classes. In most cases, 
inheritance is a horrible way to write programs anyway, because 
it's _horrible_ for code reuse. It definitely has its uses, but 
I've found that I rarely need classes in D. I suspect that far 
too many folks new to D end up using classes instead of structs 
just because they're used to using classes in C++ or Java or 
whatever.


- Jonathan M Davis

Re: What keeps you from using gtkd or dlangui

[Nick Sabalausky via Digitalmars-d]

On 10/06/2015 11:33 AM, Johannes Pfau wrote:


As of 2015, critical reception is much more positive.[48] Debian, a
Linux distribution that had historically used GNOME 2, switched to Xfce
when GNOME 3 was released. However, Debian readopted GNOME 3 in time
for the release of Debian 8 "Jessie".[49][48] Linus Torvalds, the
creator of the Linux kernel, switched back to GNOME 3 in 2013.[48]
https://en.wikipedia.org/wiki/GNOME#GNOME_3



Wow, I had no idea about any of that. While I doubt I'll be switching 
(still don't like GTK or Nautilus, and happy enough with KDE), but now 
I'm curious to take another look, see how it's come along.



Fedora and RHEL also use gnome 3 by default.

Gnome 3 was kinda annoying but has improved with every release. If
you use the keyboard shortcuts, virtual desktops and some nice
extensions it's a nice DE. And with proper icons (numix) it also looks
great.



Well that's good to hear. KDE4 went through the same path. After 
spending time with KDE4, I found it to be it a terrible blunder of an 
upgrade even after, several point releases in, people were saying it had 
finally been fixed. It still has some warts that annoy me (and some 
things I just gave in on), but it's finally won me back from my hiatus 
with XFCE/LXDE. Looking forward to v5 stabilizing further.

Re: D and microservices

[Nick Sabalausky via Digitalmars-d]

On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:

On Tue, 2015-10-06 at 16:21 +, Dejan Lekic via Digitalmars-d wrote:

On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:

Has anyone got a small example of microservices using D, with
Vibe.d or otherwise, that I can make use of? I need some
examples of small microservices for a session at μCon 2015.


As far as I know, there is no implementation of microservices as
we see in the Java world. IMHO, D community should come up with a
good microservices architecture. As you pointed out, it could be
based on vibed.


Pity, microservices is a very fashionable thing just now, and Go is wiping
the floor with Node and Java. Well that bit is opinion but… many people are
getting into all this non-blocking, event-driven, shared memory stuff and
boiling their brains, whereas the Go folk are doing blocking stuff using
dataflow which is much easier to program.



Felt stupid for not being hip to this "microservices" thing you say, so 
just looked it up. But it sounds to me like it's basically just a 
buzz-driven rediscovery of the basic principles of proper encapsulation 
and Unix philosophy ("do one thing and do it well").


(Kinda like how "cloud" sounds like a big fancy new revolution until you 
realize it's just the hip new word for "internet" or "hosted". Or 
"Facade design pattern" vs plain old "It's a thin wrapper".)


Does that sound about accurate, or am I missing something?

Re: D and microservices

[Mengu via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:

On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:
On Tue, 2015-10-06 at 16:21 +, Dejan Lekic via 
Digitalmars-d wrote:
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder 
wrote:

Has anyone got a small example of microservices using D, with
Vibe.d or otherwise, that I can make use of? I need some
examples of small microservices for a session at μCon 2015.


As far as I know, there is no implementation of microservices 
as
we see in the Java world. IMHO, D community should come up 
with a
good microservices architecture. As you pointed out, it could 
be

based on vibed.


Pity, microservices is a very fashionable thing just now, and 
Go is wiping
the floor with Node and Java. Well that bit is opinion but… 
many people are
getting into all this non-blocking, event-driven, shared 
memory stuff and
boiling their brains, whereas the Go folk are doing blocking 
stuff using

dataflow which is much easier to program.



Felt stupid for not being hip to this "microservices" thing you 
say, so just looked it up. But it sounds to me like it's 
basically just a buzz-driven rediscovery of the basic 
principles of proper encapsulation and Unix philosophy ("do one 
thing and do it well").


(Kinda like how "cloud" sounds like a big fancy new revolution 
until you realize it's just the hip new word for "internet" or 
"hosted". Or "Facade design pattern" vs plain old "It's a thin 
wrapper".)


Does that sound about accurate, or am I missing something?


a half of it is the buzz and other half of is not. remember 
people talking about reactjs, go and rails being buzz? they were 
the same. we have built an online payment gateway and we are 
about to decouple our application and switch to microservices 
architecture. we have an api, a dashboard, a checkout page, 
mobile flow. we have to deal with accounting and reporting as 
well. and there is no way that this application will turn into a 
giant monolith. i don't want that. nobody wants that. it will 
become something we cannot handle.


another thing is whenever we do deployments we have to take down 
the whole application and go offline. i know there are other 
workarounds but when we only want to deploy mobile payments or 
the api, other functionalities should continue working and our 
customers should be able to pay.


nobody suggests starting with microservices architecture because 
you'll never know where things will lead you however when it 
becomes a giant the suggestion is to use microservices.


one other benefit of using this microservice is that you don't 
have to look for specific language programmers. you only need to 
hire good programmers as the only requirement  is to do one thing 
and and doing it well. the rest is about communication.

Re: D 2015/2016 Vision?

[rsw0x via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:15:09 UTC, Paulo Pinto wrote:
GC is not an hindrance when the languages are built to properly 
work with it.


--
Paulo


+1, tired of repeating this.

[Issue 15169] Add more trig functions to std.math

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15169

--- Comment #2 from Jack Stouffer  ---
(In reply to ag0aep6g from comment #1)
> (In reply to Jack Stouffer from comment #0)
> > inverse sine
> > inverse cosine
> > inverse tangent
> 
> asin, acos, atan?

My mistake, sorry.

--

Re: D 2015/2016 Vision?

[Paulo Pinto via Digitalmars-d]

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:

On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:

[...]


It's a side effect of having the lifetime of an object managed 
by the GC. There's no way around that except to use something 
else like manual memory management or reference counting. In D, 
it's a good reason to use structs to manage resources like 
that, and since most objects really have no need of inheritance 
and have no business being classes, it's usually fine. But in 
the cases where you do have to use a class, it can get annoying.



[...]


You simply do not rely on the GC or the destruction of the 
object to free system resources. You manually call a function 
on the object to free those resources when you're done with it. 
In the case of C#, they have a construct to help with it that 
(IIRC) is something like


using(myObj)
{
} // myObj.dispose() is called when exiting this scope

In Java, you'd have no choice but to call dispose manually. And 
yes, that sucks, but it's life with a GC-managed object. The GC 
has a number of benefits to it, but it does not come without 
its costs.


Having the option to have properly ref-counted classes in 
addition to classes managed by the GC would definitely be an 
improvement, and I expect that we'll get there at some point, 
but there _are_ ways to deal with the problem in the interim, 
even if it's not ideal.


In most cases though, just don't use classes. In most cases, 
inheritance is a horrible way to write programs anyway, because 
it's _horrible_ for code reuse. It definitely has its uses, but 
I've found that I rarely need classes in D. I suspect that far 
too many folks new to D end up using classes instead of structs 
just because they're used to using classes in C++ or Java or 
whatever.


- Jonathan M Davis


As of Java 7

try (BufferedReader br =
   new BufferedReader(new FileReader(path))) {
return br.readLine();
}


Or just use a functional programming pattern for resource 
management:


withFile (something, { fd -> work with file })

Better languages allow to write that like

withFile (something) { fd -> work with file }

GC is not an hindrance when the languages are built to properly 
work with it.


--
Paulo

[Issue 15165] [Reg 2.069-devel] Can no longer use GetOptException with enforceEx

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15165

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Martin Nowak  ---
https://github.com/D-Programming-Language/phobos/pull/3697
https://github.com/D-Programming-Language/phobos/commit/d929cea294d3477684e36b3cda3a8d0ec31e21d8

--

Re: What keeps you from using gtkd or dlangui

[Russel Winder via Digitalmars-d]

On Mon, 2015-10-05 at 21:05 +, bachmeier via Digitalmars-d wrote:
> 
[…]
> This was one of the more extreme cases though:
> 
> - GNOME 3 was very different from GNOME 2. It had no appeal to 
> their existing users.

Because they hadn't tried the new way, they just wanted the old way. I
was in that camp.

> - GNOME users were told that GNOME 2 was dead so they had to 
> "upgrade".

Nothing wrong with that per se, but the GNOME team definitely failed on
almost all counts of marketing and customer care.

> - There was little advance warning that it would be so different.

Not entirely true. There was a good 6 months warning.

> These factors combined to make the vast majority of GNOME users 
> very upset and very vocal. I'm a happy MATE user today but I had 
> to switch to KDE for a while until that became a realistic option.

Not vast majority by any means. Many very vocal people yes.

I now really like GNOME3 and wouldn't want to switch back to GNOME2 or
anything remotely like it.

I do wish though that the GNOME team would learn better marketing and
customer care.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: What keeps you from using gtkd or dlangui

[Jonathan M Davis via Digitalmars-d]

On Monday, 5 October 2015 at 18:21:55 UTC, Nick Sabalausky wrote:

On 10/05/2015 12:35 PM, Russel Winder via Digitalmars-d wrote:
On Sun, 2015-10-04 at 18:28 -0400, Nick Sabalausky via 
Digitalmars-d

wrote:



[…]
I absolutely, positively cannot stand software that uses GTK 
for GUIs
(including Unity and GNOME...not that anybody actually uses 
GNOME
anymore) regardless of whether I'm running on Windows or 
Linux. So I
definitely won't write software that uses it either, if I can 
help

it.


Lots of us use GNOME and are proud to do so.



GNOME3? I'm surprised to hear that. My (perhaps inaccurate) 
understanding was that it landed with quite a thud and 
alienated a lot of its userbase (and even many of it's 
developers), moreso than the early days of KDE4 did. And I've 
never personally known anyone who did use GNOME3 (to my 
knowledge), so I figured it had become very much fringe.


Enough folks hated it that there have been at least two projects 
started which are forks of gnome (mate and cinnamon), and some 
distros are now using those as their default, which has reduced 
gnome's foothold. So, it did tick off a lot of people, but I 
don't know how many folks actually switched or how many have come 
back now that gnome 3 has become much more polished. A lot of 
folks just use what their distro has. Clearly, there are plenty 
of folks who use gnome 3 now, regardless of how it was received 
initially, but how many ultimately dropped gnome because of gnome 
3 is probably hard to judge. I don't think that there's much 
question though that gnome 3 helped further fragment the *nix DE 
communities, because now we have mate and cinnamon added into the 
mix. That's not necessarily a bad thing, but between that and 
Unity, gnome is bound to have lost a lot of market share even if 
they still have a significant number of users - though since the 
gnome guys aren't exactly in it for the money, that's not 
necessarily a problem. They'll just keep on trucking, making what 
they think is the best DE, and those that like it will use it, 
while those that don't will find an alternative.


Personally, I definitely haven't liked what I've seen and heard 
of gnome 3 and would rather use gnome 2 (much as I hated it), but 
I'm a diehard KDE guy, so it doesn't really matter all that much 
to me so long as it doesn't end up affecting KDE in a negative 
way.


- Jonathan M Davis

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

--- Comment #8 from Rainer Schuetze  ---
> The trouble is that it fails in the constraint, not the type deduction part.

It still fails, so instead of emitting an error message the compiler could
change the type of the function arguments to the aliased type and retry
deduction and constraint check. For multiple arguments with alias this, this
could lead to a large number of possible combinations to try, though.

--

Re: SysTime bug or feature?

[tchaloupka via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 05:54:44 UTC, Jonathan M Davis 
wrote:
It is by design, albeit undesirable. When SysTime was 
originally written, it was impossible to have a default value 
for a class reference other than null. So, unless SysTime was 
going to take the performance hit of constantly checking 
whether its TimeZone was null, SysTime.init was going to 
segfault if you did anything with it that required its 
TimeZone. And I wasn't about to have it constantly checking for 
null. In the vast majority of cases, the value of a SysTime 
comes from Clock.currTime() or from parsing a string, and if 
code is trying to do anything but assign to a SysTime which is 
SysTime.init, then that means that it failed to initialize it 
like it should have.


Thanks for thorough explanation.
I found the problem using vibe and REST API with SysTime argument 
with default value (which didn't work due to the bug there) when 
I tried to print out the passed value and ended up with the 
segfault. So I guess it doesn't bite devs often as it is mostly 
used as you wrote.

[Issue 15057] std.string.indexOf and friends do not accept custom types with alias this to string

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15057

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Nowak  ---


*** This issue has been marked as a duplicate of issue 15027 ***

--

[Issue 15168] New: std.variant.Algebraic interacts badly with string alias this sub-types

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15168

  Issue ID: 15168
   Summary: std.variant.Algebraic interacts badly with string
alias this sub-types
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: radu.raca...@gmail.com

When sub-typing a string via alias this, the Algebraic construct fails to
distinguish the sub-type from the string type.

Using the following:

import std.variant: Algebraic;

struct N { double val; alias val this; }
struct S { string val; alias val this; }
alias T = Algebraic!(S, N);

pragma(msg, T.AllowedTypes); 

prints (N, string)

This happens in v2.068.2 win32

The expected behavior is to have S as a allowed type instead of string.

A workaround is to use std.typecons.Proxy in the S type. Like:

struct S
{
/// the value
string val;

this(string s)
{
this.val = s;
}

import std.typecons : Proxy;
mixin Proxy!val;
}

--

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

Martin Nowak  changed:

   What|Removed |Added

 CC||rburn...@gmail.com

--- Comment #9 from Martin Nowak  ---
*** Issue 15057 has been marked as a duplicate of this issue. ***

--

Re: This Week in D: livestreaming and we're moving forward on Windows bindings!

[Iain Buclaw via Digitalmars-d-announce]

On 6 Oct 2015 12:30 am, "Adam D. Ruppe via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 5 October 2015 at 21:59:49 UTC, anonymous wrote:
>>
>> I don't think Adam minds my nagging. I hope he doesn't.
>
>
> No problem at all. I confess I slapped this one together in a bit of a
rush: yesterday didn't feel like Sunday to me (it was a special weekend in
my church so my routine was all changed) so I forgot to do it and instead
quickly pieced it together today in an attempt to get it out before it was
too late.
>

Speaking of too late, I realised I missed the boat for this announcement,
unless you're still able to add stuff.  I assume it might be fitting,
despite not going on "in here".

https://sourceware.org/ml/gdb-patches/2015-09/msg00612.html

Iain.

Re: Shout out to D at cppcon, when talkign about ranges.

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 06:52:13 UTC, Ulrich Kuettler wrote:

On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:
Given that starting point, ranges of different strength are an 
"obvious" next step that many people thought up independently. 
D took it one way and C++ went another.


When designing my range library, I looked at all the prior art 
available to me including D ranges and decided D's path was 
not the right one for C++.


What is your thinking here? Did you write it down somewhere? 
This would be very interesting.


Obviously, Eric would have to respond for us to know what his 
reasoning was, but I expect that it least part of it stems from 
the fact that C++ already uses iterators heavily. So, having a 
range-based solution that doesn't interact with iterators (like D 
has) doesn't fit in well with the existing code and paradigms. 
Even if you were to assume that D's approach is superior (which 
is debatable), that doesn't mean that it's a good fit for C++. D 
has the advantage of having considerably less baggage to deal 
with, so we have more freedom in the direction that we go. 
Whether we go in the right direction or not is another matter, 
but C++ has considerably more constraints than we have, so it's 
no surprise if we end up with different solutions.


- Jonathan M Davis

Re: Picking specific D compiler with rdmd

[Dicebot via Digitalmars-d-learn]

--compiler

Re: Picking specific D compiler with rdmd

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 07:16:39 UTC, Nordlöw wrote:
I find now flag to rdmd for choosing a specific dmd. Is there 
none?


Doh, there was already: --compiler

[Issue 15165] New: [Reg 2.069-devel] Can no longer use GetOptException with enforceEx

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15165

  Issue ID: 15165
   Summary: [Reg 2.069-devel] Can no longer use GetOptException
with enforceEx
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import std.exception : enforceEx;
import std.getopt : GetOptException;

void main()
{
enforceEx!GetOptException(true, "msg");
}
CODE

dmd -c bug

bug.d(6): Error: template std.exception.enforceEx cannot deduce function from
argument types !(GetOptException)(bool, string), candidates are:
DPL/dmd/src/../../phobos/std/exception.d(609):std.exception.enforceEx(E
: Throwable) if (is(typeof(new E("",
"DPL/dmd/src/../../phobos/std/exception.d", 610
DPL/dmd/src/../../phobos/std/exception.d(621):std.exception.enforceEx(E
: Throwable) if (is(typeof(new E("DPL/dmd/src/../../phobos/std/exception.d",
622))) && !is(typeof(new E("", "DPL/dmd/src/../../phobos/std/exception.d",
622


--

[Issue 15166] New: [Ref 2.069-devel] spurious statement not reachable warning in static foreach loop

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15166

  Issue ID: 15166
   Summary: [Ref 2.069-devel] spurious statement not reachable
warning in static foreach loop
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
template Group(T...)
{
alias expand = T;
}

private bool compare(alias Group1, alias Group2)()
{
foreach (index, element; Group1.expand)
{
static if (!is(Group1.expand[index] == Group2.expand[index]))
return false;
}
return true;
}

unittest
{
alias a = Group!(int, double), b = Group!(double, int);
static assert (!compare!(a, b));
}
CODE

dmd -c -w -unittest bug

DMD v2.069-devel-6279af3 DEBUG
bug.d(13): Warning: statement is not reachable

This is similar to issue 14835, but now the warning is also emitted with static
foreach loops.

--

Re: Walter and I talk about D in Romania

[Rory McGuire via Digitalmars-d-announce]

On Tue, Oct 6, 2015 at 2:43 AM, Andrei Alexandrescu via
Digitalmars-d-announce  wrote:

> ...
>
The event is sponsored by Siemens and free for the audience. I'll relay
> your confusion to the organizers. -- Andrei
>
>
That is interesting, do you know how Siemens ended up being the sponsor?

[Issue 15150] [REG2.068.1] Public selective import causes conflict

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15150

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/9e1e61d6e9d7713f8d64def9c468c0771bb6efff
fix Issue 15150 - Public selective import causes conflict

By making `EnumMember` to the subclass of `VarDeclaration`, the symbol itself
can be representation of the enum member name.

https://github.com/D-Programming-Language/dmd/commit/f8d24cd1796bfe369fcd55feff191b99b96aa094
Merge pull request #5161 from 9rnsr/fix15150

[REG2.068.1] Issue 15150 - Public selective import causes conflict

--

[Issue 15150] [REG2.068.1] Public selective import causes conflict

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15150

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

--- Comment #11 from Martin Nowak  ---
Slight variation of the bug where the aliased string is an lvalue, but cannot
be assigned.

cat > bug.d << CODE
struct InternedString
{
void opAssign(InternedString other)
{
this.data = other.data;
}

string data;
alias data this;
}

auto bug(InternedString s)
{
import std.file : exists;
return exists(s);
}
CODE

This breaks b/c some code in utf.d tries to `r = r[1 .. $]` slice an
InternedString.

--

Picking specific D compiler with rdmd

[Nordlöw via Digitalmars-d-learn]

I find now flag to rdmd for choosing a specific dmd. Is there 
none?

Re: Shout out to D at cppcon, when talkign about ranges.

[Walter Bright via Digitalmars-d]

On 10/5/2015 7:31 PM, Eric Niebler wrote:
> The design of the D ranges and algorithms owe quite a lot to C++, and I've 
heard
> Andrei say as much.

D ranges owe plenty to C++ iterators and algorithms, no doubt. Boost ranges, I 
can't agree.


> Stepanov did the hard work of defining common algorithms in
> terms of iterators of different strength. Given that starting point, ranges of
> different strength are an "obvious" next step that many people thought up
> independently. D took it one way and C++ went another.

It seems obvious in retrospect, I agree. But looking at the early Boost ranges, 
they didn't take the obvious step :-)


> When designing my range library, I looked at all the prior art available to me
> including D ranges and decided D's path was not the right one for C++. My work
> is based on Boost.Range. I only posted here to clear up what appeared to me to
> be confusion about that.

Re: What keeps you from using gtkd or dlangui

[Russel Winder via Digitalmars-d]

On Mon, 2015-10-05 at 14:21 -0400, Nick Sabalausky via Digitalmars-d
wrote:
> 
[…]
> GNOME3? I'm surprised to hear that. My (perhaps inaccurate) 
> understanding was that it landed with quite a thud and alienated a
> lot 
> of its userbase (and even many of it's developers), moreso than the 
> early days of KDE4 did. And I've never personally known anyone who
> did 
> use GNOME3 (to my knowledge), so I figured it had become very much
> fringe.
> 

Your understanding is indeed inaccurate. Yes there was a huge kerfuffle
when the GNOME2 → GNOME3 thing happened. Many very vocal people
screamed that the GNOME people were a bunch of w## and all that
sort of stuff. Many GNOME2 users abandoned GNOME and rewrote GNOME2.
Many people though got over the marketing (and other) stupidity of the
GNOME developers, and actually tried the revolutionary GNOME3 and liked
it. I know I went to XFCE but couldn't make it work. Then when I
actually tried GNOME3 instead of just screaming about the revolution, I
found I really liked it.

This does not excuse some of the appalling behaviours of the GNOME
developers, some of which continue to happen. This is sad.

> […]
> Wait, is there a distinction between "wx" and "wxWidgets"?

No, just bad phrasing on my part.

And wxWidgets is the old wxWindows.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Objective C and C++ Compatibility?

[Jacob Carlborg via Digitalmars-d]

On 2015-10-05 16:16, Jack Stouffer wrote:

Around the release of 2.068 I saw a couple of threads about Objective C
compatibility in D, but it wasn't merged into stable for 2.068. Is this
going to be merged into 2.069?


I think it's already merged into stable


Any improvements from the very basic support that was shown?


Unfortunately no.


Is there any documentation?


There's an open pull request for that [1]. You can either read that or 
the tests in the compiler [2].


[1] https://github.com/D-Programming-Language/dlang.org/pull/1039
[2] 
https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/objc_call.d


--
/Jacob Carlborg

Re: std.Algebraic alias this

[Radu via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 06:37:16 UTC, Nicholas Wilson wrote:

On Monday, 5 October 2015 at 11:31:32 UTC, Radu wrote:
There is a weird rule on how compiler treats alias this for 
the N and S types bellow.


[...]


Please file a bug report.

Also do the errors change if you reverse the order in T i.e. 
alias T = Algebraic!(S,N); ?


OK, will do.

Nope alias T = Algebraic!(S,N) gives the same error. AllowedTypes 
are (string, N)


This happens in 2.068.2 btw

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote:
Well, again that has it's pros and cons. This is why I just 
want a normal language solution like DIP74.


They're not the same thing at all. scoped is supposed to put the 
class on the stack, not the heap. And it's not ref-counted. It's 
so that you can create a class object in place, use it, and throw 
it away without doing any heap allocation. Essentially, it allows 
you to use a class as if it were a non-copyable struct. Even if 
we end up with ref-counting supported in the language, it doesn't 
obviate the need for scoped classes. They're for different use 
cases.


- Jonathan M Davis

[Issue 15167] New: [Reg 2.069-devel] conflicting error with repeated alias declaration

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15167

  Issue ID: 15167
   Summary: [Reg 2.069-devel] conflicting error with repeated
alias declaration
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
version (X86_64)
alias ulong CARD64;

static if (true)
alias ulong CARD64;
CODE

dmd -c bug


DMD v2.069-devel-6279af3 DEBUG
bug.d(5): Error: alias bug.CARD64 conflicts with alias bug.CARD64 at bug.d(2)


It might indeed be treated as conflict but it used to work with 2.068.2 as long
as one of the aliases is within a static if.

--

Re: std.Algebraic alias this

[Radu via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 06:37:16 UTC, Nicholas Wilson wrote:

On Monday, 5 October 2015 at 11:31:32 UTC, Radu wrote:
There is a weird rule on how compiler treats alias this for 
the N and S types bellow.


[...]


Please file a bug report.

Also do the errors change if you reverse the order in T i.e. 
alias T = Algebraic!(S,N); ?


bug report

https://issues.dlang.org/show_bug.cgi?id=15168

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #10 from Martin Nowak  ---
(In reply to Walter Bright from comment #5)
> Or, (2) can be accomplished by overloading isDir() to accept string
> arguments. But this implies adding an overload to every function that
> accepts an InputRange. This is out of the question.

What's the problem with that? It's rather good to precompile the common
template instantiations into phobos.

--

Re: Generalize .ptr to RawPtr ranges?

[Dmitry Olshansky via Digitalmars-d]

On 06-Oct-2015 01:36, Brad Anderson wrote:

On Monday, 5 October 2015 at 10:06:04 UTC, Dmitry Olshansky wrote:

Just a random idea - slices have .ptr and therefor have a bunch of
advantages such as SSE optimized copy routine.

Once I wrap a slice in something (anything) it looses ALL of that.
Now for instance std.container.Array!int.Range can easily provide .ptr
property, together with .length it would allow us to use memcpy etc.

Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where
hasRawPtr!(Range) would test for compatible .ptr and .length.

The benefit compared to manually slicing the .ptr and using that, then
propagating the change back to the original range is that:
- it's error prone
- awkwardly replicated at each call site

So it would be much better to retain safe range interface and
encapsulate speed-hacks inside of the algorithms.

Thoughts?


Somewhat related, C++17 is going to add the concept of Contiguous
Iterators.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf


I'm thinking it might be better to add support RawChunkedAccess for 
ranges that can offer raw pointer(s) but only in bits and peices like 
e.g. a typical dequeue would or more generally segmented data 
structure/range.


If these two cases could be unified in some satisfactory that would be a 
huge win.


--
Dmitry Olshansky

Re: Shout out to D at cppcon, when talkign about ranges.

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:

On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:
Yes, you can build debug iterators that know their limits, or 
iterators with back pointers to the range. This is not an 
inherent property of Boost ranges, does not appear in the 
Boost description of ranges (unless I missed it), and is a 
kludge. I do not agree that D ranges owe anything to that 
design.


The design of the D ranges and algorithms owe quite a lot to 
C++, and I've heard Andrei say as much. Stepanov did the hard 
work of defining common algorithms in terms of iterators of 
different strength. Given that starting point, ranges of 
different strength are an "obvious" next step that many people 
thought up independently. D took it one way and C++ went 
another.


D's ranges and their use in D's standard library owe a _lot_ to 
C++ - especially to the STL. They just don't owe anything to 
Boost's ranges. They're two different paths from the same root.


When designing my range library, I looked at all the prior art 
available to me including D ranges and decided D's path was not 
the right one for C++. My work is based on Boost.Range.


It'll be interesting to see where that goes.

- Jonathan M Davis

Re: DIP82: static unittest blocks

[Jonathan M Davis via Digitalmars-d]

On Monday, 5 October 2015 at 19:32:00 UTC, H. S. Teoh wrote:
One minor issue with the DIP as currently written, though: it 
should be stipulated that inside a static unittest block, it is 
illegal to reference template arguments to the enclosing 
template block. Otherwise, you may run into pathological cases 
where it's not clear what the correct semantics should be:


Given how the rest of the DIP is written, I don't see how it 
would even be possible for it to be legal to reference any 
template arguments. That's implied by the other semantics 
involved. But I should update the DIP to make that explicit.


- Jonathan M Davis

Re: std.Algebraic alias this

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 5 October 2015 at 11:31:32 UTC, Radu wrote:
There is a weird rule on how compiler treats alias this for the 
N and S types bellow.


[...]


Please file a bug report.

Also do the errors change if you reverse the order in T i.e. 
alias T = Algebraic!(S,N); ?

Re: Shout out to D at cppcon, when talkign about ranges.

[Ulrich Kuettler via Digitalmars-d]

On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:

On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:
Yes, you can build debug iterators that know their limits, or 
iterators with back pointers to the range. This is not an 
inherent property of Boost ranges, does not appear in the 
Boost description of ranges (unless I missed it), and is a 
kludge. I do not agree that D ranges owe anything to that 
design.


The design of the D ranges and algorithms owe quite a lot to 
C++, and I've heard Andrei say as much. Stepanov did the hard 
work of defining common algorithms in terms of iterators of 
different strength.


There is no denying that D owns a lot to C++. Then again D comes 
with great ideas of its own and success has many fathers.


Given that starting point, ranges of different strength are an 
"obvious" next step that many people thought up independently. 
D took it one way and C++ went another.


When designing my range library, I looked at all the prior art 
available to me including D ranges and decided D's path was not 
the right one for C++.


What is your thinking here? Did you write it down somewhere? This 
would be very interesting.


My work is based on Boost.Range. I only posted here to clear up 
what appeared to me to be confusion about that.


\e

How to check if JSONValue of type object has a key?

[Borislav Kosharov via Digitalmars-d-learn]

I'm using std.json for parsing json. I need to check if a 
specific string key is in JSONValue.object. The first thing I 
tried was:


JSONValue root = parseJSON(text);
if(root["key"].isNull == false) {
//do stuff with root["key"]
}

But that code doesn't work, because calling root["key"] will 
throw an exception of key not fount if "key" isn't there.


I need some method `root.contains("key")` method to check if the 
object has a key.


Thanks in advance!

Re: Varargs and default arguments

[anonymous via Digitalmars-d-learn]

On Tuesday 06 October 2015 22:01, Nick Sabalausky wrote:

> Ok, D-style varargs can accept a parameter length of zero:
> 
> ---
> void foo(T...)(T args) {
>  //...
> }
> foo();
> foo(t1, t2);
> ---

Terminology fun:

The spec uses the term "D-style variadic function" for something else yet: 
`int abc(char c, ...);` -- http://dlang.org/function.html#variadic

Yours is technically a "variadic function template", I guess, i.e., a 
function template that's variadic, not a template of a variadic function.

> Is there any way to stick a param with a default value before that?
> 
> ---
> void foo(T...)(string str=null, T args=/+what goes here???+/) {
>  //...
> }
> foo();
> foo(str);
> foo(str, t1, t2);
> ---
> 
> Obviously this can be worked around easily enough by splitting it into 
> two overloads ("foo(string str=null)" and "foo(string str, T args)"), 
> but is there a way to do it in one?

You can put an expression tuple ("expression AliasSeq"??) there. T.init is 
one that always fits T's types. But you could generate one with different 
values, too.


void foo(T...)(string str=null, T args = T.init) {
//...
}
void main()
{
foo();
foo("");
foo("", 1, 2);
}

Problem with type cast in if condition

[NiRu via Digitalmars-d-learn]

Hi there,

I have a problem with the typecast within my if condition, the 
dmd2 compiler says he can not cast int to User, but it never 
reaches an int type the condition (at most, the else branch).


my try:

struct User {
string name;
}

void printName(T)(T value)
{
if(is(typeof(value) == User)){
User u = cast(User) value;
writeln(u.name);

write("User Type: ");
writeln(value);
} else {
write("Another Type: ");
writeln(value);
}

}

void main(string[] args)
{
User person;
person.name = "Jacub";

printName(362);
printName("have a nice day");
printName(person);
}



without the type cast line I have the following output:


Another Type: 362
Another Type: have a nice day
User Type: User("Jacub")


Instead with type cast "Error: cannot cast expression value of 
type int to User"


where is the problem?

Thanks!

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:04:06 UTC, jmh530 wrote:
On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:
In most cases though, just don't use classes. In most cases, 
inheritance is a horrible way to write programs anyway, 
because it's _horrible_ for code reuse. It definitely has its 
uses, but I've found that I rarely need classes in D. I 
suspect that far too many folks new to D end up using classes 
instead of structs just because they're used to using classes 
in C++ or Java or whatever.


What improvements to structs do you think would help people 
coming from C++/Java most?


I don't think the problem is with structs. The problem is that 
programmers coming from other languages default to using classes. 
The default in D should always be a struct. You use a class 
because you actually need inheritance or because you want to 
ensure that a type is always a reference type and don't want to 
go to the trouble of writing a struct that way (and even then, 
you should probably just write the struct that way). You 
shouldn't use a class as your default for user-defined types in 
D. But because other languages don't have structs quite like D 
does, and you use classes in those other languages, that's what 
most everyone wants to use - at least initially.


It would not surprise me if there are some compiler bugs with 
regards to structs that result in some loopholes that shouldn't 
be there (e.g. with @disable-ing stuff), but on the whole, I 
think that D structs are very well designed as they are. The only 
real issue IMHO is having an init value vs having a default 
constructor, and that's a tradeoff with pros and cons on both 
sides. It does sometimes seem painful to folks coming from C++, 
but on the whole, I think that we're better off for it.


- Jonathan M Davis

Re: What keeps you from using gtkd or dlangui

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:23:40 UTC, Nick Sabalausky wrote:

On 10/06/2015 02:53 PM, Jonathan M Davis wrote:
On Tuesday, 6 October 2015 at 18:40:17 UTC, Nick Sabalausky 
wrote:
Well that's good to hear. KDE4 went through the same path. 
After
spending time with KDE4, I found it to be it a terrible 
blunder of an
upgrade even after, several point releases in, people were 
saying it
had finally been fixed. It still has some warts that annoy me 
(and
some things I just gave in on), but it's finally won me back 
from my
hiatus with XFCE/LXDE. Looking forward to v5 stabilizing 
further.


IIRC, KDE 4 really became properly usable around 4.2


?!?

It must've been REALLY bad before that! I think I first tried 
it around v4.4-v4.6-ish and thus became an immediate fan of the 
TrinityDE project ;) At that point, KDE4 just felt to me very 
clumsy, unpolished, sluggish and borderline broken.


LOL. Fedora was actually crazy enough to release KDE 4.0.1. I 
didn't use that on my home computer, but the computers at school 
did. It's one thing for someone to do it purposefully; it's quite 
another to release it as the normal version to use with the 
distro. Now, I _did_ purposefully install it on whatever distro I 
was using at the time (OpenSuSE IIRC), and it was truly bad. So, 
I guess that I was a glutton for punishment, but I _definitely_ 
grabbed ever update as soon as I could.


I don't really blame them for releasing it like that, because 
they were between a rock and a hard place (until they released 
it, most of the apps wouldn't be updated, and until the apps were 
updated, it was going to be trash), but for a distro to actually 
do a release with it was just crazy.


I definitely don't remember there being much in the way of 
problems with 4.4 and later, but I'd also dealt with the insanity 
of the really early stuff. It probably did need to be released 
like it was, but only the crazy folks like me who installed it 
purposefully should have been using it.


One of the projects still on my bucket list (and will likely 
remain there indefinitely, the way things seem to go...) is a 
desktop GUI mail/ng client. It pains me that I've wound up 
settling for Thunderbird :(


LOL. That's also on my todo list, though the farthest I've gotten 
is a partially finished library implementing the RFC for the 
internet message format. I'll probably get back to it after I 
finish some more stuff for Phobos. But it's going to take a 
_very_ long time to finish all of the pieces, especially since 
I'd like to write pretty much all of it in D. :)


For now, I actually put up with kmail, but man do I hate akonadi. 
Worst thing to ever happen to KDE IMHO. How on earth could anyone 
think that it was a good idea to have a server for each of your 
e-mail accounts and treat the e-mail application like a client 
for each of those servers? I bet if someone forked KDE and put a 
real backend on it, a bunch of folks would jump on the fork. But 
if I'm going to go to that much work, I'd rather just write my 
own.


- Jonathan M Davis

Re: D run-time interpretation

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:42:08 UTC, Jacob wrote:
There are many programs out there that use some sort of 
scripting capabilities.


I've been wanting to write an app that exposes a scripting like 
environment D, lua, or some other fast language to the user.


But there are two requirements:

1. The user has access to all objects created in app. e.g., if 
I create a class X in the app then the user can instantiate X 
in the script without having to recreate it. (the script then, 
is sort of an extension of the app)


I don't mind actually having to expose X to the script, but it 
should be easy.


2. It should be fast. When it is "recompiled" it shouldn't take 
more than a few seconds. It also shouldn't require a 
re-initialization of everything.


Can D do this easily?


You know, you can use D as a scripting language. On Linux, you do 
something like put


#!/bin/rdmd

at the beginning of the file, mark it is executable, and then you 
can run it. I don't know what you need to put on the top to make 
it work on Windows.


These days, I write most of my scripts in D.

- Jonathan M Davis

Varargs and default arguments

[Nick Sabalausky via Digitalmars-d-learn]

Ok, D-style varargs can accept a parameter length of zero:

---
void foo(T...)(T args) {
//...
}
foo();
foo(t1, t2);
---

Is there any way to stick a param with a default value before that?

---
void foo(T...)(string str=null, T args=/+what goes here???+/) {
//...
}
foo();
foo(str);
foo(str, t1, t2);
---

Obviously this can be worked around easily enough by splitting it into 
two overloads ("foo(string str=null)" and "foo(string str, T args)"), 
but is there a way to do it in one?

Re: Problem with type cast in if condition

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 20:35:28 UTC, NiRu wrote:

if(is(typeof(value) == User)){


Use `static if` instead of plain `if` here.

Regular if does a runtime branch, so both true and else branches 
must compile with the same types.


Static if does a compile time branch, allowing different code to 
be compiled based on the condition - meaning types can change too.

Re: D 2015/2016 Vision?

[ponce via Digitalmars-d]

On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:


But in general, at this point, with D, if you want 
deterministic destruction, then you use structs. Classes are 
not the appropriate place for it. If they were ref-counted, 
then they could be, but as long as they're not, then classes 
are not the place to have stuff that cares about deterministic 
destruction. And if you're stuck with stuff in classes that do 
care about deterministic destruction, then you have to use the 
sort of solutions that C# and Java use where you don't rely on 
the destructor/finalizer to clean anything up except for the 
cases where you screw up and forget to manually call the 
function that does the cleanup.


Unfortunately, it is quite common to need both virtual functions 
and deterministic destruction. It isn't helpful to disregard the 
problem by saying "you should have used a struct", in many cases 
it's not any easier.

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:

On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:
I'm not sure what else I can say. The example I posted says it 
all, and it can't be done properly in D (or C#, but why lower 
the bar because of their mistakes? ;)


It's a side effect of having the lifetime of an object managed 
by the GC. There's no way around that except to use something 
else like manual memory management or reference counting.


You are literally repeating what I just said in different words.

in D, it's a good reason to use structs to manage resources 
like that, and since most objects really have no need of 
inheritance and have no business being classes, it's usually 
fine.


This is an opinion.

I want polymorphism AND deterministic destruction, and the least 
you could do is just admit that it's a downside to D not having 
it, instead of trying to tell me that everything I know is wrong..


But in the cases where you do have to use a class, it can get 
annoying.


YES, its does, and it's not just an odd case here and there..

You simply do not rely on the GC or the destruction of the 
object to free system resources. You manually call a function 
on the object to free those resources when you're done with it.


I'm sorry, but I almost can't believe you're saying this.

So, you're saying you want me to just revert back to manual 
resource management and accept that huge resources like textures 
and such may just leak if someone doesn't use them right? or 
throws an exception? in a language like D that is supposed to be 
safe?


In the case of C#, they have a construct to help with it that 
(IIRC) is something like


using(myObj)
{
} // myObj.dispose() is called when exiting this scope


For the THIRD time, I'll post my example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, will 
this be called?

}

Now, does this really seem like a realistic use case to you?

using(Texture tex = new Texture2D) {
// ...
}

Having the option to have properly ref-counted classes in 
addition to classes managed by the GC would definitely be an 
improvement, and I expect that we'll get there at some point, 
but there _are_ ways to deal with the problem in the interim, 
even if it's not ideal.


This brings me right back to where I started this, which was 
asking about this situation.


_Is_ it just the interim? Will DIP74 actually ever be 
implemented? if so, when?


In most cases though, just don't use classes. In most cases, 
inheritance is a horrible way to write programs anyway,


Opinion.

I suspect that far too many folks new to D end up using classes 
instead of structs just because they're used to

using classes in C++ or Java or whatever.


I use classes for polymorphism, and although I can't speak for 
everyone else, I doubt I'm the only one.


  Bit

Re: D 2015/2016 Vision?

[ponce via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:


So, you're saying you want me to just revert back to manual 
resource management and accept that huge resources like 
textures and such may just leak if someone doesn't use them 
right? or throws an exception? in a language like D that is 
supposed to be safe?




Yes. It seems everyone has this epiphany at one point in their D 
adventures.
D is similar to Java and C# in that regard, and more manual than 
C++.


On the plus side, you get freedom from thinking about ownership 
for the 30% or so of resources who only owns memory.

D run-time interpretation

[Jacob via Digitalmars-d]

There are many programs out there that use some sort of scripting 
capabilities.


I've been wanting to write an app that exposes a scripting like 
environment D, lua, or some other fast language to the user.


But there are two requirements:

1. The user has access to all objects created in app. e.g., if I 
create a class X in the app then the user can instantiate X in 
the script without having to recreate it. (the script then, is 
sort of an extension of the app)


I don't mind actually having to expose X to the script, but it 
should be easy.


2. It should be fast. When it is "recompiled" it shouldn't take 
more than a few seconds. It also shouldn't require a 
re-initialization of everything.


Can D do this easily?

Re: D 2015/2016 Vision?

[jmh530 via Digitalmars-d]

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:
In most cases though, just don't use classes. In most cases, 
inheritance is a horrible way to write programs anyway, because 
it's _horrible_ for code reuse. It definitely has its uses, but 
I've found that I rarely need classes in D. I suspect that far 
too many folks new to D end up using classes instead of structs 
just because they're used to using classes in C++ or Java or 
whatever.


What improvements to structs do you think would help people 
coming from C++/Java most?

Re: How to check if JSONValue of type object has a key?

[via Digitalmars-d-learn]

On Tue, Oct 06, 2015 at 08:28:46PM +, Borislav Kosharov via 
Digitalmars-d-learn wrote:
> JSONValue root = parseJSON(text);
> if(root["key"].isNull == false) {

try

if("key" in root) {
// it is there
} else {
// it is not there
}


you can also do

if("key" !in root) {}

Re: D 2015/2016 Vision?

[ponce via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:


I want polymorphism AND deterministic destruction, and the 
least you could do is just admit that it's a downside to D not 
having it, instead of trying to tell me that everything I know 
is wrong..


This problem comes up again and again, here is an ugly trick to 
ease the pain:

http://p0nce.github.io/d-idioms/#GC-proof-resource-class

Re: D run-time interpretation

[Jacob via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:02:48 UTC, Jonathan M Davis 
wrote:

On Tuesday, 6 October 2015 at 19:42:08 UTC, Jacob wrote:
There are many programs out there that use some sort of 
scripting capabilities.


I've been wanting to write an app that exposes a scripting 
like environment D, lua, or some other fast language to the 
user.


But there are two requirements:

1. The user has access to all objects created in app. e.g., if 
I create a class X in the app then the user can instantiate X 
in the script without having to recreate it. (the script then, 
is sort of an extension of the app)


I don't mind actually having to expose X to the script, but it 
should be easy.


2. It should be fast. When it is "recompiled" it shouldn't 
take more than a few seconds. It also shouldn't require a 
re-initialization of everything.


Can D do this easily?


You know, you can use D as a scripting language. On Linux, you 
do something like put


#!/bin/rdmd

at the beginning of the file, mark it is executable, and then 
you can run it. I don't know what you need to put on the top to 
make it work on Windows.


These days, I write most of my scripts in D.

- Jonathan M Davis



But this isn't what I want, only part.

Essentially I want to write an app that allows the user to 
"inteface" with the internals of the app, to control things and 
such.


Half the app is graphics and provides the backbone, sets up the 
graphics, deals with all that mess that the user doesn't need to 
deal with. The user, though, can control specific things such as 
the colors, objects, and such in the graphics scene. But instead 
of providing relatively static settings for the user(mess with 
sliders and such), I would like them to be able to specify what 
they want in "code".


e.g.,
User script code:

Graphics.Objects["Ship"].X = 10*cos(time);
Graphics.Objects["Ship"].Y = 10*sin(time);


...

So the user has the ability to access the "internals". Here 
Graphics is a sort of container for all the graphics, Objects is 
a map of all the objects in the scene.


But ultimately the code should be "compiled" in to the backbone 
of the app so it runs as fast as possible(not re-interpreted each 
scene).


One can think of it like this: The user provides code, the code 
is compiled as a function and the function called by the app. As 
long as one can link up the objects this should not be difficult.


If I were to do this by hand I'd have to write or use an 
interpreter or compiler(probably too slow) and provide a mapping 
of all the objects I want to expose(I'll have to "export" them 
from the app).


I could use something like LuaD, as I think it has the ability to 
parse strings as lua code, and the lua code can directly 
interface with the app. So this would not be that difficult to 
implement. The questions here are, is it fast enough and can it 
provide the simplicity I'd want.


I think C# has some type of compiler that allows one, in real 
time, to re-compile source code chunks and execute them as part 
of the program(not as separate entities that have no access to 
the underlying code).


This process would work but surely is too slow:

1. Treat the script code as pure D code.
2. Provide object references(pointers) to the objects I want to 
expose to the D code(as function arguments or through a lookup 
table or whatever)

3. compile the code into a dll.
4. Call the code in the dll per frame(or how ever I need to).


This would work great except the recompiling part and dll 
interfacing would surely be too slow. Since the user code could 
be modified often(modify a line, recompile), I need the changes 
to happen as fast as possible. If one wanted to modify the above 
code to


Graphics.Objects["Ship"].X = 10*sin(time);
Graphics.Objects["Ship"].Y = 10*cos(time);

I don't want the user to wait 5 mins while the app does all the 
work listed. Even, if it's 50 seconds it's still too slow.


I'd also like to use D as the scripting language since it would 
probably flow better(although, maybe lua and python could work 
too).


My app essentially has a visual scene representing the 3d 
graphics, and a "script editor" that allows the user to interact 
and modify the scene using code.


The scripting is crucial as it what makes the app what it is.

Re: D run-time interpretation

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 6 October 2015 at 21:41:18 UTC, Jacob wrote:

On Tuesday, 6 October 2015 at 19:42:08 UTC, Jacob wrote:


I've been wanting to write an app that exposes a scripting 
like environment D, lua, or some other fast language to the 
user.


PyD works nicely and I have used it enough to feel comfortable, 
but fast it isn't.


Isn't LuaJIT the obvious answer for you ?  You can use the FFI 
and generate C headers, or use LuaD.  I am struggling a bit with 
LuaD at the moment, so I can't tell you for sure it's perfectly 
usable, but you have the backdrop of knowing that the worst case 
of dropping down to C style is still pretty easy.  Note that the 
FFI allows you to wrap foreign methods nicely for constructors 
etc.  it even deals with templated types !


LuaJIT is shockingly fast, and Lua itself seems the perfect 
scripting language.


I am replying now as I have the exact same problem in a different 
domain myself, and tentatively going with Lua even though I know 
Python and PyD better.  LuaD was complaining and trying to wrap 
some private methods, enums etc.  my meta programming is at an 
early stage, and I am trying to fix these teething problems.  But 
it shouldn't be too bad - I am not far off, I think.


Also it currently harmlessly segfaults on exit due to a change in 
compiler behaviour interacting with LuaObject destructor (Ponce 
may have the answer) and creating a D module for Lua doesn't work 
for me (segfaults) on Arch Linux 64 although embedding Lua is 
fine.  I am not worried about it because I know I have C API as 
last resort, and it's coming along nicely anyway.


1. The user has access to all objects created in app. e.g., 
if I create a class X in the app then the user can 
instantiate X in the script without having to recreate it. 
(the script then, is sort of an extension of the app)


I don't mind actually having to expose X to the script, but 
it should be easy.


Should be easy.


2. It should be fast. When it is "recompiled" it shouldn't 
take more than a few seconds. It also shouldn't require a 
re-initialization of everything.


Can D do this easily?


You won't need to precompile Lua but if you do it will be quick.



Half the app is graphics and provides the backbone, sets up the 
graphics, deals with all that mess that the user doesn't need 
to deal with. The user, though, can control specific things 
such as the colors, objects, and such in the graphics scene. 
But instead of providing relatively static settings for the 
user(mess with sliders and such), I would like them to be able 
to specify what they want in "code".


Yes - exactly...  Back end power, correctness, efficiency with a 
light scripting interface.




But ultimately the code should be "compiled" in to the backbone 
of the app so it runs as fast as possible(not re-interpreted 
each scene).


LuaJIT will be very fast.  I think calling back to C might not be 
something you want to do in an inner loop though, so structure 
accordingly.  It's a drop in replacement for Lua 5.1, which is 
the version supported by LuaD so just change the library you link 
against.  Beware that you might need to compile LuaJIT  on Linux 
with don't disable stack frame and some other weirdness on 
Windows.  And that LuaD is usable but docs could be more complete 
and it's a little rough around edges.


I could use something like LuaD, as I think it has the ability 
to parse strings as lua code, and the lua code can directly 
interface with the app. So this would not be that difficult to 
implement. The questions here are, is it fast enough and can it 
provide the simplicity I'd want.


I think yes and yes.  Can, but you might spend an afternoon or 
two grumbling at it before you figure it out.



1. Treat the script code as pure D code.
2. Provide object references(pointers) to the objects I want to 
expose to the D code(as function arguments or through a lookup 
table or whatever)

3. compile the code into a dll.
4. Call the code in the dll per frame(or how ever I need to).


This would work great except the recompiling part and dll 
interfacing would surely be too slow. Since the user code could 
be modified often(modify a line, recompile), I need the changes 
to happen as fast as possible. If one wanted to modify the 
above code to


Have a look at D REPL or Jupyter notebook for what's possible 
with compiling and dynamically loading libraries.  Strikes me as 
a no brainer to use Lua.  But not because of compilation speed - 
for D that should be a handful of seconds at most (Phobos 
compiles in four seconds)


I'd also like to use D as the scripting language since it would 
probably flow better(although, maybe lua and python could work 
too).


My app essentially has a visual scene representing the 3d 
graphics, and a "script editor" that allows the user to 
interact and modify the scene using code.


The scripting is crucial as it what makes the app what it is.


Let us know what you decide and how it goes.

Re: D run-time interpretation

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:42:08 UTC, Jacob wrote:
There are many programs out there that use some sort of 
scripting capabilities.


I've been wanting to write an app that exposes a scripting like 
environment D, lua, or some other fast language to the user.


But there are two requirements:

1. The user has access to all objects created in app. e.g., if 
I create a class X in the app then the user can instantiate X 
in the script without having to recreate it. (the script then, 
is sort of an extension of the app)


I don't mind actually having to expose X to the script, but it 
should be easy.


2. It should be fast. When it is "recompiled" it shouldn't take 
more than a few seconds. It also shouldn't require a 
re-initialization of everything.


Can D do this easily?


I can see two ways about this:

1. Use D

Can you include your application's source code with the 
application?


If so, what I think could work is simply import modules belonging 
to your app from your plugin's source code, but don't link with 
the app object files.


The main complication with this approach is that you would need 
to either include a D compiler with your app, or expect the user 
to have one installed on their system. Note that DMD is not 
redistributable (you can't include DMD with your program), but 
this doesn't apply to LDC/GDC.


This might also get tricky on Windows, as you'll probably need to 
create or generate a .DEF file (and accompanying import library) 
which lists all exports/imports shared between your program and 
plugins. This will include all class methods as mangled names.


D compile times are quite low already, so I don't think this 
would be an issue.


2. Use a scripting language, e.g. Lua

D's compile-time reflection and code-generation abilities 
certainly make it possible to expose functions and classes to 
scripts. You could add a mixin to an exposed class, which would 
generate all the necessary run-time type information to expose 
the class to the scripting language. I don't know if any existing 
library already provides this in an easy-to-use manner, though.


Perhaps a good starting point would be LuaD:
https://github.com/JakobOvrum/LuaD

Re: D run-time interpretation

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 6 October 2015 at 22:05:59 UTC, Laeeth Isharc wrote:
LuaJIT will be very fast.  I think calling back to C might not 
be something you want to do in an inner loop though, so 
structure accordingly.


I meant other way around.  You don't want to call out to Lua 
there, but I don't think that's your intent anyway.


https://gist.github.com/spion/3049314

it took a lot of work just for C++ to beat LuaJIT on this little 
benchmark.

Re: How to check if JSONValue of type object has a key?

[Fusxfaranto via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 20:44:30 UTC, via 
Digitalmars-d-learn wrote:
On Tue, Oct 06, 2015 at 08:28:46PM +, Borislav Kosharov via 
Digitalmars-d-learn wrote:

JSONValue root = parseJSON(text);
if(root["key"].isNull == false) {


try

if("key" in root) {
// it is there
} else {
// it is not there
}


you can also do

if("key" !in root) {}


Additionally, just like associative arrays, if you need to access 
the value, you can get a pointer to it with the in operator (and 
if the key doesn't exist, it will return a null pointer).


const(JSONValue)* p = "key" in root;
if (p)
{
// key exists, do something with p or *p
}
else
{
// key does not exist
}

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:46:00 UTC, ponce wrote:

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:


I want polymorphism AND deterministic destruction, and the 
least you could do is just admit that it's a downside to D not 
having it, instead of trying to tell me that everything I know 
is wrong..


This problem comes up again and again, here is an ugly trick to 
ease the pain:

http://p0nce.github.io/d-idioms/#GC-proof-resource-class


Heh...This only adds insult to injury I would have thought 
the GC was smart enough not to have to do this.


Bit

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:

For the THIRD time, I'll post my example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, 
will this be called?

}

Now, does this really seem like a realistic use case to you?

using(Texture tex = new Texture2D) {
// ...
}


The reality of the matter is that having the lifetime of an 
object managed by a GC inherently does not work with 
deterministic destruction. Garbage collectors simply do not work 
that way. It's a cost to using them. Code like this is what you 
have to do when you have a garbage collected language without the 
ability to put objects on the stack. C# and Java and their ilk 
are stuck with that. And it definitely sucks, but it can work.


In D, if you're using only classes, you're still stuck with that. 
However, if you use structs to wrap classes and do reference 
counting, then it becomes possible to have deterministic 
destruction for classes, because the struct is doing the 
deterministic part, and the lifetime of the class object is no 
longer managed by the GC (assuming that you don't end up with 
something like the last of the structs with references to that 
class object inside of classes which aren't ref-counted, in which 
case, you lost the deterministic destruction and the GC manages 
the lifetime again). So, we're doing better than C# or Java do, 
but unfortunately, there are just enough issues with ref-counting 
structs that to get it fully right, we do need ref-counting in 
the language (unfortunately, I don't remember all of the corner 
cases that make that the case). So, ref-counting with structs 
_mostly_ works, and it is a solution, but it's not quite where we 
want it to be, which is Walter and Andrei have been talking about 
adding ref-counting support to the language and DIP 74 was 
proposed.


_Is_ it just the interim? Will DIP74 actually ever be 
implemented? if so, when?


We don't know. It hasn't been officially accepted yet. Walter and 
Andrei could change their minds and decide that it's not 
necessary to add ref-counting support to the language. It could 
be that DIP 74 or something like it ends up being accepted and 
implemented in a year or three. Or it could be accepted as-is 
tomorrow. Until Walter and Andrei make a decision on it, we don't 
know. Given the issues involved, I expect that some form of DIP 
74 will be accepted at some point in the future, but they're not 
going to do that until they're reasonably sure that we've got it 
right, and that sort of thing is always slow. So, we may very 
well end up with ref-counting in the language sometime next year, 
but I'd be shocked if it were this year, and depending on what 
Walter and Andrei are focusing on, it could be longer than that.


In most cases though, just don't use classes. In most cases, 
inheritance is a horrible way to write programs anyway,


Opinion.


It's well known that it's generally better to use composition 
than inheritance. Inheritance is useful when you need to have 
runtime polymorphism - where multiple types need to be used in 
exactly the same code as if they were the same type with the code 
using them not caring what they really are. Beyond that, it just 
starts causing problems - especially with regards to reusibility. 
As soon as code is in a member function, the only way it can be 
reused is by deriving from the class that it's in, which is 
incredibly limiting. Free functions (especially templated free 
functions) cream member functions for flexibility and 
reusibility, because they aren't restricted to a single type and 
its descendants. This is especially true when the language does 
not support multiple inheritance.


Inheritance makes sense when it's needed, but when you use it, 
you're losing flexibility and harming code reusibility, meaning 
that if it's not actually needed, it's just costing you. And I 
don't see how anyone can really argue otherwise.


Where a lot of that gets debatable is when deciding whether a 
particular problem actually needs a solution that uses 
polymorphism, but it's quite clear that using inheritance limits 
code reusibility.


I suspect that far too many folks new to D end up using 
classes instead of structs just because they're used to

using classes in C++ or Java or whatever.


I use classes for polymorphism, and although I can't speak for 
everyone else, I doubt I'm the only one.


And that's what D classes should be used for. But based on 
questions on SO and stuff in D.Learn and other places online, 
it's pretty clear that at minimum, many folks that are new to D 
use classes even when they don't need polymorphism.


- Jonathan M Davis

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

It's a step simpler with the new inline feature (works sadly only 
with the -inline flag):



pragma(inline, true)
auto scoped(T, Args...)(auto ref Args args) if (is(T == class)) {
void[__traits(classInstanceSize, T)] buf = void;
buf[] = typeid(T).init[];

T obj = cast(T) buf.ptr;
obj.__ctor(args);

return obj;
}

class A {
string name;

this(string name) {
   this.name = name;
   writeln("Creating A");
}

~this() {
   writeln("Destroying A");
}

void hello() {
   writeln("Hello, ", this.name);
}
}

void main() {
A a1 = scoped!A("Foo");
a1.hello();
}

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

On Monday, 5 October 2015 at 22:15:59 UTC, bitwise wrote:

On Monday, 5 October 2015 at 21:29:20 UTC, Namespace wrote:
But you can simply relinquish alias this and use opDispatch. 
Problem solved.


I don't understand what you mean.



import std.stdio;

struct Scoped(T) {
private void[__traits(classInstanceSize, T)] buf = void;

this(Args...)(auto ref Args args) {
this.buf = typeid(T).init[];
this.get().__ctor(args);
}

~this() {
.destroy(this.get());
}


private T get() {
return cast(T) this.buf.ptr;
}

auto opDispatch(string method, Args...)(auto ref Args args) {
return mixin("this.get()." ~ method ~ "(args)");
}
}

auto scoped(T, Args...)(auto ref Args args) {
return Scoped!T(args);
}

class A
{
string name;

this(string name)
{
   this.name = name;
   writeln("Creating A");
}

~this()
{
   writeln("Destroying A");
}

void hello()
{
   writeln("Hello, ", this.name);
}
}

void main() {
//A a0 = scoped!A("Test"); <-- fails

auto a1 = scoped!A("Foo");
a1.hello();

auto a2 = scoped!A("Bar");
a2.hello();
}

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 08:27:02 UTC, Ola Fosheim Grøstad 
wrote:
On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
wrote:

On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote:
Well, again that has it's pros and cons. This is why I just 
want a normal language solution like DIP74.


They're not the same thing at all. scoped is supposed to put 
the class on the stack, not the heap. And it's not 
ref-counted. It's so that you can create a class object in 
place, use it, and throw it away without doing any heap 
allocation. Essentially, it allows you to use a class as if it 
were a non-copyable struct. Even if we end up with 
ref-counting supported in the language, it doesn't obviate the 
need for scoped classes. They're for different use cases.


Why not leave stack allocation of objects to the compiler, like 
inlining? Then add a "@stack" constraint that will make the 
compilation fail if the compiler is unable to put it on the 
stack?


You need the compiler to prove that that the life time of the 
object is shorter than the stack frame in order to have memory 
safety anyway.


scoped is not designed with the idea that it's memory safe. 
scoped is very much an @system operation. And scoped is intended 
to replace scope classes in the language, so I don't think that 
any language support is going to be added for this. It's 
something that someone who knows what they're doing and needs 
that extra bit of efficiency can do, not something that's really 
intended to be in your average D program. In most cases, anything 
that's supposed to live on the stack should have been a struct 
anyway. It's just an issue when you want to use something on the 
stack in a particular case whereas it normally would be on the 
heap. And given D's lack of flow analysis and Walter's insistence 
on not adding it, I rather doubt that he's going to be big on the 
idea of having the compiler decide that it's safe to allocate a 
class object on the stack rather than the heap. But I don't 
remember him ever saying anything on that topic specifically.


- Jonathan M Davis

Re: D 2015/2016 Vision?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
wrote:

On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote:
Well, again that has it's pros and cons. This is why I just 
want a normal language solution like DIP74.


They're not the same thing at all. scoped is supposed to put 
the class on the stack, not the heap. And it's not ref-counted. 
It's so that you can create a class object in place, use it, 
and throw it away without doing any heap allocation. 
Essentially, it allows you to use a class as if it were a 
non-copyable struct. Even if we end up with ref-counting 
supported in the language, it doesn't obviate the need for 
scoped classes. They're for different use cases.


Why not leave stack allocation of objects to the compiler, like 
inlining? Then add a "@stack" constraint that will make the 
compilation fail if the compiler is unable to put it on the stack?


You need the compiler to prove that that the life time of the 
object is shorter than the stack frame in order to have memory 
safety anyway.

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:

On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
wrote:
They're not the same thing at all. scoped is supposed to put 
the class on the stack, not the heap. And it's not 
ref-counted. It's so that you can create a class object in 
place, use it, and throw it away without doing any heap 
allocation. Essentially, it allows you to use a class as if 
it were a non-copyable struct. Even if we end up with 
ref-counting supported in the language, it doesn't obviate 
the need for scoped classes. They're for different use cases.



For my purposes, they are pretty much the same.

So again, I'll paste the same example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, 
will this be called?

}

Memory is not only thing that has to be cleaned up.


Well, they might seem the same when you only look at that part, 
but they won't both solve your problem, depending on what 
you're trying to do.


But in general, at this point, with D, if you want 
deterministic destruction, then you use structs. Classes are 
not the appropriate place for it. If they were ref-counted, 
then they could be, but as long as they're not, then classes 
are not the place to have stuff that cares about deterministic 
destruction. And if you're stuck with stuff in classes that do 
care about deterministic destruction, then you have to use the 
sort of solutions that C# and Java use where you don't rely on 
the destructor/finalizer to clean anything up except for the 
cases where you screw up and forget to manually call the 
function that does the cleanup.


I'm not sure what else I can say. The example I posted says it 
all, and it can't be done properly in D (or C#, but why lower the 
bar because of their mistakes? ;)


I'm not sure exactly how C# and Java handle destruction for 
non-memory resources, but I'm guessing it's something like 
calling GC.collect() manually every couple of seconds. If the 
textures aren't released in the destructor, I don't really see 
any other way to tell when they're referenced or not.


Of course though, mobile devices are the new PC, and battery life 
is very much a concern, so this is a total waste...especially if 
I'm doing very little GC allocation anyways. Also, of course, 
there are the performance issues.


I expect that we'll get ref-counting for classes at some point, 
since while ref-counting with structs works, as I understand 
it, it does have some holes that make it less than ideal (but 
not necessarily unusable). And for some reason, IIRC, 
RefCounted doesn't work with classes, so you'd be forced to 
write your own ref-counted wrapper. It can certainly be done 
though.


- Jonathan M Davis


Correct, RefCounted doesn't work with classes. Not sure why, but 
I wrote my own, and trivial unittests pass:

http://dpaste.dzfl.pl/997615d2d188

But again, as I've already mentioned, it hides the type, has 
annoying syntax, and most importantly, is error prone. I can't 
really write a class thats meant to be used with RC(T) and know 
that no one will ever try to use it on it's own, GC allocated.


D needs a real solution here.
http://imgur.com/v6CIWln

Bit

Re: What keeps you from using gtkd or dlangui

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 18:40:17 UTC, Nick Sabalausky wrote:
Well that's good to hear. KDE4 went through the same path. 
After spending time with KDE4, I found it to be it a terrible 
blunder of an upgrade even after, several point releases in, 
people were saying it had finally been fixed. It still has some 
warts that annoy me (and some things I just gave in on), but 
it's finally won me back from my hiatus with XFCE/LXDE. Looking 
forward to v5 stabilizing further.


IIRC, KDE 4 really became properly usable around 4.2, and of 
course, around that time, kmail when to hell in a handbasket, 
because they added that akonadi trash to kdepim and switched to 
that for kmail's backend. *bleh*


kmail has a great UI, but its backend sucks big time, and since 
AFAIK, they've never acknowledged that it's a horrible design, 
they're probably never going to fix it... :(


Oh, well. On the whole, KDE 4 has been quite solid for quite a 
long time now, and nothing else even comes close to what I'm 
looking for. Fortunately, the transition to KDE 5 should be much 
smoother, because they don't have to redesign all of the guts 
this time. But still, I'd just as soon not jump on it very 
quickly.


- Jonathan M Davis

[Issue 15149] [REG2.068.1] Linker error with separate compilation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15149

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5166

--

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 01:27:27 UTC, Walter Bright wrote:

On 10/4/2015 11:02 AM, bitwise wrote:

For example, streams.


No streams. InputRanges.


This is too vague to really respond to. It does serve as an 
example of the over-emphasis on ranges in the D community. Ranges 
are great, but not for everything.


 Bit

Re: AWS API Dlang, hmac sha256 function.

[holo via Digitalmars-d-learn]

Congrats on getting it working!


@Rikki Thanks :)

I was trying to write my own lib from beginning based on examples 
but after some time i resign from that idea (will back to it when 
i will have some more experience) and right now im trying to 
customize that one from link which yawniek paste:


https://github.com/yannick/vibe-aws/blob/master/source/vibe/aws/sigv4.d

I removed import from vibe.d library and copy/paste missed 
functions formEncode and filterURLEncode (BTW: what that "(R)" 
mean in it? filterURLEncode(R)(ref R dst, ..., ..) ).


Next thing what i did was to replace hmac function to use hmac 
module from newest library. Now whole code looks like this:


module sigv4;

import std.array;
import std.algorithm;
import std.digest.sha;
import std.range;
import std.stdio;
import std.string;
import std.format;
import std.digest.hmac;


const algorithm = "AWS4-HMAC-SHA256";


void filterURLEncode(R)(ref R dst, string str, string 
allowed_chars = null, bool form_encoding = false)

{
while( str.length > 0 ) {
switch(str[0]) {
case ' ':
if (form_encoding) {
dst.put('+');
break;
}
goto default;
case 'A': .. case 'Z':
case 'a': .. case 'z':
case '0': .. case '9':
case '-': case '_': case '.': case '~':
dst.put(str[0]);
break;
default:
if (allowed_chars.canFind(str[0])) 
dst.put(str[0]);
else formattedWrite(dst, "%%%02X", str[0]);
}
str = str[1 .. $];
}
}

string formEncode(string str, string allowed_chars = null)
@safe {
auto dst = appender!string();
dst.reserve(str.length);
filterURLEncode(dst, str, allowed_chars, true);
return dst.data;
}

struct CanonicalRequest
{
string method;
string uri;
string[string] queryParameters;
string[string] headers;
ubyte[] payload;
}

string canonicalQueryString(string[string] queryParameters)
{
alias encode = formEncode;

string[string] encoded;
foreach (p; queryParameters.keys())
{
encoded[encode(p)] = encode(queryParameters[p]);
}
string[] keys = encoded.keys();
sort(keys);
return keys.map!(k => k ~ "=" ~ encoded[k]).join("&");
}

string canonicalHeaders(string[string] headers)
{
string[string] trimmed;
foreach (h; headers.keys())
{
trimmed[h.toLower().strip()] = headers[h].strip();
}
string[] keys = trimmed.keys();
sort(keys);
return keys.map!(k => k ~ ":" ~ trimmed[k] ~ "\n").join("");
}

string signedHeaders(string[string] headers)
{
string[] keys = headers.keys().map!(k => k.toLower()).array();
sort(keys);
return keys.join(";");
}

string hash(T)(T payload)
{
auto hash = sha256Of(payload);
return hash.toHexString().toLower();
}

string makeCRSigV4(CanonicalRequest r)
{
auto cr =
r.method.toUpper() ~ "\n" ~
(r.uri.empty ? "/" : r.uri) ~ "\n" ~
canonicalQueryString(r.queryParameters) ~ "\n" ~
canonicalHeaders(r.headers) ~ "\n" ~
signedHeaders(r.headers) ~ "\n" ~
hash(r.payload);

return hash(cr);
}

unittest {
string[string] empty;

auto r = CanonicalRequest(
"POST",
"/",
empty,
["content-type": "application/x-www-form-urlencoded; 
charset=utf-8",

 "host": "iam.amazonaws.com",
 "x-amz-date": "20110909T233600Z"],
cast(ubyte[])"Action=ListUsers=2010-05-08");

auto sig = makeCRSigV4(r);

assert(sig == 
"3511de7e95d28ecd39e9513b642aee07e54f4941150d8df8bf94b328ef7e55e2");

}

struct SignableRequest
{
string dateString;
string timeStringUTC;
string region;
string service;
CanonicalRequest canonicalRequest;
}

string signableString(SignableRequest r) {
return algorithm ~ "\n" ~
r.dateString ~ "T" ~ r.timeStringUTC ~ "Z\n" ~
r.dateString ~ "/" ~ r.region ~ "/" ~ r.service ~ 
"/aws4_request\n" ~

makeCRSigV4(r.canonicalRequest);
}

unittest {
string[string] empty;

SignableRequest r;
r.dateString = "20110909";
r.timeStringUTC = "233600";
r.region = "us-east-1";
r.service = "iam";
r.canonicalRequest = CanonicalRequest(
"POST",
"/",
empty,
["content-type": "application/x-www-form-urlencoded; 
charset=utf-8",

 "host": "iam.amazonaws.com",
 "x-amz-date": "20110909T233600Z"],
cast(ubyte[])"Action=ListUsers=2010-05-08");

auto sampleString =
algorithm ~ "\n" ~
"20110909T233600Z\n" ~

[Issue 15166] [Ref 2.069-devel] spurious statement not reachable warning in static foreach loop

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15166

--- Comment #1 from Kenji Hara  ---
Introduced in:
https://github.com/D-Programming-Language/dmd/pull/4790

I'm not sure how we can "fix" this and issue 14835.

--