Re: AWS API Dlang, hmac sha256 function.

[Rikki Cattermole via Digitalmars-d-learn]

On 07/10/15 3:18 PM, holo wrote:

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, ..., ..) ).


If you see a template argument (which R is) it is typically meant for a 
range. In this case an output range. Although there should be 
isOutputRange!R in an template if condition, to check this.



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" ~
 

[Issue 15166] [REG2.069-devel] spurious statement not reachable warning in static foreach loop

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

Summary|[Ref 2.069-devel] spurious  |[REG2.069-devel] spurious
   |statement not reachable |statement not reachable
   |warning in static foreach   |warning in static foreach
   |loop|loop

--

Re: D 2015/2016 Vision?

[Walter Bright via Digitalmars-d]

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

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.


What can a stream do that a range cannot?

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

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

Summary|[Reg 2.069-devel]   |[REG2.069-devel]
   |conflicting error with  |conflicting error with
   |repeated alias declaration  |repeated alias declaration

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

> 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.

Yes, it was a bug and fixed as issue 13203.



If we will accept the snippet code as valid, it would need additional rule for
the overloaded alias declarations:

- If two overloaded alias declarations are aliases of an identical type, they
don't conflict.

// simplest example case
alias a = int;
alias a = int;  // identical, no conflict

alias b = int:
alias b = const int;  // not identical, conflict

How about that?

--

Re: Bug? 0 is less than -10

[Steven Schveighoffer via Digitalmars-d-learn]

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

[Issue 15138] [REG2.068.2] ICE with basic use of stdx.data.json

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/f223530ec642a28f9152d10273837254e1ab6417
fix Issue 15138 - ICE with basic use of stdx.data.json

https://github.com/D-Programming-Language/dmd/commit/e13c2bc2c47ab4e1b0531895fa3c222e7cd0c09c
Merge pull request #5164 from 9rnsr/fix15138

--

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

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master 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

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

--

[Issue 15152] [REG2.069.0-devel] template fails to instantiate if argument is itself a template

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/4d1b0864d25660fdd347146c4a19ad9ba878a3bb
fix Issue 15152 - template fails to instantiate if argument is itself a
template

https://github.com/D-Programming-Language/dmd/commit/8830d971f730ff938b2628020f70b194c55854d2
Merge pull request #5163 from 9rnsr/fix15152

--

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 02:41:12 UTC, Walter Bright wrote:

On 10/6/2015 7:04 PM, bitwise wrote:
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.


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.

When it comes to an InputRange, I suppose you're right. A 
BinaryReader could be generalized to read any range.


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.


I've detailed my reasoning in this thread already, but structs 
alone, and structs wrapping classes are not goods solutions.


Bit

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Tuesday, 6 October 2015 at 22:21:41 UTC, Jonathan M Davis 
wrote:


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.


I'll give you that. The situation is slightly better than C#.

But these problems still exists:

-structs can be nested in classes, and inherit the 
non-deterministic lifetime of classes. The designer of a library 
has no control over this.


-classes that are meant to be ref counted(meaning that they 
depend on their destructor being called in a timely fashion) are 
not guaranteed to be wrapped in a RefCounted or similar RAII 
object. Again, the designer of a library has no control over this.


-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

-The syntax is annoying(this is a lot more important that people 
in this forum usually want to believe)


-wrapper structs hide the real type of the object from templates, 
typeof(), etc..


-etc..


_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.


If it takes long enough that C++ has reflection, modules, ranges, 
stackless coroutines, concepts, etc, then I gotta be honest, I'm 
gonna start worrying about investing too much time in D.



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.


I hope you're wrong. It's one thing to move slow, but looking at 
DIP74, it doesn't seem to be moving at all(last updated 
2015-03-04)




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.


Yes, that's why they're asking question in D.Learn and SO... :)

