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

Marco van de Voort schrieb am Do., 4. Juli 2019, 16:26: > > Op 2019-07-04 om 16:25 schreef Ben Grasset: > > On Thu, Jul 4, 2019 at 10:09 AM Marco van de Voort > > mailto:f...@pascalprogramming.org>> wrote: > > > > You clearly didn't read the message fully. It is not about > >

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

Ben Grasset schrieb am Mi., 3. Juli 2019, 18:00: > On Tue, Jul 2, 2019 at 7:38 PM Ondrej Pokorny wrote: > >> A good real-word example is the cast from a pointer: >> >> program Project1; >> uses Classes; >> var >>Value: TPersistent; >>P: Pointer; >> begin >>P := TObject.Create; >>

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 >

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

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 th

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

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

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.

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

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.

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

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

Michael Van Canneyt schrieb am Do., 4. Juli 2019, 13:54: > > > On Thu, 4 Jul 2019, Tomas Hajny wrote: > > > On 2019-07-04 12:59, Marģers . via fpc-devel wrote: > > > > . > > . > >> Why introduce ` if there already is ' ? Just use ' > >> as well for multi line strings. For people of more > >>

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

Marco van de Voort schrieb am Do., 4. Juli 2019, 12:00: > > Op 2019-07-04 om 07:34 schreef Sven Barth via fpc-devel: > > > >>> But the main question is: do we actually want a multiline string ? > >>> As far as I am concerned, that question needs to be an

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Am 27.06.2019 um 20:40 schrieb Ryan Joseph: As an side since you’re talking about optimizations what would it take to make the copy/addref record operators be inline? Unless I’m mistaken that’s one of the bigger issues that makes custom ref counted objects slower than built in compiler types.

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Ryan Joseph schrieb am Do., 27. Juni 2019, 23:50: > > > > On Jun 27, 2019, at 3:09 PM, Martin wrote: > > > > The below compiles, and writes > > 1 2 > > > > Are indexes to properties intentionally allowed to take "var param"? > > Btw it even compiles with an "out" param. > > That sounds like a

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 28.06.2019 um 00:00 schrieb Ryan Joseph: On Jun 27, 2019, at 5:57 PM, Sven Barth via fpc-devel wrote: If it's a bug (what I do indeed think of this and the other bug you mentioned) it's considered acceptable to break backwards compatibility. After all we wouldn't be able to fix

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

George Bakhtadze schrieb am Fr., 28. Juni 2019, 08:26: > Hello, > > > One thing I have been considering is to promote fields and global > variables to local registers to reduce memory accesses. > > That would be great. But multithreaded code which assume (incorrectly) > that those fields and

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 27.06.2019 um 21:09 schrieb Martin: The below compiles, and writes 1 2 Are indexes to properties intentionally allowed to take "var param"? Btw it even compiles with an "out" param. program Project1; type   { TFoo }   TFoo = class   private     function GetFoo(var AIndex: Integer):

Re: [fpc-devel] Deeper problem with Internal Error 200309201

Am 13.07.2019 um 14:12 schrieb J. Gareth Moreton: I would like some discussion on this with the administrative team because this does require some careful design if we're going to do this properly.  Building on Florian's suggestion, I would like to propose splitting "pass_1" into "pass_syntax"

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

Ben Grasset schrieb am Sa., 13. Juli 2019, 21:52: > On Sat, Jul 13, 2019 at 3:47 PM Michael Van Canneyt < > mich...@freepascal.org> 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

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

Am 14.07.2019 um 04:08 schrieb J. Gareth Moreton: Just a thought that I'd chuck in on this... I did wonder how practical it would be to store checksums of all compiled procedures and the like and to look for collisions.  When studying how the compiler is built, I noticed a lot of the

Re: [fpc-devel] Deeper problem with Internal Error 200309201

Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: On another note, I do think pass_2 (pass_generate_code) could use some refactoring.  I don't like how "flowcontrol" is a global variable.  Though it's unlikely to happen, such a state variable not being tied to a management object (e.g.

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

J. Gareth Moreton schrieb am Di., 9. Juli 2019, 08:20: > Apologies - I see now... I used them with "with" without even thinking > about it! I've made the changes as requested. Admittedly it's quite > hard for me to remove spaces from either side of operators because > that's something I learnt

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

Sven Barth schrieb am Di., 9. Juli 2019, 07:41: > Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: > > On an extra note, the assembly language produced is not yet optimal, > > so it may end up that an x86-specific implementation will be > > beneficial. TIsNode contains a virtual method named >

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

Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: On an extra note, the assembly language produced is not yet optimal, so it may end up that an x86-specific implementation will be beneficial.  TIsNode contains a virtual method named "DoVariableEnumCheck" that would allow such an extension,

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Di., 9. Juli 2019, 15:39: > 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? If not I’d like to change this with my > array properties

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

Am 03.07.2019 um 22:20 schrieb Ben Grasset: On Wed, Jul 3, 2019 at 3:27 PM gabor > wrote: I am also against this program Example; (*   This is a perfectly   normal multi-line   Pascal comment. *) const SA = `   This is a multiline   string using hypothetical

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

