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 beca

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

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): Intege

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

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 bu

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

Re: [fpc-devel] XML node dump feature

Am 25.06.2019 um 06:20 schrieb Marģers . via fpc-devel: - Reply to message - Subject: Re: [fpc-devel] XML node dump feature Date: otrd., 25 jūn., 03:16 From: Ben Grasset To: FPC developers' list const A: TVec3F = (X: 1.2; Y: 2.4; Z: 3.8); B: TVec3F = (X: 2.1; Y: 4.2; Z: 8.

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

Am 24.06.2019 um 05:57 schrieb J. Gareth Moreton: We can't really use a new keyword to define an unbounded array, so I'm wondering if we can work with the syntax for open arrays.  For example, say we redefined LOGPALETTE to the following: LOGPALETTE = record   palVersion : WORD;   palNumEntrie

Re: [fpc-devel] Inlining problem and LEB128

Am 24.06.2019 um 01:02 schrieb J. Gareth Moreton: That's a point, true.  I've been for openness a lot lately, and one doesn't normally distribute the PPU files with a closed-source project, but I guess for those programs that need compiling on Linux before they can be run, it's not very desirab

Re: [fpc-devel] Inlining problem and LEB128

Am 23.06.2019 um 01:10 schrieb J. Gareth Moreton: This one is for Jonas in particular, but also to address a minor issue in general. Currently, you can get away with specifying the "inline" directive for a function in just the implementation section of a unit, and the function will be inlined

Re: [fpc-devel] [] property overloads

Marcus Marques da Rocha schrieb am Fr., 21. Juni 2019, 12:24: > It is possible to do that using variant type. I have done it as below: > Though this is not very type safe. So a correct solution in the compiler for overloading is definitely desired. Regards, Sven > _

Re: [fpc-devel] [] property overloads

Michael Van Canneyt schrieb am Do., 20. Juni 2019, 22:05: > But maybe the compiler people can see a reason why this should not be > allowed. > It will need to be be allowed for Delphi compatibility anyway: https://bugs.freepascal.org/view.php?id=29056 Regards, Sven > __

Re: [fpc-devel] Copy/move operator

Ben Grasset schrieb am Mi., 19. Juni 2019, 23:45: > On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote: > >> It’s used for making reference counted types at the user level. >> > > I'm not sure why you'd necessarily need to implement Copy specifically for > that kind of thing, though. Initialize a

Re: [fpc-devel] Overloading standard functions

Виктор Матузенко schrieb am Mi., 19. Juni 2019, 16:25: > > > ср, 19 июн. 2019 г. в 17:10, Marco van de Voort >: > >> >> No. Such guarantees/constraints on a long term basis would paralyse the >> project too much. We try to avoid breaking backwards compatibility as >> much as possible, but we can

Re: [fpc-devel] Overloading standard functions

Marco van de Voort schrieb am Mi., 19. Juni 2019, 16:09: > > The answer I see: none because any identifier may become "builtin", > > > start to hardly conflict with any declarations with the same name and > > become PITA for code maintainer. > > > No, since the default is that the local declarati

Re: [fpc-devel] Copy/move operator

Ben Grasset schrieb am Mi., 19. Juni 2019, 16:21: > On Tue, Jun 18, 2019 at 11:08 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Those operators can't be inlined, because they're called from helper >> code, not from the comp

Re: [fpc-devel] Copy/move operator

Ryan Joseph schrieb am Di., 18. Juni 2019, 16:09: > Not sure about inline though, I don’t think the compiler inlines these > operators at all. FPC seems to have lots of non-inlinable code these days > which is too bad. Maybe the LLVM backend will fix that someday? > Those operators can't be inl

Re: [fpc-devel] Object upgrades (new)

schrieb am Di., 18. Juni 2019, 03:27: > >> *this is an example of a traditional record and a traditional object as > i > >> think of them... > > [snip] > > > > These would still work as is in FPC. > > > right but are they objects, classes or advanced records? > Your example showed a couple of re

Re: [fpc-devel] Object upgrades (new)

Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm getting old and rarely dabble in pascal code any more bu

Re: [fpc-devel] Copy/move operator

Ryan Joseph schrieb am So., 16. Juni 2019, 15:29: > I just came across an efficiency issue when using management operators > that I’d like to fix before the next release and we have backwards > compatibility problems. > > Basically the problem is that the Copy operator doesn’t know if the source

Re: [fpc-devel] Object upgrades (new)

