Re: [fpc-pascal] Pass open array to static array?
I just came across another related issue to this thread. Is it not possible to init dynamic arrays from static arrays? I remember there being more compatibility between the 2 types but I may have forgotten. var a: array[0..1] of integer; d: array of integer; begin d := a; end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Prevent full unit path in ppu files? together with -Ur
On 12/04/2020 16:31, Martin wrote: When building packages for an installer, one uses -Ur. Yet (on Windows) I noted, that the ppu contain the full path to the source file used to build that ppu. Not a major issue, but slightly awkward. - The files (ppu, and maybe sources) will be packed into an installer - The end user installs them to a patch of their choice. This is most likely different from the build system. In the best case, the end users system has now links to none existing files. In the worst case, the links point to a different installation, with different versions of the files. Well probably no harm, since fpc will not recompile those files. Problematic maybe if other tools (like Lazarus) read that info from the ppu. Therefore the question: Can that full path be prevented from getting into the ppu (or any other file)? Just digging a bit deeper, searching all files indicates that this full path is stored in *.fpm files ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Prevent full unit path in ppu files? together with -Ur
When building packages for an installer, one uses -Ur. Yet (on Windows) I noted, that the ppu contain the full path to the source file used to build that ppu. Not a major issue, but slightly awkward. - The files (ppu, and maybe sources) will be packed into an installer - The end user installs them to a patch of their choice. This is most likely different from the build system. In the best case, the end users system has now links to none existing files. In the worst case, the links point to a different installation, with different versions of the files. Well probably no harm, since fpc will not recompile those files. Problematic maybe if other tools (like Lazarus) read that info from the ppu. Therefore the question: Can that full path be prevented from getting into the ppu (or any other file)? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On 4/12/20 10:09 AM, wkitt...@windstream.net wrote: PPS: Bo, if you reply, please include the above PS when you reply to the list so that the list manager(s) can see this and maybe they can/will whitelist the synacor servers... i've had several postings get blocked in recent days because of this problem... looks like the block has been removed! YAY! :) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On 4/12/20 8:26 AM, Bo Berglund via fpc-pascal wrote: I am used to *not* hide files anytime both on Windows (where I always configure the explorer to show hidden files) and on Linux where I always use an ls -la alias ll in order not to hide files. Never understood the reason for hiding stuff... the reason for hiding certain files is presentation to the majority of the masses... 99.999% of users don't need or want to know about these files... they only care that their stuff works and that they can easily find what they are looking for without having to dig through a lot of what they would generally consider cruft and fluff... programmers and others interested in the nitty-gritty details are very much a minority PS: i'm replying to both, the list and Bo, because the synacor mail server seems to be blocked by some spam lists... synacor hosts email for numerous ISPs... windstream moved to synacor a few years ago rather than continuing to host their own email servers... it is a painful annoyance when legitimate services like synacor get blocked like this :( PPS: Bo, if you reply, please include the above PS when you reply to the list so that the list manager(s) can see this and maybe they can/will whitelist the synacor servers... i've had several postings get blocked in recent days because of this problem... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On 4/12/20 7:55 AM, Michael Van Canneyt wrote: All your OOTB problems can be solved without a single line of code change in the compiler. Just create a script that people should use to compile instead of directly using the 'fpc' command, and specify the config file in the script, and any other options you want for your OOTB experience. FWIW: fpcup on linux does this script to execute fpc... i was quite glad for it when i first used fpc up because it allowed me to find where it put fpc (and lazarus) ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wiki Image Database Corruption
Am 12.04.20 um 03:28 schrieb Trev: I've been trying to attract the attention of someone/anyone with virtual access to the Wiki webserver to fix the corrupted image database since January. I've tried (in order): * Wiki Feedback page: https://wiki.freepascal.org/Site_Feedback * Forums: https://forum.lazarus.freepascal.org/index.php/topic,48428.0.html * Bugtracker: https://bugs.freepascal.org/view.php?id=36784 all to no avail. This mailing list was suggested as the last chance saloon. I fear the problem is nobody knows what to do :( Nevertheless, the mailing lists are not the last but the best resort ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wiki Image Database Corruption
On 12/04/2020 03:28, Trev wrote: > I've been trying to attract the attention of someone/anyone with virtual > access to the Wiki webserver to fix the corrupted image database since > January. At least one of the backtraces you posted doesn't seem to point to a corrupted database, but to a bug in Mediawiki or an extension: https://phabricator.wikimedia.org/T236211 I've added a comment there. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sun, 12 Apr 2020, fredvs via fpc-pascal wrote: I would think this is about the biggest failure of all for a compiler ? Imo, the worst thing is when the compilation is ok but code are bad interpreted. simply because unix does not do this. OK, like I did for all my arguments, can you prove that? I never hear that is was forbidden to place a config file in same dir than executable and forbidden to use that config file in a search. I never claimed it was forbidden ? I applaud your efforts to provide an OOTB experience, and I think I have indicated there are plenty of options available for you to achieve what you want without the need to change the compiler any further: - Correct directory structure in a zip - Installer instruction style wget https://yoururl/ -O - | bash - wrapper script for fpc itself. Take your pick... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
>I would think this is about the biggest failure of all for a compiler ? Imo, the worst thing is when the compilation is ok but code are bad interpreted. > simply because unix does not do this. OK, like I did for all my arguments, can you prove that? I never hear that is was forbidden to place a config file in same dir than executable and forbidden to use that config file in a search. But, ok, I am very tired of all that discussion, thanks for all what was already done. Fre -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sun, 12 Apr 2020 12:16:20 +0200 (CEST), Michael Van Canneyt wrote: >You can hardly blame us for you not remembering things... :-) > >> Why does fpc look for .fpc.cfg in the user home dir when it is >> otherwise looking for fpc.cfg? > >Because the naming convention on unixes is like that for config files in >your home directory. This is not fpc specific. Well, I have used a setup script I wrote years ago to set up fpc/lazarus on Raspbian so I don't have to remember these things. Has worked just fine on many RPi units. The rename is hidden inside the script of course... And yesterday is the first time I did it on an Ubuntu system and I adapted the content of the script to manual commands and of course overlooked a script line that moved the fpc.cfg file to .fpc.cfg Thanks for the explanation on why it is as it is. I am used to *not* hide files anytime both on Windows (where I always configure the explorer to show hidden files) and on Linux where I always use an ls -la alias ll in order not to hide files. Never understood the reason for hiding stuff... Thanks for replying! -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sun, 12 Apr 2020, fredvs via fpc-pascal wrote: committed in rev. 44697 Yep, excellent! Note that this still may cause surprises, because paramstr(0) is not 100% reliable. Hum, ok, but I assume to take the risk. Finally, the worst that can happen is fail to compil. I would think this is about the biggest failure of all for a compiler ? Nice, FPC is nearly OOTB now. Only miss a very, very little patches: the "so.n" of course and the searchpath order. No. Sorry. I don't intend to budge on this last one. For backwards compatibility and simply because unix does not do this. I also have not seen any convincing argument why it is needed. It's definitely not needed for your "OOTB experience". In your zip use a directory structure /bin/ /etc/ and the compiler will find the config file by itself if you place it in etc. I agree that the .so.n can only be solved in the compiler, but this not. And to be correct: All your OOTB problems can be solved without a single line of code change in the compiler. Just create a script that people should use to compile instead of directly using the 'fpc' command, and specify the config file in the script, and any other options you want for your OOTB experience. Inside the script you have the ability to detect whatever you want: https://stackoverflow.com/questions/59895/how-to-get-the-source-directory-of-a-bash-script-from-within-the-script-itself You can even call the script 'fpc'. Most large projects use a script to "sanitize" the environment before starting the actual binary. Even the firefox browser does this, android studio, vmware player etc.. (I checked) And given all the customization you want to do, that seems like the best option to me, because I get the idea you will do a lot more customization still. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
> committed in rev. 44697 Yep, excellent! > Note that this still may cause surprises, because paramstr(0) is not 100% reliable. Hum, ok, but I assume to take the risk. Finally, the worst that can happen is fail to compil. Nice, FPC is nearly OOTB now. Only miss a very, very little patches: the "so.n" of course and the searchpath order. I feel that "so.n" patch has a possibility to be apply, I dont feel so much hostility about it. So I keep my force for the last combat, the "searchpath order": compiler/option.pas line 3349 function check_configfile(fn:string; var foundfn:string):boolean; if not FileExists(fn) then // current dir if CfgFileExists(IncludeTrailingBackslash(ExtractFilePath(ParamStr(0)))+fn) then // add this: foundfn:=IncludeTrailingBackslash(ExtractFilePath(ParamStr(0)))+fn // dir of compiler else Just convince that placing a config file in the same directory than then compiler is not a crime in Unix. And prove that directory of compiler has to be in second position for searching. And that it will not break any compatibility, even for Windows. OK, I am ready for the combat, I am sure of my arguments. Fre;D -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sun, 12 Apr 2020, Sven Barth via fpc-pascal wrote: Why does fpc look for .fpc.cfg in the user home dir when it is otherwise looking for fpc.cfg? Because the naming convention on unixes is like that for config files in your home directory. This is not fpc specific. This convention predates the systems used by desktop environments which nowadays puts everything in ~/.config or ~/.share or some other convention. But it is still in use today. Just for completeness sake: this is not a convention for configuration files, but for *hidden* files in general. While in the global configuration directory (/etc) all files are (normally) visible for everyone the idea is that inside the user's home directory in most cases the user is only interested in the normal files of themselves when doing a "ls". Hidden files and directories are only shown with "ls -a". That is why FPC's configuration file is hidden: its good tone to hide configuration files in the user's home directory. Exactly. That is also why the config directory is called .config or .share. it is then 'hidden' by default. Thank you for completing my explanation. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
Michael Van Canneyt schrieb am So., 12. Apr. 2020, 12:16: > > > On Sun, 12 Apr 2020, Bo Berglund via fpc-pascal wrote: > > > On Fri, 10 Apr 2020 13:44:17 -0700 (MST), fredvs via fpc-pascal > > wrote: > > > >> 2)Your home directory, it looks for .fpc.cfg. > > > > This is something I have been wondering about for a while.. > > When I install FPC from sources I have to create a config file by > > using this command: > > > > /home/user/lib/fpc/$FPCVER/samplecfg "/home/user/lib/fpc/$FPCVER" > > "/home/user" > > (replace "user" with the actual username such as pi or whatever) > > > > The problem with this is that the generated file is named fpc.cfg so I > > have to do a rename afterwards and this is not always remembered (like > > yesterday). > > You can hardly blame us for you not remembering things... :-) > > > Why does fpc look for .fpc.cfg in the user home dir when it is > > otherwise looking for fpc.cfg? > > Because the naming convention on unixes is like that for config files in > your home directory. This is not fpc specific. > > This convention predates the systems used by desktop environments which > nowadays puts > everything in ~/.config or ~/.share or some other convention. But it is > still in use today. > Just for completeness sake: this is not a convention for configuration files, but for *hidden* files in general. While in the global configuration directory (/etc) all files are (normally) visible for everyone the idea is that inside the user's home directory in most cases the user is only interested in the normal files of themselves when doing a "ls". Hidden files and directories are only shown with "ls -a". That is why FPC's configuration file is hidden: its good tone to hide configuration files in the user's home directory. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sun, 12 Apr 2020, Bo Berglund via fpc-pascal wrote: On Fri, 10 Apr 2020 13:44:17 -0700 (MST), fredvs via fpc-pascal wrote: 2)Your home directory, it looks for .fpc.cfg. This is something I have been wondering about for a while.. When I install FPC from sources I have to create a config file by using this command: /home/user/lib/fpc/$FPCVER/samplecfg "/home/user/lib/fpc/$FPCVER" "/home/user" (replace "user" with the actual username such as pi or whatever) The problem with this is that the generated file is named fpc.cfg so I have to do a rename afterwards and this is not always remembered (like yesterday). You can hardly blame us for you not remembering things... :-) Why does fpc look for .fpc.cfg in the user home dir when it is otherwise looking for fpc.cfg? Because the naming convention on unixes is like that for config files in your home directory. This is not fpc specific. This convention predates the systems used by desktop environments which nowadays puts everything in ~/.config or ~/.share or some other convention. But it is still in use today. So, rather than adapting to the flavour of the day config system, we stick to what - after all these years - is still common practice on unix, and which we have been consistently using since day 1. If you don't like this name, fine: you can set an environment variable to point the compiler to where it is. https://www.freepascal.org/docs-html/current/user/usersu10.html#x24-310003.1.5 You only need to do this once. So it's not like we don't offer you a myriad of ways to specify a config file... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Fri, 10 Apr 2020 13:44:17 -0700 (MST), fredvs via fpc-pascal wrote: >2)Your home directory, it looks for .fpc.cfg. This is something I have been wondering about for a while.. When I install FPC from sources I have to create a config file by using this command: /home/user/lib/fpc/$FPCVER/samplecfg "/home/user/lib/fpc/$FPCVER" "/home/user" (replace "user" with the actual username such as pi or whatever) The problem with this is that the generated file is named fpc.cfg so I have to do a rename afterwards and this is not always remembered (like yesterday). Why does fpc look for .fpc.cfg in the user home dir when it is otherwise looking for fpc.cfg? And if this is so, should not samplecfg be smart enough to drop off the correctly named cfg file if the target dir is the user's home dir? -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Wiki Image Database Corruption
I've been trying to attract the attention of someone/anyone with virtual access to the Wiki webserver to fix the corrupted image database since January. I've tried (in order): * Wiki Feedback page: https://wiki.freepascal.org/Site_Feedback * Forums: https://forum.lazarus.freepascal.org/index.php/topic,48428.0.html * Bugtracker: https://bugs.freepascal.org/view.php?id=36784 all to no avail. This mailing list was suggested as the last chance saloon. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sat, 11 Apr 2020, fredvs via fpc-pascal wrote:
I did try this without luck:
-Fu$PPC_EXEC_PATH/units/$fpctarget
-Fu$PPC_EXEC_PATH/units/$fpctarget/*
-Fu$PPC_EXEC_PATH/units/$fpctarget/rtl
PPC_EXEC_PATH is an environment variable, not a compiler variable.
see globals.pas:
localexepath:=GetEnvironmentVariable('PPC_EXEC_PATH');
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Search path order for fpc.cfg
On Sat, 11 Apr 2020, fredvs via fpc-pascal wrote:
I promise, it is the last for tonight.
It would be wonderful if in /compiler/globals.pas, at line 906, you add this
line (or something like that):
{ Replace some macros }
Replace(s,'$FPCPATH',AnsiString(IncludeTrailingBackslash(ExtractFilePath(ParamStr(0);
So in fpc.cfg you may do:
-Fu$FPCPATH/units/$fpctarget
-Fu$FPCPATH/units/$fpctarget/*
-Fu$FPCPATH/units/$fpctarget/rtl
And it works like charm.
That is _exactly_ what I was talking about when I suggested adding some macros.
I added this:
Replace(s,'$FPCBINDIR',ExtractFilePath(FixFileName(system.paramstr(0;
Changed the name because 'Path' is used for search paths.
Note that this still may cause surprises, because paramstr(0) is not 100%
reliable.
committed in rev. 44697
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error format question
Ryan Joseph via fpc-pascal schrieb am So., 12. Apr. 2020, 08:53: > > > > On Apr 12, 2020, at 11:16 AM, Ryan Joseph wrote: > > > > I just did svn up and got r44689, rebuilt the compiler but I still get > the same error format. Was it supposed to be changed? > > ok, I think we're confused here. Just actually tested gcc and got this > format: > > /Users/ryanjoseph/Developer/Projects/C++/Tests/test:10:6: error: > expected expression > > > This means that FPC 3.0.4 is giving the wrong format and I guess we're > stuck with that like it is. That means trunk is and was fine like it is. > Correct. That's what Florian had fixed. We'll just have to make sure that revision is merged to 3.2 as well... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error format question
> On Apr 12, 2020, at 11:16 AM, Ryan Joseph wrote: > > I just did svn up and got r44689, rebuilt the compiler but I still get the > same error format. Was it supposed to be changed? ok, I think we're confused here. Just actually tested gcc and got this format: /Users/ryanjoseph/Developer/Projects/C++/Tests/test:10:6: error: expected expression This means that FPC 3.0.4 is giving the wrong format and I guess we're stuck with that like it is. That means trunk is and was fine like it is. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
