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

Maybe I'm missing something painfully obvious here. Can I request an example where such an invalid value/undefined behaviour crops up in bitpacked records so I can see what's going on? Logic dictates that the number of bits required to store an enum in that arrangement is equal to the index

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

On Sat, Jul 6, 2019 at 4:50 PM wrote: > one person's PrettyPrint format is another's ugly-as-sin ;) > One last thing: this is generally, as far as I'm concerned, a nitpicky non-reason to exclude a useful feature when you consider the simple fact that anyone who thinks Pascal code at large, in th

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

Florian Klaempfl schrieb am Sa., 6. Juli 2019, 21:18: > Am 06.07.2019 um 17:38 schrieb Sven Barth via fpc-devel: > >> I tried to follow the thread, but one think I miss is: what are the > >> rules for indention? Does the lines string contain > >> spaces at the beginning of every line or not? Are

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

On Sat, Jul 6, 2019 at 5:17 PM Ben Grasset wrote: > You cannot, in my opinion at least, reasonably expect something like this > to *ignore* all indentation and still function in any logical way. That the > leading whitespace is taken at "face value" is a large part of what makes > it useful for 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 Sat, Jul 6, 2019 at 4:50 PM wrote: > just asking... can't test... the private procedure is specifically to > exhibit > various formats and to query what the output would be... intended output > in this > case is > The output is always exactly what is written (apart from the line endings.) Yo

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

On 7/6/19 12:05 PM, Ben Grasset wrote: On Sat, Jul 6, 2019 at 11:51 AM Ryan Joseph wrote: You can of course shift the strings all the way to the left (which is ugly) Is it though? I think it looks fine, personally, if you place the initial backtick on the next line after the equal sign, l

Re: [fpc-devel] [] property overloads

> On Jul 6, 2019, at 4:28 PM, Ondrej Pokorny wrote: > >> I’m sorry, I didn’t know about your report. > > I though you checked it when you answered upon it. But no problem - it > happens quite often that people answer my posts without actually reading > them. On the other hand it is quite exh

Re: [fpc-devel] [] property overloads

On 06.07.2019 22:12, Ryan Joseph wrote: On Jul 6, 2019, at 4:09 PM, Ondrej Pokorny wrote: On 06.07.2019 20:03, Ryan Joseph wrote: Yeah that’s correct. Here’s my bug report: https://bugs.freepascal.org/view.php?id=35809 Did you just create a duplicate bug report to the one I linked in this t

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

I've now corrected the error-message positioning oversight that Ryan pointed out and committed the change to my fork-branch, for anyone following along. Once again I'll note also, for anyone updating or pulling the fork for the first time: {$modeswitch MultiLineStrings} *does* exist now, and you

Re: [fpc-devel] [] property overloads

> On Jul 6, 2019, at 4:09 PM, Ondrej Pokorny wrote: > > On 06.07.2019 20:03, Ryan Joseph wrote: >> Yeah that’s correct. >> >> Here’s my bug report: >> >> https://bugs.freepascal.org/view.php?id=35809 > > Did you just create a duplicate bug report to the one I linked in this thread > before

Re: [fpc-devel] [] property overloads

On 06.07.2019 20:03, Ryan Joseph wrote: Yeah that’s correct. Here’s my bug report: https://bugs.freepascal.org/view.php?id=35809 Did you just create a duplicate bug report to the one I linked in this thread before ( https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041350.html ) o

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 17:38 schrieb Sven Barth via fpc-devel: >> I tried to follow the thread, but one think I miss is: what are the >> rules for indention? Does the lines string contain >> spaces at the beginning of every line or not? Are they removed? How >> many are removed? What about tabs? Actually

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

On Sat, Jul 6, 2019 at 1:52 PM Ryan Joseph wrote: > Just thought of something. Why would it be a bad idea to have a switch > like H+ that makes all single quoted strings become multiline? I can’t > think of a reason off the top of my head which would mess up any of my > programs if suddenly strin

