Re: [fpc-pascal] Troubles with SQLDBRESTBridge

Michael Van Canneyt schrieb am Di., 2. Juli 2019, 08:20: > > > On Mon, 1 Jul 2019, Sven Barth via fpc-pascal wrote: > > > Am 01.07.2019 um 23:18 schrieb Michael Van Canneyt: > >> > >>> > >>> By the way: is it correct that the sqldbrestdataset

Re: [fpc-pascal] += property bug?

Martok schrieb am Di., 13. Aug. 2019, 14:44: > Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal: > > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", > so > > except for using a temp to avoid duplicate calculation of "a&

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Fr., 2. Aug. 2019, 15:11: > Hello Sven. > > > {$if declared(AlignTParamFlags)} > Excellent! > > If, by chance, you're running out of ideas for new methods for fpc 3.3.1 > trunk and have nothing to do or you're bored... > For people that are not fan of headaches (so not for me),

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Fr., 2. Aug. 2019, 18:32: > > cause the type information is read only. > > Yes, it is why I will not jump into that proposition. > > > And if someone is not able to check for a simple flag then they shouldn't > > work with the RTTI. > > Huh, like in your code-fix? > > ;-) > >

Re: [fpc-pascal] PPCJVM Android JVM target and building to dex

Mgr. Janusz Chmiel schrieb am Sa., 3. Aug. 2019, 11:48: > Many of advanced users and developers have tried PPCJVM. It is really > possible to create fully functioning Android applications. And because > it is even possible to access methods from previously compiled .jar > files including

Re: [fpc-pascal] += property bug?

Martok schrieb am Mo., 12. Aug. 2019, 10:18: > Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt: > > > > This question pops up from time to time since 15 years if not more. > > Fun fact: questions asking why this doesn't work have a higher Google > ranking > than the manual for "COPERATORS"

Re: [fpc-pascal] += property bug?

Am 15.08.2019 um 00:39 schrieb Jean SUZINEAU: Le 14/08/2019 à 23:18, Martin a écrit : inc(CALL_LVL [ LOCAL_CALL ],1) Yes, "inc" does not work for properties. But neither does +=. I agree and in the case of a property I think it would be cleaner to code an Inc method directly in the class,

Re: [fpc-pascal] += property bug?

Am 11.08.2019 um 18:33 schrieb Ryan Joseph: Is this a bug? It should resolve to: d.setter(d.getter + 10) but it doesn’t seem to be working. {$mode objfpc} {$modeswitch advancedrecords} program test; type TData = record x: integer; end;

Re: [fpc-pascal] += property bug?

Michael Van Canneyt schrieb am Mi., 14. Aug. 2019, 18:24: > Basically any operation that requires an address is not allowed. > That += is using an address is an implementation detail of the compiler. > Same as Inc() or In/Exclude(). I don't know the exact reason for this > limitation, > but it's

Re: [fpc-pascal] ppc64le ABI problem

schrieb am Mo., 26. Aug. 2019, 19:53: > Hello, > > trying to recompile now ... since ppc64le support is not in 3.0.4, I > suppose I need to use a more recent version to compile it. So there is > no advantage in cross-compiling and I might as well try it with the > latest native fpc compiler? > >

Re: [fpc-pascal] ppc64le ABI problem

schrieb am Di., 27. Aug. 2019, 01:38: > If anybody would like a near silent POWER9 system at home, > I can really recommend the new Blackbird mainboard with CPU bundles > from Raptor CS. The lower cost 4-core CPU uses so little power you > hardly even need a fan for it. > If only it wouldn't

Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375

Am 31.08.2019 um 14:31 schrieb fredvs: Hello everybody and specially Sven Barth. With last trunk of fpc, msegui is no more compatible with fpc. After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev 42375 breaks compatibility ---> "as attributes can be part of any type they

Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375

Am 31.08.2019 um 18:24 schrieb fredvs: Hello. Type information contains reference to attribute table Old behavior: The first field of the data represented by TTypeData is whatever the sub branch of the case statement for the type contains. New behavior: The first field of the data represented

Re: [fpc-pascal] ppc64le ABI problem

Florian Klämpfl schrieb am Mo., 26. Aug. 2019, 14:01: > Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > > > Hello, > > > > > > while examining a crash when running Lazarus on ppc64le, I found the > > following issue in function calls. > > > > > > Calls to functions with more than

Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375

