On Sunday, 9 July 2017 at 04:03:09 UTC, H. S. Teoh wrote:
On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via
Digitalmars-d-learn wrote:
On 07/08/2017 02:29 PM, Andre Pany wrote:
> I use assert(false, tmp) to see the content of variable tmp
> as it seems there is no other way in CTFE.
WhatMeForget wrote:
c.hit is undefined when `c.empty` is `true`.
I was playing around with regex
import std.regex;
import std.stdio;
void main()
{
string[] fileNames = [ "011_bad.txt", "01_01_pass",
"90_pass", "_bad" ];
auto reg = regex(r"^\d{2}_");
foreach (name; fileNames)
{
auto c = matchFirst(name, reg);
//writeln(c.hi
On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 07/08/2017 02:29 PM, Andre Pany wrote:
>
> > I use assert(false, tmp) to see the content of variable tmp as it
> > seems there is no other way in CTFE.
>
> A more natural way is pragma(msg), which you can u
On Sunday, 9 July 2017 at 03:11:17 UTC, Mike Parker wrote:
On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:
To include stat1.d and stat2.d in the compilation, you'll
either have to import them in statmain.d or use the
--extra-file command line switch:
rdmd --extra-file=stat1.d -
On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:
$ rdmd statmain.d stat1.d stat2.d
// outputs nothing...
Bug or intended behaviour?
rdmd takes the first D file you give it, follows its import tree,
and compiles all the modules found there. Anything on the command
line after
RDMD does not behave the same as DMD WRT static constructors. The
following example, extracted form Mike Parker's "Learning D",
does not produce the same result:
// stat1.d
module stat1;
import std.stdio;
static this() { writeln("stat1 constructor"); }
// stat2.d
module stat2;
import std.stdio
On Saturday, July 8, 2017 10:12:29 PM MDT Era Scarecrow via Digitalmars-d-
learn wrote:
> On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:
> > app.d(17):called from here: test("1234\x0a5678\x0a")
> >
> > I wrote the source code on windows with a source file with \r\n
> > file end
Just saw that my first example was wrong, it should read
1 void main ()
2 {
3import std.uri;
4string a = "";
5assert (a);
6auto s = a.decodeComponent;
7assert (s);
8 }
The non-nullity was not preserved. Only the second assert fa
On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn
wrote:
> Yesterday I noticed that std.uri.decodeComponent does not
> 'preserve' the
> nullity of its argument:
>
> 1 void main ()
> 2 {
> 3import std.uri;
> 4string s = null;
> 5assert (s is nul
On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:
app.d(17):called from here: test("1234\x0a5678\x0a")
I wrote the source code on windows with a source file with \r\n
file endings.
But the console output has only the character X0a. In addition
not the content of tmp is shown
On 07/08/2017 02:29 PM, Andre Pany wrote:
> I use assert(false, tmp) to see the content of variable tmp as it seems
> there is no other way in CTFE.
A more natural way is pragma(msg), which you can use in main in this case:
string test(string s)
{
string tmp = s;
tmp = tmp[4..$];
re
Hi,
I use assert(false, tmp) to see the content of variable tmp as it
seems there is no other way in CTFE.
The output is kind of weired:
app.d(6): Error: "1234\x0a5678\x0a"[4..10]
app.d(17):called from here: test("1234\x0a5678\x0a")
I wrote the source code on windows with a source fil
I use protocol buffers (using dproto) for this, storing my settings in
either text or wire format. Advantages: type-safety with fwd/backward
compatibility (unlike json which requires dynamic field access, eg
with dproto you get errors at compile time instead of runtime),
supports comments (although
What's the fastest XML-parser on code.dlang.org?
Are there any benchmarks that show performance improvements
compared to std.xml?
On 07/08/2017 07:16 PM, kdevel wrote:
The assertion in line 6 fails. This failure gave rise to a more general
investigation on strings. After some research I found that one
"cannot implicitly convert expression (s) of type string to bool" as in
[...]
Nonetheless in certain boolean contexts str
On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote:
On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote:
On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote:
On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
[...]
"best" always depends on your specific use case. I use
On 08.07.2017 19:16, kdevel wrote:
I wonder if this distinction is meaningful
Not nearly as much as it would need to be to justify the current
behavior. It's mostly a historical accident.
and---if not---why it is
exposed to the application programmer so prominently.
I don't think there i
Yesterday I noticed that std.uri.decodeComponent does not
'preserve' the
nullity of its argument:
1 void main ()
2 {
3import std.uri;
4string s = null;
5assert (s is null);
6assert (s.decodeComponent);
7 }
The assertion in line 6 fails. This failure gave ris
import std.stdio;
enum A : int { a, b };
enum B : int { a, b };
enum AS : string[2] { a = ["1","2"], b = ["3","4"] };
enum BS : string[2] { a = ["5","6"], b = ["7","8"] };
void func(A a) { writeln("A"); }
void func(B b) { writeln("B"); }
void funcs(AS a) { writeln("AS"); }
void funcs(BS b)
On Saturday, 8 July 2017 at 08:56:17 UTC, Rainer Schuetze wrote:
On 08.07.2017 07:55, Nicholas Wilson wrote:
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole
wrote:
On 08/07/2017 2:35 AM, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson
wrote:
My libr
On 08.07.2017 07:55, Nicholas Wilson wrote:
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote:
On 08/07/2017 2:35 AM, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:
My library is generating a typeid from somewhere.
e.g.
typeid(const(Point
Thanks, that was what was happening.
23 matches
Mail list logo