schrieb am Mo., 17. Juni 2019, 14:15: > On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: > > schrieb am Mo., 17. > > Juni 2019, 02:07: > > > > what always confused me these days is that records and objects were > one thing > > back in the (TP6) da

Re: [fpc-devel] Object upgrades (new)

schrieb am Mo., 17. Juni 2019, 02:07: > On 6/16/19 6:44 PM, Ryan Joseph wrote: > > > > > >> On Jun 16, 2019, at 6:00 PM, Benito van der Zander > wrote: > >> > >> Objects are much more useful than classes or records > > > > Now that’s an inflammatory statement! :) But seriously, I do miss record

Re: [fpc-devel] Object upgrades

Am 16.06.2019 um 17:43 schrieb wkitt...@windstream.net: On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this

Re: [fpc-devel] Object upgrades (new)

Ryan Joseph schrieb am Sa., 15. Juni 2019, 20:43: > > > > On Jun 15, 2019, at 12:50 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > I don't see a need to add management operators to objects. Objects have > constru

Re: [fpc-devel] Object upgrades (new)

Am 15.06.2019 um 17:17 schrieb Ryan Joseph: { I think the old thread “Object upgrades” got broken during the server move so I’ll try to start a new thread and see if this gets posted } Another question. I’m not sure it’s possible but I did try to add management operators to objects and found t

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 21:31: > > > > On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote: > > > > Result in your example is the size of a pointer in all cases, which is > fine / exactly what you'd expect it to be. > > > > Sorry, if I dereference the size is still of TBase. I don’

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:31: > > > > On Jun 10, 2019, at 2:26 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Also FPC doesn’t have something “self” but for the class level so you > need to cast the ret

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:35: > > > > On Jun 10, 2019, at 2:21 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > There exist only two assignment operators, namely "Implicit" (aka := in > mode ObjFPC

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 19:56: > Also FPC doesn’t have something “self” but for the class level so you need > to cast the return value. Btw adding “ClassSelf” is something I’ve wanted > for a while, so I can reference the class type within the class declaration. > What are you

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 16:26: > > > > On Jun 10, 2019, at 9:31 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The +-operator is not defined internally thus it is allowed to be > overloaded. (is it really tha

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 15:28: > > > > On Jun 10, 2019, at 9:25 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The operator for assigning one class instance to another exists and is > internal thus it is not

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 14:28: > > > > On Jun 10, 2019, at 3:13 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > A basic principle of operator overloads is that existing, internal > operators are not o

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 03:00: > Sorry to bring this up again but I had a thought today while working > regarding class operator overloads in classes (i.e. operators that are > members of classes). > > If the operators in classes allowed another parameter for the left sided > v

Re: [fpc-devel] Standard generic classes

Marco van de Voort schrieb am Sa., 8. Juni 2019, 13:43: > > Op 2019-06-06 om 16:57 schreef Ben Grasset: > > On Wed, Jun 5, 2019 at 11:11 AM Sven Barth via fpc-devel > > > <mailto:fpc-devel@lists.freepascal.org>> wrote: > > > > You could try t

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

Am 07.06.2019 um 23:17 schrieb Ryan Joseph: On Jun 7, 2019, at 5:06 PM, Sven Barth via fpc-devel wrote: No. The generic keywords are part of mode ObjFPC. The only thing I plan to do is to move the whole idea of generic keywords to a modeswitch, but that is neither here nor there currently

Re: [fpc-devel] Postfix operator overload or default properties

Am 07.06.2019 um 23:06 schrieb Ryan Joseph: On Jun 7, 2019, at 4:56 PM, Sven Barth via fpc-devel wrote: Because I don't want to open the can of worms that is going to be overloading the postfix "operator". People are going to abuse the hell out of it (they will with defaul

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

Am 07.06.2019 um 22:54 schrieb Ryan Joseph: On Jun 7, 2019, at 4:51 PM, Sven Barth via fpc-devel wrote: It has been part of FPC from the beginning of generics. It allows the parser to differentiate easier that a specialization is following. This was less important when only type

Re: [fpc-devel] Postfix operator overload or default properties

Am 07.06.2019 um 22:50 schrieb Ryan Joseph: On Jun 7, 2019, at 4:47 PM, Sven Barth via fpc-devel wrote: Am 07.06.2019 um 22:41 schrieb Ryan Joseph: Does that make sense? I’d like to scratch the idea of default properties and do this instead if it was permitted. No. FPC is not going down

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

Am 07.06.2019 um 22:45 schrieb Ryan Joseph: On Jun 7, 2019, at 3:50 PM, Sven Barth via fpc-devel wrote: generic procedure MemCopy(Dest, Src: specialize TPointerType.PT; Len: PtrUInt); begin while Len > 0 do begin Dest^ := Src^; Inc(Dest); Inc(

Re: [fpc-devel] Postfix operator overload or default properties

Am 07.06.2019 um 22:41 schrieb Ryan Joseph: Does that make sense? I’d like to scratch the idea of default properties and do this instead if it was permitted. No. FPC is not going down that operator madness. Regards, Sven ___ fpc-devel maillist - fp

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

Am 07.06.2019 um 18:37 schrieb Ben Grasset: For example, consider the following code, that implements a generic "memcpy"-style procedure using a static advanced-record method: program Example; {$mode Delphi} type   TMem = record   public type     PT = ^T;   public     class procedure Copy(Des

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

Am 07.06.2019 um 21:06 schrieb Ben Grasset: On Fri, Jun 7, 2019 at 2:35 PM Jonas Maebe > wrote: None of these can be defined as a type in parameter lists. Keep in mind that "^Type" defines a new type. Semantically, it's at the same level as "0..5"

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 18:06: > > *for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do* > *begin* > { Do some work that doesn't modify DataLeft } > *end*; > > Say that Min is given the *pure *directive, BUFFER_SIZE is a *const *and > DataLeft is a property or some non-l

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 14:52: > Sounds fair. I would be trying for a refactoring approach, in that the > API and outward behaviour is identical to before (i.e. a black box), but > the inner workings are better. I noticed that one potential source of > improvement is cha

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 14:27: > Still, saying all that, maybe there's room for improvement in rtl-generics > in the form of refactoring, like I've found in the compiler itself in a few > places. When you say 'heavyweight', do you mean it's a little slow > sometimes or ju

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Mi., 5. Juni 2019, 11:54: > Hah, oh that sounds fun! > > I would develop something more lightweight and efficient, but that would > just make a 4th poison to choose from. > As Ben mentioned there is also LGenerics which is a third party library, so there already is a

Re: [fpc-devel] Standard generic classes

J. Gareth Moreton schrieb am Di., 4. Juni 2019, 22:40: > Hi everyone, > > I may be missing the obvious here, but I've noticed that there are some > notable absences in the Free Generics Library. While there's a standard > list and a map and the like, there aren't any of the special lists like >

Re: [fpc-devel] When will the next version of FPC be released?

Am 02.06.2019 um 16:39 schrieb Ryan Joseph: I just tried to declare these 2 procedures in 3.3.1 and got an error. You can declare them in the reverse order with no problem. A bug? generic procedure DoThis(msg: T); begin end; procedure DoThis(msg: TObject); // Overloaded identifier "DoThis" isn

Re: [fpc-devel] When will the next version of FPC be released?

Ben Grasset schrieb am Sa., 1. Juni 2019, 22:49: > On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> I personally consider it a worthwhile addition. >> > > What version did Delphi add that in? I honestly

Re: [fpc-devel] When will the next version of FPC be released?

Michael Van Canneyt schrieb am Sa., 1. Juni 2019, 14:13: > > > On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote: > > >>> > >>> specialize ClearMem(pt); > >>> > >>> With implicit specialization: > >>> >

Re: [fpc-devel] When will the next version of FPC be released?

Michael Van Canneyt schrieb am Sa., 1. Juni 2019, 12:00: > > > On Fri, 31 May 2019, Ryan Joseph wrote: > > > > > > >> On May 30, 2019, at 4:18 PM, Ryan Joseph > wrote: > >> > >> I didn’t realize generic functions were in the trunk. I’m not sure I > got this implemented properly so it requires so

Re: [fpc-devel] Object upgrades

Nikolay Nikolov schrieb am Do., 30. Mai 2019, 00:52: > So, what's with all this FUD surrounding operator overloading not > working with objects? Did you even test it, before screaming "legacy!"? :) > He's talking about operator overloads that are members of the object like what was introduced fo

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am So., 26. Mai 2019, 17:05: > > > > On May 24, 2019, at 4:49 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Please don't. They're legacy types (even though we don't consider them &g

Re: [fpc-devel] Class management operators

Ryan Joseph schrieb am Sa., 25. Mai 2019, 19:55: > > > > On May 24, 2019, at 2:46 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Object Pascal isn't a full ARC language however. Also it is not > something that one can ena

Re: [fpc-devel] Class management operators

Ryan Joseph schrieb am Fr., 24. Mai 2019, 22:26: > > > > On May 24, 2019, at 1:17 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > This is not desired, because it would mean that for *all* assignments > between *any* class

Re: [fpc-devel] Class management operators

Ryan Joseph schrieb am Fr., 24. Mai 2019, 17:43: > Another thing I forget to mention. Since I was looking at management > operator stuff in the compiler I was curious, why don’t classes support > management operators? The infrastructure is already there for built-in > reference types like dynamic

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Fr., 24. Mai 2019, 01:20: > I’m doing some work to upgrade old-style objects including class > operators/management operators and better construction. > Please don't. They're legacy types (even though we don't consider them obsolete) and geared towards the TP behavior and

Re: [fpc-devel] fpcmake

Kevin Lyda schrieb am Di., 21. Mai 2019, 22:04: > Looking at using fpcmake and it comes up short. I'm wondering if some > patches to it would be acceptable. Broken down by section... > > In [install] it would be nice to be able to specify some other file > locations. Specifically, man pages (usin

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

Marco van de Voort schrieb am So., 19. Mai 2019, 14:04: > > Op 2019-05-19 om 13:50 schreef Michael Van Canneyt: > > Current C++ standards requires a space between the two > signs for > > nested templates, so I think it would be fine if we were to require > > that as well. Although I supposed that

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

Michael Van Canneyt schrieb am So., 19. Mai 2019, 13:51: > > > On Sun, 19 May 2019, Jonas Maebe wrote: > > > On 19/05/2019 13:25, Sven Barth via fpc-devel wrote: > >> And don't get me started about ">>". That one is going to annoy me > >

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

Jonas Maebe schrieb am So., 19. Mai 2019, 13:29: > On 19/05/2019 13:25, Sven Barth via fpc-devel wrote: > > And don't get me started about ">>". That one is going to annoy me > > enough once I add support for nested specializations -.- > > Current C++

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

J. Gareth Moreton schrieb am So., 19. Mai 2019, 13:18: > Regarding the C-style assignment operators, some of the packages that come > with the compiler use them, and trying to build everything without the -Sc > flag will result in errors. Outside of that, the biggest one that stands > out is Laz

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

J. Gareth Moreton schrieb am So., 19. Mai 2019, 05:17: > Yes, I'm jumpy, especially as you always like to open your responses > with a direct insult of some kind - yes, I checked. You want to kill me > or ban me from the mailing list, go right ahead. I'm sure Free Pascal > will survive without m

Re: [fpc-devel] Could the following be merged to 3.2.0 please (committed by Sven)

Marco van de Voort schrieb am Sa., 18. Mai 2019, 19:56: > > Op 2019-05-18 om 19:10 schreef Martin: > > See the list below. I wonder if they could be merged? > > If Sven sees no problems ( just say the word), and I'll merge them. > No problems from my side :) Regards, Sven > ___

Re: [fpc-devel] modeswitch multihelpers

Stefan Glienke schrieb am Mo., 13. Mai 2019, 14:54: > In fact it will use the last one that was found and fwiw this is imo bad > and error prone behavior - I guess everyone has had that happen at least > once that with some version change or update of some code some clash > happened - especially

Re: [fpc-devel] Building from source...

Kevin Lyda schrieb am Mo., 13. Mai 2019, 02:20: > I note that there's a git mirror hosted at > https://github.com/graemeg/freepascal which is kept up to date (last > commit, 17 minutes ago). I want to use it to do two things - first to > test a proposed patch and second on my own systems to integ

Re: [fpc-devel] Possible idea... "safe" subroutines/methods

J. Gareth Moreton schrieb am So., 5. Mai 2019, 05:11: > One problem I do have with FPC and its optimiser is that -O4 is > specifically said that it may cause side-effects and even tongue-in-cheek > says "beware". To me, this is bad design because it discourages the end > users from using the opt

Re: [fpc-devel] "inline" issue

Am 26.04.2019 um 22:41 schrieb J. Gareth Moreton: On 26/04/2019 21:29, Sven Barth via fpc-devel wrote: ... You did read what Jonas said in the bug report? Adding "inline" in the implementation section for the interface section would need to lead to a change of the interface CRC whi

Re: [fpc-devel] "inline" issue

Am 26.04.2019 um 18:29 schrieb J. Gareth Moreton: That's good to know - thanks Sven. This might be a silly question, but what error messages do you get if you put "inline" in a method's implementation etc? I'm wondering if I should develop a patch that ensures the conformance for inline matche

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

Re: [fpc-devel] class operator overloads

Am 16.04.2019 um 22:59 schrieb Ryan Joseph: On Apr 16, 2019, at 4:51 PM, Sven Barth via fpc-devel wrote: It's the same problem there. The thing however is that FPC's operator overloading support is quite old (compared to Delphi's) and it's possible that it is even ol

Re: [fpc-devel] class operator overloads

Am 16.04.2019 um 18:21 schrieb Ryan Joseph: Nagging question I had that I would like answered. I was told that we can’t have operator overloads on classes (only records) because there is a potential temporary class that could be created and thus some kind of automatic memory management would b

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 correctl

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

On 4/13/19 11:28 PM, Bart wrote: > Hi, > > This example is taken from the documentation: > https://www.freepascal.org/docs-html/ref/refse103.html > > {$mode delphi} //compiles in {$mode objfpc} or {$mode fpc} > {$h+} > > Type > TMyRec = record a,b : integer; end; > > operator = (x,y : TMyRec

Re: [fpc-devel] Aligned dynamic arrays

Am 29.03.2019 um 17:53 schrieb Ryan Joseph: First minor snag, fpc_dynarray_insert, fpc_dynarray_concat can allocate new arrays like SetLength can. Do we need to make aligned variants for these also? Using array + operators there is no possibility to set alignment. var a, b: array of integer

Re: [fpc-devel] Aligned dynamic arrays

Am 28.03.2019 um 15:17 schrieb Ryan Joseph: Also I don't think that a simple "do alignment or not" will be sufficient. What kind of alignment do you pick? What if the user needs more alignment? So it would probably be best to add a new SetLengthAligned of which the second argument is the ali

Re: [fpc-devel] Aligned dynamic arrays

Am 28.03.2019 um 18:41 schrieb Ryan Joseph: Now I’m using “cd /rtl; make all FPC=/path/to/compiler” to build the RTL but this is obviously slow and unnecessary. Is there a quicker way to build just the unit which contains dynarr.inc and have all the objects files to be put in the correct locat

Re: [fpc-devel] Aligned dynamic arrays

Ryan Joseph schrieb am Do., 28. März 2019, 03:01: > Here’s the basic structure: > > [header][padding][offset][head] > > [head] being the start of the elements (the pointer to the first element > of the array) and aligned to the requested amount. Keep in mind the head is > the pointer which is pas

Re: [fpc-devel] Packed record integers and x86_86

DJ Coertzen schrieb am Mi., 27. März 2019, 18:27: > Hi there, > > I need a solution for a packed record containing 4-byte 32-bit integers > and cardinals, and other byte 8 bit and word 16 bit sized variables to > overlay over a stream. > > Example: > *type* > * TMyBinaryHeader = packed record* >

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

Ben Grasset schrieb am Di., 26. März 2019, 13:47: > On Tue, Mar 26, 2019 at 2:33 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Those paths are not handled relative to the compiler binary, they are >> handled relative to the current

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

Am 26.03.2019 um 01:08 schrieb Ben Grasset: On Mon, Mar 25, 2019 at 5:34 PM Ben Grasset > wrote: To be properly cross-platform, it should really generate something like "-Fu..\..\units\$fpctarget" I meant to say, "generate something like that specifically f

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

Bart schrieb am Mo., 25. März 2019, 10:46: > On Mon, Mar 25, 2019 at 7:50 AM Sven Barth via fpc-devel > wrote: > > > Well, to be fair, the "\bla" ones are called "drive relative paths" as > they're always relative to the root drive of the current d

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

schrieb am Mo., 25. März 2019, 03:31: > On 3/24/19 6:21 PM, Bart wrote: > > Extract from fpc.cfg from 3.0.4 (created by offcial installer) > > # searchpath for units and other system dependent things > > -FuC:\devel\fpc\3.0.4/units/$fpctarget > > -FuC:\devel\fpc\3.0.4/units/$fpctarget/* > > -FuC:

Re: [fpc-devel] TRegistry and Unicode

Bart schrieb am So., 24. März 2019, 23:49: > On Sat, Mar 23, 2019 at 2:27 PM Bart wrote: > > > > I will look at it tomorrow. It has been a busy week. > > Thanks for applying. > Thanks to all of you for your advice and patience. > > Should the changes be documented at > http://wiki.lazarus.freepa

Re: [fpc-devel] implicit generic specialization modeswitch name

Bart schrieb am So., 24. März 2019, 17:44: > On Sun, Mar 24, 2019 at 5:18 PM Sven Barth via fpc-devel > wrote: > > > I agree with Florian that a better name is needed for the modeswitch > > ("implicitgenerics" as a different meaning in my opinion). But I do

Re: [fpc-devel] implicit generic specialization modeswitch name

Am 24.03.2019 um 15:02 schrieb Ryan Joseph: For my patch https://bugs.freepascal.org/view.php?id=35261 I have named the modeswitch “implicitgenerics” but Florian liked the name “implicitfunctionspecialization” (long but clear were his words). Btw this is the mode switch will allows specializat

Re: [fpc-devel] FPDoc - TH is a row-level tag?

Michael Van Canneyt schrieb am Fr., 22. März 2019, 09:20: > > > > If it's not by design, there are a grand total of 15 files XML files in > > both FPC and Lazarus that use the TH tag. So, not a big issue to fix in > XML > > source. > > Probably not. > Though we don't know how many third party us

Re: [fpc-devel] Closures repo

Ryan Joseph schrieb am Do., 21. März 2019, 22:43: > > > > On Mar 21, 2019, at 5:01 PM, Blaise Thorn wrote: > > > > Thursday, March 21, 2019 11:48 PM +03:00 from Ryan Joseph < > r...@thealchemistguild.com>: > >> Then maybe he’ll hear this and respond. > > > > I just did. > > Oh, you’re the author

Re: [fpc-devel] Successful implementation of inline support forpureassembler routines on x86

J. Gareth Moreton schrieb am So., 17. März 2019, 22:26: > I do have a slight concern when it comes to intrinsic support, because > support will be needed to be added for all platforms, (virtually) all > instructions and tested to see if they expand into the expected > instruction, along with dete

Re: [fpc-devel] Successful implementation of inline supportforpureassembler routines on x86

J. Gareth Moreton schrieb am So., 17. März 2019, 23:27: > I think one of the main issues with intrinsics is that you don't have much > control over where results are stored. Unless you're chaining a load of > intrinsics together in a mess of function calls in actual parameters, the > result is g

Re: [fpc-devel] Typed constants

Ryan Joseph schrieb am Mo., 18. März 2019, 00:50: > I just realized that typed constants exist and may need to be supported as > constants for generics but I’ve never used them myself (not sure when they > were introduced). > > First test gives an error so it makes me wonder if they’re buggy and

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

Martok schrieb am So., 17. März 2019, 21:47: > Am 17.03.2019 um 18:57 schrieb Florian Klämpfl: > > How is it better than intrinsics support (similiar to gcc/icc etc.)? > It *exists*? > > Remember how long it took to get PopCnt support? How about the rest of the > BMI? > TBM? AES-NI? Newer AVX? >

Re: [fpc-devel] Question about packages

Am 16.03.2019 um 01:14 schrieb J. Gareth Moreton: Hi everyone, This might be a painfully basic question, but I'm just trying to get to grips with the difference between Lazarus packages and FPC packages.  How do FPC packages work normally and what's their relation to Lazarus packages? I ask

Re: [fpc-devel] Successful implementation of inline support for pure assembler routines on x86

J. Gareth Moreton schrieb am Fr., 15. März 2019, 12:33: > P.S. Though this feature can be used for implementing intrinsics, it is > not a direct replacement for them because instructions like SHUFPS cannot > be flexibly encoded due to its immediate operand (i.e. it has to be a raw > number... it

Re: [fpc-devel] TRegistry and Unicode

Am 15.03.2019 um 00:04 schrieb Bart: On Wed, Mar 13, 2019 at 6:43 PM Bart wrote: That was the easy part. Since all values written are now UnicodeString, WriteStringList in XMLREG implementation now writes a sequence of UnicodeChar representations to the registry. Previously it wrote AnsiChar'

Re: [fpc-devel] TRegistry and Unicode

Bart schrieb am Do., 14. März 2019, 19:34: > On Wed, Mar 13, 2019 at 6:43 PM Bart wrote: > > > That was the easy part. > > TXMLRegistry does not seem to support Int64. > Any reason for that? > > If it's an oversight (support for that was only recently added for > Windows) should I try and implem

Re: [fpc-devel] Publish some of FPC's internal cross-platform functionality

Anton Shepelev schrieb am Mo., 11. März 2019, 15:12: > Sven Barth to Anton Shepelev: > > >>Since we already have cross-platform functions FileRead > >>and FileWrite, would not it be useful to have them set the > >>InOutRes variable, or to publish a facility for converting > >>the value of GetLast

<    1   2   3   4   5   6   7   8   >