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

On Sat, 9 Nov 2019, J. Gareth Moreton wrote: I tend to think more size gains can be obtained from more aggressive smartlinking. The smartlinking is sometimes disabled by the way code is written. To give an example, pas2js has a switch to convert published to public sections. As a result, th

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

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, bandwidth or data limits (even some first world countries are still on dial-up in places, or are otherwise monopolised by a sing

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

On Sat, 9 Nov 2019, Marco van de Voort wrote: Seeking to reduce binary size (without sacrificing speed) and make as many optimisations as possible may be a fool's errand because the returns don't justify the costs, but I personally enjoy the challenge and puzzle-solving element of it.  I jus

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

On Sat, 9 Nov 2019, Jonas Maebe wrote: On 09/11/2019 13:29, Michael Van Canneyt wrote: When testing I converted the tests to the format suitable for my rtl testsuite, so they are run whenever I run that testsuite. They're even more useful if they can be run by anyone, and are automati

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

On Sat, 9 Nov 2019, Bart via fpc-devel wrote: On Sat, Nov 9, 2019 at 9:08 AM Michael Van Canneyt wrote: That is why I decided to keep it: the mode of sysutils is known and will never change. A user is supposed to take this into account. OK. This error was confirmed as a compiler bug

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

On Fri, 8 Nov 2019, Bart via fpc-devel wrote: 1. Minor issue. Defining the ranges TByteBitIndex will confuse users if they define a constant array with that range and then compile their program in either mode fpc or mode tp. I have something like: const Expected: array[TIntegerBitIndex] of I

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

On Tue, 29 Oct 2019, Ben Grasset wrote: 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

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

On Tue, 29 Oct 2019, J. Gareth Moreton wrote: Please note that only Marco's e-mails are making the list.  I don't see Michael's responses. That's probably because I am not responding ;-) Michael.___ fpc-devel maillist - fpc-devel@lists.freepasca

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

On Sun, 27 Oct 2019, Sven Barth via fpc-devel wrote: Michael Van Canneyt schrieb am So., 27. Okt. 2019, 10:58: Best of all would IMHO be to abolish or even totally ignore 'inline'. It is a hint, after all. The compiler is not forced to inline, even when the modifier is there.

Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

On Sun, 27 Oct 2019, Martok wrote: Am 27.10.2019 um 17:48 schrieb Florian Klämpfl: I guess the main difference is whether one prefers side-by-side diffs or udiffs. In particular partial commits as well as conflict resolution work much better with TortoiseGit for me. Oh yeah, conflict res

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

On Sun, 27 Oct 2019, J. Gareth Moreton wrote: I was more referring to the use of correct types, use const when possible etc. Change classes to advanced records where appropriate, that kind of thing. Michael. Which is why I hoped my patches for uComplex were permissible, since it adds 'c

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

On Sun, 27 Oct 2019, Florian Klämpfl wrote: Am 27.10.19 um 10:27 schrieb Michael Van Canneyt: If you genuinely believe that micro-optimization changes can make a difference: Submit patches. As said: I am against applying them. Why? They clutter code and after all, they make assumptions

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

On Sat, 26 Oct 2019, Ben Grasset wrote: 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

Re: [fpc-devel] invoke

On Tue, 22 Oct 2019, Sven Barth via fpc-devel wrote: Marco van de Voort schrieb am Di., 22. Okt. 2019, 13:13: https://forum.lazarus.freepascal.org/index.php/topic,47147.0/topicseen.html might be of interest to you despite the title :-) It is about invoke/tvirtualinterface But, but, but

Re: [fpc-devel] multi-line strings

On Mon, 7 Oct 2019, Ben Grasset wrote: 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

Re: [fpc-devel] Copyrighted material in bugtracker?

