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 file with \r\n file endings.
But the console output has only the character X0a.
In addition not the content of tmp is shown but the full content with the slice information [4..10].

Is this the intented behavior?

string test(string s)
{
    string tmp = s;
    tmp = tmp[4..$];
    assert(false, tmp);
    return tmp;
}

enum foo =
`1234
5678
`;

void main()
{
    enum bar = test(foo);
}

Kind regards
André

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..$];
    return tmp;
}

enum foo =
`1234
5678
`;

void main()
{
    enum bar = test(foo);
    pragma(msg, bar);
}

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

Yes, looks pretty weird. :) I remember issues related to Unicode characters, which may be fixed by now, but the [4..10] part is news to me.

Ali

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 but the full content with the slice information [4..10].
>
> Is this the intended behavior?

 The escape sequence says it's hex, and 0a translates to 10, and 0d is 13; \r\n is usually a 13,10 sequence. So from the looks of it the \r is getting stripped out.

 Funny story as i understand it, \r and \n both have very specific meanings to old printers in the old days. \r for carriage-Return, and \n for New-line. DOS may have used it, but \r more-or-less has no use for newlines and printers today.

 Curious when using writeln, all newlines seem to have \r sequences added. So i suppose it's one of those things that i never needed to think about really.

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 endings.
> > But the console output has only the character X0a. In addition
> > not the content of tmp is shown but the full content with the
> > slice information [4..10].
> >
> > Is this the intended behavior?
>
>   The escape sequence says it's hex, and 0a translates to 10, and
> 0d is 13; \r\n is usually a 13,10 sequence. So from the looks of
> it the \r is getting stripped out.
>
>   Funny story as i understand it, \r and \n both have very
> specific meanings to old printers in the old days. \r for
> carriage-Return, and \n for New-line. DOS may have used it, but
> \r more-or-less has no use for newlines and printers today.

It used to matter for terminals as well. With respect to those ancient time, what Windows does with line endings with \r\n is the most correct, but at this point, it's just a pointless extra character. AFAIK, no other OS expects \r\n now. Everything that's *nix-based uses only \n. Unfortunately, web formats such as http still use \r\n though, because they're based on the original Internet Message Fomat standard (e-mail really), and it's old enough that it mattered when it was written.

LOL. As I understand it, the old Macs before Mac OS X actually just used \r, so twent years ago, depending on your OS, you had to deal with \n, \r, or \r\n for line endings. Yuck.

>   Curious when using writeln, all newlines seem to have \r
> sequences added. So i suppose it's one of those things that i
> never needed to think about really.

Only if you're on Windows. It's what printf and friends do there too (and IIRC, writeln still uses printf underneath the hood). C and UNIX pretty much came into being together, and thus both use \n as the line ending - though given when they were created, I expect that the distinction between \n and \r\n still mattered on UNIX systems occasionally. I don't know though. Now though, no *nix system is going to be doing anything with \r for line endings.

- Jonathan M Davis

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 use in main in this
> case:
[...]

Unfortunately, pragma(msg) can only be used *after* CTFE has finished. It's not possible to print the message *during* CTFE.

Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that should alleviate this limitation.


T

-- 
There is no gravity. The earth sucks.

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.
>> 
>> A more natural way is pragma(msg), which you can use in main in this
>> case:
> [...]
>
> Unfortunately, pragma(msg) can only be used *after* CTFE has finished. It's not possible to print the message *during* CTFE.
>
> Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that should alleviate this limitation.
>
>
> T

In fact ctfeWriteln harder to do for newCTFE then it is in the old interpreter.
I suggest people stick with either returning a string or assert(0, message).

On Sunday, 9 July 2017 at 06:48:30 UTC, Stefan Koch wrote:
> 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.
>>> 
>>> A more natural way is pragma(msg), which you can use in main in this
>>> case:
>> [...]
>>
>> Unfortunately, pragma(msg) can only be used *after* CTFE has finished. It's not possible to print the message *during* CTFE.
>>
>> Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that should alleviate this limitation.
>>
>>
>> T
>
> In fact ctfeWriteln harder to do for newCTFE then it is in the old interpreter.
> I suggest people stick with either returning a string or assert(0, message).

Thanks for all the answers and explanations. I will create an issue to make the assert output more readable. The first 5 times I didn't recognize the slice information at the end of the string and thought dmd isn't working at all anymore.

Kind regards
André

On Sunday, 9 July 2017 at 08:43:47 UTC, Andre Pany wrote:
>
> Thanks for all the answers and explanations. I will create an issue to make the assert output more readable. The first 5 times I didn't recognize the slice information at the end of the string and thought dmd isn't working at all anymore.
>
> Kind regards
> André

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

On Sun, Jul 09, 2017 at 06:48:30AM +0000, Stefan Koch via Digitalmars-d-learn wrote:
> On Sunday, 9 July 2017 at 04:03:09 UTC, H. S. Teoh wrote:
[...]
> > Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that should alleviate this limitation.
> > 
> > 
> > T
> 
> In fact ctfeWriteln harder to do for newCTFE then it is in the old interpreter.
[...]

Oh? Why is that?  Isn't it just a matter of adding a new opcode for outputting a string?  Or calling an intrinsic function that the interpreter recognizes as ctfeWriteln?


T

-- 
ASCII stupid question, getty stupid ANSI.