Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On 19/04/2021 07:59, Michael Van Canneyt via fpc-pascal wrote: > > But MacOS is a problem. macOS is also perfectly scriptable, I just have to finish automating it. The main remaining problem is our hard-wrapped readme and whatsnew files that look terrible in its installer (because it also performs wrapping and it uses a proportional font, so many hard-wrapped lines get wrapped again). So at least the changed/new parts need manual unwrapping every time. For Mac OS X/PowerPC there is the additional issue that the tool to create installer packages that work on Mac OS X 10.4 no longer works under macOS 10.14, so they have to be created on an older Mac OS X version (I don't know when it broke exactly). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On Mon, 19 Apr 2021, Karoly Balogh via fpc-pascal wrote: Hi, On Mon, 19 Apr 2021, Michael Van Canneyt via fpc-pascal wrote: > The main remaining problem is our hard-wrapped readme and whatsnew files > that look terrible in its installer (because it also performs wrapping > and it uses a proportional font, so many hard-wrapped lines get wrapped > again). So at least the changed/new parts need manual unwrapping every time. > > For Mac OS X/PowerPC there is the additional issue that the tool to > create installer packages that work on Mac OS X 10.4 no longer works > under macOS 10.14, so they have to be created on an older Mac OS X > version (I don't know when it broke exactly). Manual work and requiring an old OS are a problem if you want to automate. From what you say, both problems are related to the tool you use. Are there no other tools that can be used ? Well, if we're talking about automation, I'm sure some VM can be set up, and then it almost doesn't matter which version of macOS it is, until it works. In my experience, MacOS is not well-behaved in VMs, but admittedly it's been a while since I last tried. But that does not solve the manual formatting. Don't get me wrong, I am all for automating as much as possible, but if a tool requires an old macos, and manually formatting files, my first reaction is to look for another tool. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: On 19/04/2021 07:59, Michael Van Canneyt via fpc-pascal wrote: But MacOS is a problem. macOS is also perfectly scriptable, I just have to finish automating it. I didn't mean to imply that it is not scriptable. But it's a problem for the reasons you mention below. At least the first reason was known to me and one of the reasons why I described mac as problematic. The main remaining problem is our hard-wrapped readme and whatsnew files that look terrible in its installer (because it also performs wrapping and it uses a proportional font, so many hard-wrapped lines get wrapped again). So at least the changed/new parts need manual unwrapping every time. For Mac OS X/PowerPC there is the additional issue that the tool to create installer packages that work on Mac OS X 10.4 no longer works under macOS 10.14, so they have to be created on an older Mac OS X version (I don't know when it broke exactly). Manual work and requiring an old OS are a problem if you want to automate. From what you say, both problems are related to the tool you use. Are there no other tools that can be used ? I don't know whether Mac OS X/PowerPC still qualifies as a Tier-1 platform; But I doubt it. So maybe that can be dropped for these "intermediate" releases. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: From what you say, both problems are related to the tool you use. Are there no other tools that can be used ? The wrapping problem is unrelated to the tool, but to the console mode focus of our installation files. Such a manually formatted text file is simply unsuitable for a GUI installer. But if the tool didn't wordwrap, all would be OK, no ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
Hi, On Mon, 19 Apr 2021, Michael Van Canneyt via fpc-pascal wrote: > > The main remaining problem is our hard-wrapped readme and whatsnew files > > that look terrible in its installer (because it also performs wrapping > > and it uses a proportional font, so many hard-wrapped lines get wrapped > > again). So at least the changed/new parts need manual unwrapping every time. > > > > For Mac OS X/PowerPC there is the additional issue that the tool to > > create installer packages that work on Mac OS X 10.4 no longer works > > under macOS 10.14, so they have to be created on an older Mac OS X > > version (I don't know when it broke exactly). > > Manual work and requiring an old OS are a problem if you want to automate. > > From what you say, both problems are related to the tool you use. > Are there no other tools that can be used ? Well, if we're talking about automation, I'm sure some VM can be set up, and then it almost doesn't matter which version of macOS it is, until it works. > I don't know whether Mac OS X/PowerPC still qualifies as a Tier-1 platform; > But I doubt it. So maybe that can be dropped for these "intermediate" > releases. Indeed, but if there's a script which anyone can execute and a release just "pops out" at the end, then any of us with an old PowerMac can fire it up, and just execute it. Or actually, you can emulate one with QEMU too these days. Of course you don't want to run it continuously, but to fire the emulated machine up, do a build, upload it somewhere and shutting it down should be perfectly doable for any reasonably fast host, even headless. Charlie ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote: > > > On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: > >> On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: >>> >>> >>> From what you say, both problems are related to the tool you use. Are >>> there no other tools that can be used ? >> >> The wrapping problem is unrelated to the tool, but to the console mode >> focus of our installation files. Such a manually formatted text file is >> simply unsuitable for a GUI installer. > > But if the tool didn't wordwrap, all would be OK, no ? It's not the tool, it doesn't touch the files. It's the GUI of the installer application, which shows a plain window that happens to be slightly too narrow relative to our chosen line length (depending on the kind of characters on the line, as it uses a proportional font). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
Op 2021-04-19 om 07:52 schreef Karoly Balogh via fpc-pascal: No, the RTL and the compiler are tightly coupled. What might be possible are further packages like the FCL and interfaceing units, but the core RTL itself definitely not. I think the need comes from the fact that the release cycle for the compiler is horribly long, which I tend to agree with. But I think this comes from the fact that the release for Tier 1 platforms is still mostly prepared manually. Doc upload also is a bottleneck. It is not the work to those tiers that keeps up, but unforeseen things happening while doing that, because nobody tests them inbetween releases, and things pop up last minute. If you have automated systems, but nobody pays attention to them till just before release time, you get the same problem. That doesn't mean I'm against automation. The problem is just more than that, which is why I hope to moving to a bi-annual release scheme would be best. It would reduce the need for this or that fix to get in last minute, and somewhat grease the wheels of releasing. Major releases can be a pain, minor releases should be reasonably effortless. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote: On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: From what you say, both problems are related to the tool you use. Are there no other tools that can be used ? The wrapping problem is unrelated to the tool, but to the console mode focus of our installation files. Such a manually formatted text file is simply unsuitable for a GUI installer. But if the tool didn't wordwrap, all would be OK, no ? It's not the tool, it doesn't touch the files. It's the GUI of the installer application, which shows a plain window that happens to be slightly too narrow relative to our chosen line length (depending on the kind of characters on the line, as it uses a proportional font). So it's the MacOS installer window that does the wrapping ? being used to Inno Setup I automatically assumed the tool also does the GUI... That explains it. Thanks. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: > > > From what you say, both problems are related to the tool you use. Are > there no other tools that can be used ? The wrapping problem is unrelated to the tool, but to the console mode focus of our installation files. Such a manually formatted text file is simply unsuitable for a GUI installer. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Directory Tree
I updated Lazarus to Lazarus 2.0.12 / fpc 3.2.0 and that indeed did fix the default encoding error. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
> Am 19.04.2021 um 11:36 schrieb Michael Van Canneyt via fpc-pascal > : > > > > On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: > >> On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote: >>> On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: > > > From what you say, both problems are related to the tool you use. Are > there no other tools that can be used ? The wrapping problem is unrelated to the tool, but to the console mode focus of our installation files. Such a manually formatted text file is simply unsuitable for a GUI installer. >>> But if the tool didn't wordwrap, all would be OK, no ? >> >> It's not the tool, it doesn't touch the files. It's the GUI of the >> installer application, which shows a plain window that happens to be >> slightly too narrow relative to our chosen line length (depending on the >> kind of characters on the line, as it uses a proportional font). > > So it's the MacOS installer window that does the wrapping ? > being used to Inno Setup I automatically assumed the tool also does the > GUI... > > That explains it. Thanks. > But couldn’t we just wrap ourself in all installers if needed? This should be a no brainer, no? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] How does TFPGMap key compare work?
I have a question I was just curious about. From what I can tell TFPGMap uses CompareByte to compare keys of arbitrary type, which is clever but how does this work for ShortStrings? I have tried to use this method myself and I find it always fails because short strings have garbage at the end and so even if you zero out the memory (which is allocated) a short string passed as a parameter to a function will have garbage and thus fail to compare. Any ideas how this works for TFPGMap then? function TFPSMap.BinaryCompareKey(Key1, Key2: Pointer): Integer; begin Result := CompareByte(Key1^, Key2^, FKeySize); 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] Abstract classes ignored
> On Apr 18, 2021, at 11:28 PM, Sven Barth wrote: > > Nowadays: backwards compatibility. backwards compatibility strikes again. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal
> Am 19.04.2021 um 07:52 schrieb Karoly Balogh via fpc-pascal > : > > Hi, > > On Mon, 19 Apr 2021, Sven Barth via fpc-pascal wrote: > >>> Am 18.04.2021 um 23:29 schrieb Zamrony P. Juhara via fpc-pascal: >>> >>> I would like to propose to separate RTL release from compiler release >>> so that RTL bug fixes and features can be released with shorter release >>> cycle. Is that possible? >> >> No, the RTL and the compiler are tightly coupled. >> >> What might be possible are further packages like the FCL and >> interfaceing units, but the core RTL itself definitely not. > > I think the need comes from the fact that the release cycle for the > compiler is horribly long, which I tend to agree with. But I think this > comes from the fact that the release for Tier 1 platforms is still mostly > prepared manually. I think the point is more to get a release where everything works and is tested. Running make into is no problem but the quality of the resulting installer might be less than that we currently have. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
