www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - CTFE output is kind of weired

reply Andre Pany <andre s-e-a-p.de> writes:
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é
Jul 08
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jul 08
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
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.
Jul 08
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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).
Jul 08
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
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é
Jul 09
parent Andre Pany <andre s-e-a-p.de> writes:
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
Jul 09
prev sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
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.
Jul 10
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
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.
Jul 08
parent Jonathan M Davis via Digitalmars-d-learn writes:
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
Jul 08