There seems to be a general trend in software these days where 
developers are getting lazy, and saying "But no one is asking for 
it" and using that to justify leaving features out.  This 
approach doesn't take into account people that just _expect_ 
certain features to be present because they're so obvious.


If you went to a Pizza Hut and they gave you a pizza with no 
cheese on it "because no one asks for it", would you actually say 
anything, or just dismiss them offhand and go somewhere else?


There is something to be said for tradition. Not everything has 
to be a democracy..


Bit

Re: Varargs and default arguments

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/6/15 4:27 PM, anonymous wrote:


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("");


What is T in this case? I wondered, and it is an empty expression tuple 
(prints out as "()"). Interesting.


Note, this doesn't seem to work on 2.067.

There are other ways to solve this too:

void foo() {return foo(null);}
void foo(T...)(string str, T args) {...}

I find it quite fascinating that in anonymous' solution, the T.init 
doesn't ever actually get used!


-Steve

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

[Marco Leise via Digitalmars-d-learn]

Am Tue, 06 Oct 2015 21:39:28 +
schrieb Fusxfaranto :

> 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
> }

And you could go further and write

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

-- 
Marco

Re: D 2015/2016 Vision?

[rsw0x via Digitalmars-d]

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

[...]


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.


+1 to this and pretty much everything else you've said in this 
thread.

Tired of people just shrugging it off when it's a serious issue.

Re: D 2015/2016 Vision?

[Walter Bright via Digitalmars-d]

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

For example, streams.


No streams. InputRanges.