fredvs schrieb am Sa., 31. Aug. 2019, 22:00: > Hello Sven. > > > Just look at the changes: ... > > OK, but before I have to check my stock of aspirin. > I think I'm going to need a lot this time. > > Many thanks Sven to help me in that complete darkness. > Alternatively try alcohol. ;) And I

Re: [fpc-pascal] Illegal counter variable?

Christo Crause schrieb am Mi., 11. Sep. 2019, 09:54: > > On Wed, Sep 11, 2019 at 7:06 AM Ralf Quint wrote: > >> On 9/10/2019 4:26 PM, wkitt...@windstream.net wrote: >> > On 9/9/19 10:11 AM, James Richters wrote: >> >> Pascal doesn't have things like step... >> > >> > hunh??? i don't think

Re: [fpc-pascal] Overloading Inc and Dec procedures?

LacaK schrieb am Mi., 18. Sep. 2019, 13:38: > Hi *, > > seems, that overloading of Inc, Dec internal compiler procedures is not > allowed. > Is it by intention or can it be fixed (adding overload keyword to system > function definitions?). > Yes, this is by intention and no, it can't be fixed.

Re: [fpc-pascal] Calculating Pixels to represent 3D coordinates

James Richters schrieb am Di., 17. Sep. 2019, 16:15: > I'm curious if Freepascal has any package available that would calculate > X,Y screen pixels based on 3D X,Y,Z data at some given rotations. I'm > using Agg-Pas with PTC-Graph in a console application on Windows. I'm not > sure what the

Re: [fpc-pascal] Illegal counter variable?

James Richters schrieb am Mi., 11. Sep. 2019, 16:24: > How do you get ‘By’ to work? I have downto working but if I try ‘By’ I > get > > > > Fatal: Syntax error, "DO" expected but "identifier BY" found > Did you see anywhere that said that this bug report was resolved and the patch integrated

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

Am 28.07.2019 um 15:10 schrieb fredvs: I'm no fan of those nested with-blocks Same for me. Did you see my fixes, do you agree with it ? It's not beautiful if you mean that, but it will work... Oh and just in case you want more headaches: the current code will bomb on current FPC trunk on

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

Am 28.07.2019 um 03:02 schrieb fredvs: PS: If you know what makes the problems in your code, I am very curious to know what is the solution. I'm no fan of those nested with-blocks so I definitely won't try to fix that code. Regrds, Sven ___

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

Am 02.08.2019 um 03:01 schrieb fredvs: Hello. {$if FPC_FULLVERSION >= 030300} paramlist1 := AlignTParamFlags(paramlist1); {$endif} Hum, with fpc 3.3.1. [2019/04/24] there is that error message: msedesignparser.pas(694,43) Error: Identifier not found "AlignTParamFlags". Could it be that

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Fr., 2. Aug. 2019, 13:27: > > No, It's > 030300, but your version of trunk is too old, the function > > was only added a few days ago. > > Ha, ok. (but a few tricky, a new number for a new feature would be ok too). > By definition only the latest version of trunk is considered

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

Am 28.07.2019 um 16:02 schrieb fredvs: It's not beautiful if you mean that, but it will work... OK, I will make it nicer. Well, nicer would be if you'd do it inside the main for-loop. Oh and just in case you want more headaches... Yes, please, I adore it. By the way, about headache, may I

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am So., 28. Juli 2019, 22:26: > >. I think it /should/ work however if you add a "{$if > FPC_FULLVERSION >= > 030300} > > Oops, sorry, you writed it already: if > FPC_FULLVERSION >= 030300 > > OK thanks. > > Huh, and for: > > > if FPC_FULLVERSION >= 030200 (not sure of the number)

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Mo., 29. Juli 2019, 11:42: > > You should also use 030100 here as that was added at the same time as the > switch to Word size. > > Ha, ok (so Martin only had begin the work for 030100, I was thinking that > fpc > 030100 = fpc > 3.0.0., like fpc 3.0.2. or fpc 3.0.4). > > So the

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Sa., 27. Juli 2019, 17:54: > Hello Sven. > > > That said the code I showed you had an issue which might explain the > > behaviour you got: > > I did try your new code but get that error message at compilation: > > msedesignparser.pas(722,11) Error: Incompatible types: got

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

