Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Fri, Jan 14, 2022 at 5:49 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > No, it's not, because in linux I tested "make -j24 all" in the compiler > directory > That isn't what you said in your original comment about benchmarking on Linux. You specified "make cycle",

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Fri, Jan 14, 2022 at 11:09 AM Ben Grasset wrote: > It was the SEH MinGW-w64 based GCC 11.2 that MSYS2 provides through their > Windows version of pacman. > Also, more accurately, I should have said before that the *precision *of "long double" is 80-bit and equivalent

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Fri, Jan 14, 2022 at 10:46 AM Marco van de Voort via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Did you test a windows gcc (win64 SEH) or a SJLJ "posix" (basically > unported Unix) gcc ? > It was the SEH MinGW-w64 based GCC 11.2 that MSYS2 provides through their Windows version of

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Fri, Jan 14, 2022 at 1:33 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > So Delphi went the same way as we did. > I'd say Delphi imitating MSVC is sort of to be expected though, whereas *usually *FPC makes similar choices to GCC.

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Fri, Jan 14, 2022 at 1:27 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > (though to be fair it does the same on 32-bit as well) > Yeah, MSVC (for some reason) universally defines "long double" as exactly an alias for regular 64-bit double, whereas GCC and Clang (more

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 11:38 PM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > For the record, I did try make cycle for ppc386 and ppcx64 on my Windows > 10 (with Windows Defender turned on) and both finished in exactly 42 > seconds :) > Not surprising that you closed

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 9:20 AM Travis Siegel via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I wasn't aware of the whole MS not supporting the FPU thing, that was > the missing puzzle piece. > It's not a realistic concern in actuality. There's a reason almost every other compiler just

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 10:18 PM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Just for the record, is this with antivirus off or on and which antivirus > program? > I have no anti-virus actively installed or enabled on an ongoing basis at all. I just occasionally do

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 9:48 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > What do other win64 compilers do? Do they generate x87 FPU code for 64-bit > Windows? > Yes. Given the following: #include long double do_three(long double x, long double y, long double z)

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 11:28 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > So, instead of giving actual benchmark data on the Windows performance, > you speculate by claiming that having faster exception handling matters, > and then you immediately debunk your own

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 3:28 AM Alexander Grotewohl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 32bit on Windows 64-bit uses Wow64.. which has a bit of overhead as an > emulation layer. I believe it's the same one they use for ARM64 too. > It should be kept in mind also that neither

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I haven't tested in Windows, but it would be very strange and suspicious > if the results are very different. > It would be neither of those things. The exception handling on x64 Windows is

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Thu, Jan 13, 2022 at 1:25 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > We do care about scientific code as well as fast code, that's why we > support both the FPU and SSE2+ (as well as AVX, etc.). > FPC *chooses *not to generate x87 FPU instructions on 64-bit

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

It does work on 64-bit Windows, it's just technically deprecated. Beyond that, the 80-bit Extended type dates back to the mid 1980s, and ran on a particular part of the processor (the FPU, or Floating Point Unit), in such a way that it was able to provide a somewhat higher amount of precision

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Wed, Jan 12, 2022 at 8:08 AM Bart via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > It provides 32-bit fpc (so it builds for 32-bit windows by default) > and the win32->win64 crosscompiler in a single installer. > In Lazarus that means that you can target Win32 (default) and Win64 >

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Wed, Jan 12, 2022 at 7:38 AM Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > The downloads provided by Lazarus are also NOT a "pure, native 64-bit > download". Only the "fpc.exe" and the non-cross "ppc64.exe" are native > 64 bit. > > As I said, I do not know, what is

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

://sourceforge.net/projects/freepascal/files/Linux/3.2.2/ but in some way bad to add one more to the windows files directory on the Sourceforge page. On Wed, Jan 12, 2022 at 5:32 AM Ben Grasset wrote: > On Sun, Dec 19, 2021 at 3:46 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.o

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On Sun, Dec 19, 2021 at 3:46 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Ben Grasset via fpc-devel schrieb am > So., 19. Dez. 2021, 08:33: > >> To be very clear, to me, this is absolutely nothing more than just a >> matter of building the c

[fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC web

To be very clear, to me, this is absolutely nothing more than just a matter of building the compiler completely normally. It takes like two minutes all-in. I don't really get why the person who uploads the 32-bit Windows builds currently doesn't just also upload 64-bit ones. They could even just

[fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Was browsing on the FPC wiki (that is, the actual wikipedia.com entry for FPC) today, and came across an edit someone had made in the "3.2.0" section that said the following: "FreePascal cannot be installed on macOS Catalina, and no known workaround exists." It then linked to an open issue on

Re: [fpc-devel] What exactly are the differences in what each of the "-Cp", "-Cf", and "-Op" command line flags enable as far as optimizations?

particular value (I think at least "CoreI"). > > When vectorisation starts making a proper appearance in the compiler, I'll > be very likely developing optimisations for fused multiply-add (FMA), which > only came about after AVX. > > Gareth aka. Kit > On 08/09/2020 00

[fpc-devel] What exactly are the differences in what each of the "-Cp", "-Cf", and "-Op" command line flags enable as far as optimizations?

For example, a valid FPC command line would be: fpc -O3 -CfAVX2 -CpCOREAVX2 -OpCOREAVX2 file.pas To what extent is each of those flags enabling the generation of AVX2 instructions? Are they all necessary, or does their functionality overlap to some degree? Which is most important?

Re: [fpc-devel] New feature announcement: constant parameters for generics

On Sun, Apr 26, 2020 at 4:08 AM Anthony Walter via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Thank you Ryan and Sven. Your work is much appreciated as usual. > > However, Michael beat me to it in asking how this feature is useful. I am > sure there might be use cases, but for right now

Re: [fpc-devel] New feature announcement: constant parameters for generics

On Sat, Apr 25, 2020 at 6:14 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The Free Pascal team is happy to announce the addition of a new language > feature: constant parameters for generics. > YES! This is fantastic news. ___

[fpc-devel] Looking for insight on the current status (or rather, non-status) of the {$CLASSESINLINE} define

It's not clear to me how many people are specifically aware of this, but as it stands currently, each and every instance of the "inline" modifier in the Classes unit is hidden behind a CLASSESINLINE define. Unlike the SYSTEMINLINE and MATHINLINE defines (which are always set automatically

Re: [fpc-devel] Object upgrades

On Mon, Jun 10, 2019 at 3:31 PM Ryan Joseph wrote: > Sorry, if I dereference the size is still of TBase. I don’t think “result" > is actually changing depending on the class type. This may have something > to do with the way new works though. How can we fix this? > It's because Initialize isn't

Re: [fpc-devel] Thank you!

On Sat, Nov 23, 2019 at 6:44 AM J. Gareth Moreton wrote: > So once > again, thank you everyone, and I hope to continue contributing for a > while yet! > Us users would say the same in reverse for your various improvements! ___ fpc-devel maillist -

Re: [fpc-devel] inline... and philosophy

On Fri, Nov 8, 2019 at 10:02 AM J. Gareth Moreton wrote: > I guess that's the consequence of Microsoft Visual C++ having such a large > market share. > I mean, GCC is far more widely used than MSVC (and actually generates rather smaller binaries usually.) Also the Clang version of the MS

Re: [fpc-devel] inline... and philosophy

On Fri, Nov 8, 2019 at 8:28 AM J. Gareth Moreton wrote: > The large binary sizes feel like an elephant > in the room that no-one talks about. > Relatively speaking, FPC actually does very well as far as binary size for a language that specifically aims to have robust RTTI functionality. C++

Re: [fpc-devel] Question on updating FPC packages

On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt wrote: > Saying that the code is 'almost unusably slow' is the kind of statement > that does > not help. I use the code almost daily in production, no complaints about > performance, so clearly it is usable. > > Instead, demonstrate your claim

Re: [fpc-devel] Question on updating FPC packages

On Sat, Oct 26, 2019 at 1:31 PM Florian Klämpfl wrote: > This is imo a waste of time and clutters only code. It is much more > beneficial to > improve the compiler to avoid a copying of the variable if it can prove > that it is not needed (or to improve auto inlining.) > While I absolutely

Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139

On Sun, Oct 13, 2019 at 3:43 AM Jonas Maebe wrote: > The snippet came from the compiled program. It showed that the "while > true do ;" infinite loop got removed by the peephole optimiser (as also > mentioned by Martin). That was wrong. The peephole optimiser does not > perform any dead code

[fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139

I guess this doesn't matter too much in the grand scheme of things, but I'm somewhat confused by it, so I thought I'd ask. Specifically, the reporter of that issue, calling themselves "Alexander", used the following program as an "example" of what they called "too aggressive optimization":

Re: [fpc-devel] multi-line strings

On Mon, Oct 7, 2019 at 1:51 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The code changes themselves are okay and that was all I promised to > review. The problem is I personally don't care about the feature, so other > core devs should give their okay for the feature

Re: [fpc-devel] multi-line strings

On Sat, Oct 5, 2019 at 1:37 PM Ryan Joseph wrote: > I can’t remember what Bens patch did using compiler directives but I like > the Java idea of using the column of the opening string character as the > reference point for indentation. Seems easier. > > Did the FPC team even approve this idea

Re: [fpc-devel] i386-linux switched to a 16 byte aligned stack

On Sun, Sep 15, 2019 at 1:36 PM Florian Klämpfl wrote: > In r43005 to 43014 I committed a couple of patches so FPC generates > stack frames aligned to 16 byte boundaries on i386-linux > Good change! Means, for example, the long-standing issues with popular libraries like SDL2 on 32-bit Linux

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:03 AM Ben Grasset wrote: > 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

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

On Tue, Jul 16, 2019 at 8:35 AM Michael Van Canneyt wrote: > 2. The Low(T) does not work, as there is no way to tell Delphi that T must > be an enum. > Hmm, I guess it makes sense Delphi wouldn't allow the "Low", based on other Delphi generics behavior (more like C#, whereas FPC is more like

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

On Tue, Jul 16, 2019 at 5:28 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The output will then be two different addresses, thus showing that the > code had been generated twice. > > However the compiler/linker is good at leaving out unused code and in this > case only

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

On Mon, Jul 15, 2019 at 5:50 PM Michael Van Canneyt wrote: > As far as I know, they are not. I believe that when specializing, the > compiler checks if an identical specialization is in scope: > if so, it uses that. If not, a duplicate is made. > > As far as I know, Delphi behaves the same. > >

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

On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > That is exactly what is happening if you have a specialization in multiple > units that don't know about each other. > At what point are they being removed so that the executable is not comically

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

On Sat, Jul 13, 2019 at 9:02 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Not necessarily. If you have two units that don't know about each other > that specialize the function with the same enum then you'd have two > specializations already. > Surely that only applies

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

On Sat, Jul 13, 2019 at 3:59 PM Michael Van Canneyt wrote: > Yes, I know. But the goal is to have 'is/as'. Then there is at best only 1 > helper > function for all enumerateds. > Oh yeah, I wasn't really suggesting a generic function as a *solution* to the problem versus "is" and "as". I was

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

On Sat, Jul 13, 2019 at 3:47 PM Michael Van Canneyt wrote: > No doubt, but this will lead to a bloated binary. I want less code (both > source and assembler), not more. > Well, it would be one instantiation per unique type it was used on. So if you had five hand-written helper functions for

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

On Sat, Jul 13, 2019 at 2:37 PM Ondrej Pokorny wrote: > I do exactly the same - check the low/high bounds in a type helper :) > Yes, and I am tired of typing it as well :) > You can pretty easily write a generic function that will work on pretty much any enum for this, BTW: program Example;

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

Alright, I've now submitted this as a patch on the bug tracker: https://bugs.freepascal.org/view.php?id=35827 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

On Wed, Jul 10, 2019 at 12:51 PM Ryan Joseph wrote: > Excellent, I have an immediate use for this just today. Hopefully it’s > small enough it can get merged without waiting for months. ;) > Hopefully! I'll keep my branch up to date with trunk regardless, though.

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