Re: Concatenation of ubyte[] to char[] works, but assignation doesn't

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 05:38:36 UTC, Jonathan M Davis 
wrote:
Your suggestion only works by assuming that the result will fit 
in a char, which doesn't fit at all with how coversions are 
currently done in D. It would allow for narrowing conversions 
which lost data. And there's no way that Walter would go for 
that (and I don't think that he should). VRP solves the problem 
insofar as it can guarantee that the result will fit in the 
target type and thus reduces the need for casting, but simply 
assuming that char + int will fit in a char just doesn't work 
unless we're going to allow narrowing conversions to lose data, 
which we aren't.


If we were to allow the specific conversions that you're 
suggesting but only when VRP was used, then that could work, 
though it does make the implicit rules even screwier, becauses 
it becomes very dependent on how the int that you're trying to 
assign to a char was generated in the first place (straight 
assignment wouldn't work, but '0' - 40 would, whereas 'a' + 500 
wouldn't, etc.). VRP already makes it a bit funky as it is, 
though mostly in a straightforward manner.


I see, this is a new problem introduced by `char + int = char`. 
But at least the following could be disallowed without 
introducing problems:


int a = 'a';
char b = 32;

But strictly speaking, we already accept overflow (i.e. loss of 
precision) for ints, so it's a bit inconsistent to disallow it 
for chars.

Re: Experience: Developing Cloud Foundry applications with D

[Marc Schütz via Digitalmars-d]

On Tuesday, 6 October 2015 at 05:45:18 UTC, Andre wrote:
vagrant@vagrant-ubuntu-trusty-64:~/projects/tests/vibed_test$ 
dub

Target memutils 0.4.1 is up to date. Use --force to rebuild.
Target libasync 0.7.5 is up to date. Use --force to rebuild.
Target vibe-d 0.7.25 is up to date. Use --force to rebuild.
Building vibed_test ~master configuration "debug", build type 
debug.

Compiling using dmd...
Enhanced memory security is enabled.
Using Linux EPOLL for events
Linking...
Running ./bin/app
Listening for HTTP requests on :::8080
Listening for HTTP requests on 0.0.0.0:8080
E: Could not mlock 65536 bytes


Does it keep running? AFAIK, the last line is just a warning from 
the botan library that attempts to allocate non-swappable memory 
for holding secret keys etc.

Re: std.data.json formal review

[Alex via Digitalmars-d]

JSON is a particular file format useful for serialising 
heirachical data.


Given that D also has an XML module which appears to be 
deprecated, 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 would estimate that more than 70% of the times, the JSON data 
will only be read and written by a single D application, with 
only occasional inspection by developers etc.
In these cases it is undesirable to have code littered with types 
coming from a particular serialisation file format library.
As the software evolves that file format might become 
obsolete/slow/unfashionable etc, and it would be much nicer if 
the format could be changed without a lot of code being touched.
The other 30% of uses will genuinely need raw JSON control when 
reading/writing files written/read by other software, and this 
needs to be in Phobos to implement the backends.
It would be better for most people to not write their code in 
terms of JSON, but in terms of the more abstract concept of 
persistence/serialisation (whatever you want to call it).

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:44:22 UTC, ponce wrote:
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.


If you need both polymorphism and determinstic destruction, then 
you're just plain screwed when a GC is managing the lifetime of 
an object, because garbage collectors simply don't work that way. 
And anyone using class objects which are managed by a GC needs to 
understand that. To get the determinism, you need a way to 
control the lifetime of an object other than the GC (whether the 
memory for it lives on the GC heap or not). So, at this point, 
structs _have_ to get involved to get deterministic destruction 
unless you're going to do it all manually.


And that means that it's better to avoid classes if you don't 
actually need them, because then you can actually have 
deterministic destruction (on top of being able to avoid heap 
allocation if it's not necessary for any member variables). It 
also means that programs should generally avoid needing to 
combine polymorphism and deterministic destruction. If you need 
it, you need it, and you have to either get structs involved as 
wrappers or manually manage the lifetime of the class objects (or 
at least manually call a function to tell it to release whatever 
resources need to be released, even if the object itself isn't 
actually freed), but if it can reasonably be avoided, it should 
be avoided.


- Jonathan M Davis

Re: D and microservices

[Laeeth Isharc 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.


on your email, in case it fits.  nanomsg and a little vibed

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

[Ulrich Küttler via Digitalmars-d]

On Tuesday, 6 October 2015 at 07:09:21 UTC, Jonathan M Davis 
wrote:
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.




Yes, this is an explanation. Thanks. So the argument being C++ 
customs. Now that you mention it, this seems to be the argument 
in Eric's D4128 paper, too.


I was hoping for a somewhat deeper reasoning. Out of curiously, I 
am still trying to grasp all the implications. Ranges are hard.

Re: D and microservices

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:31:20 UTC, Mengu wrote:
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.


now a question for you.  do you wish you had built it from 
components from day one?  or do you see creating it as a blob to 
start with and then when the right divisions are clear factoring 
these out into micro-services as simply a natural part of the 
design process?  because you know much more by having started, 
and it's not so hard to refactor at this stage.


another thing is whenever we do deployments we have to take 
down the whole application and go offline


pretend I'm asking you before it was deployed in production...

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.


some people do.  but I would have thought the point I made above 
is the real reason.  it doesn't take very long to write it that 
way from the beginning IFF you know what you want it to look like 
before you start.  and maybe you don't.  but I am interested in 
what your experience has been.

Re: Objective C and C++ Compatibility?

[Laeeth Isharc via Digitalmars-d]

On Monday, 5 October 2015 at 14:16:22 UTC, 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? Any 
improvements from the very basic support that was shown? Is 
there any documentation?


Also, before DDMD, people were talking how D needed better C++ 
compatibility for it to work, but I can't find much 
documentation on any improvements either, as the documentation 
for C++ interface on the website hasn't been changed since 
March. Is this better compatibility going to be in 2.069?


See some comments by author of magicport here and there.  For C++ 
much more already works than dlang.org suggests.  Thaut's 
comments here are useful:

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

It's worth just writing simple a C++ program and trying so that 
you get a feel for it before trying to hook up an entire library.

Re: Bug? 0 is less than -10

[Laeeth Isharc via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 14:55:23 UTC, Adam D. Ruppe wrote:

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.


could we have ssize_t defined in phobos somewhere so your code 
ends up being portable ;) (It's trivial to do, obviously).

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

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/6/15 9:09 AM, Iain Buclaw via Digitalmars-d-announce wrote:

On 6 Oct 2015 12:30 am, "Adam D. Ruppe via Digitalmars-d-announce"
> 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


This is fantastic - congratulations Iain! -- Andrei

Re: std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 06.10.2015 um 12:05 schrieb Alex:

JSON is a particular file format useful for serialising heirachical data.

Given that D also has an XML module which appears to be deprecated, 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 would estimate that more than 70% of the times, the JSON data will
only be read and written by a single D application, with only occasional
inspection by developers etc.
In these cases it is undesirable to have code littered with types coming
from a particular serialisation file format library.
As the software evolves that file format might become
obsolete/slow/unfashionable etc, and it would be much nicer if the
format could be changed without a lot of code being touched.
The other 30% of uses will genuinely need raw JSON control when
reading/writing files written/read by other software, and this needs to
be in Phobos to implement the backends.
It would be better for most people to not write their code in terms of
JSON, but in terms of the more abstract concept of
persistence/serialisation (whatever you want to call it).


A generic serialization framework is definitely needed! Jacob Carlborg 
had once tried to get the Orange[1] serialization library into Phobos, 
but the amount of requested changes was quite overwhelming and it didn't 
work out so far. There is also a serialization framework in vibe.d[2], 
but in contrast to Orange it doesn't handle cross references (for 
pointers/reference types).


But this is definitely outside of the scope of this particular module 
and will require a separate effort. It is intended to be well suited for 
that purpose, though.


[1]: https://github.com/jacob-carlborg/orange
[2]: http://vibed.org/api/vibe.data.serialization/

Re: Walter and I talk about D in Romania

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/6/15 8:42 AM, Rory McGuire via Digitalmars-d-announce wrote:



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?


Far as I can tell it's the other way around: we ended up being invited 
:o). Siemens is sponsoring the ongoing curiousminds.ro conferences, and 
they contacted us with the idea of holding the event. -- Andrei

Re: Experience: Developing Cloud Foundry applications with D

[Etienne Cimon via Digitalmars-d]

On Tuesday, 6 October 2015 at 09:36:42 UTC, Marc Schütz wrote:

On Tuesday, 6 October 2015 at 05:45:18 UTC, Andre wrote:
vagrant@vagrant-ubuntu-trusty-64:~/projects/tests/vibed_test$ 
dub

Target memutils 0.4.1 is up to date. Use --force to rebuild.
Target libasync 0.7.5 is up to date. Use --force to rebuild.
Target vibe-d 0.7.25 is up to date. Use --force to rebuild.
Building vibed_test ~master configuration "debug", build type 
debug.

Compiling using dmd...
Enhanced memory security is enabled.
Using Linux EPOLL for events
Linking...
Running ./bin/app
Listening for HTTP requests on :::8080
Listening for HTTP requests on 0.0.0.0:8080
E: Could not mlock 65536 bytes


Does it keep running? AFAIK, the last line is just a warning 
from the botan library that attempts to allocate non-swappable 
memory for holding secret keys etc.


The error is with mlock, the ulimit for locked memory is too low 
on non-root user accounts, so it falls back to simple zeroize of 
swappable memory

Re: Experience: Developing Cloud Foundry applications with D

[Etienne Cimon via Digitalmars-d]

On Monday, 5 October 2015 at 06:24:44 UTC, Andrei Alexandrescu 
wrote:

On 10/5/15 1:34 AM, Rikki Cattermole wrote:


Vibe.d has a provider called libasync. Libasync is fully 
implemented in

D. You probably should have tried that at least.
Although I still would recommend trying it ;) It's a lot 
better then

what we have in Phobos.


Cue choir asking for porting of libasync to phobos. I've first 
asked this a couple of years ago. -- Andrei


To be fair, libasync was release only october last year :)

Will work on adding libasync to Phobos once I'm finished adding a 
few more features to my main project! (3-4 months). Will need to 
strip memutils, will you have std.allocator ready? Anyone is free 
to pick up this project and move libasync to phobos if ready 
before me. I've gotten this all-D web framework (vibe.d, botan-D 
TLS, D libhttp/2, etc) into production on my end and it works 
great!