Am 27.07.2019 um 19:02 schrieb fredvs: Imho, it seems that in your code "if not (pfHidden in flags) then" was placed one "end;" too far. That's what I meant in the mail you replied to. Am 27.07.2019 um 19:07 schrieb fredvs: Sven, did you try a simple code, it seems that "$self" first

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Di., 23. Juli 2019, 12:52: > Hello. > > I try to make msegui/mseide compatible with fpc 3.2.0. > > Thanks to Graeme fixes, interfaces of msegui is now compatible with fpc > 3.2.0. > > But there is still problem with the use of TParamFlags with fp 3.2.0 and > mseide. > > Now,

Re: [fpc-pascal] Warning: Symbol "faHidden" is not portable

James Richters schrieb am Fr., 19. Juli 2019, 19:32: > I'm using Windows 10, but I may in the future want to make a Linux version > of my program. I guess that's what the warning is about.. that fAHidden > won't detect hidden files on some operating systems? > Correct. Regards, Sven >

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Mi., 24. Juli 2019, 08:10: > Hello. > > > Check for pfHidden. > > Thanks Sven for helping. > But I do not catch how to hide those "self" parameter. > > IMHO, the guilty is here, in Martin's code msedisignparser.pas > (Sadly I did not find any example how to use TParameterFlag.

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Fr., 26. Juli 2019, 09:06: > > It would help more if you'd point me exactly at the code in question. > > OK, now that you see the problem, here the code in mse-ide project: > > In msedesignparser.pas, procedure getmethodparaminfo: (Please take a look > at > the // in code that

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

fredvs schrieb am Do., 25. Juli 2019, 15:08: > Re-re hello. > > Maybe with video it will be more easy to explain the problem. > It would help more if you'd point me exactly at the code in question. Regards, Sven ___ fpc-pascal maillist -

Re: [fpc-pascal] TParamFlags and fpc 3.2.0.

Am 26.07.2019 um 14:50 schrieb fredvs: But, imho, there is problem with the behavior of fpc-ptypeinfo and filter in TParamFlags. Dont worry, I will not annoy you with this. There is no problem with PTypeInfo or TParamFlags. The tests for these functionalities pass without any issues on multiple

Re: [fpc-pascal] [Lazarus] It's alive !

Am 21.09.2019 um 15:22 schrieb Michael Van Canneyt via lazarus: Hello, Finally, the moment has come: https://www.youtube.com/watch?v=xos2MnVxe-c Following up on a bounty offered, Dmitry Boyarintsev has accomplished milestone one in the implementation of FPC's webassembly backend. And:

Re: [fpc-pascal] for-in loop cast

Ryan Joseph schrieb am Do., 26. Sep. 2019, 17:37: > Question I’ve always had. Why do I need to cast “value” to “pointer" > otherwise I get: Incompatible types: got "Pointer" expected “TObject” > error?. I don’t find this very helpful and it doesn’t really make sense > even. > > var > list:

Re: [fpc-pascal] fcl-passrc with Objective-c

Michael Van Canneyt schrieb am Mi., 2. Okt. 2019, 16:37: > > > On Wed, 2 Oct 2019, Ryan Joseph wrote: > > > How well can the parser handle the objective-c mode? At my first attempt > it seemed to fail pretty early on so I’m not sure it’s even supported. > > Correct, it is not supported. > > I

Re: [fpc-pascal] threads, memory barriers and RTLeventSetEvent / RTLeventWaitFor

Martin schrieb am Di., 1. Okt. 2019, 17:19: > I am currently looking at a strange issue in FpDebug. > > The main thread loads a lot of data from a file, and creates various > objects. > > Then some code is executed in a sub-thread. The timing of that > (start/stop of the 2 threads) is handled by

Re: [fpc-pascal] FPC cannot understand 1-char string as PChar

