Re: [Lazarus] TMenu(Item) AutoLineReduction: help needed from Delphi users/owners
On Thu, Sep 12, 2024 at 3:16 PM Werner Pamler via lazarus wrote: > > I suppose this is how Delphi works as well. > Yes. Thanks for confirming. > > But I have absolutely no idea if Delphi does this as well. > Restores ItemB RethinkLines did not restore ItemB, we did it on purpose before calling RethinkLines. > and the separator So, I did it OK then in this case. > > Question 2 > > And TopLevel.AutoLineReduction starts out as maManual, so all > > separators are visible. > Yes > > Now I do: TopLevel.AutoLineReduction := maAutomatic > > Then I do: TopLevel.RethinkLines > > > > It will now show as: > > - ItemA > > - Separator > > - ItemB > > - Separator > > - ItemC > > > > This is Delphi compatible AFAIK. > Hmmm... I have this code in a button. When I click on this button > immediately after running the project, you are right, there are only > single separators. But when I first open the menu to verify the double > separators and then click on the button, nothing changes, and the double > separators remain... So, RethinkLines only works if the menu was never shown before? That's confusing to say the least. It's also not what the documents suggest, > > I implemented RethinkLines so that this will set all separators Visble > > property to True again. > I added a second button for the maManual code. Running the program and > clicking both buttons in the order of your description, nothing changes > - there are still single separators. This begs the question: what is the use of having maManual in that case. But that part of the code can easily be removed/commented out. I did implement it that way based upon a comment in the bugtracker though, so that confuses me even more. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TMenu(Item) AutoLineReduction: help needed from Delphi users/owners
Hi, We've recently implemented the AutoLineReduction property for TMenu(Item). The current implementation is based upon the Delphi docs and some limited user input. So, questions remain. For those who have a recent Delphi installed, can you please try to answer these 2 questions (I have D7, which is, to be mild, a bit ancient). Question 1. Given the following Menu: TopLevel - ItemA - Separator - ItemB - Separator - ItemC Given that TopLevelA.GetAutoLineRedction will return True. Now I do: ItemB.Visible := False Then I do: TopLevel.RethinkLines. This will hide one of the 2 now consective separators (in our implementation it hides the second one). So it will show as TopLevel - ItemA - Separator - ItemC I suppose this is how Delphi works as well. So far, so good. Now I do: ItemB.Visible := True Then I do: TopLevel.RethinkLines. I implemented RethinkLines such that it will now restore the separator after ItemB, because this makes sense to me. But I have absolutely no idea if Delphi does this as well. Question 2 Given the following Menu: TopLevel - Separator - ItemA - Separator - Separator - ItemB - Separator - Separator - ItemC - Separator And TopLevel.AutoLineReduction starts out as maManual, so all separators are visible. Now I do: TopLevel.AutoLineReduction := maAutomatic Then I do: TopLevel.RethinkLines It will now show as: - ItemA - Separator - ItemB - Separator - ItemC This is Delphi compatible AFAIK. Now I do: TopLevel.AutoLineReduction := maManual Then I do: TopLevel.RethinkLines I implemented RethinkLines so that this will set all separators Visble property to True again. This makes sense to me, as it performs the opposite action of maAutomatic. But again, I'm not really sure this is what Delphi does in this case. So, your (Delphi users/owners) help is appreciated. Thanks in advance. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Problems installing Lazarus on Linux Mint
On Sat, Jul 20, 2024 at 5:58 PM Juha Manninen via lazarus wrote: >> I was about to give up when I remembered to ask chatGPT. > > > Oh! So what did he say? > Why do you assume chatGPT is male? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Erreur interne wiki freepascal : Status::getWikiText called for a good result, this is incorrect
On Sun, Jun 9, 2024 at 11:29 PM Matthieu Giroux via lazarus wrote: > Erreur internel : Status::getWikiText called for a good result, this is > incorrect I already reported it on the devel mailinglist. Bart -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Off-topic: Dutch NL Delphi forum?
On Fri, May 3, 2024 at 11:43 PM Marco van de Voort via lazarus wrote: > Got some news today. The Vbulletin instance was hacked, and the owner > also took this (rebuilding) opportunity to change hosts. Forum will be > back in time. Thanks for reporting. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Call for help: Carbon bugs in the bugtracker (macOS users)
Hi, There are still several bugs in the bugtracker labeled with "Widgetset:Carbon" (appr. 120). The Carbon widgetset has been deprecated and the default widgetset for macOS is now Cocoa (announced on the forum end ML in october 2022). I would like to ask macOS users to test wether these reported bugs are also present with the Cocoa widgetset and to report this in the bugtracker. If it turns out the issue is not present in Cocoa WS, then we can close the issue at hand. (Notice that some bugs labeled with "Widgetset:Carbon" already have labels for other widgetsets as well. No need to test these.) Your help will be much appreciated. Here's the direct link to Carbon issues in our bugtracker: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=WS%3A%20Carbon -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Off-topic: Dutch NL Delphi forum?
Hi, Most likely not relevant for those who don't speak dutch, so I'll continue in dutch after this... Heeft iemand enig idee wat er met het NLDelphi forum (https://http://www.nldelphi.com/) is gebeurd of heeft iemand contact informatie van de site beheerder? Het forum is sinds een week of zo niet bereikbaar (met wisselende http foutcodes). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] When I brought a project from Linux to Windows it didn't open anymore
On Tue, Mar 19, 2024 at 1:06 AM Arí Ricardo Ody via lazarus wrote: Click on either the form or the unit and click OK. The IDE will open the form/unit. If you can't see the form after that, try: menu->window->center a lost window. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] When I brought a project from Linux to Windows it didn't open anymore
On Sun, Mar 17, 2024 at 9:06 PM Arí Ricardo Ody via lazarus wrote: > I decided to take it from Lazarus 3.2 on Windows to Lazarus 2.2 on Linux > Mint. I took it. Everything runs right. I made several changes and tests > until I thought it was the way I wanted. I'm surprised this even works, since lpi format has changed. > Would anyone have any guidance to resolve this problem? Or did I lose my > Windows 11 version project? First: make a backup. I would delete the .lps files, they contain session information and you can do without that. What does Menu->Project->Units say? And Menu->Project-Forms? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] italian accented vowels wrongly displayed in a TMemo
On Thu, Jan 25, 2024 at 7:00 PM duilio foschi via lazarus wrote: > > byte F9 is correctly displayed as ù (accented u) in PSPad/Hex (see > https://ibb.co/S7Z6rx5) and wrongly displayed as ? in my TMemo (see > https://ibb.co/BBTRhPy). Since LCL (Lazarus) is UTF8 centered, the byte F9 does not represent a valid UTF8 codepoint, hence it will show the questionmark. In UTF8 encodig ù is represented as 2 bytes: $C3 $B9 Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Running FPC in the browser...
On Sun, Oct 22, 2023 at 12:20 PM Michael Van Canneyt via lazarus wrote: > Thanks to the efforts of Nikolay Nikolov, the FPC compiler can now recompile > itself to webassembly (the support for the goto statement made this possible). > > As a consequence, this means FPC can now be run in a browser. Incredible! -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release 2.2.6
On Thu, Mar 16, 2023 at 9:05 AM Martin Frb via lazarus wrote: > Issues that > are 3.2.0 only usually only get attention when reported. Well, at least compilation failures with 3.2.0 are detected with our current CI setup. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Linux apps and gtk version choosing
On Sun, Feb 26, 2023 at 2:26 PM Mgr. Janusz Chmiel via lazarus wrote: > IIs it possible from Lazarus IDE, Form window or only from source code of app? Lazarus: Compiler Options -> Config and Target -> "Select another LCL widgetset (macro LCLWidgetType)" -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to make TBitButton set the ModalResult properly and close the form?
On Sat, Feb 11, 2023 at 9:26 PM gabor via lazarus wrote: > Have you set the TBitButton.ModalResult property or TBitButton.Kind > property appropriately? This would normally also set ModalResult to mrOk (Kind := bkOK) or mrCancle (Kind := bkCancel). Setting the modalresult to those values should be enough (no OnClick needed) to close the modal form. It definitively does so for me. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus does not find compiled package, why?
On Sun, Oct 30, 2022 at 4:50 PM Bo Berglund via lazarus wrote: > What can I do to make this work again? Project Inspector -> Add dependency -> select package you need? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Phasing out support for the Carbon widgetset
Since Lazarus 2.2.0 the Cocoa widget set has replaced the Carbon widgetset as default widgetset on MacOS. Apple has officially removed Carbon from macOS since 2019. The Lazarus team has decided to minimize the effort to support the Carbon widget set, so we can focus on stabilizing more used widgetsets. We want to review all open bug reports for Carbon. If the issue is also present when using the Cocoa widget set, the issue will be marked as such. If it is not present with Cocoa the issue will be resolved with resolution "suspended". Patches to fix such issues are still welcome, but new bug reports for the Carbon widget set are only accepted, if they contain a patch to fix it. Help from the community with cleaning up the bug tracker is appreciated. If you test a Carbon issue with Cocoa, please leave your findings as a note in the bugtracker. The Lazarus developers will try not to break the current Carbon widget set, but will not actively develop new features for it. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Can I delete a property from a collectionitem
On Wed, Oct 12, 2022 at 6:21 PM Michael Van Canneyt via lazarus wrote: > > I have a collection stored in a file. One property of each collectionitem is > > a value of what seeems to be a set but is not. That property is no longer > > needed. Is there a way to delete that property? If you mean that it should not be read anymore from the .lfm file (after you changed the code so that it no longer has that property), you can use RegisterPropertyToSkip() (use Find in Files to search for examples). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus 2.2 and FormResize
On Tue, Jun 28, 2022 at 6:48 PM Bart wrote: > IIRC then this was fixed in main (and hopefully merged to fixes). Seems I rember it wrong. It's reported (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39691), but not fixed. The cause is described in the bugreport. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus 2.2 and FormResize
On Tue, Jun 28, 2022 at 9:04 AM Luca Olivetti via lazarus wrote: > With Lazarus 2.0.12 the OnResize event for a form was fired while > resizing, but in 2.2.2 it's fired only when the resizing is done (only > under windows, under linux it behaves the same as before). > However, if I put, say, a panel with top,left,bottom,right anchoring, > its OnResize event is fired while resizing. IIRC then this was fixed in main (and hopefully merged to fixes). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Adding unit automatically adds to uses clause
On Sat, Mar 26, 2022 at 6:00 PM Timothy Groves via lazarus wrote: > Can anyone tell me how to stop Lazarus from > doing this? Yes, it's annoying. Project->Options->Miscalleneous: uncheck "Main unit has uses section containing all units of a project." I think this is a per project setting and not globall. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Gtk 1.2 fixes (again)
On Thu, Feb 17, 2022 at 1:24 PM Tarnyko via lazarus wrote: > From memory, Windows 95 would be the target of such a version (98 already > supports an early GTK+ 2.x). Is that your target? I was talking about native Win9x support for the Win32 widgetset (not GTK widgetset on Windows). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Gtk 1.2 fixes (again)
On Sun, Feb 13, 2022 at 10:58 PM Kostas Michalopoulos via lazarus wrote: > > On 2/13/22 21:33, Sven Barth via lazarus wrote: > > Bart means the internal, private Lazarus developer list. > > I see, but then why tell me? :-P So that would know it is debated and not simply ignored. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Gtk 1.2 fixes (again)
On Sat, Feb 12, 2022 at 6:25 PM Kostas Michalopoulos via lazarus wrote: This is currently being discussed on the devel ML. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Best wishes for 2022
Hi, Wishing you all the best for 2022. Let's hope it'll be a little better than before. And keep enjoying Pascal and Lazarus. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Faster than popcnt [[Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]
On Tue, Dec 28, 2021 at 11:35 PM Martin Frb via lazarus wrote: > I have a core I7-8600 > The diff between the old code and popcnt is less significant. > > old: 715 > pop: 695 > > But there is a 3rd way, that is faster. > add: 610 Not surprising that you should come up with a faster solution. IIRC you won both speed contests I had on the forum ;-) Feel free to implement it in LazUtf8. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 3:56 PM Florian Klämpfl via lazarus wrote: > > Crash at run time with sigill. Popcnt was introduced with Nehalem, so >10 > years ago. Thanks. Any other CPU's support something like this? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 3:39 PM Marco van de Voort via lazarus wrote: > On what machine did you test? The settings if for the generated code, > but the actual processor determines the effective speed. I have a Intel i5 7th generation on my Win10-64 laptop from approx. 2017 (so, it's really old for more modern folks than me). Compiled for 32-bit: With -CpCOREI Unsigned version with multiplication: 1359 Unsigned version with PopCnt: 1282 Compiled for 32-bit: With -CpCOREAVX2 Unsigned version with multiplication: 1312 Unsigned version with PopCnt: 1297 Compiled for 32-bit No -Cp switch Unsigned version with multiplication: 1329 Unsigned version with PopCnt: 3546 B.t.w. what happens if I compile for e.g. CoreAVX2 but my processor does not support that instructionset. Will the compilation/build fail, or will the executable just error out? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 3:31 PM Florian Klämpfl via lazarus wrote: > For X86, check for the define CPUX86_HAS_POPCNT (compile time!). Thanks. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 2:46 PM Marco van de Voort via lazarus wrote: > You need an appropriate minimal CPU with -Cp > > > Try e.g. -Cpcoreavx for core 3000 series and higher Thanks for that. Up to PENTIUMM: PopCnt slower COREI : approximately equally fast COREAVX PopCnt slightly faster COREAVX2 PopCnt slightly faster Most likely not worth bothering. In code can we check (at compile time) for which instructionset the code was compiled? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 1:09 PM Juha Manninen via lazarus wrote: >> I will patch the function using unsigned types where applicable. >> I will keep the loop variables unsigned though. > > > Yes, thank you. Done. Should that be merged to fixes? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 1:09 PM Juha Manninen via lazarus wrote: > I confess I didn't remember what PopCnt does. I checked from the net. > FPC implements it as internproc. > function PopCnt(Const AValue : QWord): QWord;[internproc:fpc_in_popcnt_x]; > I guess it translates to one x86_64 instruction. > Is it implemented for all CPUs? I found this: > https://gitlab.com/freepascal.org/fpc/source/-/issues/38729 I just tested PopCnt vs Multiplication on win32 and win64. The version with PopCnt is appr. 3 times slower on both 32 and 64 bit! C:\Users\Bart\LazarusProjecten\bugs\Utf8\ulenfast>fpc ulen.lpr Free Pascal Compiler version 3.3.1 [2021/12/08] for i386 Copyright (c) 1993-2021 by Florian Klaempfl and others Target OS: Win32 for i386 C:\Users\Bart\LazarusProjecten\bugs\Utf8\ulenfast>ulen Unsigned version with multiplication: 1344 Unsigned version with PopCnt: 3563 C:\Users\Bart\LazarusProjecten\bugs\Utf8\ulenfast>fpc ulen.lpr -Px86_64 Free Pascal Compiler version 3.3.1 [2021/12/08] for x86_64 Copyright (c) 1993-2021 by Florian Klaempfl and others Target OS: Win64 for x64 C:\Users\Bart\LazarusProjecten\bugs\Utf8\ulenfast>ulen Unsigned version with multiplication: 656 Unsigned version with PopCnt: 3797 It looks like PopCnt on these platforms at least calls the generic version (/rtl/inc/generic.inc). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 12:08 PM Martin Frb via lazarus
wrote:
> I would like to see the generates assembler on M1, if that is possible? (for
> code with optimization off, as well as code with whatever optimization was
> used so far)
@Noel:
Here's example code (standalone) you can use to test both signed and
unsigned versions.
Save this code as ulen.pas
In order to get assembler output compile with:
fpc -al ulen.pas
This will produce the file ulen.s
You can attach or copy that here.
=
program ulen;
{$mode objfpc}{$H+}
{$optimization off}
{$codepage utf8}
uses
SysUtils;
function UTF8LengthFast_Signed(p: PChar; ByteCount: PtrInt): PtrInt;
const
{$ifdef CPU32}
ONEMASK =$01010101;
EIGHTYMASK=$80808080;
{$endif}
{$ifdef CPU64}
ONEMASK =$0101010101010101;
EIGHTYMASK=$8080808080808080;
{$endif}
var
pnx: PPtrInt absolute p; // To get contents of text in PtrInt
blocks. x refers to 32 or 64 bits
pn8: pint8 absolute pnx; // To read text as Int8 in the initial and
final loops
ix: PtrInt absolute pnx; // To read text as PtrInt in the block loop
nx: PtrInt; // values processed in block loop
i,cnt,e: PtrInt;
begin
Result := 0;
e := ix+ByteCount; // End marker
// Handle any initial misaligned bytes.
cnt := (not (ix-1)) and (sizeof(PtrInt)-1);
if cnt>ByteCount then
cnt := ByteCount;
for i := 1 to cnt do
begin
// Is this byte NOT the first byte of a character?
//writeln('pn8^ = ',byte(pn8^).ToBinString);
//writeln('pn8^ shr 7 = ',Byte(Byte(pn8^) shr 7).ToBinString);
//writeln('not pn8^ = ',Byte(not pn8^).ToBinString);
//writeln('(not pn8^) shr 6 = ',Byte((not pn8^) shr 6).ToBinString);
//writeln;
Result += (pn8^ shr 7) and ((not pn8^) shr 6);
inc(pn8);
end;
// Handle complete blocks
for i := 1 to (ByteCount-cnt) div sizeof(PtrUInt) do
begin
// Count bytes which are NOT the first byte of a character.
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
{$push}{$overflowchecks off} // "nx * ONEMASK" causes an
arithmetic overflow.
Result += (nx * ONEMASK) >> ((sizeof(PtrInt) - 1) * 8);
{$pop}
inc(pnx);
end;
// Take care of any left-over bytes.
while ixByteCount then
cnt := ByteCount;
for i := 1 to cnt do
begin
// Is this byte NOT the first byte of a character?
//writeln('pn8^ = ',byte(pn8^).ToBinString);
//writeln('pn8^ shr 7 = ',Byte(Byte(pn8^) shr 7).ToBinString);
//writeln('not pn8^ = ',Byte(not pn8^).ToBinString);
//writeln('(not pn8^) shr 6 = ',Byte((not pn8^) shr 6).ToBinString);
//writeln;
Result += (pn8^ shr 7) and ((not pn8^) shr 6);
inc(pn8);
end;
// Handle complete blocks
for i := 1 to (ByteCount-cnt) div sizeof(PtrUInt) do
begin
// Count bytes which are NOT the first byte of a character.
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
{$push}{$overflowchecks off} // "nx * ONEMASK" causes an
arithmetic overflow.
Result += (nx * ONEMASK) >> ((sizeof(PtrInt) - 1) * 8);
{$pop}
inc(pnx);
end;
// Take care of any left-over bytes.
while ixhttps://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 11:52 AM Juha Manninen via lazarus wrote: > Can you please create a patch for UTFLengthFast. You can upload it here or > create a merge request in GitLab or anything. @Juha: can you please comment on my possible improvement using PopCnt instead of a multiplication with ONEMASK. I will patch the function using unsigned types where applicable. I will keep the loop variables unsigned though. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Mon, Dec 27, 2021 at 10:02 PM Noel Duffy via lazarus
wrote:
> It's not just the euro, though. It's any utf-8 sequence.
What I meant was that a single '€' (or any other single UTF8
"character") will not enter the mentioned block.
Can you add some debug statements to display the values of the it
uses in the calculation like I did in the 4th message in this thread?
function UTF8LengthFast(p: PChar; ByteCount: PtrInt): PtrInt;
const
{$ifdef CPU32}
ONEMASK =$01010101;
EIGHTYMASK=$80808080;
{$endif}
{$ifdef CPU64}
ONEMASK =$0101010101010101;
EIGHTYMASK=$8080808080808080;
{$endif}
var
pnx: PPtrInt absolute p; // To get contents of text in PtrInt
blocks. x refers to 32 or 64 bits
pn8: pint8 absolute pnx; // To read text as Int8 in the initial and
final loops
ix: PtrInt absolute pnx; // To read text as PtrInt in the block loop
nx: PtrInt; // values processed in block loop
i,cnt,e: PtrInt;
begin
Result := 0;
e := ix+ByteCount; // End marker
// Handle any initial misaligned bytes.
cnt := (not (ix-1)) and (sizeof(PtrInt)-1);
if cnt>ByteCount then
cnt := ByteCount;
for i := 1 to cnt do
begin
// Is this byte NOT the first byte of a character?
writeln('pn8^ = ',byte(pn8^).ToBinString);
writeln('pn8^ shr 7 = ',Byte(Byte(pn8^) shr 7).ToBinString);
writeln('not pn8^ = ',Byte(not pn8^).ToBinString);
writeln('(not pn8^) shr 6 = ',Byte((not pn8^) shr 6).ToBinString);
writeln;
Result += (pn8^ shr 7) and ((not pn8^) shr 6);
inc(pn8);
end;
// Handle complete blocks
for i := 1 to (ByteCount-cnt) div sizeof(PtrUInt) do
begin
// Count bytes which are NOT the first byte of a character.
{
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
{$push}{$overflowchecks off} // "nx * ONEMASK" causes an
arithmetic overflow.
Result += (nx * ONEMASK) >> ((sizeof(PtrInt) - 1) * 8);
{$pop}
}
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
Result := Result + PopCnt(PtrUInt(nx));
inc(pnx);
end;
// Take care of any left-over bytes.
while ixhttps://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Mon, Dec 27, 2021 at 6:35 PM Marco van de Voort via lazarus
wrote:
> The expression seems to be 1 when the top bits are 10 iow when it is a
> follow bytes of utf8, that is what the comment says, and I as far as I
> can see the signedness doesn't matter.
>
> Basically to me that seems to be a branchless version of
>
> if (p[i] and %1100)=%1000 then
>
> inc(result);
This is how I understood that paert of the code as well.
Just a side node: all this assumes that the UTF8 is correct (in the
strict sense).
Now for the part that tries to do calculations on blocks of 32 or 64 bits.
It uses a multiplication in that part.
That seems a bit odd as this code tries to do evrything with ands,
nots, and shifts.
Would this approach (in that part of the code) also work?
X = 32 or 64 bit block
1: AND X with EIGHTYMASK
2: SHR 7: gives (A)
3: NOT X
4: SHR 6: gives (B)
5: (A) AND (B): gives (C)
Basically we do the same as for a 1-byte block;
Now we have a pattern where any 1 tells us this byte was a following byte
A 32-bit example:
(Invalid sequence but that does not matter here)
X = %11xx %01xx %00xx %10xx
(Leading-ASCII-ASCII-Following, so count of following bytes must be 1)
AND with EIGTHYMASK gives %1000 % % %1000
SHR 7 gives: %0001 % % %0001 (A)
NOT %11xx %01xx %00xx %10xx = %00yy %10yy
%11yy %01yy
SHR 6 gives: % %yy10 %yy11 %yy01 (B)
(A) and (B) gives: % % % %0001 (C)
All non-following bytes turn into %
The count of following bytes is PopCnt(C)
As long as PopCnt is available as a machine instruction, this will be
faster than the (nx * ONEMASK) calculation I think.
(I would hope this is the case for all platforms Lazarus supports, if
not the call to PopCnt could be ifdef-ed.)
So basically change this:
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
{$push}{$overflowchecks off} // "nx * ONEMASK" causes an
arithmetic overflow.
Result += (nx * ONEMASK) >> ((sizeof(PtrInt) - 1) * 8);
{$pop}
into
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
Result := Result + PopCnt(PtrUInt(nx)); /PopCnt only accepts
unsigend parameter
Since bit manipulating is not my strongpoint, please comment.
--
Bart
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Mon, Dec 27, 2021 at 3:41 PM Juha Manninen via lazarus wrote: > It must be a Big endian / Little endian issue. IIRC it can be adjusted in ARM > CPUs. > Why do MacOS and Linux use a different setting there? I have no idea. On second thought: if the function returns grabage for just a single '€', the code for that should not enter the pasrt where it handles blocks of size PtrInt and does masking with EIGHTYMASK etc. (The part of the code that might be endianness dependant). It should go to one of the 2 loops that simply does: Result += (pn8^ shr 7) and ((not pn8^) shr 6); That part should not depend on endianness at all. On Win32 a sigle '€' will result in something like this: pn8^ =11100010 //first byte (pn8^ shr 7) = //<<-- I would have expected that to be 0001 ? (not pn8^)=00011101 (not pn8^) shr 6 = Add: (pn8^ shr 7) and ((not pn8^) shr 6)=0 pn8^ =1010 //second byte (pn8^ shr 7) = (not pn8^)=0101 (not pn8^) shr 6 =0001 Add: (pn8^ shr 7) and ((not pn8^) shr 6)=1 pn8^ =10101100 //third and last byte of '€' (pn8^ shr 7) = (not pn8^)=01010011 (not pn8^) shr 6 =0001 Add: (pn8^ shr 7) and ((not pn8^) shr 6)=1 B.t.w. I find the code in Utf8LengthFast difficult to read. Personally I dislike the C-ism of += and >> (even more so if both >> and shr is used). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Mon, Dec 27, 2021 at 12:44 AM Noel Duffy via lazarus wrote: > I need some help getting to the root of a problem with incorrect results > on Apple hardware (M1, aarch64) for the function UTF8LengthFast in lazutf8. Your M1 architecture is BigEndian perhaps? (I really have no idea) -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Can I configure Lazarus (or the project) to only add symbols on debug?
On Mon, Dec 13, 2021 at 10:29 PM Bo Berglund via lazarus wrote: > This sounds like what I need. > I looked at the project options and found that there is one box to enter the > Execute after command. And checkboxes to set when it is used. > > But I would need *two* commands: > - copy to the svn location > - strip -s on that copy > In compiler options you can set various debugging related options as well. One is to strip symbols. - uncheck: "generate infor for the debugger" - check: Strip symbols from executable You apply those debugging options to your "Release" build mode. You keep all relevant debugging options checked for your "Debug" build-mode. Now you develop in "Debug" build-mode. Once you're ready to release: swicth build-mode to "Release" and compile. (You might want a "Release and copy to svn" build mode with the "Execute after command", sou you can also test your release mode build (if you use e.g. different optimizations, some yet unnoticed bug may crop up.) -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New Synthwave Demo
On Wed, Dec 1, 2021 at 9:27 AM Juha Manninen via lazarus wrote: I'm breaking my promiss to not reply anymore. @All: please stop discussing this on the Lazarus mailinglist. Please, please, please, please, pretty please! -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New Synthwave Demo
On Tue, Nov 30, 2021 at 12:40 PM Juha Manninen via lazarus wrote: > A request for everybody: Do not take the jabs. If you took already, don't > take more. It would be unfortunate if the small Pascal community got reduced > by their effects. > In a year or so a new plandemic will come, most likely Marburg. Things will > get worse before they get better. > As someone who works in healthcare I feel rather offended by you now. Covid-19 is a real thing, real people are dying under my hands right now. A Marbug pandemic most likely will kill 90% of the earths population if it could travle unrestricted around the world The virus however is so effective in killing us (and it dos that really fast), that at some point it kills all vectors (=us humans), in it's vicinity so the spread stops before the vector reaches other possible victims. Sorry for being off-topic as well. I won't reply any further to this thread. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] DCPcrypt: a package looking for a new maintainer
Hi, The DCPcrypt package (see: https://wiki.lazarus.freepascal.org/DCPcrypt) does not have a maintainer anymore. Graeme unfortunately had to give up (as he pointed out: not by choice, but by circumstances). Is there anybody out there who is interested (and feels capable) in maintaining that package? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Mon, Nov 15, 2021 at 5:04 PM Marcos Douglas B. Santos via lazarus wrote: > Yes, after finding the bug issue that I posted in the last email, I > tested using trunk... > But I'm using 2.0.12. Well, either copy the relevant parts to your 2.0.12, use the 2.2RC or wait just a little bit more for the final release... -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Drag/drop project and package filenames on the IDE
On Sat, Nov 13, 2021 at 11:03 PM Juha Manninen via lazarus wrote: >> Isn't the policy to not merge new features, but only bugfixes? > Yes but this one is clearly a bugfix. Sorry, I misunderstood then. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Drag/drop project and package filenames on the IDE
On Sat, Nov 13, 2021 at 5:17 PM Juha Manninen via lazarus wrote: > I would like to merge this to 2.2. Does anybody see potential problems? > Please test. Isn't the policy to not merge new features, but only bugfixes? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Crayon physics written in Pascal
On Thu, Nov 11, 2021 at 9:54 PM Anthony Walter via lazarus
wrote:
My eye just caught this typo:
{ TDrawPhsyics is a scne
obviously you mean "scene".
--
Bart
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Wed, Nov 3, 2021 at 7:30 PM Juha Manninen via lazarus wrote: > Here it gives an error from procedure TestWindows. Fixed now. (Adjusted some tests, since DefaultMaskOpCodes changed, fixed the wqFileNameEnd error.) > I don't see commits from you in the TestMasks project. Because as it turned out the changes I made to it were wrong, so I just reverted them. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Tue, Nov 2, 2021 at 10:59 PM Bart wrote: > 2. Remove wqFilenameEnd from DefaultWindowsQuirks and describe that > adding that quirk implies that mocAnyCharOrNone will be enabled. Or a variant of this: remove it foem default and when added , aslo add mocAnyCharOrNone ... -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Tue, Nov 2, 2021 at 10:59 PM Bart wrote: > I see 2 solutions: > 1. On TWindows* mocAnyCharOrNone will be enabled by default, while it > is not on TMask* > 2. Remove wqFilenameEnd from DefaultWindowsQuirks and describe that > adding that quirk implies that mocAnyCharOrNone will be enabled. > > A cleaner solution would be to NOT have wqFilenameEnd depend on > mocAnyCharOrNone , but I have no idea how to do that. A third solution: Include mocAnyCharOrNone in DefaultMaskOpCodes. It is very unlikely that this will cause regressions, since in the old implementation [?] would only match a literal '?'. Then, setting wqFilenameEnd in Quirks on TWindows* should implicitely acitvate mocAnyCharOrNone... -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Tue, Nov 2, 2021 at 8:21 PM Juha Manninen via lazarus wrote: > I fixed its compilation in 3c7586c0f8 but many tests fail. Thank you for that (a bit late, but nevertheless). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Tue, Nov 2, 2021 at 8:21 PM Juha Manninen via lazarus wrote: > Bart, please run the TMask unit test project while you change the code. Whilst doing that I fiddled around with bot the tests and the masks unit. I then wanted to commit (push) these changes seperately. I got stuck. In svn I could commit a single file, then another. I git I don;t know how to do that. My workflow currently is: make changes git commit files I changed (solve one problem per commit) git pull (I have pull.rebase=true) git push I resorted to do a git restore on the changes to the test suite, then commiited and pushed the changes to masks unit. (And then I found out my changes to the testsuit were unnecessary, so that saved me from doing the changes all over again...) PS. The test suite runs fine again (but see my remarks on the wqFilenameEnd quirk. PS 2: building any program in the lazarus tree pollutes my tree and git gives warnings about untracked files: Here's what git tells me after building the test suite for masks unit: C:\devel\lazarus>git status On branch main Your branch is up to date with 'origin/main'. Untracked files: (use "git add ..." to include in what will be committed) components/lazutils/test/backup/ components/lazutils/test/testmasks.or nothing added to commit but untracked files present (use "git add" to track) Is there a way to suppress the warning about untracked files alltogether? Orr whould all this be added to our .gitignore file? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Tue, Nov 2, 2021 at 9:43 PM Bart wrote: > How to run that exactly without having to run the entire test suite? OK, looked at the wrong test folder... I fixed the filename 'a[b]c' not matching the mask 'a[b]c' in DisableRange. TestSpecial: to test this feature mocAnyCharOrNone must be set, which is excluded from DefaultMaskOpCodes. TestWindows: the tests for wqFilenameEnd I think only work if mocAnyCharOrNone is enabled: José commented that quirk with This presents a problem, since DefaultMaskOpCodes excludes mocAnyCharOrNone , but DefaultWindowsQuirks requires it. I see 2 solutions: 1. On TWindows* mocAnyCharOrNone will be enabled by default, while it is not on TMask* 2. Remove wqFilenameEnd from DefaultWindowsQuirks and describe that adding that quirk implies that mocAnyCharOrNone will be enabled. A cleaner solution would be to NOT have wqFilenameEnd depend on mocAnyCharOrNone , but I have no idea how to do that. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Tue, Nov 2, 2021 at 8:21 PM Juha Manninen via lazarus wrote: > Bart, please run the TMask unit test project while you change the code. How to run that exactly without having to run the entire test suite? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Attn José: TWindowsMask oddity?
On Mon, Nov 1, 2021 at 11:02 PM Bart wrote: > I think I also need to write a setter for AutoReverseRange property Indeed it did. @Jose: in the setter for EscapeChar you should also set cMaskIsCompiled to False. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Attn José: TWindowsMask oddity?
On Mon, Nov 1, 2021 at 7:30 PM José Mejuto via lazarus wrote: > > A note: IIRC (do not have the source at hand here) you escape [ ] and > > \, with or withoud mocEscapeChar enabled. > > if mocEscapeChar is not enabled, escaping these in the mask is > > probably not what you want. > ... > In the other hand I recall why the escape is necessary instead disabling > features, to mimic the "file?.dat" which must be transformed to my TMask > "file[?].dat", if I left the "AnyCharOrNone" enable and disable sets and > ranges this mask will not be interpreted correctly "fil[?.dat" so > escaping in that function is a must. Yes, I saw that you call inherited Create with TMaskOpCodesAllAllowed. So, it works as designed (ans as you expected it to work). > > So, I changed it (and documented it as a change that breaks backwards > > compatibility). > > That's a design decision, I choose the other one based in the reason > exposed. Yes, I agree. Of course this was not meant as criticism. Whil at it yesterday, I also implemented read/write access for properties mask, maskopcodes, quirks for all classes that use them. I think I also need to write a setter for AutoReverseRange property (you have it in a define, so it cannot be altered at runtime). And since I was makig all parameter in the constructor available as a r/w property, I alos should take care of CaseSensitive. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Attn José: TWindowsMask oddity?
On Mon, Nov 1, 2021 at 12:22 PM José Mejuto via lazarus wrote: > The target in *Windows classes is to mimic the old fashion CMD masks, > and CMD masks does not have ranges or sets. OK, this is by design. Since that is however not backwards compatible (the old mask implementation supported sets out of the box by default on all platforms, I changed "our" implementation. A note: IIRC (do not have the source at hand here) you escape [ ] and \, with or withoud mocEscapeChar enabled. if mocEscapeChar is not enabled, escaping these in the mask is probably not what you want. > LCL's TMask raises syntax errors (or others, I can not recall) at > creation time and in my code the syntax check is at Compile time so I > call compile to raise an exception if needed. Yes, the old mask did so, whci, to be hones, is a PITA. Normally you do SomeVar := TSomeClass.Create(...); try SomeVar.SomeThing; finally SomeVar.Free end; If you know you can let the constructor fail, just by giving it an "invalid" parameter, you hve to rewrite you code to: SomeVar := TSomeClass.Create(...); if Assigned(SomeVar) then begin try SomeVar.SomeThing; finally SomeVar.Free end; end; So, I changed it (and documented it as a change that breaks backwards compatibility). > Compile should not be called again unless the mask is changed > via the property. I think, that does not happen. The Mask property IIRC does not have a setter. I introduced a setter for the mask property, it sets fMaskIsCompiled to False Also, if compile fails and the user/prgrammer is stupid enough to call Matches again, Matches will simply return False (no exception), whic (even if the programmer is stupid) is a bad thing IMO. I fixed that by setting fMaskIsCompiled to False as first line in Compile and only set it to True if Compile does not raise an exception (so it finishes). Something else. When you reset the mask, you should also reset the internal representation of the mask and it's associated length value, otherwise you get an access violation when you set mask via the property and then call Matches. Again, thanks for helping me out. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Attn José: TWindowsMask oddity?
Hi José, In TWindowsMask.Compile (as in your TMaskUTF8Windows class) you do a call to EscapeSpecialChars on the modified mask. This will escape a.o. any '[' and ']' character, so ranges and sets are not possible to use in the mask anymore. Why did you disable ranges and sets in the Windows implementation? And another question: why do you call Compile in the constructor for TWindowsMask (TMaskUTF8Windows in your original)? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Wed, Oct 27, 2021 at 11:56 PM Maxim Ganetsky via lazarus wrote: > > Opinions please. > > Looks good to me. Done. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 11:17 PM Juha Manninen via lazarus wrote: >> Attached the codetools popup for TMask.Create constructor. >> I would think it would be clear enough? > It is clear for people who know the details already. For new users there is > no hint of an extended syntax. > Anyway, we can consider it as an advanced feature which requires users to > study deeper. No problem. I'm OK with leaving them in, but in time they should be removed. CreateLegacy in version 3.6 is going to look a little bit "off". We want people staring to use the "new" syntax (that is: use the additional last parameter(s)) as fast as possible. Maybe deprecate them in 2.5 and remove in whatever we release after 2.4? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 9:55 PM Juha Manninen via lazarus wrote: > The idea was only to offer an intuitive API which gives a hint there is > something extended available, just like CreateLegacy() gave a hint there is > the good old legacy syntax available. Attached the codetools popup for TMask.Create constructor. I would think it would be clear enough? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 8:46 PM Juha Manninen via lazarus wrote: > There would be a constructor named CreateExtended or CreateAdvanced or > similar, allowing the new nice syntax. You totally lost me here. IMHO there is no need for CreateExtende or similar new constructor. THis is what we currently have. TMask: constructor Create(const aMask: String; aCaseSensitive: Boolean; aOpcodesAllowed: TMaskOpCodes); virtual; overload; TMaskWindows: constructor Create(const aMask: String; aCaseSensitive: Boolean; aOpcodesAllowed: TMaskOpCodes; aWindowsQuirksAllowed: TWindowsQuirks); TMaskList: constructor Create(const aValue: String; aSeparator: Char=';'; CaseSensitive: Boolean=False; aOpcodesAllowed: TMaskOpCodes=MaskOpCodesDefaultAllowed); TMaskListWindows: constructor Create(const aValue: String; aSeparator: Char=';'; CaseSensitive: Boolean=False; aOpcodesAllowed: TMaskOpCodes=MaskOpCodesDefaultAllowed; aWindowsQuirksAllowed: TWindowsQuirks=WindowsQuirksDefaultAllowed); reintroduce; These __are__ the extended constructors for aal the fancy new/extended stuff. They are called by all the other constructors that only have the old parameters. So we have backwardscompatibility and extended capability just with all constructors named simply Create. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 27, 2021 at 6:42 PM José Mejuto via lazarus wrote: > Line 780, current: > >Add(TMaskParsedCode.OptionalChar); >Add(fCPLength,@fMask[fMaskInd]); >fLastOC:=TMaskParsedCode.OptionalChar; > > Line 780, new: > >if (mocSet in fMaskOpcodesAllowed) then begin > > Add(TMaskParsedCode.OptionalChar); > Add(fCPLength,@fMask[fMaskInd]); > fLastOC:=TMaskParsedCode.OptionalChar; > >end else begin > Exception_InvalidCharMask(fMask[fMaskInd],fMaskInd); >end; Applied in #63847a62. FWIW: having a proper patchfile makes this a lot easier. Do you have git installed or TortoiseGit? I would much appreciate your patch for the "escaping bug", so I can apply it to main. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Masks: the naming of ...
Hi, I thought I better start a new therad for this one, otherwise I get lost in the previous "TMask revisited" thread. I would like to rename some stuff, now we still can. Easier to remeber IMO: WindowsQuirksAllAllowed -> AllWindowsQuirks WindowsQuirksDefaultAllowed -> DefaultWindowsQuirks MaskOpCodesAllAllowed -> AllMaskOpcodes MaskOpCodesDefaultAllowed -> DefaultMaskOpcodes property RangeAutoReverse -> AutoReverseRange Internal consistency: TMaskWindows -> TWindowsMask TMaskListWindows -> TWindowsMaskList (Because of the Matches* functions we already have) Consitent coding style: TMaskParsedCode enums: mpcXXX TMaskFailCause enums: mfcXXX Opinions please. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 2:09 PM Juha Manninen via lazarus wrote: >> Wouldn't is be a bit more logical to exclude mocEscapeChar form the >> MaskOpCodesDefaultAllowed constant, since we'ld like to have the >> default behaviour as compatible as possible? > > > That is fine with me. The Create constructors would then behave like > CreateLegacy now. Yes, that sort of was the objective. > The extended syntax would have another constructor. Not really sure what you mean by that. The "default" constructor is the one with the TMaskOpcodes (/TWindowsQuirks) parameters. To be even more backwards compatible, mocRange should be disabled as well. I'm a bit reluctant to do so, as having ranges is quite an improvement over the old implementation (which had only sets). Possible problem is the '-' inside a range: this would be no problem in old code, but can raise exceptions in the new code. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Masks: ConstructLegacy
Hi, The new masks unit has several CreateLegacy constructors (and some *Legacy* functions). They call the new constructros with mocEscapeChar disabled. Wouldn't is be a bit more logical to exclude mocEscapeChar form the MaskOpCodesDefaultAllowed constant, since we'ld like to have the default behaviour as compatible as possible? Since most of this code will be used for filename matching, escaping in most common practice won't be necessary. Also, in existing code people may have mask with '\' as intentionally as a PathDelim, and this would break that. If we leave things as is, then the question remains: how long do we keep the *Legacy* constructors and functions? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 27, 2021 at 1:28 PM José Mejuto via lazarus wrote: > This is a side effect of the found bug, in ranges the only valid syntax > (without sets enabled) is "char-char". So, without [mocSet] [a-dqx] would be invalid? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 27, 2021 at 1:28 PM José Mejuto via lazarus wrote: > "]" must be escaped in all cases, with ranges and with sets or it will > be interpreted as a premature closing (ranges). Actually I did not think of that. Could you possibly provide a patch against main and post it on GitLab (or attch the diff here)? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New TMaskList [forked from: TMask revisited]
On Tue, Oct 26, 2021 at 10:44 PM Bart wrote: > I'll have a go at it then To simplify matters I decided to remove the CreateWindows and CreateNative constructors for TMaskList. The CreateWindows skipped the population of fMasksWindows, but that is a small price to pay IMO. I can't have this as a constructor in TMaskListWindows, but I would inherit it, so I got rid of it. So, for the moment TMaskList always internally creates and populates 2 lists. I tried to use a factory pattern, , so that I would not have to replicate the Matches method for TMaskListWindows. I factored out populating the respective objeclists (fMasks and fWindowsMasks) and made that a virtual method so I could override that in TMaskListWindows. That has it's drawbacks however: in TMaskListWindows I have to iterate through fMasks in order to set some privae variables/fields of the created TMaskWindows instances, and then have to call the Compile method. (Duplicating some actions in the TMaskWindows constructor, so that possibly needs updating when TMaskWindows constructor gets changed). The problem turned out to be the fact that: FMaskClass.Create(S[i], CaseSensitive, aOpcodesAllowed) does not call the TMaskUtf8Windows constructor, when FMaskClass definitely _is_ TMaskWindows (it calls TMaskUTF8 constructor directly). This probably is because the signature of te constructor has a long list of default parameters. Unfortunately you can't override that constructor in TMaskUtf8Windows: you'll get a "Error: Can't determine which overloaded function to call". So, I untangeld all constructors for TMaskUtf8: constructor Create(const aMask: String); (1) constructor Create(const aMask: String; aCaseSensitive: Boolean); (2) constructor Create(const aMask: String; aCaseSensitive: Boolean; aOpcodesAllowed: TMaskOpCodes); virtual; overload; (3) Then in TMaskUtf8Windows I override the last one (3) to call the constructor with "quirks" parameter. It may look a bit messy, but AFAICS all possible constructor calls still work. (I had to add "overload" to constructor (3), otherwise constructors (1) and (2) were not visible in TMaskWindowsUTF8, something about constructors which I did not know). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New TMaskList [forked from: TMask revisited]
On Tue, Oct 26, 2021 at 7:20 PM Bart wrote: > So, now we have: > TMask > TMaskWindows About naming: We have MatchesWindowsMask(List), but TMaskWindows. That's not very logical or consistent. Either we should rename TMaskWindows to TWindowsMask, or fase out MatchesWindowsMask(List) in favour of MatchesMask(List)Windows. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New TMaskList [forked from: TMask revisited]
On Tue, Oct 26, 2021 at 9:15 PM Juha Manninen via lazarus wrote: > Yes, sounds OK, I'll have a go at it then > but it cannot cover CreateSysNative which is now used in procedure > TFileSearcher.Search. > The IFDEF can be placed there directly of course. Probably better. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] New TMaskList [forked from: TMask revisited]
Hi, So, now we have: TMask TMaskWindows TMaskList TMaskList also caters for the old TMask.MatchesWindowsMask. However, now that we have a dedicated TMaskWindows, wouldn't it also make more sense to have a TMaskListWindows class? The TMaskList constructors constructor CreateWindows(const aValue: String; aSeparator: Char; aOptions: TMaskOptions); constructor CreateSysNative(const aValue: String; aSeparator: Char; CaseSensitive: Boolean); would not be necessary anymore. For the TMaskListWindows we only need the constructor with the new syntax, and the class would be rather simple. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Tue, Oct 26, 2021 at 6:48 PM Bart wrote: > Point 2 would need (probably a minor) change to the CompileRange method. Attached diff might do what I intended. @José: does it in fact allow ? in a range as a literal, without side effects. I don't really understand the matching algorithm. -- Bart masks.allowquestionmarkinrange.diff Description: Binary data -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Tue, Oct 26, 2021 at 1:38 PM José Mejuto via lazarus wrote: > You found a bug, I thought about it some more. Inside a range everything is treated as a literal, the only exceptions are: 1. [?] 2. '!' as the first char in a range when [mocNegateGroup] is enabled. 3. '-' if it is NOT the first char (or the first after the negating !), it is then the indicator for a range So, even '*' is taken as a literal. Since '*' as a wildchar in a range would make no sense at all, to me this sounds OK. A '?' in a range is forbidden (EMaskError: Invalid character "?" in mask), except for the [?]. Having '?' interpreted as a wildcard in a range would also make no sense. The only things one could possibly imagine to have to escape in a range are: 1. ? for a literal ?: currently forbidden 2. * for a literal *: currently * works as a literal 3. - for a literal -: solvable by having - as the first char in a range. 4. The EscapeChar itself. Given this, I would think that: 1. escaping inside a range is not necessary: everything in a range is literal except for the 3 cases outlined above. 2. having a '?' could also be accepted as long as it is not the first character in the range specification, even [!?] could be allowed: any char but not a '?'. Point 2 would need (probably a minor) change to the CompileRange method. It would then be simply a matter of documenting this. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 20, 2021 at 11:42 AM Bart wrote: > > The Create in TMaskBase is never called directly by a user. He will get a > > deprecated message from elsewhere. As I see it now, we are planning to remove all the old TMask stuff (in the future) and replace it with the new and improved TMask. Shouldn't that mean that we should also deprecate the CreateLegacy method? That way we can remove all backwards compatibility stuff in 2.5/2.6. And the same for the TMaskOption(s) type? (Although it stands to reason that we remove this once we remove the methods that use those as a paramater-type.) -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sun, Oct 24, 2021 at 4:26 PM José Mejuto via lazarus wrote: > > @José: is this indeed as intended? > No, in fact escaping was introduced to allow "[a\-]" to be interpreted > as literal set "a-". I must check my test cases, maybe a simple missing > if. Please let me check it tomorrow, monday. OK, thanks About mocRange and mocSet (previously AdditionalChar). Since ranges allow/include sets (e.i. [abc] is a valid range), and the [mocSet] is only used in Compile, but there mocRange follows the same code-path: IMO mocSet can be removed. Unless, of course [abc] is NOT supposed to be a valid range... -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sun, Oct 24, 2021 at 3:26 PM Bart wrote: > It looks like escaping does not work as advertised? Seems like escaping is NOT supported in ranges or sets, but only outside them? If that is the case (and by design) then, with [mocRange] enabled, you can only have '-' in a range if the range starts with '-'? In essence that's fine with me. @José: is this indeed as intended? If so, I'll adjust the comments for the mocXXX enums. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 11:33 PM Bart wrote: > I renamed mocOptionaChar to mocSet and added some comments in the code. > > @José: are these comments correct? I'm still strugling with the difference between mocRange and mocSet (previously mocOptionalChar). Consider the following mask: [a-c] With [mocRange] this matches 'a', 'b', or 'c', but not '-'. With [mocSet] this matches 'a', '-' or 'c', but not 'b'. That's clear to me. Mask [ac] [mocRange]: matches 'a' or 'c'. [mocSet]: matches 'a' or 'c'. To me this seems as [mocRange] is equivalent to [mocRange,mocSet] So, only mocSet without mocRange has a special meaning. Or they should be mutually exclusive: if you enable mocSet, mocRange should be disabled and vice versa (the latter does not cause any functional change). Now we take into account the mocEscapeChar and things get a little confusing. IIUC then if mocEscapeChar is eneabled, then EscapeChar+SomeChar is interpreted as just a literal SomeChar. By default EscapeChar = '\' so '\*' is a literal '*' and '\\' is a literal '\'. And '\-' should mean a literal '-'. In the following examples RangeAutoReverse is set to FALSE. Opcodes : [mocRange] Mask: [a\-] Filename: - EMaskError: Missing closing character "]" in mask (offset 5). This is to be expected. Opcodes : [mocRange,mocEscapeChar] Mask: [a\-] Filename: - EMaskError: Missing closing character "]" in mask (offset 5). ** ? Escaping the '-' should mean that the mask should match 'a' or '-' Opcodes : [mocSet] Mask: [a\-] Filename: \ Matches This is expected Opcodes : [mocSet,mocEscapeChar] Mask: [a\-] Filename: \ Matches Since mocEscapeChar is enabled the sequence '\-' should be interpreted as a literal '-' and it should therefore not match '\'. Some more oddities: Opcodes : [mocRange] Mask: [$\-&] Filename: $ Matches Opcodes : [mocRange] Mask: [$\-&] Filename: % Does NOT match Opcodes : [mocRange] Mask: [$\-&] Filename: & Does NOT match Actually OK, since the range '\-&' is not reversed and therefore empty (took me a while to realize that) Opcodes : [mocRange] Mask: [$\-&] Filename: - Does NOT match Opcodes : [mocRange] Mask: [$\-&] Filename: \ Does NOT match Opcodes : [mocRange,mocEscapeChar] Mask: [$\-&] Filename: $ Matches Opcodes : [mocRange,mocEscapeChar] Mask: [$\-&] Filename: % Does NOT match Opcodes : [mocRange,mocEscapeChar] Mask: [$\-&] Filename: & Does NOT match ? Looks like '\-&' is interpreted as an (empty) range, but '\-' should be interpreted as a literal '-', so not a range but a set, and it should match Opcodes : [mocRange,mocEscapeChar] Mask: [$\-&] Filename: - Does NOT match ? Same argument as above Opcodes : [mocRange,mocEscapeChar] Mask: [$\-&] Filename: \ Does NOT match With [mocSet] instead of [mocRange] Opcodes : [mocSet] Mask: [$\-&] Filename: \ Matches Opcodes : [mocSet,mocEscapeChar] Mask: [$\-&] Filename: \ Matches ? Here enabling mocEscapeChar makes no difference at all. (Checked the same filenames as with mocRange) Finally this: Opcodes : [mocRange] Mask: [\a-c] Filename: \ Matches Opcodes : [mocRange,mocEscapeChar] Mask: [\a-c] Filename: \ Matches ? It should not. It looks like escaping does not work as advertised? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 10:39 PM Juha Manninen via lazarus wrote: > In 964d5f4d69 I changed most names as you suggested. > The original TMaskOpCode is now TMaskParsedCode because it is not related to > the other enums directly. > I did the changes before reading your last mail. I renamed mocOptionaChar to mocSet and added some comments in the code. @José: are these comments correct? TMaskOpCode=(mocAnyChar, //treat ? as a wildcard mocAnyCharOrNone,//treat [?] to match any char the absence of a char mocAnyText, //treat * as a wildcard mocRange,//treat [a-d] to match either 'a', 'b', 'c', or 'd' mocSet, //treat [ab] to match either 'a' or 'b mocNegateGroup, //treat [!a-d] to not match 'a', 'b', 'c', or 'd', but match any other char. Requires mocRange and/or mocSet mocEscapeChar); //treat EscapeChar (defaults to '\') in [a\-b] to match either 'a', 'b', or '-'. Requires mocOptionalChar enabled and mocRange disabled -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Tue, Oct 19, 2021 at 10:44 AM José Mejuto via lazarus wrote: > With "eMaskOpcodeRange" and "eMaskOpcodeOptionalChar" enabled to match > "a" or "-" or "z" the "-" must be escaped (something like regex) using > the escapechar, by default "\", in this way "[a\-z]". That does not seem to work (at least not as I expected): Opcodes: [eMaskOpcodeRange, eMaskOpcodeOptionalChar, eMaskOpcodeEscapeChar] Mask: [a\-z] // since '-' is escaped should match 'a', '-' or 'z' Matches Filenames 'a', 'b', 'c' ,'d' .. 'z', but not '-' Opcodes: [eMaskOpcodeRange, eMaskOpcodeOptionalChar, eMaskOpcodeEscapeChar] Mask: [a\-] //should match either 'a' or '-' EMaskError: Missing closing character "]" in mask (offset 5). Opcodes: [eMaskOpcodeOptionalChar, eMaskOpcodeEscapeChar] Mask: [a\-] //should match either 'a' or '-' Matches Filenames: 'a', '\' and '-' Q: eMaskOpcodeEscapeChar only treats '\' as escape char is eMaskOpcodeRange is enabled? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 12:22 PM Bart wrote: > Then we have TMaskOpcode and TMaskOpcodesEnum types. > The first one is more or less an internal type. > The latter one is for common user interface. > Since TMaskOpCode is used in the interface part of TMask, we must have > it in the interface part of the unit. I've given it some more thought. AFAICS the TMaskOpCode and TMaskOpcodesEnum types are not related at all. TMaskOpCode is some kind of internal identifier in the internal mask representation, whereas TMaskOpcodesEnum are options for interpreting the mask. Q1: is it possible to have the TMaskOpCode as an internal type in the class (maybe in the protected part of the class definition)? It seems it is not needed outside (as in the public part of the interface). If we did not already have the old TMaskOption type, I would actually have liked to propose to rename the TMaskOpcodesEnum into TMaskOption... Q2: @José: the TMaskOpCode enums are indexed, and there is a gap in the index. Is the index necessary for the code to work? Is the gap necessary? In the Add() method, the enum is cast to a byte, this should also work if no indices are used (as long as you do not do mathematical operations with the value of that byte). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 6:16 PM José Mejuto via lazarus wrote: > Because in the code each syntax piece can be enabled and disabled, even > "*" and "?" can be disabled to not be interpreted as a mask char, so to > allow granularity a name to that "feature" must be given. Yep, OK. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 12:22 PM Bart wrote: > So: > TInternalMaskOpcode (integers) > TMaskOpcode (the enums) > TMaskOpcodes: set of TMaskOpcode > Enum names: moXXX Maybe better make that mopXXX, as not to confuse them with old moXXX TMaskOption enums. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 12:22 PM Bart wrote: > Naming conventions. Also: we typically have the convention of nameing fileds in a class Fxxx Here we have cXXX and eXXX. Again: not meant as crtitcism. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 12:02 PM Bart wrote: > since we are still looking for a better (?) name for the > eMaskOpcodeOptionalChar enum: This brings me to another point, and please, please, please don't see this as criticism of feel offended by me. Naming conventions. Typically we don't have the habit of haveing the literal phrase "enum" in our enum typenames. We also tend to adopt that enum names are derived form the typename in a manner like typename: TSomeType enum name: stXXX Then we have TMaskOpcode and TMaskOpcodesEnum types. The first one is more or less an internal type. The latter one is for common user interface. Since TMaskOpCode is used in the interface part of TMask, we must have it in the interface part of the unit. If we rename TMaskOpCode to TInternalMaskOpCode and rename TMaskOpcodesEnum to TMaskOpcodesEnum to TMaskOpcode and TMaskOpcodesSet to TMaskOpcodes (we tend to do that with sets of enums: set typename = typename+s), then the opcode enum names can be changed to moAnyChar, moAnyCharOrNone etc. So: TInternalMaskOpcode (integers) TMaskOpcode (the enums) TMaskOpcodes: set of TMaskOpcode Enum names: moXXX This would be more in line with our unwritten style guide (at least this is how I percieve it). Also we have shorter, yet not less intuitive, enum names. The same for TWindowsQuirks: TWindowsQuirks: enums TWindowsQuirks: set of TWindowsQuirks Enum names: wqXXX Yes, those are intrusive changes, and they add no functionality, nor do they fix any bugs, but this is the time to consider such a change. The new and improved (yes, improved) TMask with all new types won't be used very much ATM. In a few weeks or months this might not be the case anymore. Opinions please! -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Thu, Oct 21, 2021 at 10:29 AM José Mejuto via lazarus wrote: > So the question is, why sets if ranges can be used ? Because sometimes > you need to exclude strings that starts with number 1: > > "[0234567989][a-z]" > > > Naming them different just confuses me (which probably is my fault). > > Because they are different beast in the code and in the syntax, many > times ranges apparently are syntactic sugar for sets, but ranges have a > begin and an end, and both have a mission, one, ranges, add clarity to > the desired match, and the second, sets, add flexibility to the mask write. > I can understand why having [a-e] is good (and better than [abcde]). I was just confused by the fact that these had different names. since we are still looking for a better (?) name for the eMaskOpcodeOptionalChar enum: When eMaskOpcodeOptionalChar enables the use of [abcde] and eMaskOpcodeRange enables the use of [a-z] and syntactically there is a difference between ranges [a-e] and sets [abcde], then a potentially better name could be eMaskOpcodeSet(s)? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 20, 2021 at 9:37 PM José Mejuto via lazarus wrote: > >> There are IMHO two front lines, one is the "replace" of TMask in > >> internal LCL functions, exposed or not to the user, and in this case all > >> options that allow mimic the old behaviour should be disabled. The other > >> one is the TMask itself which can be "replaced" with same settings as > >> internal LCL functions and/or a TMaskExtended which can use all the > >> syntax options. The IDE just uses the TMask of the LCL (but maybe with restricted options, so ranges are disabled, as not to break backwards compatibility. Then again we might decied to use the full capability of TMask and give users the option to uses ranges as well. B.t.w. I did not study that piece of code in the IDE: if it did not specify moDisableSets, it would have supported ranges (not as extended as the current implementation though). Oh, and thank you for donating this code to us. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 20, 2021 at 9:37 PM José Mejuto via lazarus wrote: > In the "masks" world sets are a group of chars inside "[]", optional > chars, option chars, or other fancy name. > > Range syntax: [a-z] > Set syntax: [abcdefghijklmnopqrstuvwxyz] What would be the effective difference between [a-e] and [abcde] then? I did understand that both meant: a single charcter being either 'a', 'b', 'c', 'd', or 'e'? Naming them different just confuses me (which probably is my fault). -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Tue, Oct 19, 2021 at 7:11 PM Juha Manninen via lazarus wrote: > The Create in TMaskBase is never called directly by a user. He will get a > deprecated message from elsewhere. But it is part of the interface. Some poor soul might implement it's own dereive control from TMaskBase and rely on it. I also suppose that, once the MatchesWindowsMask method has been removed and the old TMaskOptions (2.6 or later), then that constructor will be removed as well? If so, then at least we should comment this in the source code. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 20, 2021 at 11:00 AM José Mejuto via lazarus wrote: > There are IMHO two front lines, one is the "replace" of TMask in > internal LCL functions, exposed or not to the user, and in this case all > options that allow mimic the old behaviour should be disabled. The other > one is the TMask itself which can be "replaced" with same settings as > internal LCL functions and/or a TMaskExtended which can use all the > syntax options. I'm sorry, but I don't really know what you mean here. > > Lots of documentation to do. > > In the mask world I think that many mask samples are better than a lot > of text trying to explain what a set, a range, etc, is. Short text with > 3, 4, ... 10 samples. I agree. > but current TMask allows ranges and > sets which is confusing me about the function requirements. Again ,not sure what you mean by that. In the old TMask I introduced the option to disable that and called it moDisableSets (I'm also not native English), where your use of the word Range might have beeen more appropriate. In Pascal a set (of characters) is ['a'..'z'], whic is a synatx TMask does not support AFAICS. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Tue, Oct 19, 2021 at 10:44 AM José Mejuto via lazarus wrote: > Yes, at least it should. To completely disable the "[" syntax three > options must be removed from default, "eMaskOpcodeOptionalChar", > "eMaskOpcodeRange" and "eMaskOpcodeAnyCharOrNone". > > eMaskOpcodeAnyCharOrNone = [???] matches 0, 1, 2 or 3 chars. > eMaskOpcodeRange = [a-z] matches 1 char from "a" to "z". > eMaskOpcodeOptionalChar = [abc] matches "a" or "b" or "c" > > With the three options disabled "[" is interpreted as a regular > character to be matched. > > With "eMaskOpcodeRange" and "eMaskOpcodeOptionalChar" enabled to match > "a" or "-" or "z" the "-" must be escaped (something like regex) using > the escapechar, by default "\", in this way "[a\-z]". Thanks for explaining that. Sounds to me like you should not enable both of them, unless you want something to match 'a'..'f' or '+' or '-' [a-f+\-] ? Lots of documentation to do. With only eMaskOpcodeOptionalChar enabled [a-z] would match 'a', '-' or 'z'? (This would be the old behaviour of TMask) The eMaskOpcodeOptionalChar enum name is not very self-explanatory, maybe we should come up with another name (better now than in half a year). And maybe a constant that has all opcodes except the ones that enable ranges. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sun, Oct 17, 2021 at 7:37 PM José Mejuto via lazarus wrote: > OpcodeOptionalChar (maybe the name should be OptionChar) works in the > compiled stream as CheckMatch and if match go to next char; if not match > continue checking without advance in the target string. > > Most people are familiar with ranges "[a-z]", optional chars use the > same "[" syntax but without the dash "-", so "[abcde]" matches one > position with any of those chars or if you negate the set "[!abcde]" it > will match any char *except* any of those. So, with that option specified ranges work like "sets" in the old Masks implementation? And [a-z] will mean either 'a' or '-' or 'z'? -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 16, 2021 at 11:20 PM Juha Manninen via lazarus wrote: > Ideas? Comments? I see you implemented the "old" constructors with the TMaskOptions parameter and deprecated them as suggested. Thanks for that. Maybe add: 'Will be removed in 2.4' or similar to the deprecated message? The corresponding Create in TMaskBase is not deprecated: is that by design? Thanks also for implementing MaskOpCodesDisableRange It needs to be apllied in the TShell* components, to presevere default behaviour. The method TMask.MatchesWindowsMask still is not implemented, so it immediately causes compiler errors in my code. This also needs to be implemented an deprecated IMHO. What does eMaskOpcodeOptionalChar do? It's not very clear to me from the comments in the code. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 16, 2021 at 3:19 PM Maxim Ganetsky via lazarus wrote: > > So far, this has not been reporduced by others in this thread. > > Juha already reproduced it. Happens in `Find in Files` dialog. That's GMail for you. When I wrote that, it was a reply to the only new message in this thread (as per GMail). Once I hit "Send" I saw numerous new messages, including the one where it is confirmed. Ahh, computers -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 16, 2021 at 12:14 AM DougC via lazarus wrote: > Shouldn't the mask "*.pas*" be used to match file.pas.bak ? If so, the old > code and new code are ok. You miss the point. It was said that the mask '*.pas;*.pp;*.inc' now also matched the file foo.pas.bak, which would be a bug. So far, this has not been reporduced by others in this thread. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Fri, Oct 15, 2021 at 1:55 AM Juha Manninen via lazarus wrote: > > On Thu, Oct 14, 2021 at 7:57 PM Bart via lazarus > wrote: >> >> You have changed the existing interface for both TMask and the >> Matches(Windows)Mask(List) functions. >> TMaskOptions has been removed. > > > It can be added for compatibility. Please do. But, also feel free to deprecate them. >> Noticable the ability to NOT interpret [] as a set in the mask has now >> disappeared. > > > How should a range / set [] be interpreted? ?? [az] is interpreted as either a or z by default Diasbling use of sets would interpret this as literally [az] (4 chars). > Now the same thing is done by passing MaskOpCodesDisableRange constant where > type TMaskOpcodesSet parameter is used. > TMaskOptions can be restored for compatibility. OK. >> You have sacrificed consistent and reliable behaviour for gain of speed. > > No Bart, that is not true. This is not only about speed. The old Mask was > buggy and limited. I agree about the limited part. Not many bugs were filed against asks unit, and I did not encounter them, but my locale is Ducth and the ocaasional non-ascii I happen to have in my filenames all process correctly. > Please run the test project testmasks.lpi. All current tests pass. > Now checkout a revision before my Mask changes, eg. e5ed5082d and run tests > again. Many errors. Notably there was no support for Unicode. I'll have a look. > Yes, there should be an option for backwards compatible syntax, like "[?]" . > However the small changes in the syntax can be seen as improvements. > There already is a define for converting "[z-a]" to "[a-z]". Why a define? Shouldn't that better be configurable at runtime? >> José's code also catered for some odd DOS behaviour where a mask like >> >> 'file.txt?' actually matches with the filename 'file.txt' and a mask >> 'file?.txt' would match 'file1234.txt' (but not 'file12345.txt'). >> That would be rather counter-intuitive to most users. >> I did not test (it was in one of the "quirks" settings) if it behaves >> like this by default, but that should IMHO not be the case. I tested it now, and by default it returns fals for those cases. > Yes it is counter-intuitive but it matches with Windows' behavior. > You can test it on a DOS/Windows cmd prompt. file?.txt matches file.txt and file1.txt, but not file12.txt, so ? as last char before . is treated as no or 1 character. > That is why it is called TMaskWindows. The normal TMask behaves more > logically. > The "quirks" prove that Jose has tested it a lot. > > About the speed: TMask can also be used without disk file operations. Then > the speed matters. Yes it can, but it was desigend for filemasks (see the original parameter names). > I will look at the compatibility issues and possible bugs tomorrow. Thank you. I did not study th enre code at length, but it looks quite a bit more complicated to me than the old one. Not sure if I will be able to contribute to it anymore. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Fri, Oct 15, 2021 at 2:38 PM Maxim Ganetsky via lazarus wrote: > Please try with, for example bla.pas and bla.pas.bak files. Mask: *.pas;*.pp;*.inc Filename: file.pas.bak Result: does not match, both in the old code and the new code. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Thu, Oct 14, 2021 at 6:54 PM Bart wrote: > This was discussed at length in february. From the discussion in february: Feb 24 11:22 AM > And also define if a compatibility break is a bug in the new code or in > the old code. In example my mask supports (there is a define to disable) > "[z-a]" converting it to "[a-z]" which is a compatibility break. Also > there is the support (also can be disabled) for the mask "[?]" which is > the counterpart for "*" but with one char position. Current behaviour of sets and wildcards should not be changed by default. E.g. TShellTreeView and TShellListView use the Masks unit to populate the tree/view. An option to have the behaviour you described would be OK, the TMaskOption can be extended for that. Feb 26 7:15 PM The normal way of doing this is: Deprecate the function in question, but do NOT kill it's functionality. Add a useful deprecated message. Remove the function in the next major release (deprecate in 2.1, and so 2.2, only remove in 2.3, so it'll be gone in 2.4). Simply removing functionality like you have done now will alienate users from Lazarus, since apparently "we" cannot be trusted. Juha: you seem to be obsessed with speeding up string handling code. This is not really a problem as long as you are not deaf to arguments against your changes. You introduce new bugs, remove old features, all for the sake of speed. - Let me be very clear: I am NOT against improving and expanding TMask and associated functions. Overhauling the "matching algorithm" so that it is no longer O(n^3) or O(n^4) is a good thing. Speeding up string handling functions is most of the time also a good thing. Breaking things in the long run also may be acceptable. Breaking them over night, unannounced and especially __removing existing functionality__ is a no-no from my point of view. José's code also catered for some odd DOS behaviour where a mask like 'file.txt?' actually matches with the filename 'file.txt' and a mask 'file?.txt' would match 'file1234.txt' (but not 'file12345.txt'). That would be rather counter-intuitive to most users. I did not test (it was in one of the "quirks" settings) if it behaves like this by default, but that should IMHO not be the case. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 13, 2021 at 5:16 PM Juha Manninen via lazarus wrote: > Please test everybody. I will read the old posts more carefully later. You have changed the existing interface for both TMask and the Matches(Windows)Mask(List) functions. TMaskOptions has been removed. Noticable the ability to NOT interpret [] as a set in the mask has now disappeared. From my test program: FAIL Filename: 'Heoworld', MaskList: 'He[lo]world', Options=[moDisableSets], WindowsMask=FALSE ResOld: FALSE, ResNew: TRUE This is not some cornercase: Suppose you have files that have filenames like foo[1].dat, foo[2].dat etc. Now you could specify a mask of 'foo[*].dat' with the moDisableSets option set and it would find those files. The new implementation won't. (This was the usecase of the person who reported the bug for TShellListView, which first was hacked by using [[] to mean a single '[', but later was properly fixed by adding the TMaskOptions. This was discussed at length in february. Now you're doing it all over again. You have sacrificed consistent and reliable behaviour for gain of speed. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Start application maximized with a shortcut
On Tue, Sep 7, 2021 at 11:26 AM John Landmesser via lazarus wrote: > fp-ide works as aspected on Win 10 Home :-) > > Ok its a terminal application ?! The terminal starts in the specified mode, not the FP executable. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Start application maximized with a shortcut
On Sun, Sep 5, 2021 at 10:42 AM Gabor Boros via lazarus wrote: > Create a new "Application", compile it. Send a shortcut from > project1.exe to the desktop. At shortcut's properties change "Run" to > "Maximized". Start the application with the shortcut, its not maximized. I can confirm that. > Is it a bug? Apparently. You could file a bugreport. -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] trying to read an EXE
On Fri, Sep 3, 2021 at 11:08 PM duilio foschi via lazarus wrote: > In which form gets this instruction compiled? >i:=cmbYear.ItemIndex+2005; Compile wit -al and then open the resulting .s file in a texteditor. You'll see the assembler that the compiler generates for that line: It will be preceeded by a comment more or less like this: # i:=cmbYear.ItemIndex+2005; -- Bart -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