Re: Experience: Developing Cloud Foundry applications with D

[John Colvin via Digitalmars-d]

On Tuesday, 6 October 2015 at 11:30:00 UTC, Etienne Cimon wrote:

Will need to strip memutils, will you have std.allocator ready?


https://github.com/D-Programming-Language/phobos/tree/master/std/experimental/allocator

:)

Re: What keeps you from using gtkd or dlangui

[Jonathan M Davis via Digitalmars-d]

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

Re: Experience: Developing Cloud Foundry applications with D

[Andre via Digitalmars-d]

On Tuesday, 6 October 2015 at 09:36:42 UTC, Marc Schütz wrote:

On Tuesday, 6 October 2015 at 05:45:18 UTC, Andre wrote:
vagrant@vagrant-ubuntu-trusty-64:~/projects/tests/vibed_test$ 
dub

Target memutils 0.4.1 is up to date. Use --force to rebuild.
Target libasync 0.7.5 is up to date. Use --force to rebuild.
Target vibe-d 0.7.25 is up to date. Use --force to rebuild.
Building vibed_test ~master configuration "debug", build type 
debug.

Compiling using dmd...
Enhanced memory security is enabled.
Using Linux EPOLL for events
Linking...
Running ./bin/app
Listening for HTTP requests on :::8080
Listening for HTTP requests on 0.0.0.0:8080
E: Could not mlock 65536 bytes