Am 03.07.2019 um 20:55 schrieb Ryan Joseph: On Jul 3, 2019, at 2:43 PM, Michael Van Canneyt wrote: There is also still: https://bugs.freepascal.org/view.php?id=25536 What does this do and why has it been sitting there since 2014 if it’s useful? There are also still open questions regarding

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 30.06.2019 um 00:02 schrieb Martin Frb: However this works: === code begin === function GetFoo(AIndex: Integer; BIndex: Integer = 0): Integer; property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read GetFoo; Ouch What then about   function GetFoo(AIndex: Integer = 0): Integer;  

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 28.06.2019 um 10:39 schrieb Martin Frb: On 28/06/2019 07:39, Sven Barth via fpc-devel wrote: Am 27.06.2019 um 21:09 schrieb Martin:   { TFoo }   TFoo = class   private     function GetFoo(var AIndex: Integer): Integer;   public     property Foo[var AIndex: Integer]: Integer read GetFoo

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 16:10: > I just encountered something to consider. Should a property be > overloadable if the names/args are the same but the return type is > different? I think if they are not the same access type (i.e. read/write) > then it could work (not sure about

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 18:04: > > > > On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > As Pascal does not allow differentiating between result types this > indeed needs to be/st

Re: [fpc-devel] WideString vs UnicodeString / len in char vs byte / *nix vs windows

Am 25.04.2019 um 15:41 schrieb Martin: Looking at https://bugs.freepascal.org/view.php?id=35359 and the latest comments (see end of mail) Is it correct, that "widestring" here has 2 meanings? - the "widestring" that has length in bytes (windows bstr) - "widestring" as a typename / alias And

Re: [fpc-devel] Operator overloading and {$mode delphi}

Am 14.04.2019 um 17:21 schrieb Bart: On Sun, Apr 14, 2019 at 8:26 AM Michael Van Canneyt wrote: I added a table with the delphi operator names, mentioned that they can be used in operator definitions, but that they must be used in Delphi mode. If I understand the delphi documentation

Re: [fpc-devel] "inline" issue

Am 23.04.2019 um 16:33 schrieb Marco van de Voort: Op 4/23/2019 om 4:31 PM schreef J. Gareth Moreton: I should ask actually... what's Delphi's support on 'inline' appearing just in the implementation section? My guess: only inline locally in the implemenation, iow the function is exported

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

Michael Van Canneyt schrieb am Mo., 15. Juli 2019, 23:50: > > > On Mon, 15 Jul 2019, Ben Grasset wrote: > > > On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < > > fpc-devel@lists.freepascal.org> wrote: > > > >> That is exactly w

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

Ben Grasset schrieb am Di., 16. Juli 2019, 00:13: > On Mon, Jul 15, 2019 at 5:50 PM Michael Van Canneyt < > mich...@freepascal.org> 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

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

Ben Grasset schrieb am Mo., 15. Juli 2019, 23:48: > 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

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

Michael Van Canneyt schrieb am Di., 16. Juli 2019, 16:31: > > > On Tue, 16 Jul 2019, Ben Grasset wrote: > > > On Tue, Jul 16, 2019 at 5:28 AM Sven Barth via fpc-devel < > > fpc-devel@lists.freepascal.org> wrote: > > > >> The output will

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

J. Gareth Moreton schrieb am Do., 27. Juni 2019, 12:18: > One thing I have been considering is to promote fields and global > variables to local registers to reduce memory accesses. However, it would > make multi-threaded code a bit trickier to write and demand the use of the > "volatile"

[fpc-devel] State of i8086-embedded

Hello together! For a project at work I need to run 16-bit x86 code on a bare x86 hardware (more precisely a 8086 VM). Considering that i8086-embedded had been added to FPC nearly exactly 3 years ago I though I'd give it a try and cross compiled the units for the tiny memory model. However

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Ryan Joseph schrieb am Fr., 28. Juni 2019, 20:12: > > > > On Jun 28, 2019, at 1:39 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > I just tested with Delphi and it works there as well. So contrary to > what we thought this does

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

George Bakhtadze schrieb am Sa., 29. Juni 2019, 09:32: > > > This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen > and FPC's LLVM backend the assumption is incorrect which can be seen by > them having added "volatile" mechanisms. > > > I believe this assumption incorrect

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Florian Klaempfl schrieb am Sa., 29. Juni 2019, 15:52: > Am 28.06.2019 um 11:24 schrieb George Bakhtadze: > > This assumption is *not* incorrect. Only on the LLVM based Delphi > > NewGen and FPC's LLVM backend the assumption is incorrect which can > > be seen by them having added

Re: [fpc-devel] Streamlining TVMTBuilder.generate_vmt after r41716 & r41884

Am 02.08.2019 um 21:27 schrieb bla...@blaise.ru: On 02.08.2019 21:36, bla...@blaise.ru wrote: embed a copy of the body of insert_struct_hidden_paras into TVMTBuilder.generate_vmt, then merge those two procdef-member traversals into one (hey, performance!) Would you guys oppose such a change?

Re: [fpc-devel] Scoped VMTDefs

Am 03.08.2019 um 15:54 schrieb bla...@blaise.ru: Before the main course, I offer the attached refactorings for trecorddef.create_global_internal: 1) streamline insertions into the symtable; Applied in r42652 2) avoid shadow-copying of the parameter "n", which is now const Applied in