Re: [fpc-devel] [] property overloads

> On Jul 6, 2019, at 12:14 PM, Michael Van Canneyt > wrote: > > Why should this declaration not be allowed ? > > Only the first GetValue() should be called, of course. > > i.e. statement 1: > A:=Values[MyVariant] > must work > > but e.g. statement 2: > A:=Values[MyVariant1,MyVariant2] > mus

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

Just thought of something. Why would it be a bad idea to have a switch like H+ that makes all single quoted strings become multiline? I can’t think of a reason off the top of my head which would mess up any of my programs if suddenly strings were allowed to be more than one line. Regards,

Re: [fpc-devel] [] property overloads

On Sat, 6 Jul 2019, Ryan Joseph wrote: Sorry to ask again but has it been decided that this code should *not* be allowed for ObjFPC mode? I’ll file a bug report right now if so. It will break existing code but when my patch gets applied it can be added back using proper properties. fu

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 6, 2019, at 12:05 PM, Ben Grasset wrote: > > Is it though? I think it looks fine, personally, if you place the initial > backtick on the next line after the equal sign, like this: > It’s ugly imo, but that doesn’t matter because it’s better than nothing AND we can do a post process

Re: [fpc-devel] [] property overloads

Sorry to ask again but has it been decided that this code should *not* be allowed for ObjFPC mode? I’ll file a bug report right now if so. It will break existing code but when my patch gets applied it can be added back using proper properties. function GetValue(k0: variant): TJSON; overlo

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

On Sat, Jul 6, 2019 at 11:51 AM Ryan Joseph wrote: > You can of course shift the strings all the way to the left (which is ugly) > Is it though? I think it looks fine, personally, if you place the initial backtick on the next line after the equal sign, like this: const MultiLine = `Sentence one

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 6, 2019, at 11:38 AM, Sven Barth via fpc-devel > wrote: > > I've also complained about that point here: > https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041453.html For your case: const SomeString = `Whatever bar blubb

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 14:24 schrieb Ben Grasset: General question regarding the tests I'm writing: What kind of numbers should I be going for? Is something like 10 that pass and 10 that fail a good ratio? Or should it be more of them that pass? It's not about the ratio of passing and failing test

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 16:25 schrieb Florian Klämpfl: Am 05.07.2019 um 17:29 schrieb Ryan Joseph: 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 ob

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

On Sat, Jul 6, 2019 at 10:56 AM Ben Grasset wrote: > Yep. I was actually just writing a couple of tests that directly look at > how errors are handled, so this might prove as a good case for one of them > once I get it remedied. > Ok, I see exactly what's wrong (or more specifically, missing) in

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