Does it keep running? AFAIK, the last line is just a warning 
from the botan library that attempts to allocate non-swappable 
memory for holding secret keys etc.


I got it working. *Argh* I forgot the command parameter in the 
cloud foundry manifest file. vibe-d is working fine, out of the 
box in cloud foundry with libasync :)

Re: Concatenation of ubyte[] to char[] works, but assignation doesn't

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 09:28:29 UTC, Marc Schütz wrote:
I see, this is a new problem introduced by `char + int = char`. 
But at least the following could be disallowed without 
introducing problems:


int a = 'a';
char b = 32;

But strictly speaking, we already accept overflow (i.e. loss of 
precision) for ints, so it's a bit inconsistent to disallow it 
for chars.


Yes, D does not have overflow, it has modular arithmetics. So the 
same argument would hold for an enumeration (like character 
ranges), do you want them to be modular (a circle) or monotonic 
(a line). Neither is a good fit for unicode. It probably would 
make most sense to split the unicode universe into multiple typed 
ranges, some enumerations, some non-enumerations and avoid char 
altogether.

Re: Concatenation of ubyte[] to char[] works, but assignation doesn't

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, October 06, 2015 09:28:27 Marc Schütz via Digitalmars-d-learn wrote:
> I see, this is a new problem introduced by `char + int = char`.
> But at least the following could be disallowed without
> introducing problems:
>
>  int a = 'a';
>  char b = 32;

Sure, it would be nice, but I rather doubt that Walter would go for it. He
seems to be fully in the camp of folks that think that life is better if
charater types and bool always are treated as integral types - which
unfortunately, creates fun problems like this

void foo(bool b) { writeln("bool"); }
void foo(long l) { writeln("long"); }

foo(1); // prints bool

In this case, adding on overload that takes int fixes the problem, because
integer literals default to int, but in general, it's just stupid IMHO. But
when it was brought up last, Walter didn't think that there was any problem
with it and that it was just fine to require that the int overload be added
to fix it.

> But strictly speaking, we already accept overflow (i.e. loss of
> precision) for ints, so it's a bit inconsistent to disallow it
> for chars.

