Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 2019-07-06 05:06, Ben Grasset wrote: . . He hasn't reported anything, so far, that isn't just how strings have always worked. The only real issue we've uncovered is the strange behavior of {$mode} as it relates to {$push} and {$pop}. Have you tested command-line compilation with a

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 10:53 PM J. Gareth Moreton wrote: > If someone has reported it, then it's not impossible. Granted, a > reproducible case helps here, along with any configuration settings. > He hasn't reported anything, so far, that isn't just how strings have always worked. The only real

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ok, I've implemented {$modeswitch MultiLineStrings}. The compiler now stops immediately with "file.pas(lineno,lineno) Fatal: Illegal character "'`'" ($60)" (which I find to be more informative than "illegal expression") upon any occurrence of a backtick outside a single-line string when the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

If someone has reported it, then it's not impossible.  Granted, a reproducible case helps here, along with any configuration settings. Gareth aka. Kit On 06/07/2019 03:46, Ben Grasset wrote: On Fri, Jul 5, 2019 at 10:37 PM Ryan Joseph > wrote: String constant

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 10:37 PM Ryan Joseph wrote: > String constant too long while ansistrings are disabled > > Regards, > Ryan Joseph > Getting that with "var SomeString: AnsiString = " should be (and is) impossible at all times. Getting that with "var SomeString: String = " only

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 10:36 PM, Ben Grasset wrote: > > What error, though? String constant too long while ansistrings are disabled Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 9:35 PM Ryan Joseph wrote: > I just tried pasting some code from Sublime Text into the string and I get > the error. If I copy your code or just type myself the error goes away. > I’m on a Mac btw so it may have something to do with that. > What error, though?

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 8:14 PM, Ben Grasset wrote: > > No, that makes no sense whatsoever. > I just tried pasting some code from Sublime Text into the string and I get the error. If I copy your code or just type myself the error goes away. I’m on a Mac btw so it may have something to do

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 8:14 PM Ben Grasset wrote: > On Fri, Jul 5, 2019 at 8:08 PM Ryan Joseph wrote: > >> ah! Your code works but mine doesn’t! maybe the line ending are messing >> it up? I get "String constant too long while ansistrings are disabled”.\ >> > > No, that makes no sense

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 8:08 PM Ryan Joseph wrote: > ah! Your code works but mine doesn’t! maybe the line ending are messing it > up? I get "String constant too long while ansistrings are disabled”.\ > No, that makes no sense whatsoever. Another example: {$mode objfpc} { explicitly set H- ! }

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 06.07.2019 um 01:21 schrieb J. Gareth Moreton: > According to this , > a > Longint. Ah, right. I checked the source again: that is true only if the argument is an enum. If it is any other ordinal type or Pointer, the result is of the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 7:54 PM Ryan Joseph wrote: > I’m confused now. The error is coming from the middle of the string after > it exceeds the character limit. Can we fix this? If it’s possible to turn > on longer than 255 char multiline strings locally that’s going to be a > problem for

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 8:04 PM, Ben Grasset wrote: > > With a build of my fork of the compiler as uploaded, compiling it with simply > "fpc ./test.pas" works without issues, and it runs like you'd expect. > ah! Your code works but mine doesn’t! maybe the line ending are messing it up? I get

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 7:49 PM Ryan Joseph wrote: > Do you mean this? I still get an error without H+. > > {$mode objfpc} > > program test; > > var lines: ansistring = ` > #version 150 > > uniform sampler2D textures[8]; > in vec2 vertexTexCoord; > in vec4 vertexColor; > in float

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 6:48 PM, Sven Barth via fpc-devel > wrote: > > Ah! Check the location of the error. It's the Writeln, not the declaration of > the constant. Seems like the compiler doesn't correctly handle this case. But > to be fair it's really seldom that someone uses $H locally, so

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 7:33 PM, Ben Grasset wrote: > > {$H+} is definitely not needed for an explicit 'var string: ansistring'. It > works even with {$H-}. Do you mean this? I still get an error without H+. {$mode objfpc} program test; var lines: ansistring = ` #version 150 uniform

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05/07/2019 23:50, Sven Barth via fpc-devel wrote: Am 05.07.2019 um 22:34 schrieb J. Gareth Moreton: It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 7:33 PM Ben Grasset wrote: > I'm still very unclear about where Ryan said he got "illegal expression" > and such, though. I just now tested another large number of possible ways > you can use multi-line strings, and they all do work. > As an (extreme) example of something

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 6:41 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The constant itself is parsed depending on the state of $H and only then > "assigned" to the constant (just tested that myself). So the directives are > needed to get the correct string type of the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

According to this , a Longint. Gareth aka. Kit On 06/07/2019 00:04, Martok wrote: I think there is a shorter version, but what is the exact return type of Ord() again? By the way, what you're reinventing here is type marshalling, for

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

I think there is a shorter version, but what is the exact return type of Ord() again? By the way, what you're reinventing here is type marshalling, for one single type class, and in a very roundabout way. If that is really what the discussion settled on, it would probably make sense to not tack

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 22:34 schrieb J. Gareth Moreton: It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums taking on invalid values, I have to say that this is the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 06.07.2019 um 00:21 schrieb Ryan Joseph: On Jul 5, 2019, at 5:45 PM, Ben Grasset wrote: Like, not working in any sense at all? That's definitely not normal. I think it’s just the push/pop isn’t working. Just to be clear should the follow code compile? For me I get an error.Try it

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 22:30 schrieb Ben Grasset: On Fri, Jul 5, 2019 at 1:41 PM Ryan Joseph > wrote: This doesn’t work either. {$push} {$h+} var lines: ansistring = `   #version 150   uniform sampler2D textures[8];   in vec2

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 5:45 PM, Ben Grasset wrote: > > Like, not working in any sense at all? That's definitely not normal. > I think it’s just the push/pop isn’t working. Just to be clear should the follow code compile? For me I get an error.Try it yourself when you get some time. {$mode

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 4:49 PM Ryan Joseph wrote: > In ObjFPC mode H+ doesn’t seem to be working unless it’s before the > program section. > Like, not working in any sense at all? That's definitely not normal. ___ fpc-devel maillist -

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 4:39 PM Ben Grasset wrote: > I'll have to look at this later today when I have more free time. I did > however test a variety of things (both typed and untyped constants and > variables, and also literals in function calls, and had no issues.) > > Note again that

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