Re: [fpc-devel] Streamlining TVMTBuilder.generate_vmt after r41716 & r41884

Am 02.08.2019 um 21:27 schrieb bla...@blaise.ru: On 02.08.2019 21:36, bla...@blaise.ru wrote: embed a copy of the body of insert_struct_hidden_paras into TVMTBuilder.generate_vmt, then merge those two procdef-member traversals into one (hey, performance!) Would you guys oppose such a change?

Re: [fpc-devel] Minor debate with ISO standard on case blocks

thaddy schrieb am Di., 30. Juli 2019, 10:04: > On 2019-07-30 01:43, J. Gareth Moreton wrote: > > As someone on the issue pointed out... on page 2, section 3.1: > > > > 3.1 Error > > > I have added this to the bug report. Consider that here all possible > case labels are implemented, the compiler

Re: [fpc-devel] Submitting patches using git

Am 20.07.2019 um 18:58 schrieb Ryan Joseph: 3) remove .gitignore (which now includes thousands of .o/.ppu files which need to be deleted) and any other unrelated personal files. Why is your .gitignore so big? Mine looks like this: === file begin === # ignore binary files *.o *.ppu *.exe

Re: [fpc-devel] Submitting patches using git

Am 20.07.2019 um 22:29 schrieb Ryan Joseph: On Jul 20, 2019, at 4:19 PM, Sven Barth via fpc-devel wrote: Why is your .gitignore so big? Mine looks like this: I’m sorry, what I wrote didn’t make any sense. I mean that after I delete .gitignore then all the .o etc.. files