Overflow is only permitted when doing arithmetic operations (when you really
can't do anything about it except maybe throw an exception, which would be
too expensive to be worth it) or when casting explicitly (in which case,
you're telling the compiler that you don't care). Overflow is never allowed
via implicit conversions.

- Jonathan M Davis

Re: Experience: Developing Cloud Foundry applications with D

[Rikki Cattermole via Digitalmars-d]

On 07/10/15 12:29 AM, Etienne Cimon wrote:

On Monday, 5 October 2015 at 06:24:44 UTC, Andrei Alexandrescu wrote:

On 10/5/15 1:34 AM, Rikki Cattermole wrote:


Vibe.d has a provider called libasync. Libasync is fully implemented in
D. You probably should have tried that at least.
Although I still would recommend trying it ;) It's a lot better then
what we have in Phobos.


Cue choir asking for porting of libasync to phobos. I've first asked
this a couple of years ago. -- Andrei


To be fair, libasync was release only october last year :)

Will work on adding libasync to Phobos once I'm finished adding a few
more features to my main project! (3-4 months). Will need to strip
memutils, will you have std.allocator ready? Anyone is free to pick up
this project and move libasync to phobos if ready before me. I've gotten
this all-D web framework (vibe.d, botan-D TLS, D libhttp/2, etc) into
production on my end and it works great!


I'm hoping as part of this we will be able to merge the platform 
abstraction out to something like: 
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/platform.d#L10

That way windowing as well can take advantage of it :)

Re: Is Anything Holding you back?

