Re: [fpc-pascal] FPC 3.2.0 released!
Great news! Thank you to the FPC team for all magnificent work. I maintain Docker images with FPC (with various versions and cross-compilers, with Castle Game Engine and some related tools), see https://hub.docker.com/r/kambi/castle-engine-cloud-builds-tools/ and https://github.com/castle-engine/castle-engine/wiki/Docker . I just updated them to contain FPC 3.2.0 (and use it by default, as "latest stable release"). Regards, Michalis sob., 20 cze 2020 o 23:59 Tomas Hajny napisał(a): > On 2020-06-20 19:47, code dz via fpc-pascal wrote: > > great . > > but why fpc-3.2.0.i386-win32.exe in the ftp site is different in size > > and date than sourceforge one > > They have the same size, it's just the SF webpage shows the size > differently from the FTP listing: > > [SF.net]$ ls -l /home/frs/project/freepascal/Win32/3.2.0 > total 379964 > [permissions and ownership hidden] 99388066 Jun 16 00:15 > fpc-3.2.0.i386-win32.cross.android.exe > [permissions and ownership hidden] 27577540 Jun 16 00:15 > fpc-3.2.0.i386-win32.cross.arm-wince.exe > [permissions and ownership hidden] 168171805 Jun 16 20:03 > fpc-3.2.0.i386-win32.cross.i8086-msdos.exe > [permissions and ownership hidden] 40791180 Jun 16 00:16 > fpc-3.2.0.i386-win32.cross.x86_64-win64.exe > [permissions and ownership hidden] 53136366 Jun 16 00:16 > fpc-3.2.0.i386-win32.exe > [permissions and ownership hidden] 16097 Jun 16 21:00 readme.txt > > > [FTP site]$ ls -l ftp/dist/3.2.0/i386-win32 > total 379956 > [permissions and ownership hidden] 99388066 Jun 5 12:43 > fpc-3.2.0.i386-win32.cross.android.exe > [permissions and ownership hidden] 27577540 Jun 4 11:08 > fpc-3.2.0.i386-win32.cross.arm-wince.exe > [permissions and ownership hidden] 168171805 Jun 7 08:09 > fpc-3.2.0.i386-win32.cross.i8086-msdos.exe > [permissions and ownership hidden] 40791180 Jun 4 10:51 > fpc-3.2.0.i386-win32.cross.x86_64-win64.exe > [permissions and ownership hidden] 53136366 Jun 4 10:42 > fpc-3.2.0.i386-win32.exe > > > The dates differ because I didn't pay attention to use the -p parameter > while uploading the files ( :/ ), thus the date and time on SourceForge > reflect the time when the files were transferred there. BTW, the date > and time of files on the FTP site have no special meaning either (it > could be the time of uploading the files to the main FTP server, or the > time when the packages were prepared, or the time when they were updated > the last time (sometimes there may have been last minute fixes of e.g. a > certain source files or a readme file, etc.), or whatever. > > Tomas > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange "division by zero" error using variants
That's a funny interaction between Variants and Pascal's ambiguous
(logical or bitwise) "and" :) Both the operators and the types are
ambiguous -> making the boolean short-circuit evaluation not possible.
Indeed one workaround is to cast the variants to Booleans explicitly,
which makes it use logical "and" with expected result. I.e. this
doesn't raise "division by zero":
if Boolean(v1) and Boolean(v2 > 0) and Boolean((0+1) mod v2 = 0) then
Writeln ('ok');
Regards,
Michalis
wt., 24 maj 2022 o 22:52 Florian Klämpfl via fpc-pascal
napisał(a):
>
> Am 24.05.22 um 19:28 schrieb Thomas Kurz via fpc-pascal:
> > Dear all,
> >
> > please consider the following code:
> >
> >
> > program Project1;
> >
> > {$booleval off}
> >
> > var
> >v1, v2: variant;
> >a: boolean;
> >b: integer;
> >
> > begin
> >a := true;
> >b := 0;
> >// this works as expected:
> >if a and (b > 0) and ((0+1) mod b = 0) then Writeln ('ok');
> >
> >v1 := true;
> >v2 := 0;
> >// this gives a "division by zero":
> >if v1 and (v2 > 0) and ((0+1) mod v2 = 0) then Writeln ('ok');
> > end.
> >
> >
> > The "variant" variant results in a "division by zero". Obviously, it tries
> > to evaluate the modulo-expression even though this shouldn't happen because
> > complete boolean evaluation is disabled and the "if"-result is already
> > known to be false after checking "v2>0".
> >
> > Can anyone explain this strange behavior?
>
> When compiling the and expressions, the compiler does not know (in this
> example it could, but in general it cannot) what the variants contain so
> just the variant and-operator is executed which does not/cannot
> distinguish between the logical and bitwise and variant.
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Programming Pascal using an AI Chatbot
The chatbot is quite amazing :) I wrote about my nicest moments on https://castle-engine.io/wp/2022/12/17/my-mind-is-blown-i-can-use-ai-to-generate-castle-game-engine-code-to-integrate-it-with-physx-i-can-use-ai-to-generate-html-documentation-from-comments-in-pascal-code/ -- generate Pascal code to integrate Castle Game Engine + PhysX, or perform the job of PasDoc. It can do that :) Regards, Michalis niedz., 1 sty 2023 o 00:44 Anthony Walter via fpc-pascal napisał(a): > > The following page hosts a series of Pascal programming questions I asked an > AI chatbot system while testing its abilities. > > https://www.getlazarus.org/aichatbot > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What is -CO ?
I'm also curious :)
I just tested, and the -Co (lowercase "o") enables overflow checking
by default (like "{$Q+}" in code),
https://github.com/michaliskambi/modern-pascal-introduction/wiki/What-are-range-and-overflow-checks-(and-errors)-in-Pascal
.
But -CO (uppercase "O") seems unrelated to it.
This example:
"""
{$mode objfpc}
uses SysUtils;
var
A: Int64;
begin
A := High(Int64) - 100;
A := A + 200;
Writeln('Result is ', A);
end.
"""
... behaves the same, regardless if it's compiled with "-CO" or not.
(Only "-Co" is relevant, controls do we make overflow check, as
expected.)
Regards,
Michalis
pt., 9 cze 2023 o 12:03 Mattias Gaertner via fpc-pascal
napisał(a):
>
> Hi,
>
> What is -CO?
>
> In the docs I can only find this sentence:
> "Check for possible overflow of integer operations"
>
>
> Mattias
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc isn't optimised for tail recursion, is it?
Steve,
If you're looking for equivalent to "return X", use "Exit" with a
parameter in Pascal: "Exit(X)".
It's just a shortcut for "Result := X; Exit;"
Regards,
Michalis
pon., 12 cze 2023 o 19:57 Steve Litt via fpc-pascal
napisał(a):
>
> Nikolay Nikolov via fpc-pascal said on Mon, 12 Jun 2023 09:15:17 +0300
>
> >On 6/12/23 04:44, Steve Litt via fpc-pascal wrote:
>
> [snip]
>
> >> So, subject to your guidance, I'm assuming FPC isn't optimized for
> >> tail recursion. Is my assumption an accurate one?
> >
> >FPC supports tail recursion optimization, it is enabled at -O2
> >optimization level for most CPUs, however your code isn't eligible for
> >that optimization, because there's extra code, after the recursive
> >invoke. If you change it like that:
> >
> >program recursion_hello;
> >
> >function nextt(num: int64): int64;
> >begin
> >writeln('Going deeper=> ', num);
> >nextt := num;
> >if (num > 0) then
> > begin
> > nextt(num - 1);
> > end;
> >end;
> >
> >begin
> > nextt(10);
> >end.
> >
> >And if you compile with -O2 it works, without segfaulting (tested with
> >FPC 3.2.2 on x86_64-linux).
>
> Thanks Nickolay,
>
> You're right about not assigning nextt below the call to nextt, and
> about the -O2 argument. After learning from you about -O2 and
> investigating further, I used {$OPTIMIZE tailrec}, which isn't quite the
> same thing, but it worked beautifully. {$OPTIMIZE on} also enables tail
> recursion and speeds things up about 10% of tailrec.
>
> Thanks for your help.
>
> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [Lazarus] Lazarus server under DDOS
Note: As a consequence, the GitHub Action https://github.com/gcarreno/setup-lazarus also fails now. Trying to use it to install FPC+Lazarus results in an error Error: getPackageList -- Request timeout: /packagelist.json in GitHub Action workflow output. I guess because the action downloads https://packages.lazarus-ide.org/packagelist.json . Which, while it works in the normal browser (like Firefox) (with a considerable delay), but e.g. "wget" (with default timeouts) fails: $ wget https://packages.lazarus-ide.org/packagelist.json --2024-10-01 17:09:44-- https://packages.lazarus-ide.org/packagelist.json Resolving packages.lazarus-ide.org (packages.lazarus-ide.org)... 37.97.187.115, 2a01:7c8:aac1:2f0::1 Connecting to packages.lazarus-ide.org (packages.lazarus-ide.org)|37.97.187.115|:443... failed: Connection timed out. Connecting to packages.lazarus-ide.org (packages.lazarus-ide.org)|2a01:7c8:aac1:2f0::1|:443... failed: Network is unreachable. ( I understand this, I mean I'm writing above as just "FYI" for people who may be using https://github.com/gcarreno/setup-lazarus , like Castle Game Engine actions do. I was surprised today to see our GitHub Actions fail, but this explains it. I'm not "demanding" any action, sure you need to put limits to protect from DDOS. I'm just making a note to eventually relax these limits to at least enable the above wget again. ) Regards, Michalis wt., 1 paź 2024 o 11:00 Marc Weustink via lazarus napisał(a): > > Hi, > The Lazarus server is currently under heavy DDOS. This affects the > Lazarus main site, the Lazarus packages, the Lazarus mailing list > archives and the Lazarus+Freepascal forum. > I've enabled a rate limiter so the sites should be available again (in > the first few seconds it was active, it blocked 10k connection attempts) > but it might have some side effects using the forum. > I hope it gets over soon. > > Marc > -- > ___ > lazarus mailing list > laza...@lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding Javascript to Pascal
Karoly Balogh wrote: > We're in the offtopic again, but I really hate this kind of elitism. As a > kid I started with BASIC - on various Commodore home computers then also > on early IBM PCs - and I hope to think I grew up to be a semi-decent > programmer. At least I can fix your Pascal compiler for ya... It's good to hear some positive voices in this thread :) 1. Let's focus on constructive answers to questions like "how do I integrate Pascal with language X", for any X, *before* we jump into discussion with statements "I hate X". People want such integration also because they like Pascal, not only X. We work in an ecosystem filled with lots of technologies, with devs knowing other languages than Pascal, with www browsers using JS, whether we like it or not. The choice of integrating with JS (or really any other popular language X) may be just reasonable for a given project. 2. I don't have a constructive answer myself, though I know people working on QuickJS integration with Castle Game Engine, see #quickjs channel on Castle Game Engine Discord ( https://castle-engine.io/talk.php ) and https://github.com/castle-engine/quickjs-demo . You can touch with people on that channel, in particular Coldzer0, if you're looking for people familiar with Pascal + QuickJS. 3. Discussions whether language X is good or bad should be an independent discussion, in an independent thread(s), IMHO. Because such talk can quickly go off-topic -- which this thread clearly shows. The poster didn't get any sort of an answer he counted on (feedback about QuickJS + Pascal), instead the thread went into JS and do we like it, and Python, and Lua, and Basic... We can all talk about advantages and disadvantages of various languages, and to be clear I think it can be a constructive discussion, but it should be a separate thread(s). Because we know such discussions can get both lengthy and heated :) 4. Personally, from the "integration with other languages", I'm looking in the future for Python + Castle Game Engine integration, which I described for https://castle-engine.io/roadmap#_python_integration . I documented there the reasons "why" (you can scroll to the "why" section there). Regards, Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
