On Wednesday, 25 August 2021 at 19:51:36 UTC, H. S. Teoh wrote:
What I understand from what Andrei has said in the past, is
that a range is merely a "view" into some underlying storage;
it is not responsible for the contents of that storage. My
interpretation of this is that .save will only
On Wednesday, 25 August 2021 at 17:01:54 UTC, Steven
Schveighoffer wrote:
In a world where copyability means it's a forward range? Yes.
We aren't in that world, it's a hypothetical "if we could go
back and redesign".
OK, that makes sense.
Technically this is true. In practice, it rarely
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven
Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to
properly save a forward range when copying, even if the guts
need copying (unlike classes). In general, I think it was a
mistake to use `.save` as the mechanism,
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
That's quite a strong assumption, because its state might be a
reference type, or it might not _have_ state in a meaningful
sense --
On Friday, 23 October 2020 at 14:16:50 UTC, user1234 wrote:
The third case is just like `cast(int) 1.1` it's not _at
programmer request_ from my point of view
If the programmer explicitly writes a `to!int` or the
`cast(int)`, then it's pretty clearly at their request. And it's
unambiguous
On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
Since (1.1).to!int = 1, shouldn't the string value
("1.1").to!int at least try to convert to float/double and then
to int?
The thing is, that's a great way for hard-to-identify bugs to
creep into code. In these cases:
auto
On Thursday, 10 September 2020 at 13:14:47 UTC, drug wrote:
Just a thought - couldn't you use classes for this? Get an UDA
and check if it is a descendant of the specific class.
Yes, I did wonder about that, but it doesn't allow all the
inference that I'm looking for. For example:
Hello folks,
Is there any way to define UDAs such that they automatically
inherit other UDA definitions?
For example, suppose I define:
enum BaseUDA { A, B }
Is there a way to define `AnotherUDA` such that if `hasUDA!(T,
AnotherUDA)` then it is a given that `hasUDA!(T, BaseUDA)` will
On Tuesday, 12 May 2020 at 12:59:14 UTC, Paul Backus wrote:
You should be able to get this information from the JSON output
of `dub describe`.
Cool, thanks. Much appreciated :-)
Has anyone created any tools to condense that into a licensing
report? No worries if not, just curious.
Hello folks,
Are there any tools that exist to help prepare a report of all
the different software licenses used by dependencies of a DUB
project? (This should cover all pulled in dependencies, not just
direct dependencies.)
Thanks and best wishes,
-- Joe
Hello folks,
Are there any well-established CI patterns/tools for detecting
unneeded imports in D code? Ideally including detecting unused
symbols from selective imports?
Thanks and best wishes,
-- Joe
On Saturday, 7 December 2019 at 15:57:14 UTC, Jonathan M Davis
wrote:
There may have been some tweaks to std.encoding here and there,
but for the most part, it's pretty ancient. Looking at the
history, it's Seb who marked some if it as being a replacement
for std.utf, which is just plain
On Saturday, 7 December 2019 at 03:23:00 UTC, Jonathan M Davis
wrote:
The module to look at here is std.utf, not std.encoding.
Hmmm, docs may need updating then -- several functions in
`std.encoding` explicitly state they are replacements for
`std.utf`. Did you mean `std.uni`?
It is
Hello folks,
I have a use-case that involves wanting to create a thin struct
wrapper of underlying string data (the idea is to have a type
that guarantees that the string has certain desirable properties).
The string is required to be valid UTF-8. The question is what
the most useful API
On Thursday, 19 September 2019 at 22:55:55 UTC, Jonathan M Davis
wrote:
For better or worse, ranges were more or less set up as a
linear hierarchy, and it's unlikely that use cases for
bidirectional ranges which aren't forward ranges are common. I
expect that it's a bit like infinite,
Hello folks,
A question that occurred to me while implementing a new data
structure recently, which I'm not sure I've ever seen a reason
for.
Why must bidirectional ranges also be forward ranges (as opposed
to just input ranges)?
It doesn't seem to me that the `save` property is
On Tuesday, 9 July 2019 at 08:51:59 UTC, Mitacha wrote:
I've managed to make it work using 'alias this' and wrapper
struct.
https://run.dlang.io/is/3SMEFZ
It's not an elegant solution, there could be a better way to do
this.
Yea, a wrapper struct with custom `toString` seems the most
On Monday, 8 July 2019 at 12:53:18 UTC, Digital Mars wrote:
I guess that there is no way to have `writeln` automatically
use the output range overload instead of allocating one. You
need somehow to provide the output range to `toISOExtString`
explicitly because `writeln` outputs the return of
On Sunday, 7 July 2019 at 20:12:30 UTC, drug wrote:
07.07.2019 17:49, Joseph Rushton Wakeling пишет:
it's possible to do something like
`writefln!"%s"(now.toISOExtString)` and have it automatically
use the output range overload rather than allocating a new
string instance.
This is exactly
Hello folks,
Is there an idiomatic/intended way to use the output-range taking
overloads of SysTime.toISOString and toISOExtString with stuff
like `writeln` and `format`, as opposed to explicitly generating
an output range to stdout or a string, and passing that to these
methods?
I'm a bit
On Tuesday, 13 June 2017 at 20:04:46 UTC, WhatMeWorry wrote:
Sorry I didn't reply sooner. I just reinstalled everything and
it's all good. Something was really screwed up.
"Screwed up" is also a fairly good way to describe my responses
too, since I also missed your clear statement that you
On Tuesday, 13 June 2017 at 12:38:03 UTC, Joseph Rushton Wakeling
wrote:
On Sunday, 11 June 2017 at 21:58:27 UTC, WhatMeForget wrote:
Just trying to compile a "Hello World" using dub and ldc2.
I presume from your command line you're running Windows?
... I don't know where I got that idea
On Sunday, 11 June 2017 at 21:58:27 UTC, WhatMeForget wrote:
Just trying to compile a "Hello World" using dub and ldc2.
Let's start from the beginning: how did you install LDC? I
presume from your command line you're running Windows?
On Sunday, 9 April 2017 at 07:12:51 UTC, Patrick Schluter wrote:
32 bit modes support for PIC is painful because the RIP
relative addressing mode does not exist. AMD introduced it when
they added 64 bit support in the Opteron processors. In 32 bit
mode it was possible to generate PIC code but
Hello folks,
The default dmd.conf settings for 64-bit environments include the
-fPIC flag (for good reason), but the settings for 32-bit
environments do not. Any particular reason for this?
Thanks & best wishes,
-- Joe
On Tuesday, 28 February 2017 at 00:22:28 UTC, sarn wrote:
If you ever have doubts, you can always use something like
this to check:
assert (__ctfe);
Sorry, "enforce" would more appropriate if you're really
checking.
if (!__ctfe) assert(false);
... might be the best option. That
On Saturday, 7 January 2017 at 22:55:55 UTC, Joseph Rushton
Wakeling wrote:
I should probably also create a formal issue for this. Any
thoughts on how best to break it down into a minimal example?
It does not appear easy to do so at first glance :-\
Turned out to be easier than I
On Thursday, 29 December 2016 at 09:57:25 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 29 December 2016 at 09:24:23 UTC, Joseph Rushton
Wakeling wrote:
Sorry for delay in following up on this. Yes, the same
problem occurs with dmd 2.071 (as installed from the deb
package downloaded from
On Thursday, 29 December 2016 at 09:24:23 UTC, Joseph Rushton
Wakeling wrote:
On Tuesday, 27 December 2016 at 22:34:50 UTC, Johan Engelen
wrote:
Do you see the same with dmd 2.071? (that's the same front-end
code as the LDC version tested)
Sorry for delay in following up on this. Yes, the
On Tuesday, 27 December 2016 at 22:34:50 UTC, Johan Engelen wrote:
On Tuesday, 27 December 2016 at 17:56:07 UTC, Stefan Koch wrote:
I doubt that this is a CTFE bug since there should be little
difference in the ctfe code between ldc and dmd.
That said, it is of course a possibility.
Do you
On Tuesday, 27 December 2016 at 17:56:07 UTC, Stefan Koch wrote:
I doubt that this is a CTFE bug since there should be little
difference in the ctfe code between ldc and dmd.
That said, it is of course a possibility.
I'll have a look.
Thanks! It's very weird how, of the values in the
Hello all,
I've recently been working on a port of the mir.random Mersenne
Twister implementation to Phobos, and I've run into a bit of
weirdness with CTFE.
Specifically, I use some CTFE functionality to generate a default
starting state for the generator:
On Saturday, 24 September 2016 at 19:42:11 UTC, Joseph Rushton
Wakeling wrote:
On Saturday, 24 September 2016 at 19:27:31 UTC, Joseph Rushton
Wakeling wrote:
Further to earlier remarks: I now think this may be a general
problem of LDC 1.0.0 and not a problem of the snap package.
I tried
On Saturday, 24 September 2016 at 19:27:31 UTC, Joseph Rushton
Wakeling wrote:
Further to earlier remarks: I now think this may be a general
problem of LDC 1.0.0 and not a problem of the snap package.
I tried building my simple curl-using program using an LDC
1.0.0 build and installed from
On Saturday, 24 September 2016 at 19:11:52 UTC, Joseph Rushton
Wakeling wrote:
On Friday, 23 September 2016 at 00:55:43 UTC, Stefan Koch wrote:
This suggests that libcurl is loaded.
could you compile with -g ?
and then post the output ?
Further to earlier remarks: I now think this may be a
On Friday, 23 September 2016 at 00:55:43 UTC, Stefan Koch wrote:
This suggests that libcurl is loaded.
could you compile with -g ?
and then post the output ?
Thanks Stefan! It was compiled with -g, but I was missing the
libcurl3-dbg package. Here's the results:
#0 0x0046b048 in
Hello all,
As some have you may have followed, I've been working on
snap-packaging LDC. However, I've run into an issue when it
comes to programs that use std.net.curl.
Here's a simple example:
void main ()
{
import std.net.curl : get;
auto website =
On Tuesday, 9 August 2016 at 14:30:21 UTC, Seb wrote:
There is also
https://github.com/ikod/dlang-requests
Which I find in general more intuitive to use ;-)
Interesting, I'd not come across that before. Thanks -- I'll
give it a glance some time ...
On Tuesday, 9 August 2016 at 14:21:09 UTC, ketmar wrote:
http://dpldocs.info/experimental-docs/std.net.curl.HTTP.setPostData.html
https://dlang.org/phobos/std_net_curl.html#.HTTP.setPostData
reading documentation rox!
Yea, mea culpa. I had actually glanced at that but was asking on
the
Hello all,
I'm currently writing a little client app whose job is to make a
POST request to a vibe.d webserver and output the response.
However, vibe.d is picky about the content-type of the request
body, and so far as I can see there is no way to specify this via
the `std.net.curl.post`
On Thursday, 12 May 2016 at 22:51:17 UTC, Andrew Edwards wrote:
The following preprocessor directives are frequently
encountered in C code, providing a default constant value where
the user of the code has not specified one:
#ifndef MIN
#define MIN 99
#endif
On Monday, 16 May 2016 at 15:33:09 UTC, Dicebot wrote:
tl; dr: DIP25 is so heavily under-implemented in its current
shape it can be considered 100% broken and experimenting will
uncover even more glaring holes.
Well, it's always fun to find the holes in things ... :-)
To be more precise,
Hello all,
Consider a struct that wraps a pointer to some other piece of
data as follows:
struct MyWrapper(T)
{
private T* data;
public this(ref T input)
{
this.data =
}
... other methods that use `this.data` ...
}
Is there
On Tuesday, 12 April 2016 at 18:23:25 UTC, Jonathan M Davis wrote:
Well, work has been done to make it so that different runtimes
will work - e.g. there's a CRuntime_Glibc and a CRuntime_Bionic.
That's pretty cool. Was that a result of the recent Android
porting work, or was it a
On Tuesday, 12 April 2016 at 01:32:02 UTC, Brian Schott wrote:
On Monday, 11 April 2016 at 23:01:08 UTC, marcpmichel wrote:
Is it because Linux is not an OS ? :p
I gnu somebody would bring that up.
There's actually a serious point here, though -- as D is ported
to other platforms and
On Monday, 11 April 2016 at 22:06:00 UTC, ag0aep6g wrote:
mixin template multipleEdgeProperties (EdgePropertyList...)
{
static if (EdgePropertyList.length >= 1)
{
mixin singleEdgeProperty!(EdgePropertyList[0]);
mixin multipleEdgeProperties!(EdgePropertyList[1 .. $]);
Hello all,
I've been playing around recently with some new ideas for a
reworking of my Dgraph library:
https://github.com/WebDrake/Dgraph
... and particularly, considering how to use D's metaprogramming
techniques to best allow the fundamental graph data structures to
be extended
On Thursday, 26 November 2015 at 07:28:37 UTC, Jacob Carlborg
wrote:
Hmm, I was pretty sure I fixed this, but perhaps not for that
file. Please report an issue. In the meantime there's a
workaround in the documentation [1], second paragraph, perhaps
not very clear though.
[1]
On Tuesday, 24 November 2015 at 23:49:26 UTC, cym13 wrote:
There are some binding generator the most two famous being htod
and dstep:
http://wiki.dlang.org/List_of_Bindings#Binding_generators
Is htod maintained any more? I had the impression it had kind of
fallen by the wayside.
I'll give
On Wednesday, 25 November 2015 at 17:45:48 UTC, ponce wrote:
If doing it by hand, some tips here:
http://p0nce.github.io/d-idioms/#Porting-from-C-gotchas
Cool, thanks. The stuff about using c_long and c_ulong is
particularly useful/relevant to my use-case, so it's good to be
reminded of
I've just built and installed dstep (on Ubuntu 15.10, using
libclang-3.7) but whenever I try to run it on a header file, I
run into the error message:
File(8AC8E0, "")/usr/include/limits.h:123:16: fatal error:
'limits.h' file not found
I suspect this is a libclang problem, but does anyone
Hello all,
I'm considering creating some D bindings for a C library. Before
I start, I was wondering if anyone could advise me on the current
state-of-the-art in automatically converting C headers to .d or
.di files; it's a long time since I've looked at anything to do
with this and the
On Tuesday, 24 November 2015 at 23:14:14 UTC, Joseph Rushton
Wakeling wrote:
I'm considering creating some D bindings for a C library.
I should probably clarify that I know what to do assuming I have
to write all the bindings manually. However, as the library has
quite a lot of header
... or, it turns out, sdc doesn't like it when you forget to rewrite
`void main()` as `int main()`, and its error messages are still in the cryptic
stage :-P
Onwards and upwards, then ... :-)
On 18/10/15 19:58, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
Turns out even `return 42
Hello all,
I recently decided to have another play with sdc to see how it's doing. Since
my dmd is installed in /opt/dmd/ I had to do a couple of tricks to get sdc
itself to build:
(i) put a dlang.conf in /etc/ld.so.conf.d/ containing the /opt/dmd/lib64 path;
(ii) call 'make
On 18/10/15 19:43, Marco Leise via Digitalmars-d-learn wrote:
Maybe you should have started with `return 42;`? :D
writeln is not a light-weight in terms of exercised compiler
features. I didn't even know that it compiles yet. Last time I
heard it was not usable.
Hahahahahahahaha :-D
Turns out
On Monday, 3 August 2015 at 09:01:51 UTC, Dicebot wrote:
It is now verified as safe by `return ref`.
Yes, until you pointed this out to me I'd been convinced that
classes were the way forward for RNGs. I think that `return ref`
is going to be a _very_ powerful tool for facilitating
On 02/08/15 03:38, Dicebot via Digitalmars-d-learn wrote:
On Saturday, 1 August 2015 at 17:50:28 UTC, John Colvin wrote:
I'm not sure how good an idea it is to totally enforce a range to be
non-copyable, even if you could deal with the function call chain problem.
Even in totally save-aware
On 31/07/15 19:21, Ali Çehreli via Digitalmars-d-learn wrote:
On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
is this design idea even feasible in principle, or just a bad
idea from the get-go?
As I understand it, it is against one of fundamental D principles
On 31/07/15 13:40, Kagamin via Digitalmars-d-learn wrote:
On Sunday, 26 July 2015 at 12:16:30 UTC, Joseph Rushton Wakeling wrote:
Example:
Unique!Random rng = new Random(unpredictableSeed);
rng.take(10).writeln;
My aim by contrast is to _allow_ that kind of use, but render the original
On Sunday, 26 July 2015 at 11:30:16 UTC, Joseph Rushton Wakeling
wrote:
Hello all,
A design question that came up during the hackathon held during
the last Berlin D Meetup.
[...]
Ping on the above -- nobody has any insight...?
On 26/07/15 14:24, Adam D. Ruppe via Digitalmars-d-learn wrote:
If the whole function is marked @trusted, the compiler doesn't try to check it
at all - it just takes your word for it.
There was a bit of argument about this a while ago in bugzilla, not everyone
agrees it is a good idea. I don't
Hello all,
A design question that came up during the hackathon held during the last Berlin
D Meetup.
I was trying to come up with a range that can be copied by value, but when this
is done, destroys the original handle. The idea would be behaviour something
like this:
auto
On 26/07/15 13:45, Martijn Pot via Digitalmars-d-learn wrote:
Sounds like unique_ptr (so UniqueRange might be a nice name). Maybe you can get
some ideas from that.
There is already a Unique in std.typecons. However, I'm not sure that it's
doing what I require.
Example:
Unique!Random
On Tuesday, 19 May 2015 at 14:31:21 UTC, Ivan Kazmenko wrote:
On Tuesday, 19 May 2015 at 10:00:33 UTC, BlackEdder wrote:
The documentation seems to indicate that partialShuffle:
Partially shuffles the elements of r such that upon returning
r[0..n] is a random subset of r, (which is what I
On 07/01/15 16:02, Laeeth Isharc via Digitalmars-d-learn wrote:
class node
{
string name;
node ref;
}
Small recommendation (apart from the reserved word issue which you fixed): it's
generally considered good D style to give structs and classes names that start
with capital letters,
A question that suddenly occurred to me, and I realized I didn't know the
answer.
Why is it necessary/desirable to define separate .length and .opDollar methods
for custom types?
On 28/12/14 19:21, Tobias Pankrath via Digitalmars-d-learn wrote:
To allow slicing for types that don't have a length property but
are terminated by a sentinel value, like null terminated strings
or single linked lists.
It's usefull for multi-dimensional containers as well.
Ah, clear. Thanks
On 22/12/14 19:06, aldanor via Digitalmars-d-learn wrote:
https://github.com/D-Programming-Language/dmd/pull/4200
Yes, I saw that PR with some joy -- thanks for the link! :-)
On 22/12/14 20:12, aldanor via Digitalmars-d-learn wrote:
On Monday, 22 December 2014 at 19:11:13 UTC, Ali Çehreli wrote:
On 12/22/2014 10:06 AM, aldanor wrote:
https://github.com/D-Programming-Language/dmd/pull/4200
Thank you! This fixes a big problem with the contracts in D.
Ali
It's
On 09/12/14 08:31, Nicholas Londey via Digitalmars-d-learn wrote:
Does @property ever make sense for a free floating function?
http://dlang.org/phobos/std_random.html#.rndGen :-)
Suppose I have a base class where one of the methods has an in-contract, and a
derived class that overrides it:
/
import std.stdio;
abstract class Base
{
abstract void foo(int n)
in
{
assert(n 5);
}
body
{
On 05/12/14 23:45, Ali Çehreli via Digitalmars-d-learn wrote:
This is a known problem with contract inheritance. The following bug report
mentions the ugly hack of defining assert(0) as the derived's 'in' contract:
https://issues.dlang.org/show_bug.cgi?id=6856
Thanks for the clarification.
On 06/12/14 00:24, bearophile via Digitalmars-d-learn wrote:
Is this a strong need?
Let's put it this way: I don't mind copy-pasting the same in-contract into
derived class methods. I'd just rather avoid it, and was hoping there was a way
to do so which was trivial.
It's disappointing
Here's a little experiment I was trying out earlier today in order to try and
convert foreach-style code to using UFCS of ranges:
//
import std.algorithm, std.range, std.stdio;
void main()
{
size_t s = 0;
void essify(size_t n)
{
On 06/12/14 00:58, bearophile via Digitalmars-d-learn wrote:
Joseph Rushton Wakeling:
Can anyone advise why,
map is lazy, like most other ranges.
Ah, I see. That function would only be called on consumption of the results of
the map.
Lazy higher order functions like map/filter should
On 30/11/14 13:21, Arjan via Digitalmars-d-learn wrote:
Hi!
D noob here.
I'm trying to call this function from the GSL lib:
Out of curiosity (since your question has already been answered), what
functionality is it that is making you want to use GSL? I ask because I want to
be sure we're
On 14/08/14 19:16, Philippe Sigaud via Digitalmars-d-learn wrote:
Do people here get good results from Appender? And if yes, how are you using it?
An example where it worked for me:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
(You will have to scroll down a bit to get to the
On 14/08/14 23:33, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
An example where it worked for me:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
I should add that I don't think I ever explored the case of just using a regular
array with assumeSafeAppend. Now
Hi all,
I'm running into a little trouble trying to build SDC. The first problem was
that the makefile does not auto-detect the appropriate llvm-config, or the
libphobos2 location, but that's simply enough fixed by doing (in my case):
make LLVM_CONFIG=llvm-config-3.4
On 27/07/14 14:22, Stefan Koch via Digitalmars-d-learn wrote:
your LD_PATH seems to not have the lib in it
From the Makefile, I'd understood that LD_PATH was meant to point to the
_directory_ where the libraries are contained, not the actual library itself ...
? After all, it's just mapped
On 27/07/14 14:16, Stefan Koch via Digitalmars-d-learn wrote:
sdc itself should not use phobos at all as far as I can tell.
libsdrt should be selfcontaint.
Yes, it's obviously being used to build the compiler, and supplying the flag
directly is clearly only necessary in this case for the gcc
On 27/07/14 15:10, Dicebot via Digitalmars-d-learn wrote:
Is shared Phobos library in /opt/dmd known do ldconfig?
No, but isn't that what the -L flag should be passing to gcc?
On 27/07/14 16:20, Stefan Koch via Digitalmars-d-learn wrote:
if gcc knows where the lib is it can compile agianst it.
But the library beeing _shared_ will not be linked with the executable but the
library will be loaded form the path's supplied as LD_PATH or in ldconfig.
The -L flag does not
Alternative:
randomSample(lowercase, 10, lowercase.length).writeln;
No, I don't think that's appropriate, because it will pick 10 individual
characters from a, b, c, ... , z (i.e. no character will appear more than once),
and the characters picked will appear in alphabetical order.
On 12/07/14 21:01, Danyal Zia via Digitalmars-d-learn wrote:
I noticed that in Andrei's talks and his book, he used braces on the same line
of delcaration, however Phobos and other D libraries I know use braces on their
own line. Now I'm in a position where I need to take decision on coding
On 13/07/14 16:52, H. S. Teoh via Digitalmars-d-learn wrote:
I had my own style before, but after I started contributing to Phobos, I
found it a pain to keep switching back and forth between styles (and to
convert styles before submitting PR's), so eventually I decided to just
adopt Phobos style
On 13/07/14 14:23, Danyal Zia via Digitalmars-d-learn wrote:
I'm going with Andrei's style of preference on his talks ;)
Andrei can no doubt speak for himself about his preferences, but I'd be wary of
assuming that the style he uses in his talks necessarily reflects his actual
stylistic
On 13/07/14 19:24, Timon Gehr via Digitalmars-d-learn wrote:
Wrong. There are things which are simply bad ideas.
I think that we can take it as read that I meant, Any reasonable stylistic
choice. Of course, YMMV about what counts as reasonable, but most of the
things that people fuss over
On 13/07/14 19:51, Brian Rogoff via Digitalmars-d-learn wrote:
Yes, the same argument for books and slides is also applicable to all other
media.
Not really. In a book or a slide you have an unavoidable constraint on how much
vertical space you can take up. On a screen, you are unavoidably
On 11/06/14 16:22, Adam D. Ruppe via Digitalmars-d-learn wrote:
On Wednesday, 11 June 2014 at 14:11:04 UTC, simendsjo wrote:
I believe the correct answer should be Buy my book!.
ah, of course! I should just make a .sig file lol
Hello all,
Here's an interesting little bug that arises when std.random.uniform is called
using dchar as the variable type:
//
import std.conv, std.random, std.stdio, std.string, std.typetuple;
void main()
{
On 08/06/14 16:25, monarch_dodra via Digitalmars-d-learn wrote:
Arguably, the issue is the difference between invalid and downright illegal
values. The thing about dchar is that while it *can* have values higher than
dchar max, it's (AFAIK) illegal to have them, and the compiler (if it can) will
On 08/06/14 18:41, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
On 08/06/14 10:47, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
Here's an interesting little bug that arises when std.random.uniform is called
using dchar as the variable type:
Issue report submitted: https
Hello all,
Just a quick check -- which version of the dmd frontend introduces support for
the notation T(n) to initialize a variable as type T? Is it 2.065 or the
upcoming 2.066? I ask because as I'm always running git-HEAD DMD, I'm never
entirely on top of what's in which version ... :-)
On 07/06/14 19:57, Peter Alexander via Digitalmars-d-learn wrote:
Well, it doesn't work in 2.065, so must be 2.066 :-)
P.S. thanks for letting me know about this feature. I had no idea it was going
in!
I only discovered it when I was advised to use it in a recent Phobos PR of
mine. :-)
The
On 07/06/14 19:57, bearophile via Digitalmars-d-learn wrote:
Joseph Rushton Wakeling:
which version of the dmd frontend introduces support for the notation T(n) to
initialize a variable as type T? Is it 2.065 or the upcoming 2.066?
In 2.066.
Thanks for the confirmation :-)
On 02/06/14 08:57, Chris Cain via Digitalmars-d-learn wrote:
On Sunday, 1 June 2014 at 14:22:31 UTC, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
I missed the debate at the time, but actually, I'm slightly more concerned
over the remark in that discussion that the new uniform
Hello all,
What's the current state of preference (if any) for using std.conv.text vs.
std.string.format (or others?) when formatting error messages for
assert/enforce/exceptions?
I seem to recall a deprecation message pushing the use of std.string.format at
some point in the past, but
On 01/06/14 14:11, Ivan Kazmenko via Digitalmars-d-learn wrote:
I second the thought that reproducibility across different versions is an
important feature of any random generation library. Sadly, I didn't use a
language yet which supported such a flavor of reproducibility for a significant
1 - 100 of 109 matches
Mail list logo