[krzaq via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


Nothing major for me, just a plentitude of small problems.

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.


When I decide to write a small tool in D, I pretty ensure that, 
next to D's awesome features, I'll be exposed to some ugly warts 
of the language or its ecosystem. My experience with DUB packages 
(btw, there should be a word for it, like Ruby's gems) is that, 
at least on Windows, they are often out of date and require 
undocumented build steps to even build -- and that's before you 
try to use them and hit the wall of RTFS solutions to 
documentation.


TL;DR: instead of focusing on solving my problem, I have to focus 
on solving problems unknown in other languages. Saving time by 
using fantastic language features and then wasting twice as much 
reinventing the wheel is not what I want to do.

Re: What keeps you from using gtkd or dlangui

[Gerald via Digitalmars-d]

On Sunday, 4 October 2015 at 13:24:23 UTC, karabuta wrote:
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.


I'm working on a search utility using gtkd, it's essentially a 
GUI for grep. I was using a program called Search Monkey 
previously but it hasn't seen much development and was pretty 
buggy, so looking to replace it with something of my own. This is 
my first experience using D and GTK so I'm a complete newbie.


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.


I really like the fact that gtkd appears to be a full binding and 
supports GTK 3.16 so newer GTK features like headerbar are 
available. I had considered learning Go for this utility but the 
lack of a full binding for GTK was a major impediment for me. I 
had also previously fooled around with Python but didn't like the 
language very much, the dynamic typing and indentation to 
delineate blocks are not for me.

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

[via Digitalmars-d-bugs]

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

--- Comment #4 from Kenji Hara  ---
Created attachment 1554
  --> https://issues.dlang.org/attachment.cgi?id=1554=edit
Dustmited test case.

--

Re: What is the postfix for min long value?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, October 06, 2015 15:16:12 tcak via Digitalmars-d-learn wrote:
> 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.

L is the prefix to use, but it looks like there's a compiler bug here,
because

long l = -9_223_372_036_854_775_807L;

compiles

and

long l = -9_223_372_036_854_775_808L;

doesn't, even though that's the same as long.min.

long l = -9_223_372_036_854_775_807UL;

compiles and does the right thing, though that's a pretty silly thing to
have to do.

Actually, digging through bugzilla, it looks like it's already been
reported:

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

Though since C has the same problem, it's treated as an enhancement rather
than a bug (which seems wrong to me). Apparently, the problem stems from the
compiler processing the literal and _then_ applying the sign, and long.max
is 9_223_372_036_854_775_807L. Apparently, -2L^^63 will work though.

All in all, it's probably not a big deal, since you should probably just
being using long.min anyway, but this doesn't seem like particularly good
behavior to me.

- Jonathan M Davis

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Tuesday, 6 October 2015 at 14:28:42 UTC, Kagamin wrote:

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


I know about that too, the KnownType is applied to types that the 
DataContractSerializer (not the XmlSerializer) must be aware of 
before it can serialize the type (you enlist the type to the 
serializer). Thanks.

Re: D 2015/2016 Vision?

[bitwise 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.


- Jonathan M Davis



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

The deterministic destruction is actually what I'm after.


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.

Bit

D and microservices

[Russel Winder via Digitalmars-d]

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.

-- 
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: Moving back to .NET

[Chris via Digitalmars-d]

On Monday, 5 October 2015 at 15:01:14 UTC, Ola Fosheim Grøstad 
wrote:


Could you line out how you would like a language to be so it 
doesn't bore you stiff?


Consistency in philosophy is important. If D is a compile time 
oriented library authors language (and I think it is) then that 
needs to come to the forefront so that library authors easily 
can write beautiful code and easily integrate D code with other 
environments. The runtime dependencies must be kept low and the 
focus on powerful and easy to use compile time resolution and 
static analysis has to be strengthened.


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? Do 
you have prototypes or made pull requests?

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

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 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

Re: Bug? 0 is less than -10

[Meta 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


If you need to mix signed and unsigned values but want to avoid 
this issue, you an use the comparison functions from 
std.functional.


http://dlang.org/phobos/std_functional.html#.lessThan

Re: D and microservices

[Dejan Lekic 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.


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.

Re: Linker error with dmd

[Chris via Digitalmars-d-learn]

On Friday, 2 October 2015 at 14:03:08 UTC, John Colvin wrote:

On Friday, 2 October 2015 at 09:43:54 UTC, Chris wrote:
Why do I get this error msg with dmd 2.067.1 and 2.068.0 in 
release mode:


$ dub --build=release

(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
 undefined reference to 
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.

It works fine with the latest version of ldc2.


What is it that you are building?


An executable. I mainly use a code base that compiles perfectly 
well in release mode. I couldn't find the reason for this error 
message, plus, ldc2 has no problem with it.

Re: std.data.json formal review

[Atila Neves via Digitalmars-d]

On Tuesday, 6 October 2015 at 15:47:08 UTC, Sebastiaan Koppe 
wrote:
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.


The binary one is the one I care about, so that's the one I wrote:

https://github.com/atilaneves/cerealed

I've thinking of adding other formats. I don't know if it's worth 
it.


Atila

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

[Nick Sabalausky via Digitalmars-d-announce]

On 10/05/2015 05:30 PM, Andy Smith wrote:

On Monday, 5 October 2015 at 19:35:53 UTC, anonymous wrote:

On Monday 05 October 2015 21:29, Adam D.  Ruppe wrote:

which generates Microsoft format object files and the MS linker even
on 32

bit

I think you a word there.



I think you a grammatical error there.



Yea, I hate when I accidentally a word. At least he didn't accidentally 
all the words, and be in the same boat as this poor fella: 
https://answers.yahoo.com/question/index?qid=2021143759AAw9rUQ

Re: What is the postfix for min long value?

[Ali Çehreli via Digitalmars-d-learn]

On 10/06/2015 08:16 AM, tcak wrote:
> While writing max ulong value, I added the "u" postfix.

Better to use U to be consistent with L (see below).

> 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 );

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. :)

(You can use UL and LU as well.)

> 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.

They go by "suffix". The officital documentation:

  http://dlang.org/lex.html#integerliteral

My short mention of them start at the section "The L suffix":

  http://ddili.org/ders/d.en/literals.html#ix_literals.literal

(They were missing in my index section. Adding now...)

Ali