Ok, I think I'm getting close to being ready to open a formal issue on the bug tracker for this feature (will probably do so later today), however, I first wanted to clarify: Is it preferable if I upload two separate patch files, one containing the actual changes to the compiler sources, and one

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 5:40 PM Ryan Joseph wrote: > I’m not sure if it’s a bug or not so I’ll wait for the compiler teams > response and I don’t care either way, I just want constref to work. :) > I looked into this some more, and it's almost certainly completely intentional behavior as Delphi

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 5:40 PM Ryan Joseph wrote: > I just want constref to work. :) > Pretty sure taking "vs_constref" out of the set here in defcmp.pas would do it.

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 4:18 PM Ryan Joseph wrote: > it goes against the idea of properties anyways. > I don't know if I completely agree with this part in a general sense. There's plenty of perfectly valid uses for properties that are nothing like the straightforward "make something act like an

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 3:17 PM Ryan Joseph wrote: > Please post an example of the var/out bug if you don’t mind. Just to be > sure. > I don't know if it necessarily *is* a bug. It would definitely be if it worked with literals as input, which is the impression I had based on what someone

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 2:58 PM Ryan Joseph wrote: > Ok, I'm confused now. I thought that var/out were accepted but I just > tested myself and indeed they are rejected. > Well, they *are* accepted for things that would normally be valid with "var" and "out" in other scenarios (by which I mean,

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 12:59 PM Ben Grasset wrote: > On Tue, Jul 9, 2019 at 12:32 PM Ryan Joseph wrote: > >> So do I need to open another bug report for for this out/var/constref >> stuff? We already have https://bugs.freepascal.org/view.php?id=28949 but >> that’s ju

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 12:32 PM Ryan Joseph wrote: > So do I need to open another bug report for for this out/var/constref > stuff? We already have https://bugs.freepascal.org/view.php?id=28949 but > that’s just about the overloading bugs. > > I think it needs to be something like var/out should

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 12:11 PM Ryan Joseph wrote: > Why does that require a special switch? Also, I thought it was determined > that allowed “out” in array properties was a bug? > Not sure about the exact history of VARPROPSETTER. It's an old Delphi thing, rarely used nowadays though. As far

