Re: [fpc-pascal] Wiki: platform defines

Alexey Tor. schrieb am Fr., 28. Juni 2019, 12:16: > https://wiki.freepascal.org/Platform_defines#Operating_system_defines > > I 've added all defines of OS. You can tell me if it's not ok. Missed > one item: 'nativent' target. Seems some Win32 target? why new? Why it > don't have extradefines "wi

Re: [fpc-pascal] Troubles with SQLDBRESTBridge

Am 24.06.2019 um 09:30 schrieb Michael Van Canneyt: With the sample module, I tested all possible cases: I updated both FPC and Lazarus and also tested the sample module. However those variants BasePath empty don't work. I get an exception at line 2053 of sqldbrestbridge.pp. It seems that Ba

Re: [fpc-pascal] Troubles with SQLDBRESTBridge

Am 01.07.2019 um 23:18 schrieb Michael Van Canneyt: By the way: is it correct that the sqldbrestdataset currently does not support editing/inserting/deleting entries? Do you plan to change this? Ehm, no, of course it is supposed to support that. It would not be much good if it didn't :-)

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] Virtual object methods

Am 02.07.2019 um 19:43 schrieb Michael Van Canneyt: On Tue, 2 Jul 2019, Ryan Joseph wrote: On Jul 2, 2019, at 10:32 AM, Michael Van Canneyt wrote: It overwrites the first. There is no such thing as '2 VMT tables'. That’s what I thought. How costly is this? Not sure what it’s doing un

Re: [fpc-pascal] Developing a mini ERP / web based development

Graeme Geldenhuys schrieb am So., 7. Juli 2019, 11:45: > Does FPC support annotations yet? > In the Object Pascal world they are called custom attributes, are accessible through the RTTI and their syntax is [AttributeName(Arguments)]. There exists a branch with them and it's "just" a matter of i

Re: [fpc-pascal] Implementation of variant records

Am 07.07.2019 um 02:55 schrieb Ralf Quint: On 7/6/2019 12:21 PM, Florian Klaempfl wrote: Am 05.07.2019 um 13:53 schrieb Ralf Quint: Shouldn't a PACKED Record guarantee that values are aligned at the byte level? It does in TP, but the ISO says only that it shall be economised. Well, the ISO is

Re: [fpc-pascal] Implementation of variant records

Am 07.07.2019 um 12:54 schrieb Sven Barth: Am 07.07.2019 um 02:55 schrieb Ralf Quint: On 7/6/2019 12:21 PM, Florian Klaempfl wrote: Am 05.07.2019 um 13:53 schrieb Ralf Quint: Shouldn't a PACKED Record guarantee that values are aligned at the byte level? It does in TP, but the ISO says only t

Re: [fpc-pascal] specify variable name with string variable

James Richters schrieb am Mo., 8. Juli 2019, 22:44: > SetStoragePinByName('Ini_Opto_Enable_Positive_Pin', True) ; > > And it would somehow get the value of 'Ini_Opto_Enable_Positive_Pin > That indeed sounds like something where you could use classes together with published properties. At least i

Re: [fpc-pascal] Compile fpc twice or only once during install?

Christo Crause schrieb am Fr., 12. Juli 2019, 15:30: > > On Fri, 12 Jul 2019, 14:19 Bo Berglund, wrote: > >> When I install FPC/Lazarus on new Linux systems I use a script I wrote >> several years ago. It is cofigured for the actual versions to install >> but otherwise it is self-contained. >> >

[fpc-pascal] Initial support for Custom Attributes

Hello together! Today FPC has finally gained initial support for Custom Attributes. The work had initially been done by Joost van der Sluis almost 6 years ago and Svetozar Belic had adjusted the code for trunk. So thank you both for that work even if it took quite some time until it was finall

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

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 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 - fpc-pascal@

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 f

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

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 paramete

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 ___ fpc-pasca

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 tar

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 a

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.

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 the

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.

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? > > ;-) > > Ok

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 Mysql.ja

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

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?

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] += property bug?

Ryan Joseph schrieb am Mi., 14. Aug. 2019, 18:04: > > > > On Aug 14, 2019, at 11:52 AM, Joost van der Sluis wrote: > > > > Roflol... yeah... people do not use Pascal because they have to type: > > i := i + 1; > > > > Sure. > > I’m once again shocked that anyone would be against such syntaxes as

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] += 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, or

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 ei

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 st

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 ar

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 b

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 su

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 that's

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 i

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] 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] [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: It's

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

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

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 f

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

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 fu

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

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 Lucki

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

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

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 anothe

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

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 a

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 Curr

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

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 t

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?

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 di

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] 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);     well

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

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 b

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

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 i

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

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

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 p

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

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) = tk

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

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

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

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 slo

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 CopyList(sou

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

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 construc

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

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

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

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