On Sat, Jul 6, 2019 at 10:52 AM Ryan Joseph wrote: > {$mode objfpc} > > program test; > > const lines: ansistring = ` > #version 150 > > uniform sampler2D textures[8]; > in vec2 vertexTexCoord; > in vec4 vertexColor; > in float vertexUVMap; > out vec4 fragColor; > > void main() >

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 6, 2019, at 10:50 AM, Ben Grasset wrote: > > I'll have to look at exactly how the errors get propagated in that scenario. > None of my code directly involves the "file info", though. Try this test. I get Identifier not found “b” at 18:11. = {$mode objfpc} prog

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

On Sat, Jul 6, 2019 at 10:44 AM Ryan Joseph wrote: > > Ben, I think that the multiline strings are messing up the current file > info so errors are appearing at the wrong place. The “illegal expression” > should appear at the variable initialization but it’s appearing in the > middle of the strin

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

Ben, I think that the multiline strings are messing up the current file info so errors are appearing at the wrong place. The “illegal expression” should appear at the variable initialization but it’s appearing in the middle of the string instead. If you remove any new lines from the string you’

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

On Sat, Jul 6, 2019 at 10:34 AM Ben Grasset wrote: > No spaces or tabs are implicitly inserted or removed by the compiler at > any time. Line endings are handled via the directive syntax suggested by > Michael. > > If you wish to test the feature yourself, Florian, currently I have the > branch 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 Sat, Jul 6, 2019 at 10:25 AM Florian Klämpfl wrote: > I tried to follow the thread, but one think I miss is: what are the rules > for indention? Does the lines string contain > spaces at the beginning of every line or not? Are they removed? How many > are removed? What about tabs? Actually, th

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 17:29 schrieb Ryan Joseph: > 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}

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

On Sat, Jul 6, 2019 at 10:15 AM Ryan Joseph wrote: > > On Jul 6, 2019, at 9:56 AM, Ben Grasset wrote: > > > > You cannot under any circumstances initialize a variable with a "typed" > constant, because typed constants are themselves mutable by default. > > > > Ok so typed constants are not reall

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 6, 2019, at 9:56 AM, Ben Grasset wrote: > > You cannot under any circumstances initialize a variable with a "typed" > constant, because typed constants are themselves mutable by default. > Ok so typed constants are not really constants. Makes sense. :) The error also doesn’t make 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 Sat, Jul 6, 2019 at 2:15 AM Tony via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > On Thu, 4 Jul 2019 12:00:07 +0200 > Marco van de Voort wrote: > > > In conclusion: it is a solution in search of a problem, with bad > > behaviour in errorhandling (when unbalanced the compiler errors on

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

On Sat, Jul 6, 2019 at 9:10 AM Ryan Joseph wrote: > Btw, here is the "Illegal expression” error which I mentioned before but > lost track of. > > == > > {$mode objfpc} > > program test; > > const lines: ansistring = ` > #version 150 > > uniform sampler2D textures[8]; > in vec2 verte

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

On 06/07/2019 14:56, Martok wrote: > Am 06.07.2019 um 09:01 schrieb Ondrej Pokorny: >> Ord(aEnum) for invalid enumeration values is undefined ;) > > If there was any logic here, it should be, but it's not ;-) > > The documentation page specifically mentions Ord as the older syntax to hard > casts

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 6, 2019, at 8:07 AM, Ben Grasset wrote: > > Everything he was talking about was clearly based on fundamentally not > understanding the basic differences between things like "const SomeString: > String = " and "var SomeString: AnsiString = ", and assuming that they were > somehow *su

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

Am 06.07.2019 um 09:01 schrieb Ondrej Pokorny: > Ord(aEnum) for invalid enumeration values is undefined ;) If there was any logic here, it should be, but it's not ;-) The documentation page specifically mentions Ord as the older syntax to hard casts. Whatever it contains, any enum is always small

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

General question regarding the tests I'm writing: What kind of numbers should I be going for? Is something like 10 that pass and 10 that fail a good ratio? Or should it be more of them that pass? Also, is using the names "tmultilinestrings1.pp", "tmultilinestrings2.pp", e.t.c. appropriate? __

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

On Sat, Jul 6, 2019 at 8:07 AM Ben Grasset wrote: > On Sat, Jul 6, 2019 at 1:34 AM Tomas Hajny wrote: > >> Have you tested command-line compilation with a CR-only source file? >> Since this is what he mentioned to be using (because being on a Mac)... >> There may be some difference on the scanne

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

On Sat, Jul 6, 2019 at 1:34 AM Tomas Hajny wrote: > Have you tested command-line compilation with a CR-only source file? > Since this is what he mentioned to be using (because being on a Mac)... > There may be some difference on the scanner side in theory... > I have. It works fine, because of c

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

On Sat, 6 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 22:44, J. Gareth Moreton wrote: 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 wo

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

On 05.07.2019 22:44, J. Gareth Moreton wrote: 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.

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

On 06.07.2019 02:10, Martok wrote: In that case, unlike what was previously said in this thread, this should simply work: generic function TStreamHelper.ReadEnum(out aEnum: T): Boolean; begin if Read(aEnum, SizeOf(aEnum)) <> SizeOf(aEnum) then Exit(False) else begin Result := (Or