Re: [fpc-devel] [] property overloads

On Tue, Jul 9, 2019 at 9:39 AM Ryan Joseph wrote: > Another thing regarding array properties. If I use constref on the setter > I get an error "Illegal symbol for property access”. Is there any reason > why the setter can’t be constref? > It works for constref if you use {$VARPROPSETTER ON}.

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

Ok, after thinking about it for a bit, I decided to go ahead and implement the "customizable leading whitespace" thing right away, as a lot of people seemed to want it, and also because I just realized that it would not be difficult at all to do. So, that said, my Github fork branch

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 3:47 PM Ben Grasset wrote: > On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph wrote: > >> and it will actually write to the actual record in the array and not a >> returned copy. However due to how the properties are currently structured >> this means

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph wrote: > and it will actually write to the actual record in the array and not a > returned copy. However due to how the properties are currently structured > this means we can’t use the setter without passing pointers > Ah, I see what you mean. Note

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 12:04 PM Ryan Joseph wrote: > There actually is a need to distinguish between getters/setters but the > way property syntax works we’re forced for the return type to be the same > as the input for the setter. This is a problem I faced before where I want > the getter 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 Mon, Jul 8, 2019 at 8:51 AM Ben Grasset wrote: > I'm probably not gonna be working on that myself any time soon, but > certainly yeah I think that IncludeString has an equal amount of value as a > feature, and would compliment multi-line strings well. > Hmm, perhaps I sp

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

On Mon, Jul 8, 2019 at 12:27 AM J. Gareth Moreton wrote: > Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing > alongside it, because things like shaders are programs in themselves and > may have to be tested in a third-party application, so including the > file directly rather

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

Neat bit of trivia: Multi line strings even work properly with Ryan's (Ryan Joseph that is) very-cool-but-not-yet-merged-to-trunk generic constants patch. With a build of FPC that includes both, you can do some really interesting stuff: program

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

On Sun, Jul 7, 2019 at 4:20 AM Tomas Hajny wrote: > - snip - > These are all good points! Thanks for the feedback. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

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 wha

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

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] 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

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

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 specifica

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

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 ha

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,

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

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

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

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)... >> Ther

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

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.

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 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 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”.\ >>

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] 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 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 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

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

multi-line strings, and they all do work. On Fri, Jul 5, 2019 at 6:41 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 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 ei

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

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 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] 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.

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 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 o

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

  1   2   3   >