Re: [fpc-devel] Property attributes support

Ondrej Pokorny schrieb am Sa., 20. Juli 2019, 12:04: > Hello! > > I saw that Sven committed property attributes support in trunk. Thank > you for this! > > Is there any documentation how to use them? (Syntax, reading information > during runtime etc?) I only found very old information: >

Re: [fpc-devel] Property attributes support

Am 20.07.2019 um 18:38 schrieb Ondrej Pokorny: The old Wiki page should propably be updated to reflect the current state of affairs... I deleted the old information (nearly everything) and put a link to the new Wiki page there. Probably for the best ;) You can also take a look at Delphi

Re: [fpc-devel] Submitting patches using git

Am 20.07.2019 um 23:18 schrieb Martin Frb: On 20/07/2019 23:13, Sven Barth via fpc-devel wrote: For example I myself don't commit my .gitignore, but simply have it lying around as untracked file. Try .git/info/exclude https://git-scm.com/docs/gitignore Nice! :D Regards, Sven

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

Ben Grasset schrieb am Mo., 15. Juli 2019, 22:57: > 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 th

Re: [fpc-devel] Return to pure functions!

Am 19.09.2019 um 20:25 schrieb J. Gareth Moreton: One thing I've fallen foul of is how to track variables in what will become the 'node parser' that the compiler will use to evaluate pure functions to calculate their return values.  Because a variable can be anything, I was planning on using

Re: [fpc-devel] Case else allows multiple statements