On Sat, 5 Oct 2019, Bart wrote: On Sat, Oct 5, 2019 at 1:26 AM Michael Van Canneyt wrote: > What if this piece of code ends up in the compiler? > Can Embarcadero (or however they're called these days) sue us? We'll just have to make sure the code isn't copied. The

Re: [fpc-devel] Copyrighted material in bugtracker?

On Fri, 4 Oct 2019, Bart wrote: On Fri, Oct 4, 2019 at 10:52 PM Michael Van Canneyt wrote: I tend to agree on this, I think this is harmless. You'd have to throw away large parts of stackoverflow if this was enforced rigorously. What if this piece of code ends up in the compiler

Re: [fpc-devel] Copyrighted material in bugtracker?

On Fri, 4 Oct 2019, Kai Burghardt wrote: Ahoy! On Fri, Oct 04, 2019 at 10:23:34PM +0200, Bart wrote: It appears that this is coe copied from some Delphi version. In general, I side with the FSF. Citing code - i.e. a /small/ excerpt _naming_ the source - is legit. No software patents! I t

Re: [fpc-devel] Build problem

On Thu, 3 Oct 2019, Pascal Riekenberg wrote: What went wrong when i get this error during recompiling fpc trunk? . . . Compiling ide\wwinhelp.pas Compiling ide\fpcodcmp.pas Compiling ide\fpcodtmp.pas Compiling ide\fptemplt.pas Linking ide\bin\i386-win32\fp.exe [ 99%] Compiled package ide Star

Re: [fpc-devel] Reserved words in OLE automation properties

On Sat, 28 Sep 2019, Werner Pamler wrote: I am porting an older Delphi project to Lazarus/FPC which analyzes the internal structure of PowerPoint files using OLE automation. While the overall program is working I am stuck with some OLE properties which have the name of Pascal keywords, e.g.

Re: [fpc-devel] for .. in documentation and classes based iterators.

On Tue, 3 Sep 2019, Marco van de Voort wrote: Op 2019-09-03 om 12:59 schreef Michael Van Canneyt: "5. Any type for which an enumerator operator is defined. The enumerator operator must return a structured type that implements the IEnumerator interface. The type of the control varia

Re: [fpc-devel] for .. in documentation and classes based iterators.

On Tue, 3 Sep 2019, Marco van de Voort wrote: I did an initial patch to add for..in iterator support in fcl-stl ghashmap (https://bugs.freepascal.org/view.php?id=35940) I've looked at the docs of for..in, and it doesn't seem to name the delphi getenumerator() method in its options. I assu

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

On Sat, 3 Aug 2019, Ondrej Pokorny wrote: On 13.07.2019 21:26, Michael Van Canneyt wrote: I think all sides have now been reviewed to the point of boring or annoying each other almost to death, and we finally need to decide on whether the patch is applied, and if so, which parts of it

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

On Tue, 30 Jul 2019, Martin Frb wrote: How you're suppsed to construct a working & compliant 'processor' (I assume this means compiler or interpreter or somesuch) after reading this is a mystery to me. Well if we make the following substitutions (to specialize the statement for the case of

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

On Tue, 30 Jul 2019, thaddy wrote: Telling. NOTES 1. If it is possible to construct a program in which the violation or non-violation of this International Standard requires knowledge of the data read by the program or the implementation definition of implementation-defined features, then v

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

On Mon, 29 Jul 2019, J. Gareth Moreton wrote: Hi everyone, So there's been an issue raised in regards to ISO compliance with case blocks (when under $mode iso).  Currently, a compiler error is raised if a case block does not have exhaustive c

Re: [fpc-devel] Evaluation order in expressions

On Tue, 30 Jul 2019, Ondrej Pokorny wrote: On 30.07.2019 08:55, Jonas Maebe wrote: Delphi evaluates e.g. all parameters to subroutine calls from left to right, which FPC does not guarantee. If I am not mistaken Delphi doesn't guarantee this either. I remember I "learned it by doing" quite

Re: [fpc-devel] Evaluation order in expressions

On Tue, 30 Jul 2019, Ondrej Pokorny wrote: On 30.07.2019 08:33, Michael Van Canneyt wrote: The documentation has already been fixed in this regard, there was a bugreport about it not so long ago. Great, thank you. Is there some online version of the latest documentation trunk (nightly

Re: [fpc-devel] Evaluation order in expressions

On Tue, 30 Jul 2019, Ondrej Pokorny wrote: On 30.07.2019 08:23, Ondrej Pokorny wrote: /Remark: The order in which expressions of the same precedence are evaluated is not guaranteed to be left-to-right./ Is this valid for boolean expressions, too? I use the following construct with {$BOOLEV

Re: [fpc-devel] pas2js: Generics for TJSArray?

On Sun, 21 Jul 2019, Simon Ameis wrote: Hello all, I'm currently defining some external classes for my JSON data payload which contains some array elements. So far I got two solutions: The first one uses "pascal arrays". This gives a lot of type safety but there are no array helpers yet whi

Re: [fpc-devel] TFIeld.lookup problem

On Sat, 20 Jul 2019, Marco van de Voort wrote: Op 2019-07-20 om 16:04 schreef Michael Van Canneyt: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set

Re: [fpc-devel] TFIeld.lookup problem

On Sat, 20 Jul 2019, Marco van de Voort wrote: Op 2019-07-20 om 14:40 schreef Michael Van Canneyt: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set

Re: [fpc-devel] TFIeld.lookup problem

On Sat, 20 Jul 2019, Marco van de Voort wrote: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set fieldKind=fkLookup Michael. _

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

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 then be two different addresses, thus showing that the code had been generated twice. However the compiler/linker is good at leaving out

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

On Sat, 13 Jul 2019, Ben Grasset wrote: 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

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

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

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

On Mon, 15 Jul 2019, Sven Barth via fpc-devel wrote: 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

Re: [fpc-devel] Move operator

On Sun, 14 Jul 2019, Ryan Joseph wrote: On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt wrote: You are assuming here that there is a problem. Has it occurred to you that maybe there is no problem and that a solution is simply not needed? How is this not a problem? Sorry I don’t

Re: [fpc-devel] Move operator

On Sun, 14 Jul 2019, Ryan Joseph wrote: On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote: The question then still remains: why would a user want to call a copy operator when the data is just moved from a temp to another place? Having an explicit copy operator when there is no use case for i

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

On Sat, 13 Jul 2019, Ben Grasset wrote: 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. I know. See

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

On Sat, 13 Jul 2019, Ben Grasset wrote: 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

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

On Sat, 13 Jul 2019, Ondrej Pokorny wrote: Even to such a degree that the compiler would simply reject your code by not allowing is/at on a variable of the type itself. Also defendable. No - not this one. Don't forget about e.g. generics: function Test(MyValue: T): Boolean; begin   Result

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

On Sat, 13 Jul 2019, Jonas Maebe wrote: On 13/07/2019 13:52, Michael Van Canneyt wrote: On Sat, 13 Jul 2019, Jonas Maebe wrote: On 13/07/2019 13:28, J. Gareth Moreton wrote: Okay, okay.  So what do we do to stop all these bug reports and help programmers who get caught out by case

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

On Sat, 13 Jul 2019, Jonas Maebe wrote: On 13/07/2019 13:28, J. Gareth Moreton wrote: Okay, okay.  So what do we do to stop all these bug reports and help programmers who get caught out by case blocks raising access violations?  Are you effectively saying "don't ever use enumerations for exte

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

On Thu, 11 Jul 2019, J. Gareth Moreton wrote: On 11/07/2019 11:52, Ondrej Pokorny wrote: BTW, your note in the issue report is very misleading: https://bugs.freepascal.org/view.php?id=33603#c117162. > The idea behind "is" and "as" is that they are the sole exception to the rule and will re

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

On Thu, 11 Jul 2019, J. Gareth Moreton wrote: Should I modify the patch to allow enumerations with holes with "is" and "as"?  Note that these operators will return True/not raise an error if a value falls within a hole but is otherwise between the lowest and highest elements. IMO, yes. Mi

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, 8 Jul 2019, J. Gareth Moreton wrote: I'm a bit late to the party again, but the example of an OpenGL shader has won me over, since game design is one thing I enjoy doing.  I guess I'm still a bit unsure how leading and trailing whitespace should be handled, but as long as it's well-d

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] [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 Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 10:52, Sven Barth via fpc-devel wrote: Michael Van Canneyt <mailto:mich...@freepascal.org>> schrieb am Fr., 5. Juli 2019, 10:47: If memory serves well, FPC introduced this (before delphi) to be able to import C e

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Fri, 5 Jul 2019, J. Gareth Moreton wrote: Ah, my apologies, Michael. I can see the issue of it being a convenience thing, but given that many programmers have fallen foul of the lack of range checking in case blocks, the typecasting necessary to avoid the problem is cumbersome, adds a p

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

On Fri, 5 Jul 2019, J. Gareth Moreton wrote: It's not so much convenience... it's more the fact that the compiler can and will optimise out "if (MyValue>=ord(Low(TMyType))) and (MyValue<=Ord(High(TMyType))) then" because it has every reason to assume that MyValue cannot possibly take on a va

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

On Thu, 4 Jul 2019, Zoe Peterson wrote: From: Sven Barth via fpc-devel Whitespace is indeed an important point. I myself pay quite some attention to nice identation and with multiline strings that will probably break: What about matching Python's whitespace handling for multiline docstri

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

On Thu, 4 Jul 2019, Jonas Maebe wrote: Be it implicit assignments in object creation, clearing records with Default(TMyRecord), reading records from streams etc etc. The issue is here and it needs some solution. If you don't like "is" for this purpose, why not to introduce a compiler intrinsic

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

On Thu, 4 Jul 2019, Ben Grasset wrote: On Thu, Jul 4, 2019 at 12:29 PM Michael Van Canneyt wrote: I would think this is a given... After all, they are valid characters in a single line string now, that must be kept for backward compatibility. One more question in this general regard

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

On Thu, 4 Jul 2019, Ben Grasset wrote: On Thu, Jul 4, 2019 at 12:29 PM Michael Van Canneyt wrote: I would think this is a given... After all, they are valid characters in a single line string now, that must be kept for backward compatibility. That's what I was kind of thinking myse

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

On Thu, 4 Jul 2019, Ben Grasset wrote: General implementation question: The version of this feature I currently have working introduces something of a chicken-and-egg problem while bootstrapping: The initial version of the compiler being used for the build of course has no knowledge of multi

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

On Thu, 4 Jul 2019, Sven Barth via fpc-devel wrote: Your argument works if you start with a string that's started with a backtick, but not correctly terminated. To be correct, I think the argument about unterminated line endings needs to be seen for what it is: a nuisance, but not more a n

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

On Thu, 4 Jul 2019, Ben Grasset wrote: Also, things like trailing spaces and the line terminators being either #10 or #10#13 may cause a lot of problems if the string has to be known exactly (e.g. for cryptographic hash generation). This, which is IMO *still* a non-problem in the sense of i

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

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 conservative view point, put multilinestring behind mode switch. Because then it's never cl

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

On Thu, 4 Jul 2019, Pascal Riekenberg wrote: Michael Van Canneyt hat am 4. Juli 2019 um 10:43 geschrieben: On Thu, 4 Jul 2019, Pascal Riekenberg wrote: > What about a Lazarus-Addon / Codetools extention that generates an old style > multi-line string from a selection and the oth

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

On Thu, 4 Jul 2019, Pascal Riekenberg wrote: What about a Lazarus-Addon / Codetools extention that generates an old style multi-line string from a selection and the other way around to make old style multi-line strings editable again, so you can keep indention and trailing and leading white

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, 3 Jul 2019, Ryan Joseph wrote: 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? Because none of the compiler devs finds time

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, 3 Jul 2019, gabor wrote: W dniu 2019-07-03 o 20:43, Michael Van Canneyt pisze: 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 resounding &qu

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, 3 Jul 2019, Ryan Joseph wrote: On Jul 3, 2019, at 12:53 PM, Ben Grasset wrote: After thinking about it more though I think Michael's backtick suggestion might actually be the best way to go, because of the fact that backticks currently have no meaning at all in Pascal, and as such

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, 3 Jul 2019, Ben Grasset wrote: This has been discussed I think several times in the past, but I thought I'd bring it up once more as it has never made sense to me that FPC happily supports multi-line *comments* of any length, while having no such multi-line equivalent for string litera

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

a valid enum, I think 'is' would be equally suitable. Michael. On Tue, 2 Jul 2019, J. Gareth Moreton wrote: Aah, thank you. On 02/07/2019 19:56, Michael Van Canneyt wrote: On Tue, 2 Jul 2019, J. Gareth Moreton wrote: I don't recall a conversation where such an intrinsic is see

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

On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 02.07.2019 19:53, J. Gareth Moreton wrote: I don't recall a conversation where such an intrinsic is seen as desirable, but if such a construct is desirable, then that's a good thing since it will help patch up this problem. The conversation is m

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

On Tue, 2 Jul 2019, J. Gareth Moreton wrote: I don't recall a conversation where such an intrinsic is seen as desirable, but if such a construct is desirable, then that's a good thing since it will help patch up this problem. As for the Delphi problem, it's second-hand information I heard f

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

On Tue, 2 Jul 2019, J. Gareth Moreton wrote: Hi everyone, So there have been a lot of issues going back and forth regarding case blocks when dealing with enumerations and what happens if the enum falls outside the valid range of values for some reason, because the internal domain check is

Re: [fpc-devel] [] property overloads

On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 02.07.2019 09:10, Michael Van Canneyt wrote: I had a quick peek in the compiler sources. In pexpr.pas, before processing the [, the compiler calls this:     { we need the resultdef }     do_typecheckpass_changed(p1,nodechanged); In my

Re: [fpc-devel] [] property overloads

On Tue, 2 Jul 2019, Michael Van Canneyt wrote: On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 23:25, Michael Van Canneyt wrote: I understand. But all depends on how the compiler parses and evaluates this. Let me put brackets to make it more clear: is MyTest.StringArray[i

Re: [fpc-devel] [] property overloads

On Tue, 2 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 23:25, Michael Van Canneyt wrote: I understand. But all depends on how the compiler parses and evaluates this. Let me put brackets to make it more clear: is MyTest.StringArray[i] parsed & evaluated as (MyTest.StringArray)

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 21:04, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 19:38, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 19:38, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote:   TTest = class   public

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 18:21, Michael Van Canneyt wrote: On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote: Yes, I’ve made a patch to allow overriding the actual property (https://bugs.freepascal.org/view.php?id=35772

Re: [fpc-devel] [] property overloads

On Mon, 1 Jul 2019, Ondrej Pokorny wrote: On 01.07.2019 15:57, Ryan Joseph wrote: Yes, I’ve made a patch to allow overriding the actual property (https://bugs.freepascal.org/view.php?id=35772). Very good! Just a short question: does your solution allow one overload without array indexes? I

Re: [fpc-devel] fphttpclient cannot download a file from w3.org

I tested: If I run a strace, it just hangs on the read operation: connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("128.30.52.100")}, 16) = -1 EINPROGRESS (Operation now in progress) select(4, NULL, [3], NULL, {tv_sec=3, tv_usec=0}) = 1 (out [3], left {tv_sec=2, tv_usec=

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

On Sun, 30 Jun 2019, Sven Barth via fpc-devel wrote: 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 abou

Re: [fpc-devel] viewvc breoken

Yes temporarily, on purpose. We were experiencing a DDOS attack using it. Michael. On Fri, 28 Jun 2019, John Lee wrote: URL for viewvc broken... svn.freepascal.org/cgi-bin/viewvc.cgi/?sortby=date#dirlist ___ fpc-devel maillist - fpc-dev

Re: [fpc-devel] [] property overloads

On Thu, 27 Jun 2019, Ryan Joseph wrote: Another user just reported that default properties can ALREADY be overloaded (https://bugs.freepascal.org/view.php?id=35772). The syntax is kind of awkward (thus we weren’t able to infer it) but it seems to work. Does this mean we should ignore my pat

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

On Thu, 27 Jun 2019, J. Gareth Moreton wrote: https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Well, it was meant seriously. You mentioned more than once that you like optimizations. This one would be a real big improvement for a pattern that is often

Re: [fpc-devel] Record types with unbounded trailing data

On Mon, 24 Jun 2019, Martin Frb wrote: On 24/06/2019 06:41, Michael Van Canneyt wrote: If you want to get rid of warnings, define it as LOGPALETTE = record    palVersion : WORD;    palNumEntries : WORD;    palPalEntry : array[0..(MAXINT div sizeof(PALETTEENTRY)] of PALETTEENTRY; end

Re: [fpc-devel] Record types with unbounded trailing data

On Mon, 24 Jun 2019, J. Gareth Moreton wrote: Hi everyone, So after a problem over at https://bugs.freepascal.org/view.php?id=35753 that led to a change of https://bugs.freepascal.org/view.php?id=35671 , it became apparent that there may need to be better support for unbounded arrays in re

Re: [fpc-devel] [] property overloads

On Thu, 20 Jun 2019, Ryan Joseph wrote: On Jun 20, 2019, at 4:59 PM, Sven Barth via fpc-devel wrote: It will need to be be allowed for Delphi compatibility anyway: https://bugs.freepascal.org/view.php?id=29056 Well that settles it. ;) Indeed. You can be sure that patches for this

Re: [fpc-devel] [] property overloads

On Thu, 20 Jun 2019, Ryan Joseph wrote: On Jun 20, 2019, at 2:17 PM, Michael Van Canneyt wrote: IMHO this goes contrary to what the word 'default' means. There can be only 1 default. I think the name of “default” was probably a mistake and it should have been “nameless” or

Re: [fpc-devel] [] property overloads

On Thu, 20 Jun 2019, Ryan Joseph wrote: I just had some plans for a cool JSON class thwarted because apparently [] properties don’t allow overloading of the parameters. Can we allow multiple default properties as long as their parameters are different? I know there’s not overloading of prope

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt wrote: Records do. Objects not. Ooops forget the mode switch. :) I’m seeing objects have properties. Are you sure? Maybe they got added recently. Well, at the time I used objects, they didn&#

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: (same for properties, BTW) Just noticed this. Yes, why don’t records have properties? Seems like an omission. Records do. Objects not. Michael

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and claim they are the only way to get inheritance for records since I’

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, 10 Jun 2019, Florian Klämpfl wrote: Am 10.06.2019 um 09:14 schrieb Michael Van Canneyt: Now, there exists an exception to this rule, introduced by Borland: open array parameters. Well, open strings and open arrays cannot be considered as real types imo (you cannot declare

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, 10 Jun 2019, Ben Grasset wrote: So, you're going to keep pretending like you're actually concerned about maintaining the integrity of some (completely fictional) "traditional" Pascal (that FPC never has been and was presumably never intended to be), and implying that arbitrary *synt

<    1   2   3   4   5   6   7   8   9   10   >