Re: [fpc-pascal] Legitimate use of for and break
Il 20/06/2023 09:05, Hairy Pixels via fpc-pascal ha scritto: Educators continuously have stupid ideas that don't work out as intended in the real world. I would love to see them make a real program that does something difficult and not use early breaks. I assume them they forbid early exits in functions also or is the loop special for them? You don't need something difficult to show that avoiding break is stupid! Just take a loop searching a linked list for a specific item. You must test two conditions: item found or end of list. But the item you're searching might be the last one, so you can't test next=Nil at the beginning of a do-while loop. A repeat-until can't be used because the list might be empty. I prefer in those cases use a function, and exit instead of break, so that the caller can easily test how the loop was terminated, but it's just a matter of tastes. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wrong assignment detected only run time without warning
Il 16/06/23 15:02, Tomas Hajny via fpc-pascal ha scritto: If you compile with -CO, you should get at least a hint (if you enable displaying them, of course): I believed that -Co was enough. I'll add -CO to the debug options. Thanks. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wrong assignment detected only run time without warning
Il 16/06/23 13:36, Peter B via fpc-pascal ha scritto: Yes. Assigning a 64bit integer to a 32bit one is fine as long as the range is within bounds. Range of a variable can only be checked at run time. I can understand that. But the compiler generates quite a number of warning for potential loss of information. In that case a little warning wouldn't be excessive, I think. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Wrong assignment detected only run time without warning
I made a stupid error. My code: TFileObj = Class(TObject) [snip] Size: Integer; [snip] end; procedure TForm1.FillDir(FileData : TSearchRec); ... FFIleObj.Size := FileData.Size; ... but TSearchRec structure is: TRawbyteSearchRec = Record [snip] Size : Int64; [snip] IOW I assign an int64 to an integer. But when compiling I don't get any warning about that, and when the program runs there's no problem until the FileData.Size fits into an integer. When FileData.Size gets too large if compiled with -Co I get a range exception, if compiled without I just get wrong value for Size. Is that the intended behavior of compiler? Platform Linux CentOs 7 - fpc 3.2.2 Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] override and virtual: was SetFileTime
Il 03/05/23 16:44, Steve Litt via fpc-pascal ha scritto: José Mejuto via fpc-pascal said on Wed, 3 May 2023 11:35:50 +0200 Hello, Attached is a dirty implementation of "touch" for junctions == TTouchJunction = class(TCustomApplication) protected procedure DoRun; override; function DateTimeToFileTime(DateTime: TDateTime): TFileTime; public constructor Create(TheOwner: TComponent); override; destructor Destroy; override; procedure WriteHelp; virtual; end; == I'm an old Turbo Pascal (mainly 3.x, a little 5.5) guy and don't remember or never saw override and virtual. What do they do? SteveT * Override: When you're dealing with objects, you have the inheritance, that is you may derive a new class (the template of an object) from an existing class and the newly created class inherits all the methods and properties of the parent class. In this case TTouchJunction is declared as a descendant of TCustomApplication, therefore it inherits all the methods and properties. If you need that your object does something different from the methods of its parent, but keep the same name, you must declare that your declaration overrides the ancestors one. If in the body of your new method if you want to execute also the ancestor method you may call it with the keyword "inherited". * Virtual: means that this method can be overridden by a descendant class. The same does the keyword Dynamic. The difference has to do with the way the code is allocated in memory. Virtual is optimized for speed, Dynamic for memory. Hope that it helps. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Declaring an array as var or not in function calls?
Il 12/04/2023 21:17, Bo Berglund via fpc-pascal ha scritto: And if so, what is the rule for*when* to use var in function call argument lists for items that will be changed inside the called function and used afterwards? Your Wargs is defined as an open array, i.e. its length is unknown at compile time. Therefore the compiler cannot pass it in the subroutine call other than a pointer to the array. It cannot pass the array content because it doesn't know its length. In that case you may omit the var specifier. But if one day you change your mind, and decide to establish a size for your array, without var the compiler may decide to pass the full array data to the procedure, and therefore whatever you do in your procedure is done on the local copy of the array and not in the original array. My suggestion is to specify "var" whenever your procedure is expected to modify the data passed. It makes the program more readable, even if "var" is redundant. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC/Lazarus on RPi4 - How to read/write I2C connected EEPROM?
Il 01/04/2023 21:56, Bo Berglund via fpc-pascal ha scritto: I need to read and write data to an EEPROM connected by I2C on a RaspberryPi4. The I2C channel is found in /dev as i2c-1: $ ll /dev/i2* crw-rw 1 root i2c 89, 1 2019-02-14 11:12 /dev/i2c-1 In this channel the EEPROM CAT24C128 is at address 0x50 The data on the device is organized as 256 pages of 64 bytes data each AFAIU. I can check the EEPROM using i2c-tools, which I have installed, but I am unsure if the read is correct... Question: Can I use Linux file system commands to read/write the data on the i2c EEPROM memory device and if so how from fpc? I have installed the current versions of Lazarus and Fpc on the RPi4 itself. I2c is a serial protocol. All what the hardware can see is just a pair of bits: a clock line and a data line. I2c-tools provides the required software to write and read those two bits. In your case for programming the EEPROM and reading it back. The linux kernel uses i2c-tools and knows what i2c-tools tell it. I don't know if i2c-tools can be required to emulate a block device thus providing the system a block device, which then becomes readable by any means. But even if it does, and you can read your EEPROM from fpc, or whatever software you like, you will not gain any advantage, because the reading mechanism will be implemented by i2c-tools, and it will be exactly the same when verifying after programming. If reading was wrong, it will be wrong again, if it was good it'll be good again. Forget about writing. Writing an EEPROM is a complex procedure. If i2c-tools knows how to do it, let it do it. If you really need an independent verification, you should find an adapter which accepts your EEPROM and makes it accessible via a block device interface, such as USB. I don't know if such adapter does exist, but it's the only way. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to protection key?
Il 22/03/2023 11:18, Bo Berglund via fpc-pascal ha scritto: If I have fpc 3.2.2 inbstalled on Windows 10 x64 I assume it is a 64 bit target exe which will be the output, right? If in Project Options -> Config and Target ->Target OS you specify Win32, you'll get a 32 bit exe (which is what Delphi does, I presume, if it links a 32 bit object). Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] star operator on enum types
Il 26/01/2023 18:52, Sven Barth via fpc-pascal ha scritto: Giuliano Colla via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Do., 26. Jan. 2023, 18:43: I found in a fpc program a statement sort of: Type TSomeType = (a,b,c) TaType = set of TSometype var setA,setB: TaType; . *if setA * setB = [] then doSomething*; which I found very smart to detect if the two sets have some common elements, but I've been unable to find in the fpc documentation how the * operator is overloaded in fpc when dealing with enumerated and sets of enumerated types. Should I find out by trial and error or it's written somewhere? You are operating on *sets*, not enums. Thus you need to look at the documentation about set operators: https://www.freepascal.org/docs-html/current/ref/refsu49.html#x156-1812.8.6 Regards, Sven Thanks a lot, Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] star operator on enum types
I found in a fpc program a statement sort of: Type TSomeType = (a,b,c) TaType = set of TSometype var setA,setB: TaType; . *if setA * setB = [] then doSomething*; which I found very smart to detect if the two sets have some common elements, but I've been unable to find in the fpc documentation how the * operator is overloaded in fpc when dealing with enumerated and sets of enumerated types. Should I find out by trial and error or it's written somewhere? Thanks, Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why in {$mode delphi} it works and in {$mode objfpc} it doesn't?
Il 16/01/23 22:23, Mattias Gaertner via fpc-pascal ha scritto: On Mon, 16 Jan 2023 22:12:52 +0100 Mattias Gaertner via fpc-pascal wrote: On Mon, 16 Jan 2023 19:50:34 +0100 Giuliano Colla via fpc-pascal wrote: I stumbled into a problem I don't understand. I'm developing a little program for an ftp client. In order to connect to the site I need the site address from the site name, and the libc gethostbyname() provides the required information. gethostbyname returns a PHostEnt type which is declared as: Btw, gethostbyname is obsolete. Applications should use getaddrinfo, getnameinfo, and gai_strerror instead. I know that it's obsolete. It's not reentrant and it is ugly. But I'm pretty sure that it will survive for a long time to come, because it provides you a check on a name *before* creating a socket. If the name is wrong (a typo, e.g.) you don't need to get rid of an useless socket, as it would happen with getaddrinfo and getnameinfo. [...] Ah, I just saw gethostbyname returns a PHostEnt and Addr is Pin_addr. Then for the first address: Addr := Pin_addr(HostEnt^.h_addr[0]); IT WORKS! But for me it's a bit obscure why in Delphi mode the right syntax is HostEnt.h_addr^ and in objfpc HostEnt.h^.h_addr[0] I can understand the first caret (Delphi puts it there implicitly) but not the rest. However thanks a lot. If gethostbyname can be a little obsolete, Delphi mode for me is much more obsolete and deprecated! Giuliano___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why in {$mode delphi} it works and in {$mode objfpc} it doesn't?
Il 16/01/23 20:58, Marco van de Voort via fpc-pascal ha scritto: On 16-1-2023 20:56, Giuliano Colla via fpc-pascal wrote: No chance. Addr is a pointer (of type Pin_addr) but Addr := Pin_addr(HostEnt.h_addr^) works only if mode is Delphi. In objfpc it raises exactly the same error. A little bit weird, isn't it? It depends. It assumes .h_addr is compatible with pointer. Since Free Pascal is more portable, that might be a platform dependent assumption. I fail to grasp the different assumptions that the compiler makes on objfpc mode. If the typecast tells that the two types are compatible (and they are, because they're both pointers and also of the same type) it should write the one to the other without making any fuss! But I can live with it! The horrible mess they've done with gethostbyname, and the chars which are actually bytes is not so frequent, luckily! That's what happens when you don't have the "based" construct, which makes very easy to deal with those situations. Different structures can be based on the same pointer, and one "type" field, common to all structures, makes you pick up the right one. Giuliano Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why in {$mode delphi} it works and in {$mode objfpc} it doesn't?
Il 16/01/23 20:32, Michael Van Canneyt ha scritto: On Mon, 16 Jan 2023, Giuliano Colla via fpc-pascal wrote: .I stumbled into a problem I don't understand. Should that not simply be Addr := Pin_addr(HostEnt.h_addr^) (if addr is a pointer) or addr:=Pin_addr(HostEnt.h_addr^)^ if Addr is an in_addr record ? Michael. No chance. Addr is a pointer (of type Pin_addr) but Addr := Pin_addr(HostEnt.h_addr^) works only if mode is Delphi. In objfpc it raises exactly the same error. A little bit weird, isn't it? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Why in {$mode delphi} it works and in {$mode objfpc} it doesn't?
I stumbled into a problem I don't understand.
I'm developing a little program for an ftp client. In order to connect
to the site I need the site address from the site name, and the libc
gethostbyname() provides the required information.
gethostbyname returns a PHostEnt type which is declared as:
THostEnt = packed record
h_name: PChar; { Official name of host. }
h_aliases: PPChar; { Alias list. }
h_addrtype: Integer; { Host address type. }
h_length: socklen_t; { Length of address. }
case Byte of
0: (h_addr_list: PPChar); { List of addresses from name
server. }
1: (h_addr: PPChar); { Address, for backward
compatibility. }
end;
PHostEnt = ^THostEnt;
Actually the chars h_addr points to are /hlength/ bytes to be
interpreted as an /in_addr/
In order to recover h_addr I have a line which works perfectly in Delphi
mode (inherited from an old Kylix app):
Addr := Pin_addr(HostEnt.h_addr^);
I believed that in objfpc mode it was sufficient to change it in
Addr := @(Pin_addr(HostEnt.h_addr^));
or in
Addr := Pin_addr(@HostEnt.h_addr^);
but such is not the case. In both cases it flags the line with the same
error, i.e.:
Error: illegal qualifier
Hint: may be pointer dereference is missing
Fatal: Syntax error, ")" expected but "identifier H_ADDR" found
What I'm missing? How should i write that line of code to make it work
in objfpc mode?
Thanks,
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calculating CRC16?
Il 25/10/22 09:58, Marco Borsari via fpc-pascal ha scritto: On Tue, 25 Oct 2022 08:30:19 +0200 Bo Berglund via fpc-pascal wrote: Is there some package or code available somewhere which can calculate the CRC16 value over a byte array of some 1000 bytes? http://www.retroarchive.org/swag/CRC/index.html Maybe you'll find this implementation more efficient: https://gist.github.com/prof7bit/7fc558626f94bd8a81b7 Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a simple tcp/ip connection
Il 28/05/2020 18:00, Graeme Geldenhuys ha scritto: Though in general, I would just use Indy. +1 The main reason is that I have a relevant amount of Delphi/Kylix code using Delphi's Sockets unit. That way porting that code to Lazarus becomes trivial. Secondly my applications typically involve point-to-point connections in a production environment. Upstream machine must communicate with downstream machine, end of line machine must send production data to a dedicated server, and so on. I need to transparently handle failures such as a server side being temporary down. All of that in the hands of unskilled operators. Lighter and simpler code, makes it easier both to develop and to debug. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Implementing a simple tcp/ip connection
Hi everybody, I needed to implement a simple dedicated TCP/IP connection between a client and a server. Nothing fancy, just sending and receiving short strings. I have used in the past for that purpose the unit Sockets lifting it from Delphi/Kylix. This unit was taking advantage of libc, and this makes it unusable today. Instead of using heavy libraries such as Synapse, intended or other purposes I believe I have found a simpler and cleaner solution by just using the fpc Sockets unit. This unit however doesn't provide all of the required functionalities. Therefore I have implemented a small unit which I named klibc, which provides the extra functions required such as fpinet_addr, fpgethostbyname etc. and which i share which whomever has similar problems. As I'm in possess of a valid licence, I also took advantage of the Kylix Sockets unit, which I adjusted and renamed KSockets to avoid name clashing. Being copyrighted code I can't share it publicly, but I can share it privately with whomever is in a similar condition as mine. I have not yet tested all functionalities, but the Delphi/Kylix NetChat example works just fine. I only had to add KSockets and BaseUnix in the uses clause without touching the rest of code. There are a few things which deserve attention, because some deprecated functions are used, such as inet_addr (which should be replaced with intet_ntoa, already supported by klibc) and suspend and resume used in thread handling. Hope that it can be useful. -- Do not do to others as you would have them do to you.They might have different tastes. <> ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Copying a Pchar to an array of bytes
Thank you both guys. Il 19/05/2020 19:28, Alexander Grotewohl ha scritto: do move(Hello^, ... -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
Il 19/05/2020 18:57, Michael Van Canneyt ha scritto: They are not missing. How do you think fpsock and lnet implement non-blocking ? It's simply called O_NONBLOCK. I'm using fpc 3.0.4. With just Sockets in the uses clause both SOCK_NONBLOCK and O_NONBLOCK give an Identifier not found error. I've seen that SO_REUSEPORT was commented out, so I just defined it in my code. -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Copying a Pchar to an array of bytes
I'm not too familiar with Pchar, and apparently I'm missing something. I have a Pchar string which I must copy into an array of bytes. Could someone explain me while a move doesn't work while an assignment byte by byte does? Here's a snippet of the code: buffer: array [0..1023] of byte; Hello: PChar = 'Hello from server'; len := strlen(Hello); Move(Hello,buffer,len); <--- Garbage in buffer - doesn't work for I := 0 to Pred(len) do begin buffer[I] := Byte(Hello[I]); < Works just fine. end; I fail to understand why. What I'm missing? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
I'm struggling with a similar problem. It would appear that the easiest way would be just take advantage of the Sockets unit. You only must define some more constants, such as SO_REUSEPORT and SOCK_NONBLOCK which are missing in fpc. I just made some preliminary tests, and it looks like it's not so difficult to implement something quite compatible with Delphi philosophy. The SOCK_NONBLOCK flag is one of the keys. Now I'm planning to look in more detail the old Delphi implementation, in order to see how they were tacking advantage of Libc. If you're interested I'll let you know my results. Giuliano Il 16/05/2020 20:13, Bo Berglund via fpc-pascal ha scritto: I am myself struggling with this problem right now converting an old Windows service application that is configured from a Delphi programmed client operating over TCP/IP sockets. And it uses TClientSocket and TServerSocket I am going to try LNet hoping it will not bee too different from the Delphi native components... (Note: Delphi 7/Delphi 2007) -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
Thank you to all of you guys. Now I have a much better picture -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] How to implement a simple tcp/ip connection?
Hi all, I need to implement a simple dedicated TCP/IP connection between a client and a server. Nothing fancy, just sending and receiving short strings. I have used in the past for that purpose the unit Sockets lifting it from Kylix. This unit was taking advantage of libc, and this rules it out. I see that fpc provides a Socket unit in rtl-extra and a fpSock unit in fcl-net. At first glance they both appear to provide what I need. Can somebody which has used those units point me in the right direction, before I painfully study in detail those units. Thanks for any help. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Warning: Symbol "faHidden" is not portable
Il 19/07/2019 19:32, James Richters ha scritto: 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? More exactly it means that fAHidden won't detect a hidden file in any OS, except Windows (and DOS if you care about). It means File Attribute = Hidden, and only Microsoft has the Hidden flag among the file attributes. A file in Linux is hidden if the first character of its name is a dot. If you want to make a file hidden, or make visible a hidden file, you must rename it. But this visibility rule applies only to POSIX human interface applications. If you programmatically read a directory, you always get all files. If your goal is to get all files of a directory, hidden or not, then you need fAHidden only for Windows, because the fpc procedures will get all of them under Linux. If your goal is to tell apart hidden files from visible ones then you must use platform specific ifdef's, using fAHidden for Windows, and checking for the first character of the name under Linux (or UNIX, because all Unices follow the same rule). Hope that it helps, Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Checking if a TStringList already exists
Il 21/05/2019 14:40, Michael Van Canneyt ha scritto: FreeThenNil should never be necessary. FreeAndNil() should be enough for all circumstances. In a perfect world maybe you're right. But if you're dealing with LCL, you'll find it sometimes necessary, less your program segfaults, because the freeing of some children is postponed, and when they're set free their parent is already dead. Maybe it's a matter of bad design of some LCL components or even of TApplication, but either you decide that to make your project work you must redesign significant parts of LCL or you give up and sadly take advantage of FreeThenNil(). Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Checking if a TStringList already exists
Il 20/05/2019 15:23, James Richters ha scritto:
Thank you very much for the explanation and examples of this! I am glad you pointed out the FreeAndNill() function, I will defiantly be needing that.
James
Then you might also appreciate the function Assigned. Assigned(P)
returns true if P is non-nil, and false if P is Nil. Nothing fancy,
just making the code more readable.
From fpc documentation:
Program Example96;
{ Program to demonstrate the Assigned function. }
Var P : Pointer;
begin
If Not Assigned(P) then
Writeln ('Pointer is initially NIL');
P:=@P;
If Not Assigned(P) then
Writeln('Internal inconsistency')
else
Writeln('All is well in FPC')
end.
Giuliano
P.S. In some rare case when dealing with complex objects you might
need FreeThenNil() in place of FreeAndNil(). Give a look to https://lists.lazarus-ide.org/pipermail/lazarus/2011-April/062743.html
--
Do not do to others as you would have them do to you.They might have different tastes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] h2pas fails on c++ header file
Il 01/02/2019 10:37, Marco van de Voort ha scritto: Op 2019-01-31 om 19:00 schreef Sven Barth via fpc-pascal: That is because h2pas is unable to handle it, or because fpc is unable to generate the proper code for a c++ parameter by reference The former. For the later you'd either use var or constref. Though there'd still be the topic of name mangling... (FPC's cppdecl is not that good yet) And I guess it should be a simple type, not a smartpointer. IOW a pure C wrapper around the C++ module would be the only easy way out at the moment? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] h2pas fails on c++ header file
Il 30/01/2019 13:17, Marco van de Voort ha scritto: Op 1/30/2019 om 11:57 AM schreef Giuliano Colla: What I'm doing wrong? Using a C header converter or a C++ header file. & is not proper C. That is because h2pas is unable to handle it, or because fpc is unable to generate the proper code for a c++ parameter by reference? -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] h2pas fails on c++ header file
I have a c++ module which just performs calculations, and does not use c++ objects. Just c++ syntax. The header file which is used from a c++ main, is the following: extern int delta_calcForward(float theta1, float theta2, float theta3, float , float , float ); extern int delta_calcInverse(float x0, float y0, float z0, float , float , float ); Invoking h2pas with the following command line: h2pas -e -p -D -i deltarobcpp.h generates an "Internal error 1 in line 1". The temporary files generated, ext*.tmp, are all of zero length. Platform is Linux x86_64, tested with h2pas from different fpc releases from 2.6.4 to trunk. What I'm doing wrong? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get "disk" ID
Il 05/01/2019 17:03, Bart ha scritto: I need some function to get a unique ID for a disk. I need this to identify if my program has accessed this disk previously. For that purpose on Linux, out of laziness, I usually just parse the output of command-line utilities, such as blkid or lsblk. blkid /devs/sd/xy/ provides an output such as: blkid /dev/sda1 /dev/sda1: LABEL="SYSTEM" UUID="980C041F0C03F6D2" TYPE="ntfs" or blkid /dev/sda3 /dev/sda3: UUID="ce9d5b2f-232f-4a87-a75e-70e1386dd134" TYPE="ext4" while lsblk can provide either a single partition UUID (/dev/sd/xy/) or the UUIDS for all the disk partitions (/dev/sd/x/): sudo lsblk -f /dev/sda3 NAME FSTYPE LABEL UUID MOUNTPOINT sda3 ext4 ce9d5b2f-232f-4a87-a75e-70e1386dd134 /boot or sudo lsblk -f /dev/sda NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ntfs SYSTEM 980C041F0C03F6D2 ├─sda2 ntfs Windows 5E1043661043446D /media/Windows ├─sda3 ext4 ce9d5b2f-232f-4a87-a75e-70e1386dd134 /boot ├─sda4 ├─sda5 ntfs HP_RECOVERY 2CF47035F470037E ├─sda6 vfat HP_TOOLS 7E18-51AB ├─sda7 swap 68647ac3-2d0b-4f71-92dd-65220092bab6 [SWAP] └─sda8 ext4 4ccb4264-9920-4d2b-a568-bfc5024eafcd / Those utilities are based on the libblkid library, which does the real job. If you prefer an approach which doesn't require launching an executable and parsing its output, you may give a look to the C code of the sources, find the appropriate API's, and then bind what required to your Pascal program. On Mac OSX you should be able to get the UUID by using diskutil, but I never tested. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows programming tutorials for FPC
Il 03/11/2018 23:16, James ha scritto: It’s not a snippet, that’s the entire thing. It’s pretty simple, just a sequential set of events to fix a file. It would be a great help if you could get me an example of how to make this work. The simplest thing you can do is just to transform your application into a GUI application. Try to do the following: Start your Lazarus, then select Project->New Project -> Application You get that way an empty form and a skeleton unit. You'll find that in the var section there's de declaration of Form1, you may add there your var's. If you want your user to pick up a file name from the file dialog, do the following: Click on the Dialogs Tab, on the icon "TOpen Dialog", and then click anywhere on the Form. Now you have an OpenDialog icon on your form, which will not be visible run time. It's there just to let you set its properties in the Object Inspector. You may set there a default extension, an Initial Dir, a default file name, or whatever you think can be useful to the user. Or you may leave the fields empty so that the system defaults are taken. You may also set the OpenDialog File name from the invocation command line: in the initialization section (or in the OnCreate event of the form) you may add OpenDialog1.FileName := ParamStr(1). Now from the "Standard" Tab click on the TButton Icon and click on the form. You get a Button on the form. Change in the Object Inspector the Caption to what you want, sort of "Select Input File". In the object Inspector select the Events tab and then the OnClick event. Click on the three periods to the right, and you'll get in the source editor the skeleton of a new procedure (TForm1.Button1Click). That's where all of your code goes. Typically: If OpenDialog1.Execute then begin TapFileName := OpenDialog1.FileName; .. etc. You may add a Tedit (always fron the "Standard" tab) object to show your messages: your writeln becomes Edit1.Text := 'Whatever'. Where you need to ask the user for a new filename, you may just call a second time OpenDialog1.execute, to get it. If you want to be kind to your user, you may add a "Close" button, to close the application when the user is done. Just pick from the "Aditional" tab a TBitBtn, put it in your form, then in the Object Inspector select the "Kind" as "bkClose". There's no more than that. You may now save your project, giving the program and the unit some name you like. Then play a bit with it, and adjust following your needs. Hope that it helps. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Branch table
Il 23/08/2018 11:34, Marco Borsari via fpc-pascal ha scritto: It would be for the Wirth optimization in the access of an array, when the index is 0 or 1, allowing the elimination of a multiplication. I'm afraid that this sort of optimization is rather outdated, and doesn't take into account a number of factors which make modern processors behave quite differently from old times ones. First of all, saving a multiplication was important at the times when even integer multiplication was very costly in terms of machine cycles. Today one must carefully check if there's really any saving in replacing a multiplication (which is nowadays very fast) in just a couple of cases (index 0 and 1) with a number of checks and jumps for *all* cases. Moreover, any compiler will align your array elements on 32bits boundaries (or 64bits if you're in a 64bits platform) for better efficiency, so that your multiplication will be a multiplication by a power of two, which all the modern compilers translate into a much faster shl. No doubt that adding checks and jumps to save a shl doesn't make much sense. The second important factor to take into account is that modern processors do not execute instructions taken directly from the slower main memory, but they fetch them from the much faster cache. A jump instruction, if the target isn't very near, will generate a cache flush, thus dramatically increasing the execution time. That's why modern compilers try to avoid a branch table whenever possible. In the example you mentioned earlier (http://www.mindfruit.co.uk/2012/01/switch-blocks-jump-tables.html) you can read that gcc translates a switch (= fpc case) construct into a branch table with -O1 (minimal optimization), but with higher optimization (-O3) it avoids the branch table and translates the construct into a sequel of conditional jumps. In any case for the above reason (avoid cache flushing with a jump target too far away) the code that I had proposed (branch table in the data area) is preferable to the one of your last attempt (branch table in the code area). You may easily verify what solution provides the best efficiency in your platform, by performing a high number of iterations over your code, with random idx's in the range of your array size, and getting the total execution time (sort of: time your_prog). Keeping in mind that on a different platform (different cache size) it could behave quite differently. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Branch table
Il 18/08/2018 15:52, Marco Borsari via fpc-pascal ha scritto: it works only for index 0, and crashes otherwise. Maybe a problem of alignment? Or must be tab declared in data section? On the Intel architecture you cannot perform pointer arithmetic as if a pointer were just a number. A pointer is composed of two parts: a "selector" and an "offset", which must be handled separately. If in place of your addition (add ebx,eax) you leave the appropriate instruction to take care of putting together selector and offset, it works. Just change your lines: mov ebx,tab; add ebx,eax; jmp ebx; Into: jmp tab[eax] and it will work just fine. Just tested. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Branch table
Il 17/08/2018 15:46, Marco Borsari via fpc-pascal ha scritto:
I found
that someone made that for me at link
http://www.mindfruit.co.uk/2012/01/switch-blocks-jump-tables.html
and I have tried to rewrite the program in at syntax
program branch2;
{$ASMMODE att}
label next,stop,a,b,c;
var idx:byte;
begin
write('Index? ');
readln(idx);
asm
movb idx,%al
jmp *next(,%eax,4)
next:
jmp a;
jmp b;
jmp c;
end['EAX'];
a:
writeln('0');
goto stop;
b:
writeln('1');
goto stop;
c:
writeln('2');
stop:
writeln('stop');
end.
but this fails compilation at line 10 with messages
Unsupported symbol type for operand
Unknown identifier 'NEXT'
Well, I think I can live without it, it is only for
the sake of curiosity,
Marco
I modified your code, to add a jump table (as it is in the example
you mention) and here it works just fine. The code which works is:
program branch2;
{$ASMMODE att}
label stop,a,b,c;
var idx:byte;
Jtab: array [0..2] of pointer;
begin
// Fill up the Jump table with the addresses of jump targets
Jtab[0] := @a;
Jtab[1] := @b;
Jtab[2] := @c;
write('Index? ');
readln(idx);
asm
mov $0x0,%eax // clear upper bits of eax
movb idx,%al // so that it contains just idx
jmpq *Jtab(,%eax,8) // 8 is for x86_64; replace with 4 for i386
end['EAX'];
a:
writeln('0');
goto stop;
b:
writeln('1');
goto stop;
c:
writeln('2');
stop:
writeln('stop');
end.
Enjoy programming!
Giuliano
--
Do not do to others as you would have them do to you.They might have different tastes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Branch table
Il 14/08/2018 15:21, Marco Borsari via fpc-pascal ha scritto:
Why the code below does exit gracefully without prints anything?
Sure, it is for my poor knowledge of the assembler, but in some
details, please...
program branch;
{$ASMMODE intel}
label next,stop,a,b,c;
var idx:byte;
begin
write('Index? ');
readln(idx);
asm
mov ax,idx;
shl ax,2;
mov bx,next;
add bx,ax;
jmp (*short*) [ebx+4];
next:
jmp a;
jmp b;
jmp c;
end['EAX','EBX'];
a:
writeln('0');
goto stop;
b:
writeln('1');
goto stop;
c:
writeln('2');
stop:
writeln('stop');
end.
Just another question: why the short modifier is unrecognized?
Thanks for any help in this holydays time,
Marco
I tested your code in my environment (Linux - x86_64), compiled with fpc
-g -a branch.pas. (-g is to add debug information, -a to get the
assembler listing).
Then launched it with gdb debugger:
>gdb branch
(gdb)run
The output is the following:
(gdb) run
Starting program: /home/colla/Applicazioni/Lazarus/Branch/branch
Index? 1
Program received signal SIGSEGV, Segmentation fault.
main () at branch.pas:13
13 jmp (*short*) [ebx+4];
The first thing I notice is that you load BX, which is a 16 bit register
(the lower 16 bits of EBX), with the value of "next", and then Jump to
the content of EBX which is a 32 bit register, whose lower 16 bits have
been loaded but whose upper 16 bits are undefined. A SIGSEV is therefore
to be expected. If you are in a 32 Bit environment you should use EBX,
if you're in a 64 Bit environment you should use RBX.
What I would do, if I were in your place, would be to rewrite your
program in pure Pascal, compile it with the -a switch to get the
assembler listing, and use the compiler generated assembler code as a
guideline to your optimized assembler.
Giuliano
--
Do not do to others as you would have them do to you.They might have different
tastes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Il 23/07/2018 18:11, Ryan Joseph ha scritto: The spirit of the language is really hard to define in my opinion. To the contrary, in an Open Source project, it is the easiest thing to define. It is what the core developers deem to be the spirit of the language. That's all. One should never forget what Open Source is: one or more persons, because of their personal motivations (fun, technical interest, altruism, egoistic desire to appear, whatever) decide to develop some software in their free time, without getting any money for that, and to share it with whomever is interested. One should understand that it is *their* toy, not *our* toy. We may suggest them to include new features, to modify existing ones, but to accept or to reject them it is just their choice. You cannot force them neither to spend their free time developing something they don't like, nor to accept a patch which in their judgement would taint their toy. It's as simple as that. Open Source however provides an easy way out. If they don't like it, but you do need it or just want it, you are free to implement whatever you like on top of the existing project. Then you may just keep it for your personal usage, or share it, giving rise to another OS project. That's what Maciej Izak has done with its NewPascal. If you don't know how to implement it, then you're in a worse situation, because you cannot judge the implications of what you request, which might require an effort not proportionate to the result, might conflict with a lot of other things, etc. etc. You have no other choice than to rely on core developers' judgement. For those reasons I believe that this thread has become too long, and that it would be reasonable to end it. Just my 2 cents. Giuliano -- Do not do unto others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to translate Delphi Assembly MOV EAX,[EBP+4]
Il 18/07/2018 17:19, Dennis ha scritto:
The following delphi code when compiled by FPC, raised these errors:
Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
Errors: 10, Warnings: 2
StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
StrBuffer.pas(100,23) Error: Assembler syntax error in operand
StrBuffer.pas(100,24) Error: Unknown identifier "EBP"
StrBuffer.pas(100,29) Error: Invalid constant expression
StrBuffer.pas(100,29) Error: Invalid reference syntax
StrBuffer.pas(100,29) Warning: No size specified and unable to
determine the size of the operands, using DWORD as default
StrBuffer.pas(207,19) Error: Unknown identifier "EAX"
StrBuffer.pas(207,23) Error: Assembler syntax error in operand
StrBuffer.pas(207,24) Error: Unknown identifier "EBP"
StrBuffer.pas(207,29) Error: Invalid constant expression
StrBuffer.pas(207,29) Error: Invalid reference syntax
StrBuffer.pas(207,29) Warning: No size specified and unable to
determine the size of the operands, using DWORD as default
Can anyone help me?
class procedure TStrBuffer.Error(const Msg: string; Data: Integer);
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP+4]
end;
begin
raise EListError.CreateFmt(Msg, [Data])at ReturnAddr;
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
It looks like Intel asm syntax, while fpc defaults to AT assembler.
According the docs you should prepend a switch
{$ASMMODE intel)
to your asm section, or at the top of the unit.
Hope that it helps,
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new fpc desirable feature
Il 17/07/2018 23:40, Tomas Hajny ha scritto: Indeed - please, everybody make sure to keep the discussion on this list on topic, this thread doesn't belong to this list. You are perfectly right that the discussions on this list should be kept on topic. But I don't agree that this thread is out of place. It only has deviated from the core of the matter, as suggested by my post. The purpose of my post was not to joke or to troll. My aim was to point out, by means of a paradoxical proposal, that too many discussions suggest to transform fpc into something completely different, a sort of hybrid thing, mixing up C++ features, Ada features, Java features and God knows what else. I have not yet seen the proposal to get rid of begin/end and replace it with indentation level, but it appears to be just a matter of time! In that case, however, it turned out that even the craziest idea such as the please keyword wasn't new, but already present in the INTERCAL language, and this led to some off-topic remarks. You cannot think of anything crazy without discovering that someone crazier than you has already implemented it! However it remains that Pascal is a very good language, whose clarity and self consistency require some small sacrifice. Too many programmers do not realize that saving a bit of typing may cost a lot in debugging and maintaining, and that what matters is not the time spent in typing, but the total time from the beginning, up to a fully debugged production ready program, which can be maintained by other people as well. Sorry for the extra noise generated, but the main point remains. Please help to keep this list on its topic, which is to help users to exploit Pascal at his best, to point bugs or things that can be improved, and not to betray Pascal spirit. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new fpc desirable feature
Il 17/07/2018 14:12, Karoly Balogh (Charlie/SGR) ha scritto: I also propose that if you do not write "please" often enough, the compiler would error out, claiming the user being too rude. But if it's used too often, the source can be rejected for being excessively polite. A problem would be to determine the appropriate amount of politeness accepted. Maybe a compiler option, such as -P0 (almost rude) to -P3 (extremely polite)? Or up to -P7 for an increased granularity? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new fpc desirable feature
Il 17/07/2018 16:06, Reimar Grabowski ha scritto: I DO NOT beg the compiler for something, I command. Then I would not be astonished if it turned out that you experience more troubles than the average, such as unexpected sigsev, libraries not found, unexpected shutdowns, and disk errors. I have learned from Russians that the computer must be treated gently. In Russian the word for computer is feminine, and they say that it must be treated as such. Gently and with love. Be kind with your computer and he (she) will be kind to you! :-) Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] A new fpc desirable feature
As everybody is suggesting new fpc features, I feel it right to add my own proposal, to make the language more useful and user friendly. I propose the support for the keyword "please". The syntax is quite simple: "please:", followed by the explanation in plain English (or whatever locale is selected) of what you want the compiler to do, makes the compiler generate the appropriate code. E.g. : please: fetch from the database xxx the relevant data and put them neatly in a string grid; please: if the user modifies the data in the string grid, update the database accordingly; I hope that this simple request will not be rejected, even if it is in line with most of the requests I read in this list and which face strong resistance from core developers :-). Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
Il 03/07/2018 15:14, Marcos Douglas B. Santos ha scritto: Can we sleep a thread for minutes or even hours without any problems? The OS will not kill the thread? On Linux environment, sample situation on one of our servers: ├─hald───hald-runner─┬─hald-addon-acpi │ ├─hald-addon-keyb │ └─2*[hald-addon-stor] 16:27:34 up 567 days, 20:40, 1 user, load average: 0.02, 0.01, 0.00 Hald threads are unused since 567 days (they're triggered by the insertion of new hardware, which never happened on our server) and are still there! On Windows a CTRL-ALT-DEL will show you a lot of useless threads activated at power on, and sleeping since then. OS may decide to swap them off, so that activation may be slower, but never to kill them. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
Il 20/06/2018 12:14, Michael Van Canneyt ha scritto: If you need a preprocessor, maybe you simply need to rethink your design. If you could explain your actual problem, maybe we can help solving it without resorting to preprocessing. In my experience a preprocessor comes handy mainly during the development of an application. E.g.: you need to evaluate if solution A is better than solution B, and each solution involves calling a different procedure with a different number of parameters, in dozens of points of your code. This is an example from a C program: #define CON_TMAX #ifdef CON_TMAX #define AspettaRisposta(x,y,z) SMD aspetta_risp(y,z) #else #define AspettaRisposta(x,y,z) SMD rqwait(x,z) #endif A #define makes it possible to compare the two solutions with the same efficiency you'll get in the final version. A workaround, such as an extra procedure which does the same job, generates some extra code and may not tell you the full story. It's not matter of rethinking the design, but of picking up the best design. Just my 2 cents Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Anchors on a child form
Il 04/06/2018 14:06, Martin Wynne ha scritto: uses Unit1; procedure TForm2.FormCreate(Sender: TObject); begin Parent:=Form1; Anchors:=[]; Visible:=True; end; 4. run it, and the debugger will show the error message. Just remove the two lines Parent:= Form1; (which is wrong, because it makes Form2 a widget inside Form1) and Anchors:=[]; (which is useless) And it will work. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Anchors on a child form
Il 03/06/2018 14:06, Martin Wynne ha scritto: I'm porting a project to Lazarus from Delphi5, where it works fine. Child forms can be dragged around even with the top and left anchors set. Thanks for any help in fixing this This appears to be a topic for the Lazarus list, as it appears that you're using the Lazarus LCL: laza...@lists.lazarus-ide.org There you may obtain adequate assistance. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using constants instead of comments
Il 18/04/2018 05:06, James Richters ha scritto: is there a better way to optionally exclude diagnostic information entirely from the compiled program? Did you consider to replace your Writeln with a DiagWrite (or whatever name you prefer), and have a DiagWrite such as: DiagWrite: Procedure(aMessage: string); inline; begin if diagnosticdetail then Writeln(aMessage); end; This should do the job, and reduce your typing. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
Il 08/01/2018 21:30, Graeme Geldenhuys ha scritto: I was horified to find out how much slower Delphi's Generics were compared to TList and TObjectList I don't expect FPC behave much better. Whenever you move something from compile time to execution time you may gain in flexibility, but you surely lose in performance. Whenever a generic can be replaced by an if .. then .. else .., using a generic is just an useless performance killer. The same holds true for using a TObject, when a record would be enough or for using an Interface instead of just linking the appropriate library when this would be possible (see Lazarus vs fpGui!). Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C code
Il 06/01/2018 01:39, Darius Blaszyk ha scritto: #define MEMNEXT(x) ((MyStruct *)(((char *) x) - ((char *) & (((MyStruct *)0)->next h2pas translates it into the enclosed file. Hope that it helps. Giuliano darius.pp Description: application/wine-extension-pp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get user ID for name on Linux
Il 03/01/2018 01:12, Tobias Giesen ha scritto:
I would like to get the user ID for a Linux user name.
You might execute from the application the "/usr/bin/id" command
which should exist in any Linux flavour passing the required user
name ( if it's the current user, UserName :=
GetEnvironmentVariableUTF8('USERNAME'); ) as a parameter and then
parse the resulting output, sort of:
uid=500(colla) gid=500(colla)
groups=500(colla),3(sys),5(tty),18(dialout)
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What happened to FileOpen in trunk?
Il 27/12/2017 18:40, Michael Van Canneyt ha scritto: Your code was simply lucky to work in the beginning. It's not guaranteed that passing OS-Specific options to FileOpen will work. using fpOpen is the correct method, since you're using OS-specific features. Understood. Thanks a lot. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] What happened to FileOpen in trunk?
In multi-thread applications in Linux environment, I'm using FIFO's for communicating between threads. In order to make it work properly, the FIFO must be opened in non blocking mode. Up to fpc 3.0.4 I've been successfully using code like this: fdc := FileOpen(myFifo,fmOpenWrite or O_NONBLOCK); now in trunk the call returns forever an EAGAIN error (as if the O_NOBLOCK flag was not forwarded to OS), and to make it work I'm forced to use a call to fpOpen: fdc := fpOpen(myFifo,O_RDWR or O_NONBLOCK); which works properly. Is this an fpc new feature or a bug? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is there some example of an FPC program for use in svn hook calls (email)?
Il 14/12/2017 18:02, Bo Berglund ha scritto: But*sending email* is not the problem, I have done this in many applications using Indy TIdSMTP. Instead it is getting data out oof svn and formatting these in a friendly looking email to be sent You might find useful guidelines in the fpcup and fpcupdeluxe programs which extensively use svn to automatically update the fpc and lazarus versions from svn: https://github.com/LongDirtyAnimAlf/Reiniero-fpcup https://github.com/newpascal/fpcupdeluxe (btw they provide also a comfortable way to keep different fpc and lazarus versions on the same platform, to set them up for crosscompiling, etc.) Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unable to compile fpc 3.0.4
Il 09/12/2017 22:06, Pierre Muller ha scritto: Simply try to run make but adding -n to Free Pascal compiler options, simply by using make OPT=-n or make OPT="-n ALL_OPTIONS_YOU_USED_BEFORE" OPT=-n did the trick. It remains obscure to me while paszlib did origin to the problem, while other packages did compile properly, but as long as it works... Merci beaucoup. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Unable to compile fpc 3.0.4
I've stumbled into a problem. On one platform (linux x86_64, distro is CentOs6) I'm unable to compile fpc packages of fpc 3.0.4 The compiler is successful but the package compilation fails on package paszlib. The error given is zbase.pas(446,7) Error: Illegal expression zbase.pas(447,36) Error: Operator is not overloaded: "Constant String" + "zError(LongInt):AnsiString;" zbase.pas(506) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted The affected lines are: str(err,zerror); zerror:='Unknown zlib error '+zerror; if I patch those lines, sort of: //str(err,zerror); zerror:='Unknown zlib error ';//+zerror; then compilation fails in trees.pas: all occurences of tree[n].xx give raise to an error trees.pas(871,18) Error: Array type required (followed by 30 more similar messages) I have no clue of where could be the problem. Any hint will be greatly appreciated. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OT: what happened with the Lazarus mailing list?
Il 25/11/2017 09:29, Lubos Pintes ha scritto: I don't know if the problem is somewhere on my side, but the latest message in Lazarus mailing list on gmane.org is from November 17. Same here. I'm subscribed to the Lazarus mailing list, but last message i got is of nov 17, 10:23. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] installing cross fpc in parallel to systems fpc
Il 09/11/2017 22:56, Marc Santhoff ha scritto: I see, so when using fpc for ARM these define is automatically set? Yes And would that be CPUAVR for Atmels chips? Not sure about that. I never used fpc on Atmel chips. When I'm in doubt about the conditional defines, I either google or take advantage of Lazarus: in project->options I select the target CPU family and the target processor, and then I use "show all options" to see which defines are set. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] installing cross fpc in parallel to systems fpc
Il 09/11/2017 02:36, Marc Santhoff ha scritto: how does fpc and it's makefiles handle the case of installing a cross compiler on a system having fpc installed? The target path will differ and I can set that, but how is the config file .fpc.cfg handled? You may edit your fpc.cfg for your different target using an IFDEF/ENDIF pair. Under Linux I have in my home directory a .fpc.cfg sort of: #include /etc/fpc.cfg <--- to get all the defaults #IFDEF CPUARM here all the ARM specific paths and options #ENDIF That's the basic idea. All that's between #IFDEF -- #ENDIF is ignored when you're *not* cross-compiling. All that's between #IFDEF -- #ENDIF overrides the previous settings when you're cross-compiling Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3
Il 04/06/2017 08:02, Bo Berglund ha scritto: But I also have other systems where a real time system would be handy. Do you have more info on this? Yes. There was a bug in the way the FIQ was handled in a multicore ARM CPU (i.e. RPi2 and RPi3) , which was causing random freezes, not much frequent with vanilla kernels, but much more frequent with an RT_PREEMPT kernel. Finally someone (Oussama Ghorbel) took care of this and provided a patch. Now at the OSADL (Open Source Automation Development Lab) Realtime QA Farm a system is under test with an uptime of 173 days, which makes it promising. You may download kernel and patches from their website: https://www.osadl.org/Profile-of-system-in-rack-7-slot-3.qa-profile-r7s3.0.html?shadow=1 I did it and it works just fine. Another workaround for the problem can be disabling the Fast Interrupt Queue in the command line, playing with kernel parameters. You can find more details in: https://www.raspberrypi.org/forums/viewtopic.php?f=29=159170=1094375#p1094375 Then, if you're new to real time under Linux, you might find handy our Real Time Framework (YRMX), which provides a sort of high level interface, robust, efficient, easy to exploit and now also fpc compatible, to the pthread library. You'll find a description, both in a pdf paper and pdf slides at: http://www.copeca.it/OSADL/ Feel free to ask if you have more questions, or if you're interested in YRMX. It's GPL'd but not yet published. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3
Il 29/05/2017 23:28, Bo Berglund ha scritto: I have bought and initialized a new RPi3 today. It runs Raspbian Jessie PIXEL latest version. I don't know what you're going to use your RPi3 for, but just in case, are you aware that now you can install an RT_PREEMPT kernel, and enjoy the real-time patch low latencies? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Correct syntax for initialized constants/variables
Il 27/04/2017 20:49, Ralf Quint ha scritto:
I see in the reference docs (section 4.4) examples for arrays and
examples for records, but in my case, I would need to properly define an
array of records.
Any hint/example for the proper syntax in that case would be deeply
appreciated, it's probably something simple that I am missing,
This comes from a working program, and the compiler didn't complain, so
I assume it is the correct syntax (the added comments are unnecessary,
of course):
type
Tentry = record
bf: array [0..3] of Integer;
sq: array [0..3] of Integer;
ls: array [0..3] of Integer;
ins:array [0..3] of Integer;
end;
var
TTAB_XX: array[0..3] of Tentry = (
{ N=0 }
{ bf }(bf: (0,0,0,0);
{ sq }sq: (1,2,0,0);
{ ls }ls: (0,3,0,0);
{ ins}ins:(1,0,0,0)),
{ N=1 }
{ bf }(bf: (0,0,0,0);
{ sq }sq: (1,1,0,0);
{ ls }ls: (3,0,0,0);
{ ins}ins:(1,0,0,0)),
{ N=2 }
{ bf }(bf: (0,0,0,0);
{ sq }sq: (2,0,0,0);
{ ls }ls: (3,0,0,0);
{ ins}ins:(1,0,0,0)),
{ N=3 }
{ bf }(bf: (0,0,0,0);
{ sq }sq: (3,0,0,0);
{ ls }ls: (3,0,0,0);
{ ins}ins:(1,0,0,0)));
I hope that it helps,
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hash List
Il 12/04/2017 15:57, Michael Van Canneyt ha scritto: we could put it in contnrs, and alias it in inifiles.pp +1 Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading vs Parallelism ?
Il 30/03/2017 00:26, fredvs ha scritto: Perfect, I have now all the arguments to defend the "Dinosaur Threading" choice. When I'm charged of not using the most cool and new technology, my favourite argument are the tombstones. They're made out of stone, which is a stone-age technology. But, as nothing more suitable has been found for that purpose, the stone-age technology survives. Up to now it turns out to be the most appropriate technology for that application. The best course is always to pick up the most *appropriate* technology, as opposed to the one most *modern* or *fashionable*. There are applications where parallel computing is the best solution, and applications where parallel computing is useless. My main line is on industrial process control. You must react in real-time to "events". A multi-threading approach, with threads activated by events, gives a performance which you can't achieve with any other technique. But if you attempt to apply our event-driven approach to optimize a matrix calculation you'll miserably fail. Just my 2c Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
Il 05/04/2017 18:09, Bart ha scritto:
http://www.freepascal.org/docs-html/current/rtl/system/random.html
"Random returns a random number larger or equal to 0 and strictly less than L"
However random(a negative number) returns a number <= 0 and > L
program r;
begin
randomize;
writeln('Random(-10) = ',Random(-10));
end.
C:\Users\Bart\LazarusProjecten>test
random(-10) = -1
C:\Users\Bart\LazarusProjecten>test
random(-10) = -4
Maybe my understanding of English ("strictly less than") is not
correct, so I ask here before posting as a bugreport.
My scant knowledge of English leads me to believe that the sentence
should be rephrased in order to cover the negative numbers case:
either:
Random return a random number with the same sign of L, and whose
absolute value is larger or equal to zero and strictly less than the
absolute value of L.
or:
Random return a random number in the range 0 (included) to L (excluded).
Just my 2c.
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] INVALID_SOCKET constant not defined for Linux
Il 28/03/2017 12:34, LacaK ha scritto: This technique is used in fcl-net which should be cross-platform. So I am right, when I say that also in Linux invald socket = -1 (in other words: in case of error syscall() returns always -1) Becuase in other place I see another test "if socket < 0 then ..." (which may mean that any negative value can be returned) Most likely this is only because "socket < 0" is faster to write than "socket = -1" :-) From Linux man page for socket: RETURN VALUE On success, a file descriptor for the new socket is returned. On error, -1 is returned, and errno is set appropriately. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi for Linux is out
Il 23/03/2017 17:19, Sven Barth via fpc-pascal ha scritto: In the end you'll just need the correct units to do GUI applications as well though one would need to do everything by hand as there'd be no VCL or FM :P IOW with the newest Delphi for Linux you're in a worse condition than using old Kylix! We are still supporting a lot of old Kylix applications, and, when I'm too lazy to bring up a VM with an old Linux supporting the Kylix IDE, I just edit the files using Lazarus, and then compile the app using dcc which still runs on today's distro's (provided you supply it the required Kylix libraries). Even the app runs on today distro's, provided you feed it with its 32 bit libraries. Whenever possible we migrate the app to Lazarus, and then you feel like updating a Lazarus 0.9x app to Lazarus 1.6! Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Windows - Force files to write to disk
Il 22/03/2017 14:21, Karoly Balogh (Charlie/SGR) ha scritto: Hi, On Wed, 22 Mar 2017, Giuliano Colla wrote: Il 22/03/2017 13:20, James Richters ha scritto: No, it is not only freepascal, but not every program either. A wild guess. The vilain could be the journal logic. Wild indeed. :) You might try overwriting the old file instead of clearing it. Something like: Assign. Seek to the beginning of the file. (instead of rewrite) Write whatever you need. Truncate. Close. This will give the journal a different story to cope with. Maybe it will help. Even if this would work (no idea), it builds completely on assumptions and the behavior might be different depending on the underlying storage system. It's not atomic as well, because if you get a power loss during the above process, you could still end up with a broken file with random contents. So it is dangerous, and could be very hard to reproduce if it causes problems. See my other mails about the documented way, and what Microsoft seem to suggest. There's no doubt that the best solution would be writing a new file and then renaming it, second only to using an UPS to protect against accidental power loss, which costs just a fraction of the time value spent in this discussion. My suggestion was just a test to get an idea on how the MS Journaling works, and which pitfalls it may hide. If they store/execute the pending operations not in the order they where given, but giving somehow precedence to the operations faster to execute, and dropping the actions which are no more executable, you might end up with a renamed file which is still empty, because its creation and renaming are by far much faster than writing it! As far as Microsoft's suggestion are related, a friend of mine with some decades of career as a MCSE once told me is that, according his experience, the best course to take is always *not* to follow Microsofts suggestions, but to do exactly the opposite:-) Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Windows - Force files to write to disk
Il 22/03/2017 13:20, James Richters ha scritto: No, it is not only freepascal, but not every program either. A wild guess. The vilain could be the journal logic. The journal tells that the write operation has not been completed at power off, and restores the last valid version of the file, which was empty, because of the rewrite you performed after assigning. You might try overwriting the old file instead of clearing it. Something like: Assign. Seek to the beginning of the file. (instead of rewrite) Write whatever you need. Truncate. Close. This will give the journal a different story to cope with. Maybe it will help. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hash List
Il 18/03/2017 00:29, African Wild Dog ha scritto: Ia there any hash list implementation in free Pascal? The IniFiles unit (fpc/packages/fcl-base/src/inifiles.pp) provides a THashedStringList (descendant from TstringList) which I'm using reliably since many years. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking to Linux on a FreeBSD system with Linux emulated ?
Il 09/09/2016 10:17, Graeme Geldenhuys ha scritto: Unfortunately I don't have any other 32-bit FreeBSD VM where I can install FPC 3.0.0 on. I know that you don't like automated scripts, but you should consider fpcup (or fpclazup), in order to experiment with different fpc/Lazarus versions. You may safely use without messing up your setup, because it provides an installation of fpc (and Lazarus) completely independent of your main installation, in a "sandbox" path. As it provides a number of nice tricks to keep it completely independent, you may use as it is, or just use it to look at the tricks, and then create your own scripts. Just my 2c Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THashedStringList doesn't honour CaseSensitive?
Il 02/09/2016 14:20, Michael Van Canneyt ha scritto: On Fri, 2 Sep 2016, Giuliano Colla wrote: In my application I stumbled into a problem with a search in a HashedStringList: IndexOfName doesn't return the proper index if the search string doesn't match the name case, even if CaseSensitive is set to false. For common sense and Delphi compatibility (http://docwiki.embarcadero.com/Libraries/Berlin/en/System.IniFiles.THashedStringList_Properties) CaseSensitive should be supported. Am I doing something wrong, or it is an fpc missing feature? Please report a bug. Done: http://bugs.freepascal.org/view.php?id=30568 I have attached a small patch which should fix the issue. As a side issue, Delphi's TIniFiles, (at least in the CLX version which I checked), uses a THashedStringList for better efficiency. Once THashedStringList supports the CaseSensitive flag, it can be used in fpc too. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] THashedStringList doesn't honour CaseSensitive?
In my application I stumbled into a problem with a search in a HashedStringList: IndexOfName doesn't return the proper index if the search string doesn't match the name case, even if CaseSensitive is set to false. For common sense and Delphi compatibility (http://docwiki.embarcadero.com/Libraries/Berlin/en/System.IniFiles.THashedStringList_Properties) CaseSensitive should be supported. Am I doing something wrong, or it is an fpc missing feature? Verified both with fpc 2.6.4 and fpc 3.0.0 Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] old school crc32
Il 24/07/2016 01:18, wkitt...@windstream.net ha scritto: this is driving me battier than i already am :( i have a binary file that contains a record of data... the first field of the data is a crc32 value of a string of characters... the string of characters is lower cased before being fed to the crc32 function... i need to calculate the same crc32 value as what is stored in the file... i've already checked the polynomial ($edb88320) is the same in both, the original implementation (converted to TP4 in 1988) and this implementation... the original routine uses longint and speaks of initializing the variable to $ before feeding it to the crc32 routine... the existing routine in FPC says "Pre- and post-conditioning (one's complement) is performed within this function so it shouldn't be done by the application." but that doesn't give me the proper answer in this case... i've tried using cardinal types and longint types to no avail... the following is so so so very close but now i'm bald headed, completely lost in the deep dark woods and can't find my breadcrumbs any more :( What I'd do in your place would be to forget about strings, and use just an array of bytes. This way you're sure that you don't have in the way the string length value and some automatic encoding conversion, which messes up things. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unable to compile 3.0.0 both Linux x86_64 and arm-linux
Il 17/07/2016 20:01, Jonas Maebe ha scritto: Could you edit that wiki page and remove the -Sd so other people won't run in the same problem? Thanks. Sorry, bad link. That's the good one: http://wiki.freepascal.org/Setup_Cross_Compile_For_ARM#Create_custom_fpc.cfg Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unable to compile 3.0.0 both Linux x86_64 and arm-linux
Il 17/07/2016 20:01, Jonas Maebe ha scritto: Could you edit that wiki page and remove the -Sd so other people won't run in the same problem? Thanks. Done. http://wiki.freepascal.org/Setup_Cross_Compile_For_ARM#Configure_Lazarus_for_cross_Compile I was planning to edit this page when I was completely done, because many points are obsolete, but this clean up takes priority. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unable to compile 3.0.0 both Linux x86_64 and arm-linux
Il 17/07/2016 17:34, Jonas Maebe ha scritto: Try adding OPT=-va FPMAKEOPT=-v to the make invocation and check the output to see whether the compiler is picking up any extra configuration files or options somehow. That's it! I had just pasted from the wiki page an extra fpc.cfg for cross compiling, and I had failed to notice that it had an extra -Sd added, which has nothing to do with cross-compiling, but which generates troubles around. Thanks a lot for your help! Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unable to compile 3.0.0 both Linux x86_64 and arm-linux
Il 16/07/2016 15:52, Jonas Maebe ha scritto: These errors suggest you are not compiling that unit in FPC mode. If you use the top level Makefile in the fpcsrc directory, it will compile the packages directory with RELEASE=1, which in turn causes -n to be added to the FPC command line options so that it ignores any default (.)fpc.cfg files (that may otherwise contain -Mdelphi or so). The default compiler mode in FPC (including 3.0) is plain FPC mode. I'm using the top level Makefile, while buildin All. Everything else, before that package, compiles properly (compiler, LCL, other packages, etc.) Should I locate something specific which might turn off FPC mode in the affecting package Makefiles or fpmake or whatever, or in the upper folder (packages)? Thanks, Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] unable to compile 3.0.0 both Linux x86_64 and arm-linux
Hello, I'm trying to upgrade from fpc 2.6.4 to 3.0.0 but make all fails both in Linux x86_64 platfoms and in arm-linux (Raspbian) plaform. I've downloaded a precompiled 3.0.0 in order to be able to compile. I have also tried using fpcup, but the result is the same in all cases: while compiling package paszlib, in file zbase.pas it fails with: zbase.pas(446,7) Error: Illegal expression where the offending line is a simple str(err,zerror); and with zbase.pas(447,36) Error: Operator is not overloaded: "Constant String" + "zError(LongInt):AnsiString;" where the offending line is zerror:='Unknown zlib error '+zerror; If I try to continue by patching the offending lines, the unit compiles but then I get tons of errors from the trees.pas unit. Any idea? Do I need to add some options previously unneeded besides '-gl -O3p3' ? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Happy tickets benchmark
Il 14/02/2016 11:09, Florian Klaempfl ha scritto: But actually, before bothering randomly with command line options, I would just rewrite the inner loop. Something like for n7 := 0 to 9 do if n1 + n2 + n3 + n4 - n5 - n6 - n7 in [0..9] then Inc(TicketsCount); should be much better. For the record: Platform: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz OS: Linux CentOs 6 1) With FPC Compiler: fpc 2.6.4. Compiler flags: -O3 -Cr- Inc(TicketsCount) replaced with TicketCounts:=TicketCounts+1 Original inner loop: [colla@probookcolla SandBox]$ ./HappyTickets Found 4816030 tickets. Elapsed time, msec: 215 (range from 215 to 225) Florian's inner loop: [colla@probookcolla SandBox]$ ./HappyTickets_florian Found 4816030 tickets. Elapsed time, msec: 20 (range: from 17 to 26 ms) 2) With GNU C Compiler: gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) Compiler flags: -O3 Found 4816030 tickets. Time elapsed: 80. msec [colla@probookcolla SandBox]$ ./happytickets (range from 70 to 80 ms) My conclusion: depending on how you code, GCC wins over FPC by 3-1 or FPC wins over GCC 4-1! Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IfThen() intrinsic removed
Il 05/02/2016 10:58, Michael Van Canneyt ha scritto: And please remember, we do not NEED this construct; the added value is marginal as I indicated. Simply not adding is an option. Not all change is necessarily progress. +1 C philosophy is to save *typing* time. Pascal philosophy is to save *development* time. Typing is but a small fraction of development. Attempts to save typing usually end up in making the code less readable, and therefore harder to debug, to maintain, to share between developers, etc. Just my 2 c. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] loadlibrary() unsafe ?
Il 20/06/2015 17:11, fredvs ha scritto: Re-re-re-Hello. This one does not work too ;-( = - AProcess.Environment.Text := 'LD_PRELOAD=/home/fred/sak/sak/sakit/liblinux64/libportaudio.so' ; ??? Many thanks. Have you tried: AProcess.Environment.Text := LD_LIBRARY_PATH=/home/fred/sak/sak/sakit/liblinux64/ ? Once supplied the right folder, this should be sufficient to make the loader search the proper file. Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] THashedStringList.IndexOfName returns bogus value for empty string
Hi fpc experts. I've just discovered that THashedStringList.IndexOfName often return a bogus value instead of the expected -1 when the parameter passed is an empty string. The value returned depends on the hash content. This happens both with fpc 2.6.4 and with fpc 2.7.1. Should I enter an issue in the bugtracker? Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Il 02/01/2015 13:47, Jonas Maebe ha scritto: On 02/01/15 13:35, Giuliano Colla wrote: Contrary to what written in docs, DefaultFormatSettings aren't adjusted to the current locale in Linux at the startup of an application both on fpc 2.6.4 and on fpc 2.7.1. Where is this written? At least http://www.freepascal.org/docs-html/rtl/sysutils/defaultformatsettings.html doesn't say anything like that. See here: http://www.freepascal.org/docs-html/rtl/sysutils/shortdaynames.html Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FormatSettings not updated in Linux
Contrary to what written in docs, DefaultFormatSettings aren't adjusted to the current locale in Linux at the startup of an application both on fpc 2.6.4 and on fpc 2.7.1. One is forced to explicitly add clocale in the uses section of the application, in order to get the proper locale settings. Did someone forget to add cloclale to the uses section of /rtl/unix/sysutils.pp or there's another reason for this? Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Trying to register a Windows Service gives error
Il 07/10/2014 13:31, Graeme Geldenhuys ha scritto: Hi Michael, On 07/10/2014 12:12, Michael Schnell wrote: Please don't use such excessive multi-line declaimers in a forum. I did notice those (and don't like it either), but unfortunately nothing I can do about it. It is my work address and our mail server injects those disclaimers _after_ we sent the messages from our computers. It's the way lawyers try to appear indispensable: annoying everybody with useless lengthy legal stuff. Decent people, when receiving an e-mail not meant for them, just trash it. Marauders will try to take advantage from it, no matter how long is the disclaimer. Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mapping Cairo pixmap to FPC Bitmap and back
Thanks a lot. Muito obrigado. Giuliano Il 22/09/2014 02:32, luiz americo pereira camara ha scritto: https://code.google.com/p/luipack/source/browse/trunk/cairo/lcl/cairolcl.pas#152 https://code.google.com/p/luipack/source/browse/trunk/cairo/lcl/include/win32/cairolcl.inc#4 Direct bitmap data access (possible also with LCL.TBitmap in some cases) https://code.google.com/p/luipack/source/browse/trunk/cairo/imaging/cairoimaging.pas#116 Luiz 2014-09-21 19:10 GMT-03:00 Giuliano Colla giuliano.co...@fastwebnet.it mailto:giuliano.co...@fastwebnet.it: Could anyone more knowledgeable than me point me in the right direction to find how a Cairo pixmap maps into a FPC Bitmap, and possibly to some existing code for doing the trick of converting from the one to the other, thus saving me hours of searching? Thanks in advance for any hint. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org mailto:fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Mapping Cairo pixmap to FPC Bitmap and back
Could anyone more knowledgeable than me point me in the right direction to find how a Cairo pixmap maps into a FPC Bitmap, and possibly to some existing code for doing the trick of converting from the one to the other, thus saving me hours of searching? Thanks in advance for any hint. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
Il 16/09/2014 12:26, Philippe ha scritto: could the compiler avoid with pitfalls? The with construct can be very handy, but should be used with caution, like a lot of other constructs, declarations, etc. E.g. for symbols present with the same name in different units, depending on the order of the uses declaration the one or the other will be picked up. The IDE codetools provide already a powerful checking tool: you stop with the cursor on a symbol, and it tells you which reference will be taken. More than that would be an overkill: if you don't take the time to verify that your with does what you expect, you can't blame neither the construct nor the compiler. Just my 5 cents Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] how to activate debug info
Hi fpc team. When I need to understand how some code works, I frequently use the debugger, and single-step. But when debugging Lazarus applications, I can single-step through user code and Lazarus code only, while fpc code is skipped. I presume that this is happening because my fpc binary is stripped of debug information. In the zillion of compiler options, which are the best ones to provide a non-stripped fpc binary? My environment is Linux, fpc 2.7.1 from svn. Thanks for any hint Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to activate debug info
Il 18/07/2014 14:30, Sven Barth ha scritto: Am 18.07.2014 14:09 schrieb Giuliano Colla giuliano.co...@fastwebnet.it mailto:giuliano.co...@fastwebnet.it: Hi fpc team. When I need to understand how some code works, I frequently use the debugger, and single-step. But when debugging Lazarus applications, I can single-step through user code and Lazarus code only, while fpc code is skipped. I presume that this is happening because my fpc binary is stripped of debug information. In the zillion of compiler options, which are the best ones to provide a non-stripped fpc binary? My environment is Linux, fpc 2.7.1 from svn. Generation of debug information is disabled by default for RTL, FCL and packages units (those distributed with FPC). To enable it you must build FPC like this: make OPT=-gl Of course you can add any other options you need for building. Regards, Sven Thanks a lot, Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] nonlcl widgetsets
Hi fpc wizards, I'm interested in the nonlcl topic, and I tested the source found in the examples (designnonlcl). But, getting it from trunk I stumbled into an error: in the module mywidgetdesigner.pas, /procedure GetObjInspNodeImageIndex(APersistent: TPersistent; var AIndex: integer); override;/ it complains that there's no ancestor method to override. This procedure appears to be currently unused, and commenting it out makes it possible to compile, and play with the example. Then I checked a previous stable version of Lazarus which I had at hand (version 1.0.8), and I noticed that this procedure isn't there. Now my question is: is getting the NodeImageIndex a stale remnant of the past, or a new feature one must be aware of, because it'll come into play in future (making therefore unwise to develop anything before the dust settles)? Thank in advance for any hint. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] nonlcl widgetsets
Il 11/06/2014 14:11, Sven Barth ha scritto: You should better ask this on Lazarus list. It might be non-LCL, but it's not non-Lazarus ;) I was mistaken because I found the reference on a post of Michael in this list. Sorry for the noise. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: [fpc-devel] Lazarus 1.0.8 Release
Il 19/03/2013 10:28, Mattias Gaertner ha scritto: The Lazarus team is glad to announce the release of Lazarus 1.0.8. This is a bug fix release, built with the current fpc 2.6.2. The previous release 1.0.6 was built with 2.6.0. Although with the last updates RHEL5.x and CentOs 5.x do claim to support the new compression format, they don't manage to handle those rpm's. I didn't test with Suse 10.x, but I'm afraid that the problem will be there too. For those interested, repackaged versions of Lazarus 1.0.8 and fpc 2.6.2, compatible with those distros can be downloaded from the following link: http://www.bononiadocta.it/Lazarus/ Have fun! Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Lukasz Sokol ha scritto: It is subtle, I agree, but in try try [code] finally [code] end; except [code] end; (my version) I can catch the errors of either normal and finally code; I assume that try...finally...end is the more important; it is try...finally.. end that has to go without errors, or else one will be reported; if no exception happens, except is omitted; the except section in this case, can catch anything and its job is to decide whether to allow further execution, show/log a message or bail out. (also AFAICS this way it is recommended to be used in most snippets) In your case (try..finally...end being the outer), what if it may not be possible to free the global resources (e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end to properly show user a message? Or if something else that has to be done in finally section, throws?) The purpose of the try..except construct is to allow the developer to put some remedy in case of errors, instead of just aborting the program. The purpose of the try..finally construct is to guarantee some actions even if the program is going to be aborted. The new constructs would provide both options at the same time. But I'm afraid that there's not a better solution good for all situation. It depends on what one tries to do in the try.. clause, on which errors one choses to deal with on the except clause, and the likelihood of recoverable errors in the finally clause. Allowing both constructs, (try..except..finally and try..finally..except) as Sven suggested, would most likely cover a broader range of cases. Then, sometimes someone will still need nested try..whatever, to deal with situations which do really require the HOLES you mentioned. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Sven Barth ha scritto: I don't see the point of a else or nonexcept branch. If I want code to be executed in the case that no exception happened (e.g. a Commit for a database transaction) then I put in the block started by the try... One might argue that an additional branch would increase readability, but I personally don't see a real use for it... You're right. At first glance it appeared to me a good idea, but actually it wouldn't provide anything useful. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use try-finally
OR try-except but there are situations where you need both. One of
the criteria is if the object is local or global since for a global
object it is likely that you place the .Free (or for a global object
better FreeAndNil()) into a destructor or finalization section (which
means that you have to stop the program in case of an error and not
continue showing just a dialog) so you'll need only the try-except if
you want to catch the exception. In case of a local object you'll
ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put
try-except extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except, just
try..finally just try..except..else etc.
The except..else is a very useful construct, because it provides a path
to a code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful
features.
What fpc developers think about that?
Giuliano
--
Giuliano Colla
Before activating the tongue, make sure that the brain is connected
(anonymous)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Michael Van Canneyt ha scritto:
On Wed, 13 Feb 2013, Giuliano Colla wrote:
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use
try-finally OR try-except but there are situations where you need
both. One of the criteria is if the object is local or global since
for a global object it is likely that you place the .Free (or for a
global object better FreeAndNil()) into a destructor or
finalization section (which means that you have to stop the program
in case of an error and not continue showing just a dialog) so
you'll need only the try-except if you want to catch the exception.
In case of a local object you'll ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put
try-except extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except,
just try..finally just try..except..else etc.
The except..else is a very useful construct, because it provides a
path to a code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful
features.
What fpc developers think about that?
Else is used in Except already to select between various classes:
try
..
except
on E : MyType do
begin
end
else
// exception is not MyType
end;
so that is a problem.
I didn't think of that, because I never use it. It would be nice to use
it the other way, but I understand it would break existing code. A
different keyword like nonexcept?
I see no problem in adding finally, if you define carefully when it is
executed.
IMHO the try..except..finally construct should provide exactly the same
functionality as a nested
try
try
[code]
except
[code]
end;
finally
[code]
end;
i.e. it should be executed whatever happened in the sections between try
and finally (except if somewhere there was an Application.terminate!).
Any exception not handled shoud be re-raised after the finally block has
been executed.
The advantage would be to get rid of one level of nesting, making the
code more readable and less error prone.
This would guarantee both proper error handling and freeing of global
resources, even in presence of errors.
Giuliano
--
Giuliano Colla
Before activating the tongue, make sure that the brain is connected
(anonymous)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Lukasz Sokol ha scritto: On 13/02/2013 13:14, Michael Van Canneyt wrote: I'd rephrase what I discussed with Sven Barth: this construct (the packed try.(1).finally.(2).except.(3).end;) - a packed/condensed version - I would be in favor of try..except..finally, as opposed to try..finally..except, because I believe it better to handle exceptions before, and clean-up after. Exception handling doesn't consist only in showing an error box, it may involve also providing a remedy to some errors, and hopefully passing to finally a cleaner situation to handle. I'm ready to change advise if proved wrong. - should be semantically EXACT to try.(HOLE1).try.(1).finally.(2).end;.(HOLE2).except.(3).end; Legend: (1,2,3): code blocks (HOLE1) possibility for the try..finally..end block to be skipped if exception happens here (HOLE2) possibility for code to be skipped if exception happens in the try...finally...end; block - except, it will not have the HOLEs. Because [maybe some statistics needed here] this is probably the main (most advocated ?) use of them both at the same time. - It shall allow any constructs that are allowed in traditional (1,2,3) code blocks to be used exactly the same way with the same meaning. The new way will: -flatten the source code (one indent level less) -shorten the source code (one 'try' and one 'end;' less) -provide automatic protection from falling into the (HOLEs). (thinkos and PEBKACs protection) (this is most important here I think). Note that I'm not advocating for this to replace the traditional constructs; Also I accept, that HOLEs may be perfectly justified code. But if someone needs them, they probably know what they are doing. If one is left free not to use the new construct, he can use the old one, and put in as many holes as he want. After all one is free to insert anywhere in the code a few assembler lines and to break anything fpc developers had in mind.. Giuliano -- Giuliano Colla Before activating the tongue, make sure that the brain is connected (anonymous) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/11/2013 09:14 PM, Sven Barth wrote:
It would be nice if you could minimize the problemematic code further
step by step so that we can see what caused the missing dialog.
Maybe it's a bug somewhere else...
I've made some further experiments with my minimal test.
Test form is just a Form with a Close button (BitBtn Kind=bkClose).
The full code is the following:
unit uinitfile;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs,
Buttons,IniFiles;
type
{ TForm1 }
TForm1 = class(TForm)
BitBtn1: TBitBtn;
procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
procedure FormCreate(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;
var
Form1: TForm1;
ini: TIniFile;
AppConfigFileName: string;
SomeData: boolean;
SomeOtherData: boolean;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.FormCreate(Sender: TObject);
begin
AppConfigFileName:= '/not/existing/path/inifile.cfg';
ini := TIniFile.Create(AppConfigFileName);
try
SomeData:= ini.ReadBool('Section','Val',true);
SomeOtherData:= ini.ReadBool('Section','Val1',true);
finally
ini.Free;
end;
end;
procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
ini:= TIniFile.Create(AppConfigFileName);
{$DEFINE Finally}
{$IFDEF Finally}
try
ini.WriteBool('Section','Val',SomeData);
ini.WriteBool('Section','Val1',SomeOtherData);
finally
ini.Free;
end;
{$ELSE}
try
ini.WriteBool('Section','Val',SomeData);
ini.WriteBool('Section','Val1',SomeOtherData);
except
MessageDlg('Error while writing '+AppConfigFileName,mtError,[mbOK],0);
end;
ini.Free;
{$ENDIF}
end;
end.
One may test two conditions: with try..finally and with try..except.
Even with this minimal sheds some light on the matter.
Try..finally situation, with IDE and Debugger.
Press the Close button. A debugger error notification is shown. Pressing
Continue, an error dialog is displayed: Unable to create ... press OK
to Ignore...etc.:
Pressing OK (no harm should come, just the file can't be written) the
form isn't closed as it should, and it's still there.
Pressing again the close Button, FormClose is executed again, and the
same dialog is shown. No way to close the form, unless you press Cancel
on the error dialog.
Why FormClose doesn't close the form in presence of an error (handled by
a try..finally) when writing the ini file?
Launching from command line, you have the same behavior, and an
additional information when you select Cancel:
WARNING: TLCLComponent.Destroy with LCLRefCount0. Hint: Maybe the component is
processing an event?
Try..except situation, from IDE and Debugger.
Press the Close button. Debugger Notification. Pressing Continue my
message dialog is shown. Pressing OK on my dialog the form is closed and
the program is terminated.
Launching from command line, no console messages.
My conclusion is that one can't properly handle INI files with just a
try..finally construct, as all examples show, because a possible error
will propagate outside the construct, with unpredictable effects (in
this case the FormClose procedure doesn't properly complete).
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/12/2013 10:02 AM, Mark Morgan Lloyd wrote: I admit that I was slightly trolling there, since Giuliano was complaining about exceptions that he wasn't seeing (because, it turns out, he wasn't catching them). You catch an exception if you can handle it. If a user for some reasons has write-protected a configuration file, there's nothing the application can do about it. One can usually rely on the system default exception handler to show the error message. If it doesn't happen, then there's something wrong somewhere. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/12/2013 01:58 PM, Mattias Gaertner wrote: The LCL has a default exception handler, so that the application notifies the user, that the application has a bug instead of simply crashing and vanishing silently. The programmr is reponsible to handle exceptions, show the user error messages and give the user choices (e.g. ignore, retry). That's what I was relying on. There's nothing the application can do if a user has write-protected the configuration files, or if there's a disk error while writing (I didn't think of a non existing .config/, because I've always found it there, before the last episode). So I was just happy with a system error, which in this case fails to show. As an additional information: in FormClose ini := TIniFile.Create(BadAppConfigFileName); try ini.WriteWhatever(... ... except on E: Exception do Application.ShowException(E); end; shows the error only on the console, but no visual dialog. While on E: Exception do MessageDlg(E.Message,mtError,[mbOk],0); shows a proper message dialog. Maybe this discussion should be moved to Lazarus list? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