AlexeyT via fpc-pascal schrieb am Mo., 4. Nov. 2019, 23:40: > FPC 3.3.1-r43022 [2019/09/16] for Linux x64. This code crashes, because > fpc sees 'x', 'y' wrong: > >Py_BuildValue('{sLsisisisisisisOsOsOsisisisisisO}', > 'tag', > Mark.Tag, > 'x', > Mark.PosX, > 'y', >

Re: [fpc-pascal] Generic type conflicts

Am 02.11.2019 um 15:55 schrieb Ryan Joseph via fpc-pascal: I've wanted to make a generic version of a vector for a while but I always give up because it seems not very possible. It's probably not even a great idea because many methods don't translate between float and integer but I wanted to

Re: [fpc-pascal] Generic operator overload problem

Am 02.11.2019 um 15:01 schrieb Ryan Joseph via fpc-pascal: Is this a bug or did I do something wrong? The minus operator overload seems to be getting confused and I get a "Can't determine which overloaded function to call" error as a result. {$mode objfpc} {$modeswitch advancedrecords}

Re: [fpc-pascal] Generics in Objective-C mode bug?

Ryan Joseph via fpc-pascal schrieb am Mo., 11. Nov. 2019, 19:21: > Is this a bug I should report? Knowing what I do about generics now I > think the type check needs to be suspended until the type is actually > specialized. > Generics are not considered supported with Objective Pascal types.

Re: [fpc-pascal] Generic type conflicts

Michael Van Canneyt schrieb am Do., 7. Nov. 2019, 16:23: > > > On Thu, 7 Nov 2019, Ben Grasset via fpc-pascal wrote: > > > On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal < > > fpc-pascal@lists.freepascal.org> wrote: > > > >> If there i

Re: [fpc-pascal] Generic type conflicts

Ben Grasset via fpc-pascal schrieb am Mi., 6. Nov. 2019, 04:49: > On Tue, Nov 5, 2019 at 5:24 PM Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> Does this really work? Cause the compiler should nevertheless typecheck >> the code in the ot

Re: [fpc-pascal] Generic type conflicts

Ben Grasset via fpc-pascal schrieb am Di., 5. Nov. 2019, 19:11: > On Sat, Nov 2, 2019 at 11:51 AM Ryan Joseph via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> Are there any solutions for this currently? I feel like generics need to >> support some compiler directives so different

Re: [fpc-pascal] Generic type conflicts

Ben Grasset via fpc-pascal schrieb am Mi., 6. Nov. 2019, 15:43: > On Wed, Nov 6, 2019 at 2:01 AM Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> A normal if-statements has the same non-evaluation. >> > > Not in the way I m

Re: [fpc-pascal] Generic type conflicts

Am 07.11.2019 um 01:33 schrieb Ben Grasset via fpc-pascal: On Wed, Nov 6, 2019 at 12:44 PM Sven Barth via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> wrote: Pascal has a strong type safety, thus something like the if-expression won't be used/allowed

Re: [fpc-pascal] Generic type conflicts

Am 07.11.2019 um 01:42 schrieb Ben Grasset via fpc-pascal: On Wed, Nov 6, 2019 at 7:33 PM Ben Grasset > wrote: Encouraging typecasting (which cares only about the sizes of the types involved, nothing else) at the programmer level is far more error-prone

Re: [fpc-pascal] Generic type conflicts

Ryan Joseph via fpc-pascal schrieb am So., 10. Nov. 2019, 02:11: > > > > On Nov 7, 2019, at 12:28 PM, Ben Grasset via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > {$IF GetTypeKind(T) in [tkInteger, tkInt64, tkQWord]} > > Result := A div B > > {$ELSEIF GetTypeKind(T) =

Re: [fpc-pascal] get_caller_frame

Am 20.11.2019 um 23:52 schrieb Ryan Joseph via fpc-pascal: On Nov 20, 2019, at 1:56 AM, Sven Barth via fpc-pascal wrote: It returns the address of the caller's frame pointer. See also https://www.freepascal.org/docs-html/rtl/system/get_caller_frame.html It's mainly used in context

Re: [fpc-pascal] fpbind ipv6 version

schrieb am So., 27. Okt. 2019, 19:32: > On 10/27/19 11:56 AM, Alexander Grotewohl wrote: > > I sent this direct to him on accident but I don't think it worked > anyways > > (bounced?) > > > > Just some test code so not very pretty. It works, but IN6ADDR_ANY was > missing > > and I'm not familiar

Re: [fpc-pascal] fpbind ipv6 version

Am 28.10.2019 um 00:24 schrieb wkitt...@windstream.net: On 10/27/19 6:23 PM, Sven Barth via fpc-pascal wrote: schrieb am So., 27. Okt. 2019, 19:32:     On 10/27/19 11:56 AM, Alexander Grotewohl wrote: > const >      IN6ADDR_ANY: array[0..3] of longint = (0, 0, 0, 0);   

Re: [fpc-pascal] FPC Mantis has 2 fields "fixed in revision" in issues

AlexeyT schrieb am Mo., 21. Okt. 2019, 17:24: > First field is below the "OS" and "Product build" on the top; 2nd is > below "Attach tags". Remove 1 of them. > > https://bugs.freepascal.org/view.php?id=35400 No, they are different (they are even named differently!). The revision at the top is

Re: [fpc-pascal] fcl-passrc errors

Am 15.10.2019 um 23:46 schrieb Ryan Joseph: On Oct 15, 2019, at 5:26 PM, Benito van der Zander wrote: you could do var it: pointer; obj: TObject absolute it; begin for it in list do begin // continue on like before using “obj” instead of “it" end; That is a

Re: [fpc-pascal] Dynamic loading to static?

Am 26.10.2019 um 14:56 schrieb Ryan Joseph: On Oct 26, 2019, at 4:26 AM, Sven Barth via fpc-pascal wrote: CodePointer(Py_Initialize) := GetProcAddress(handle, 'Py_Initialize'); Thanks that works. I don’t think I’ve ever cast a left side value before in Pascal and honestly I didn’t think

Re: [fpc-pascal] Dynamic loading to static?

Am 25.10.2019 um 20:49 schrieb Ryan Joseph: On Oct 25, 2019, at 12:02 PM, Michael Van Canneyt wrote: You need to manually change them. if you look in the packages, you'll see that many library import units exist in 2 flavours. One static, one dynamic. That’s what I was afraid of. btw, I

Re: [fpc-pascal] Dynamic loading to static?

Ryan Joseph schrieb am Sa., 26. Okt. 2019, 22:46: > > > > On Oct 26, 2019, at 12:55 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > tmpenum := y.GetEnumerator; > > while tmpenum.MoveNext do begin > > x := tmp

Re: [fpc-pascal] get_caller_frame

Ryan Joseph via fpc-pascal schrieb am Mi., 20. Nov. 2019, 04:36: > I came across get_caller_frame in some unrelated code and I was just > curious about this so I wanted to ask. > > What does get_caller_frame return exactly? Is this a pointer to a stack > frame that could be copied to the heap?

Re: [fpc-pascal] Two possible generics bugs

Am 30.11.2019 um 18:56 schrieb Florian Klämpfl: Am 30.11.19 um 18:51 schrieb Sven Barth via fpc-pascal: Am 28.11.2019 um 16:14 schrieb Ryan Joseph via fpc-pascal: {$mode objfpc} program test; uses    FGL; // Type identifier expected // Internal error 2019112401 generic function CopyList

Re: [fpc-pascal] Two possible generics bugs

Am 28.11.2019 um 16:14 schrieb Ryan Joseph via fpc-pascal: {$mode objfpc} program test; uses FGL; // Type identifier expected // Internal error 2019112401 generic function CopyList(source: specialize FGL.TFPGObjectList): specialize FGL.TFPGObjectList; begin end; begin end. What option

Re: [fpc-pascal] Two possible generics bugs

Am 29.11.2019 um 01:01 schrieb Ryan Joseph via fpc-pascal: function CopyList (source: TFPSList): TFPSList; begin result := TFPSList(source.ClassType.Create); result.Assign(source); end; This can't work. ClassType is of type TClass and TClass.Create calls TObject.Create, *not* the

Re: [fpc-pascal] Two possible generics bugs

Am 29.11.2019 um 22:56 schrieb Ryan Joseph via fpc-pascal: On Nov 29, 2019, at 2:00 AM, Sven Barth via fpc-pascal wrote: Why? It does say that a class type is expected. And the column of the error should point to the correct location. That's the same error you'd get when specializing

Re: [fpc-pascal] Two possible generics bugs

Ryan Joseph via fpc-pascal schrieb am So., 1. Dez. 2019, 23:11: > > > > On Nov 30, 2019, at 1:04 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Well, if you want you can find any place where the _SPECIALIZE and > _GENERIC

Re: [fpc-pascal] Two possible generics bugs

Ryan Joseph via fpc-pascal schrieb am Mo., 2. Dez. 2019, 14:01: > > > > On Nov 30, 2019, at 12:58 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > This can't work. ClassType is of type TClass and TClass.Create calls > TObject.C

Re: [fpc-pascal] get_caller_frame

Ryan Joseph via fpc-pascal schrieb am Fr., 22. Nov. 2019, 01:51: > > > > On Nov 21, 2019, at 1:41 AM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > No. On x86 it's essentially the content of the EBP/RBP register which is >

Re: [fpc-pascal] Pre-allocated TFPGList or similar

Am 23.11.2019 um 23:42 schrieb Ryan Joseph via fpc-pascal: I need a pre-grown list which I can put (not insert!) items into at indexes without getting "List index out of bounds" errors. For example I want to start with a list that has 10 empty indexes: list := TList.Create(10); // 10 empty

Re: [fpc-pascal] Pre-allocated TFPGList or similar

Am 24.11.2019 um 10:14 schrieb Michael Van Canneyt: On Sun, 24 Nov 2019, Sven Barth via fpc-pascal wrote: Am 23.11.2019 um 23:42 schrieb Ryan Joseph via fpc-pascal: I need a pre-grown list which I can put (not insert!) items into at indexes without getting "List index out of bounds&qu

Re: [fpc-pascal] Two possible generics bugs

Ryan Joseph via fpc-pascal schrieb am Do., 28. Nov. 2019, 20:36: > Testing on 3.3.1. Are these both bugs? I wanted to ask first before filing > a report. > > {$mode objfpc} > > program test; > uses > FGL; > > // No Error specializing TFPGList in parameter list... > generic function

Re: [fpc-pascal] Two possible generics bugs

Ryan Joseph via fpc-pascal schrieb am Fr., 29. Nov. 2019, 01:11: > > > > On Nov 28, 2019, at 6:38 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > TFPGObjectList has a constraint to class types, so you need to constrai

Re: [fpc-pascal] FPC docs about FindFirst

Ched schrieb am So., 22. Sep. 2019, 21:11: > Hello, > > > Le 22.09.19 à 16:59, Michael Van Canneyt a écrit : > > > > > > On Sun, 22 Sep 2019, AlexeyT wrote: > > > >> https://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html > >> > >> 1) add to the list of attribs the value faAnyFile. > >

Re: [fpc-pascal] generic proc inference

Ryan Joseph schrieb am Mo., 7. Okt. 2019, 00:16: > > > > >>> 3. > >>> timpfuncspez2.pp > >>> DoThis > >>> DoThis > >>> Delphi gives an error "Ambiguous call to DoThis". FPC silently > >>> selects the one with only one param. IMO this is dangerous, it > >>> should give an error. > > > > generic

Re: [fpc-pascal] generic proc inference

Mattias Gaertner schrieb am Mo., 7. Okt. 2019, 11:59: > On Mon, 7 Oct 2019 07:54:51 +0200 > Sven Barth via fpc-pascal wrote: > > > Ryan Joseph schrieb am Mo., 7. Okt. 2019, > > 00:16: > >[...] > > > >>> 3. > > > >>> timpfuncsp

Re: [fpc-pascal] generic proc inference

Ryan Joseph schrieb am Mo., 7. Okt. 2019, 15:51: > That bug aside the rule is that non-generic overloads always win over > generics. I remember this was discussed at length if we can find the old > thread. > Here: https://lists.freepascal.org/pipermail/fpc-pascal/2018-December/055225.html

Re: [fpc-pascal] generic proc inference

Mattias Gaertner via fpc-pascal schrieb am Mo., 7. Okt. 2019, 18:42: > On Mon, 7 Oct 2019 12:38:51 -0400 > Ryan Joseph wrote: > > > > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal > > > wrote: > > > > > > Note that in Delphi the "non-generic-wins" rule is per parameter: > > > >

Re: [fpc-pascal] generic proc inference

Ryan Joseph schrieb am Mi., 9. Okt. 2019, 22:53: > > > > On Oct 9, 2019, at 1:51 AM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Yes, exactly that. It could also be that the parser picks up a non > generic overload from ano

Re: [fpc-pascal] generic proc inference

Am 10.10.2019 um 22:41 schrieb Ryan Joseph: On Oct 9, 2019, at 6:21 PM, Sven Barth via fpc-pascal wrote: Hmmm, I thought letting that dummy sym pass through would have lots of adverse affects in various places. I’ll have to study this later in the debugger. In that case the necessary

Re: [fpc-pascal] generic proc inference

Ryan Joseph schrieb am Fr., 4. Okt. 2019, 17:10: > > > > On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > A patch for it by Ryan Joseph exists ( > https://bugs.freepascal.org/view.php?id=35261 ), but I'v

Re: [fpc-pascal] generic proc inference

Ryan Joseph schrieb am Di., 8. Okt. 2019, 23:00: > > > > On Oct 8, 2019, at 11:32 AM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > I checked again. The thing is that in the compiler overload handling is > done inside htypechk

Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375

fredvs schrieb am Fr., 6. Sep. 2019, 22:23: > Hello everybody (included Sven). > > It seems that the problems come from > /mseide-msegui/lib/common/fpccompatibility/mclasses.pas. > > In procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo: > Pointer), IMHO there is something not

Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375

fredvs schrieb am Mi., 9. Okt. 2019, 12:00: > Could it be possible to simplify the life of rtl-users and add methods with > same parameters as previous version and make it compatible with new > features? > Working with the RTTI simply is *not* simple, because you're interfacing with binary data

Re: [fpc-pascal] generic proc inference

Mattias Gaertner via fpc-pascal schrieb am Do., 3. Okt. 2019, 21:35: > Hi, > > What is the state of FPC support for calling generic procedures using > inference like Delphi? > > For example: > > {$mode objfpc} > generic procedure Run(a: T); > begin > end; > > begin > Run(2); > end. > A patch

Re: [fpc-pascal] generic proc inference

Ryan Joseph schrieb am Fr., 4. Okt. 2019, 17:10: > > > > On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > A patch for it by Ryan Joseph exists ( > https://bugs.freepascal.org/view.php?id=35261 ), but I'v

Re: [fpc-pascal] fcl-passrc errors

Michael Van Canneyt schrieb am So., 13. Okt. 2019, 08:20: > > 2) For..in loops > > > > EParserError: Expected := or in at token "(" in file > > > > /Users/ryanjoseph/Developer/Projects/FPC/NewEngine/Sources/Examples/EmptyWindow.pas > at line 138 column > >

Re: [fpc-pascal] fcl-passrc errors

Am 13.10.2019 um 11:26 schrieb Michael Van Canneyt: On Sun, 13 Oct 2019, Sven Barth via fpc-pascal wrote: Just type casting because the array is an array of pointers. I get these errors otherwise "Incompatible types: got "Pointer" expected “TEntity"”. I could use a prop

Re: [fpc-pascal] fcl-passrc errors

Ryan Joseph schrieb am So., 13. Okt. 2019, 16:22: > > > > On Oct 13, 2019, at 5:58 AM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > >> Delphi does not allow it: > >> > >> [dcc32 Error] Project1.dpr(18):

Re: [fpc-pascal] fcl-passrc errors

Am 13.10.2019 um 23:19 schrieb Ryan Joseph: On Oct 13, 2019, at 11:11 AM, Sven Barth via fpc-pascal wrote: Then specialize the list with the correct type. This issue *will* be fixed and is not up to discussion. Here’s some code from the parser today. TFPList is being used because it’s

Re: [fpc-pascal] FPC_CURRENCY_IS_INT64

LacaK schrieb am Mo., 14. Okt. 2019, 11:08: > Hi, > > what is the meaning of this compiler define? > I am expecting, that Currency datatype is internaly stored using Int64 > datatype (*1). > This compiler define is set for Win64, but not for Win32. > Does it means, that on Win32 there is

Re: [fpc-pascal] fcl-passrc errors

Mattias Gaertner via fpc-pascal schrieb am Mo., 14. Okt. 2019, 10:39: > On Mon, 14 Oct 2019 07:37:38 +0200 > Sven Barth via fpc-pascal wrote: > > >[...] > > Because the iterator returns a Pointer and not whatever you think it > > might return. If you know it

Re: [fpc-pascal] Passing a CORBA interface as parameter

Am 20.12.2019 um 16:17 schrieb Adriaan van Os: I would like to pass a CORBA interface-type as parameter and test for equality, So, for example, I have {$mode objfpc} {$interfaces corba} type IMyInterface = Interface     [  '{34aad6d0-5884-4143-97c2-b6e330305ae3}']     Function

Re: [fpc-pascal] Interface delegates and the implements property specifier

Am 22.12.2019 um 04:44 schrieb Ryan Joseph via fpc-pascal: On Dec 21, 2019, at 10:49 AM, Adriaan van Os wrote: I had hoped that procedure IMyInterface2.P2 would now be visible as a method of TMyClass. This would be quite helpful in implementing multiple-inheritance. But no, the implements

Re: [fpc-pascal] Passing a CORBA interface as parameter

Am 21.12.2019 um 16:12 schrieb Adriaan van Os: Sven Barth via fpc-pascal wrote: The important difference in this regard between COM and CORBA interfaces is that for CORBA interfaces the "guid" is a ShortString, not a TGUID. Thus the compiler allows to convert a CORBA

Re: [fpc-pascal] Interface delegates and the implements property specifier

Am 21.12.2019 um 16:49 schrieb Adriaan van Os: Section 7.4 Interface delegation of the FPC Language Reference Guide discusses interface delegates and the implements property specifier. For example $interfaces

Re: [fpc-pascal] FreeVision Resources?

Kevin Monceaux schrieb am Do., 13. Feb. 2020, 10:57: > Pascal Fans, > > I've recently started getting reacquainted with Pascal. I learned a bit of > it back in the late '80s in college on a VAX 11/750 running DEC VMS. I've > loved PascalCase ever since. > > I'm working my way through the Turbo

Re: [fpc-pascal] OpenCV

Adriaan van Os schrieb am Do., 13. Feb. 2020, 14:26: > > I looked around on the web for OpenCV Pascal bindings. What I found, seems > to be based (mostly) on > the OpenCV C interfaces, which covers only part of OpenCV. > > Alternatives are: > > 1. Write flat C++ wrappers by hand > > 2. Hook

Re: [fpc-pascal] Extended type under Win64

denisgolovan via fpc-pascal schrieb am Di., 25. Feb. 2020, 23:01: > Hi all > > I'm trying to get an idea if Extended float is/can actually be 80bit? > I have FPC built under Linux x64 and it works fine (co-processor command > are actually used). > > But I haven't found any reliable information

Re: [fpc-pascal] Extended type under Win64

denisgolovan schrieb am Mi., 26. Feb. 2020, 11:38: > > > > The Extended type is not available for x86_64-win64. You either need to > use Double or the software floating point support in unit sfpux80 (though > that is only available in 3.2 and newer). > > So, Linux x64 having hardware Extended

Re: [fpc-pascal] Cannot find system type "__m64"

Ryan Joseph via fpc-pascal schrieb am Fr., 6. März 2020, 06:57: > I'm continuing this from the bug tracker. Also please note that for some > reason the mail list server has stopped sending me replies to gmail so I > need to look at https://lists.freepascal.org/pipermail/fpc-pascal/ for > replies

Re: [fpc-pascal] Cannot find system type "__m64"

Ryan Joseph via fpc-pascal schrieb am Fr., 6. März 2020, 06:57: > I'm continuing this from the bug tracker. Also please note that for some > reason the mail list server has stopped sending me replies to gmail so I > need to look at https://lists.freepascal.org/pipermail/fpc-pascal/ for > replies

Re: [fpc-pascal] Cannot find system type "__m64"

Ryan Joseph via fpc-pascal schrieb am Fr., 6. März 2020, 16:12: > > > > On Mar 6, 2020, at 2:04 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Yes, that is the problem. When Florian had merged the SIMD intriniscs

Re: [fpc-pascal] Cannot find system type "__m64"

schrieb am Fr., 6. März 2020, 15:51: > On 3/6/20 9:17 AM, Ryan Joseph via fpc-pascal wrote: > > Ok, I got this reply finally so maybe something else went wrong. I'm > tempting > > to try another account with some free email service because Gmail never > shows > > my initial post, which is

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