Am 19.09.2019 um 21:07 schrieb Kirinn: I've stumbled on a situation where a case statement compiles when I wouldn't expect it to. I would expect the below code to produce a compile error:     program test;     var i : byte = 5;     begin     case i of     0..4: writeln('value

Re: [fpc-devel] Windows 32bit - FPC 3.0.4 Gets an Error - but not on Linux or Mac...

Ozz Nixon schrieb am Sa., 28. Sep. 2019, 22:53: > It's a CDECL thing... :-( > > Disabled Using_CDECL, and now the pointer passes to/from the imported > functions. (Florian/Jonas/Michael - is this an expected issue on Windows?) > It would help if you'd provide a self contained example that

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

Am 04.07.2019 um 00:08 schrieb Ben Grasset: On Wed, Jul 3, 2019 at 5:48 PM Sven Barth via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> wrote: I'm with Michael here: I see no *need* for a separate syntax for a multi line string.  I don't really think the suggested bac

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

Am 04.07.2019 um 02:09 schrieb Martin Frb: On 04/07/2019 01:57, J. Gareth Moreton wrote:  Also, with the backtick suggestion, what should one do if they wish to include a control character (e.g. a linefeed) or the backtick character itself? answer := `Well, this for ``inline`` backticks

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

Am 04.07.2019 um 01:00 schrieb Marco van de Voort: Op 2019-07-03 om 20:43 schreef Michael Van Canneyt: But the main question is: do we actually want a multiline string ? As far as I am concerned, that question needs to be answered first, and for me personally the answer to that is still 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 04.07.2019 um 00:21 schrieb Ryan Joseph: On Jul 3, 2019, at 5:48 PM, Sven Barth via fpc-devel wrote: In case case of readability: most cases of multi line string constants are likely to be embedded scripts (shaders, SQL, whatever) and thus the $INCLUDESTRING directive mentioned

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

Am 04.07.2019 um 01:57 schrieb J. Gareth Moreton: While I like the idea in principle, one thing that I'm a bit worried about is how whitespace is handled, like what counts for a leading or trailing space in the string when between lines, since Pascal parsers (and those for many other

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

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

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

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

J. Gareth Moreton schrieb am Sa., 9. Nov. 2019, 16:20: > > On 09/11/2019 15:14, Michael Van Canneyt wrote: > > > > > > On Sat, 9 Nov 2019, J. Gareth Moreton wrote: > > > >> Competitions aside, there are times where space is a premium, whether > >> it be from distributing an application on a DVD,

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

Florian Klämpfl schrieb am Sa., 9. Nov. 2019, 20:45: > Am 09.11.19 um 20:26 schrieb Michael Van Canneyt: > > > > > > On Sat, 9 Nov 2019, Florian Klämpfl wrote: > > > >> Am 09.11.19 um 20:02 schrieb Michael Van Canneyt: > >>> > >>> > >>> On Sat, 9 Nov 2019, Florian Klämpfl wrote: > >>> > >

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

J. Gareth Moreton schrieb am Fr., 8. Nov. 2019, 14:28: > > On 08/11/2019 13:14, Sven Barth via fpc-devel wrote: > > ... > > What's stopping that? Simple: no driving need. It's just work for > > something that has essentially no gain. > > No gain? Wow,

Re: [fpc-devel] Optimizer Overhaul Take 2... Jump Optimizations

Am 31.10.2019 um 05:57 schrieb J. Gareth Moreton: One thing I do need to do is to cross-compile to all known platforms... I can only test a handful of the i386 and x86_64 platforms, but I want to at least see if it compiles before I submit the patch for more thorough testing.  Does anyone have

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

J. Gareth Moreton schrieb am Fr., 8. Nov. 2019, 11:20: > > On 08/11/2019 09:49, Sven Barth via fpc-devel wrote: > > ... > > The compiler is compiled multiple times anyway when bootstrapping and > > the need for the scripting there is not only the WPO, but the repeate

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

J. Gareth Moreton schrieb am Fr., 8. Nov. 2019, 04:01: > Speaking of whole program optimisation, it always seems very fiddly to > set up, to the point that the FPC bootstrapper needs a script to get it > working. Not exactly user-friendly and practically demands learning a > separate skill to

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

J. Gareth Moreton schrieb am So., 10. Nov. 2019, 03:23: > Does the smart linker strip out LCL components that are not used, or must > everything that's registered in a package or unit be included? Granted, > since forms are being read from a resource file, I doubt it can really be > tied into

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

Am 10.11.2019 um 15:47 schrieb Marco van de Voort: (and btw, if you are serious about these scenarios, drop all optimization work immediately, and start working on packages :-) I don't know if that would help much, cause especially on Windows every application would probably provide its own set

Re: [fpc-devel] dyn packages [[was: Re: inline... and philosophy]]

Martin schrieb am Fr., 22. Nov. 2019, 19:29: > On 21/11/2019 22:56, Sven Barth via fpc-devel wrote: > > In the meantime I've managed to fix the dynamic package support that > > had experienced a bit of bit rot in the last years. Though I've > > currently only tested Win32 an

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

Am 10.11.2019 um 16:06 schrieb Michael Van Canneyt: On Sun, 10 Nov 2019, J. Gareth Moreton wrote: This message chain has proven to be a lot more educational and insightful than I would have given it credit for.  Thanks everybody! I know a lot of the time, the size of binaries is just an

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Ryan Joseph via fpc-devel schrieb am Di., 10. Dez. 2019, 22:29: > > > > On Dec 10, 2019, at 11:38 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > First of Object Pascal supports "array of const" which is safer

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 12.12.2019 um 23:24 schrieb Ryan Joseph via fpc-devel: On Dec 12, 2019, at 11:13 AM, Martin Frb wrote: I brought an example, where actually the "drop [] for last param" would break code. Therefore it no longer matters if it is or is not against good design. Dropping the [], (in the new

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

Am 16.12.2019 um 23:08 schrieb Marco van de Voort: Op 2019-11-21 om 22:56 schreef Sven Barth via fpc-devel: In the meantime I've managed to fix the dynamic package support that had experienced a bit of bit rot in the last years. Though I've currently only tested Win32 and Win64 (x86_64-linux

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Michael Van Canneyt schrieb am Do., 12. Dez. 2019, 15:34: > > It was already mentioned, that the [] can be dropped if the array has > > *exactly one* element. > > Not sure what you mean here, but even if there is only 1 argument, today > the [] cannot be dropped: > > home:~> cat tf.pp > program

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru: On 08.12.2019 22:30, Sven Barth wrote: there is no official way to access such parameters 1) At the time of providing that answer on Stack Overflow, Barry Kelly worked as a DCC developer. While it is not truly official, it is pretty close,

Re: [fpc-devel] Object/Pointer Swap Intrinsic

Am 11.12.2019 um 07:26 schrieb J. Gareth Moreton: Hi everyone, I was wondering... is there an intrinsic in Free Pascal that swaps the pointers stored in two object or pointer variables? That is... something like "procedure SwapAddresses(var Obj1: TObject; var Obj2: TObject);" so after it is

Re: [fpc-devel] Refactoring TVMTBuilder

Am 05.12.2019 um 13:48 schrieb bla...@blaise.ru: 1) Currently, the following snippet vmtbuilder:=TVMTBuilder.Create(...); vmtbuilder.generate_vmt; vmtbuilder.free; is present @ types_dec :objectdef generate_specialization_phase2 :objectdef jvm_maybe_create_enum_class    

Re: [fpc-devel] open array calling [[was: Re: C-block reference syntax (blocker for 3.2)]]

Am 12.12.2019 um 17:23 schrieb Michael Van Canneyt: On Thu, 12 Dec 2019, Martin Frb wrote: On 12/12/2019 17:14, Michael Van Canneyt wrote: On Thu, 12 Dec 2019, Sven Barth via fpc-devel wrote: For array of const it is not allowed, but any other open array parameter allows it. Really

Re: [fpc-devel] open array calling [[was: Re: C-block reference syntax (blocker for 3.2)]]

Am 12.12.2019 um 17:20 schrieb Martin Frb: On 12/12/2019 17:14, Michael Van Canneyt wrote: On Thu, 12 Dec 2019, Sven Barth via fpc-devel wrote: For array of const it is not allowed, but any other open array parameter allows it. Really, are you sure ? Since when is this allowed ? It works

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 10:28 schrieb Jonas Maebe: If there is a consensus that this is a blocker, I am ready to do the work ASAP. provided we select the syntax. Personally, I am inclined towards these three: type M = procedure (const N: Integer) with var; type M = procedure (const N:

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 01:00 schrieb bla...@blaise.ru: Beforehand, to provide a context, here are some excerpts from private correspondence: On 11.12.2016 22:00:37 +0300, bla...@blaise.ru wrote in 1c51a35a-bbbc-c99d-232f-0bf6529df...@blaise.ru: my progress thus far 9) Method reference directives

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 14:31 schrieb bla...@blaise.ru: your argument with VarArgs does not count either: one can not access VarArgs parameters inside a Delphi function (without resorting to assembly) Again, you are misinformed. I understand that you may not use DCC as much or at all, but you have

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru: @Jonas: Has the team decided on the amended syntax for C-block references? I am ready to start implementing whichever. In r43684 the syntax was now adjusted, so that an additional "cblock" directive is required (in addition to the calling

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Ryan Joseph via fpc-devel schrieb am So., 8. Dez. 2019, 23:26: > > > > On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > And no, your patch WILL NOT allow that. We've consciously decided > AGAINST implement

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 11.12.2019 um 23:40 schrieb Ryan Joseph via fpc-devel: On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt wrote: It does gain something: it tells you it is NOT a varargs, but an array of const, which is a different beast altogether. But it's a syntax equivalent for "a variable amount of

Re: [fpc-devel] Object/Pointer Swap Intrinsic

Am 12.12.2019 um 00:34 schrieb J. Gareth Moreton: That's true.  Given I specialise in optimisation, I've started to venture towards the node level to see where improvements can be made. One question I do have in that regard... are platform-specific nodes allowed? What I mean is, for example,

Re: [fpc-devel] Policy on reserving error numbers

J. Gareth Moreton schrieb am Sa., 19. Okt. 2019, 03:52: > Hi everyone, > > So I've run into a slight annoyance while developing support for pure > functions. The compiler will need new parser messages because of > situations such as specifying the 'pure' directive when something in > said

<    1   2   3   4   5   6   7   8   >