In the meantime, I've extended your AS/IS patch over here to create efficient code for x86 platforms, although currently it only does a range check and won't correctly handle enumerations with holes.  If non-contiguous enumerations are going to

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 4:39 PM, Ben Grasset wrote: > > I'll have to look at this later today when I have more free time. I did > however test a variety of things (both typed and untyped constants and > variables, and also literals in function calls, and had no issues.) > Thanks. I don’t even

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 4:36 PM Ryan Joseph wrote: > The problem is I was using ObjFPC mode. Works fine in Delphi. A bug? > > {$mode objfpc} > {$modeswitch multilinestrings} > {$multilinestringlineending crlf} > > program test; > > {$push} > {$H+} > const lines = ` > #version 150 > > uniform

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 4:30 PM, Ben Grasset wrote: > > Doesn't work in what regard? You wouldn't even need {$H+} there, as you're > explicitly using an ansistring. > The problem is I was using ObjFPC mode. Works fine in Delphi. A bug? {$mode objfpc} {$modeswitch multilinestrings}

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums taking on invalid values, I have to say that this is the best solution should we not be allowed the "is"

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 1:41 PM Ryan Joseph wrote: > This doesn’t work either. > > {$push} > {$h+} > var lines: ansistring = ` > #version 150 > > uniform sampler2D textures[8]; > in vec2 vertexTexCoord; > in vec4 vertexColor; > in float vertexUVMap; > out vec4 fragColor; > > void

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 22:25 schrieb Sven Barth: Am 05.07.2019 um 08:08 schrieb Sven Barth: Jonas Maebe mailto:jo...@freepascal.org>> schrieb am Do., 4. Juli 2019, 21:21: On 03/07/2019 09:26, Ondrej Pokorny wrote: > On 02.07.2019 23:34, Jonas Maebe wrote: >> Invalid data means undefined

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 08:08 schrieb Sven Barth: Jonas Maebe mailto:jo...@freepascal.org>> schrieb am Do., 4. Juli 2019, 21:21: On 03/07/2019 09:26, Ondrej Pokorny wrote: > On 02.07.2019 23:34, Jonas Maebe wrote: >> Invalid data means undefined behaviour, always. "is" is not a

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 19:36 schrieb Ben Grasset: On Fri, Jul 5, 2019 at 1:14 PM Ryan Joseph > wrote: This may present a bit of problem then because you don't appear to be able to opt-in to long strings just for constants. $h+ will always be required for

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 19:41 schrieb Ryan Joseph: On Jul 5, 2019, at 1:36 PM, Ben Grasset wrote: {$push} {$H+} var Ansi: String; {$pop} This doesn’t work either. {$push} {$h+} var lines: ansistring = ` #version 150 uniform sampler2D textures[8]; in vec2 vertexTexCoord; in vec4

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 19:38 schrieb Ryan Joseph: On Jul 5, 2019, at 1:34 PM, Sven Barth via fpc-devel wrote: Why should they always be required? If your multiline string is shorter than 256 characters then all is well. And otherwise you'd have the same problem with an ordinary string constant.

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 16:51, Pierre Muller wrote: This means that using pred() or succ() intrinsics on enumerated types with holes will generate a Compile Time Error. To be consistent, I would propose that we also generate a Compile Time Error if 'is' or 'as' keyword is used on such a type, unless

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Hey there - sorry if I'm not explaining myself too well. My question would be this... if Value is a variable of type TEnum that is invalid (either because it is out of range or contains a 'hole' value, but more specifically the former), should "Value is TEnum" return True, False or an

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 1:36 PM, Ben Grasset wrote: > > {$push} > {$H+} > var Ansi: String; > {$pop} This doesn’t work either. {$push} {$h+} var lines: ansistring = ` #version 150 uniform sampler2D textures[8]; in vec2 vertexTexCoord; in vec4 vertexColor; in float vertexUVMap; out

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 1:34 PM, Sven Barth via fpc-devel > wrote: > > Why should they always be required? If your multiline string is shorter than > 256 characters then all is well. > > And otherwise you'd have the same problem with an ordinary string constant. > > So this behaves exactly as

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 1:14 PM Ryan Joseph wrote: > This may present a bit of problem then because you don't appear to be able > to opt-in to long strings just for constants. $h+ will always be required > for multi-line strings but I don’t want the rest of my “string” types to > turn into

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ryan Joseph schrieb am Fr., 5. Juli 2019, 19:14: > > > > On Jul 5, 2019, at 12:10 PM, Ben Grasset wrote: > > > > Explicit "ShortString" variables are still exactly what they say they > are in all cases though, of course. > > > > This may present a bit of problem then because you don't appear to

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Pierre Muller schrieb am Fr., 5. Juli 2019, 17:51: > > > Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit : > > > > On 05/07/2019 15:51, Pierre Muller wrote: > >> Just one point from current compiler implementation: > >> > >> in trunk/fpcsrc/compiler/ninl.pas (around line 3180) > >> > >>

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 12:10 PM, Ben Grasset wrote: > > Explicit "ShortString" variables are still exactly what they say they are in > all cases though, of course. > This may present a bit of problem then because you don't appear to be able to opt-in to long strings just for constants. $h+

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 11:56 AM Ryan Joseph wrote: > So H+ makes all short strings ansistrings? I added that or I got an error > about the string being too long. > It makes all "just String without the word Short or Ansi in front of it" variables AnsiStrings, and yes, enables "true constant"

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 11:35 AM, Ben Grasset wrote: > > Your example has nothing to do with multi-line strings specifically, and is > completely normal, expected behavior when in {$H+}. > So H+ makes all short strings ansistrings? I added that or I got an error about the string being too

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit : > > On 05/07/2019 15:51, Pierre Muller wrote: >> Just one point from current compiler implementation: >> >> in trunk/fpcsrc/compiler/ninl.pas (around line 3180) >> >>in_pred_x, >>in_succ_x: >>

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 11:35 AM Ben Grasset wrote: > On Fri, Jul 5, 2019 at 11:29 AM Ryan Joseph wrote: > >> This may not be related but why does "l: string = lines;” work, shouldn’t >> that be an error or at least get clipped? I’m seeing writeln prints out the >> entire string as if it was an

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05/07/2019 15:51, Pierre Muller wrote: Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]);

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 11:29 AM Ryan Joseph wrote: > This may not be related but why does "l: string = lines;” work, shouldn’t > that be an error or at least get clipped? I’m seeing writeln prints out the > entire string as if it was an ansistring. > Your example has nothing to do with

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

This may not be related but why does "l: string = lines;” work, shouldn’t that be an error or at least get clipped? I’m seeing writeln prints out the entire string as if it was an ansistring. {$mode objfpc} {$multilinestringlineending crlf} {$h+} program test; const lines = ` #version 150

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 10:27 AM Ryan Joseph wrote: > program test; > > {$modeswitch multilinestrings} > {$multilinestringlineending cr} > > const lines = ` > aaa > bbb > ccc > ddd > `; > > begin > writeln(lines); > end. > Also: Just so nobody gets confused, if you want to test the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 10:57 AM Tomas Hajny wrote: > That's what CR (Carriage Return) means, right? The cursor is moved to > the beginning of the current line and writing continues there. > I believe he may have had CR mixed up with LF. (And by the sounds of it, his platform does specifically

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Martok schrieb am Fr., 5. Juli 2019, 14:54: > Am 05.07.2019 um 14:24 schrieb Sven Barth via fpc-devel: > > Huh? The comment regarding dynamic packages is nonsense. The compiler > and RTL > > check that the checksums of the involved interface sections match and > thus there > > is no problem

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 2019-07-05 16:43, Ryan Joseph wrote: If use {$multilinestringlineending cr} then the string only prints “ ddd”. If I use {$multilinestringlineending crlf} then all the text prints. That's what CR (Carriage Return) means, right? The cursor is moved to the beginning of the current line and

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 10:44 AM Ryan Joseph wrote: > If use {$multilinestringlineending cr} then the string only prints “ > ddd”. If I use {$multilinestringlineending crlf} then all the text prints. > Well, CR, (which is to say, #13) is extremely rarely used by itself (specifically it is native

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 16:51, Pierre Muller wrote: Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]);

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]); resultdef:=left.resultdef;

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 14:58, Martok wrote: Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: Anything that even looks like a subrange cannot be used for these interfaces. You may use enumerations for these interfaces - you may just not fill them directly but through an integer variable in between when

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 10:40 AM, Ben Grasset wrote: > > Not quite sure exactly what you mean. > If use {$multilinestringlineending cr} then the string only prints “ ddd”. If I use {$multilinestringlineending crlf} then all the text prints. Regards, Ryan Joseph

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 10:27 AM Ryan Joseph wrote > Sweet. Why does the “cr” setting only print one line and “crlf” prints all > of them? Sorry I wasn’t following along with all the talk. > Not quite sure exactly what you mean. ___ fpc-devel maillist

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 5, 2019, at 12:31 AM, Ben Grasset wrote: > > Ok, here's a link to my github fork implementing the multi-line string > functionality. > Sweet. Why does the “cr” setting only print one line and “crlf” prints all of them? Sorry I wasn’t following along with all the talk. It still

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 14:58, Martok wrote: Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: Anything that even looks like a subrange cannot be used for these interfaces. You may use enumerations for these interfaces - you may just not fill them directly but through an integer variable in between when

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05/07/2019 13:29, Sven Barth via fpc-devel wrote: J. Gareth Moreton > schrieb am Fr., 5. Juli 2019, 14:02: I'm glad we agree on the "is" operator.  Personally I would like to extend it so it accepts "if (I is TMyEnum) then" when I is also of type

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

> But I will not argue the point, it is largely a matter of personal > interpretation > of the intended use of an enumerated. Well, yes. Since any argument from authority is discarded, what remains is personal interpretation. > But I will definitely adapt the FPC documentation to be more clear

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 11:28 schrieb Michael Van Canneyt: > But IMO such a strict stance is untenable: you cannot ensure correct values > in all cases even within the confines of the language (as demonstrated > before). Correct. Even if certain (exactly two) people here believe differently. > So,

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: >> Anything that even looks like a subrange cannot be used for these interfaces. > > You may use enumerations for these interfaces - you may just not fill > them directly but through an integer variable in between when reading > from outside. Then

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 14:24 schrieb Sven Barth via fpc-devel: > Huh? The comment regarding dynamic packages is nonsense. The compiler and RTL > check that the checksums of the involved interface sections match and thus > there > is no problem there. Does that cascade? If so, that's better than

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

J. Gareth Moreton schrieb am Fr., 5. Juli 2019, 14:02: > I'm glad we agree on the "is" operator. Personally I would like to > extend it so it accepts "if (I is TMyEnum) then" when I is also of type > TMyEnum, since it may be the case that you're reading I directly from a > stream, either

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Martok schrieb am Fr., 5. Juli 2019, 11:10: > Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt: > > > With this sentence you forbid storing or communicating enumerated values > in any way: > > file, database, over network. It can be used only in a computer program > and never > > leave the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Benito van der Zander schrieb am Fr., 5. Juli 2019, 11:33: > Hi, > > Am 04.07.19 um 19:51 schrieb Marco van de Voort: > > > > If $ifdef was a single char token, maybe. And for a trivial feature, not a > core one, like conditional compiling. > > > So the compiler will correctly give an error. > >

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Hi Michael, I'm glad we agree on the "is" operator.  Personally I would like to extend it so it accepts "if (I is TMyEnum) then" when I is also of type TMyEnum, since it may be the case that you're reading I directly from a stream, either individually or as part of a record, in which case

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 11:08, Martok wrote: Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt: With this sentence you forbid storing or communicating enumerated values in any way: file, database, over network. It can be used only in a computer program and never leave the context of the running

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 11:33, Michael Van Canneyt wrote: On Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 10:52, Sven Barth via fpc-devel wrote: Michael Van Canneyt > schrieb am Fr., 5. Juli 2019, 10:47:     If memory serves well, FPC introduced this (before

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 10:52, Sven Barth via fpc-devel wrote: Michael Van Canneyt > schrieb am Fr., 5. Juli 2019, 10:47: If memory serves well, FPC introduced this (before delphi) to be able to import C enums with

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Hi, Am 04.07.19 um 19:51 schrieb Marco van de Voort: If $ifdef was a single char token, maybe. And for a trivial feature, not a core one, like conditional compiling. So the compiler will correctly give an error. ... but not at or near the place where the mistake is made. Some

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Fri, 5 Jul 2019, Martok wrote: Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt: With this sentence you forbid storing or communicating enumerated values in any way: file, database, over network. It can be used only in a computer program and never leave the context of the running

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 10:52, Sven Barth via fpc-devel wrote: Michael Van Canneyt > schrieb am Fr., 5. Juli 2019, 10:47: If memory serves well, FPC introduced this (before delphi) to be able to import C enums with assigned values. Correct. That is also why we

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Fri, 5 Jul 2019, Martok wrote: Am 05.07.2019 um 10:47 schrieb Michael Van Canneyt: Note that the explanation is IMO fuzzy, not to say contradictory: 'An enumerated type defines an ordered set of values by simply listing identifiers that denote these values' is at odds with (under the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt: > With this sentence you forbid storing or communicating enumerated values in > any way: > file, database, over network. It can be used only in a computer program and > never > leave the context of the running program under any form. Because

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 10:47 schrieb Michael Van Canneyt: > Note that the explanation is IMO fuzzy, not to say contradictory: > > 'An enumerated type defines an ordered set of values by simply listing > identifiers that denote these values' > > is at odds with (under the heading 'Enumerated Types

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Michael Van Canneyt schrieb am Fr., 5. Juli 2019, 10:47: > If memory serves well, FPC introduced this (before delphi) to be able to > import C enums with assigned values. > Correct. That is also why we allow both "=" and ":=" for the value assignments. Because Delphi only supports one of the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Fri, 5 Jul 2019, Ondrej Pokorny wrote: Note: This is my opinion, it may be at odds with what the compiler actually implements :) Read: http://docwiki.embarcadero.com/RADStudio/Rio/en/Simple_Types_(Delphi)#Enumerated_Types_with_Explicitly_Assigned_Ordinality As I said, my opinion

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 09:57, Michael Van Canneyt wrote: On Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 09:04, Michael Van Canneyt wrote: In this, I would definitely exclude enumerateds that have explicitly assigned values: str does not handle them, getenumename etc. also do not work: They

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 09:04, Michael Van Canneyt wrote: In this, I would definitely exclude enumerateds that have explicitly assigned values: str does not handle them, getenumename etc. also do not work: They are in effect simply integer constants. (if I

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 09:04, Michael Van Canneyt wrote: In this, I would definitely exclude enumerateds that have explicitly assigned values: str does not handle them, getenumename etc. also do not work: They are in effect simply integer constants. (if I had my way I would even remove them from the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Fri, 5 Jul 2019, J. Gareth Moreton wrote: Please don't put words in my mouth Michael or twist me up with word play.  I have never said I want to forbid the storing or communication of enumerations, and if people start using my argument for the exact opposite of what I'm trying to

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, 5 Jul 2019, Ben Grasset wrote: On Fri, Jul 5, 2019 at 2:02 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: As stated by I think Michael, a new modeswitch which is by default off is also required. Ok. {$modeswitch MultiLineStrings} I guess? Posts crossed :)

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, 5 Jul 2019, Ben Grasset wrote: Ok, here's a link to my github fork implementing the multi-line string functionality. you'll see that each string adheres to the setting above it. Note that "platform" means whatever line ending your

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Fri, Jul 5, 2019 at 2:02 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > As stated by I think Michael, a new modeswitch which is by default off is > also required. > Ok. {$modeswitch MultiLineStrings} I guess? ___ fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Jonas Maebe schrieb am Do., 4. Juli 2019, 21:21: > On 03/07/2019 09:26, Ondrej Pokorny wrote: > > On 02.07.2019 23:34, Jonas Maebe wrote: > >> Invalid data means undefined behaviour, always. "is" is not a special > >> case that is immune to this. > > > > Don't you really see the need to handle

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ben Grasset schrieb am Fr., 5. Juli 2019, 06:31: > Once I have a set of proper tests written, I suppose I'll submit a formal > patch to the FPC bugtracker. > As stated by I think Michael, a new modeswitch which is by default off is also required. Regards, Sven >