Re: [Lazarus] Lazarus Release 2.0.12

2021-02-24 Thread Ondrej Pokorny via lazarus

On 24.02.2021 12:09, Mattias Gaertner via lazarus wrote:

The Lazarus team is glad to announce the release of Lazarus 2.0.12.


Thank you all for your work!

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] Attn Marc: snv up please [[Re: Lazarus Release 2.0.12]]

2021-02-24 Thread Martin Frb via lazarus

On 24/02/2021 12:09, Mattias Gaertner via lazarus wrote:

The Lazarus team is glad to announce the release of Lazarus 2.0.12.



Hi Marc, please svn up the web. Thanks
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 12:28 PM José Mejuto via lazarus
 wrote:

> Filename:='test.txt'
> Mask:='test??.txt?'
> Match must be true

That sucks big time.
A ? is supposed to match EXACTLY 1 character (not optional).
Bloody @#$%$#@#$ Micro$uck,


-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 9:54 PM Juha Manninen via lazarus
 wrote:

> I am interested in how well your TMask version compares with Delphi's version.
> Does it match the speed or even surpass it?
>
> Anyway this unit looks very promising!
> It works with Unicode as advertised. It passes all cases in the updated unit 
> test. Our current implementation fails miserably.

IIRC then fpc has some wildcard matching code in one of it's *nix units.
At least it used to have it.

-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 12:28 PM José Mejuto via lazarus
 wrote:

> Filename:='test.txt'
> Mask:='test??.txt?'
> Match must be true

That sucks big time.
? is supposed to match exactly 1 character (non-optional).
Bloody #$%$#!! M$uck.


--
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Juha Manninen via lazarus
On Wed, Feb 24, 2021 at 1:05 PM José Mejuto via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Note: Just to put in context, my "explore" in the TMask world started
> when writing my NTFS filesystem reader, when all file names are read
> (400,000) I can search for them using masks. When compiled in fpc
> (Lazarus) the "*.txx" search takes 1-2 seconds (not measured) and when
> compiled with Delphi it takes +/- 0.3 seconds, so I stated to write my
> own TMask.
>

I am interested in how well your TMask version compares with Delphi's
version.
Does it match the speed or even surpass it?

Anyway this unit looks very promising!
It works with Unicode as advertised. It passes all cases in the updated
unit test. Our current implementation fails miserably.
See components/lazutils/test/testmasks.lpi
For example this
  TestMask('ö', '[!☺-☂]', True);
means that 'ö' is not between a happy face and an umbrella.
Case-insensitive matching of Unicode can be fixed later with functions
found in LazUTF8.

With José's approval the license will be LGPL with a linking exception. It
will be part of the LazUtils package. Author's name will be mentioned of
course.
Is that OK?
I will not copy the whole original unit but use the UTF-8 parts + rename
and tweak some things.

Regards
Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 12:11 PM Juha Manninen via lazarus
 wrote:

>> I tested that extensively on my machine with all scenarios I could think of.
> Please add your tests to the project I mentioned.

I did that when writing the code.
I never saved the tested masks I used anywhere AFAIK.

The comments in the code state what scenario's I have come up with.
The scenarios described were made to behave like the dir command of windows.

-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Juha Manninen via lazarus
MaskList is used in TCustomShellTreeView.GetFilesInDir().
It sets a mask option *moDisableSets*. Why are sets disabled? Is it to stay
compatible with FindFirstUTF8() syntax?
I don't fully understand the comment. Why would EConvertError be raised?

  //Disable the use of sets in the masklist.
  //this behaviour would be incompatible with the situation if no
MaskList was used
  //and it would break backwards compatibilty and could raise
unexpected EConvertError where it did not in the past.
  //If you need sets in the MaskList, use the OnAddItem event for that.
(BB)
  MaskOptions := [moDisableSets];
  {$ifdef NotLiteralFilenames}
  if (ACaseSensitivity = mcsCaseSensitive) then
MaskOptions := [moDisableSets, moCaseSensitive];
  {$else}
  if (ACaseSensitivity <> mcsCaseInsensitive) then
MaskOptions := [moDisableSets, moCaseSensitive];
  {$endif}
  MaskList := TMaskList.Create(MaskStr, ';', MaskOptions);  //False by
default

Anyway I don't see why a useful Mask syntax should be disabled. Can this be
solved by other means?
Can José's mask do a similar thing?

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread José Mejuto via lazarus

El 24/02/2021 a las 13:31, Juha Manninen via lazarus escribió:

Hello,


I was thinking in import the NTFS (the filesystem) case comparison
tables which are 128 KB "only".
That is not necessary.
LazUTF8 has functions like UTF8CompareText(), UTF8CompareTextP() and the 


The code was originally designed to be fpc only, not Lazarus libs (even 
when compatibles with console apps).



Your code does not compile when RANGES_AUTOREVERSE is not defined.
cMask is not found.
The reverse logic can be enabled by default. It does not break anybody's 
masks as I understand it. Earlier it was an error, now it does something 
sensible.


Probably cMask falls by error inside one $IFDEF, I'll check but must be 
a trivial error.



Also there is the support (also can be disabled) for the mask "[?]"
which is the counterpart for "*" but with one char position.
Where did you get this "[?]" syntax? There must be a reference 
documentation somewhere but I have not seen it.

What is the difference between "?" and "[?]" ?


Wildcards except "*" and "?" do not have any kind of standard reference, 
some use "[]" others "{}", some negate with "!", others with "^", some 
ranges using "-" others "<", there is a jungle of widcards.


In the develop of the Windows matching I found that there is no option 
for zero or one char which is needed in the Windows matching, so started 
to googling about and find some that uses the "?" inside brackets to 
notate the zero or one and it is compatible with the idea of ranges and 
charsets, so used it.


The difference is:

?   = 1 char
[?] = 1 or 0 chars.

??   = 2 chars
[??] = 0,1 or 2 chars

In the DOS/Windows world (behaviour, not syntax) it is used like:

--
File name: "test.txta"
DOS mask: "test.txt?"
Match: True

File name: "test.txt"
DOS mask: "test.txt?"
Match: True
--

Also in the code I have added the escape character "\" (also selectable 
use or not) to allow string matching of stars, question mark, brackets, 
etc. characters. As other wildcards there is no standard character 
and/or behaviour.



Have a nice day.

--

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Juha Manninen via lazarus
On Wed, Feb 24, 2021 at 12:22 PM José Mejuto via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> In my code there is non 100% unicode compatibility when using the
> "CaseInsensitive" mode as as it uses lowercase mask and lowercase string
> to perform the test which is wrong by definition but I was unable to
> find a method to test codepoints case insensitive without pulling in big
> unicode tables.
>
> I was thinking in import the NTFS (the filesystem) case comparison
> tables which are 128 KB "only".
>

That is not necessary.
LazUTF8 has functions like UTF8CompareText(), UTF8CompareTextP() and the
latest UTF8CompareLatinTextFast().
UTF8CompareLatinTextFast supports full Unicode but is optimized for mostly
Latin text.
We should add a PChar version UTF8CompareLatinTextFastP() and use it in
your mask code.


> Comprehensive unit tests are a way to prevent breaking things.
>
> 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.


Your code does not compile when RANGES_AUTOREVERSE is not defined.
cMask is not found.
The reverse logic can be enabled by default. It does not break anybody's
masks as I understand it. Earlier it was an error, now it does something
sensible.


Also there is the support (also can be disabled) for the mask "[?]"
> which is the counterpart for "*" but with one char position.
>

Where did you get this "[?]" syntax? There must be a reference
documentation somewhere but I have not seen it.
What is the difference between "?" and "[?]" ?


On Wed, Feb 24, 2021 at 1:28 PM José Mejuto via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> > Sometimes I wish we would migrate to using UnicodeString by default.
> > It would make life a bit easier.
> > (And yes I know you would have to deal with composed characters
> > (grapheme defined by more than 1 16-bit word)).
>
> That's a can of worms! UTF8 forces you to write "correct code" (at least
> try it) for any character >127, with UnicodeString you get the false
> apparence that everything magically works until everything cracks when a
> string with surrogate pairs come in play :-) and ALL you text handling
> must be rewritten, and most of them completly rewritten.
>

Exactly. UnicodeString uses UTF-16 which is also a variable length
encoding. The same rules should be applied but often they are not. There is
plenty of sloppy UTF-16 code out there.
Writing proper code UTF-8 is not difficult once you wrap your mind around
the concept. There is a learning curve, true. I also scratched my head for
some time when studying it.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread José Mejuto via lazarus

El 24/02/2021 a las 11:58, Bart via lazarus escribió:

Hello,


In my code there is non 100% unicode compatibility when using the
"CaseInsensitive" mode as as it uses lowercase mask and lowercase string
to perform the test which is wrong by definition


Currently Masks unit does the same.


Yes, but in example in my case I can not success test mask "ä*" vs 
string "Ä*" because "Ä" is not lowercased to "ä" (Windows 7).



Sometimes I wish we would migrate to using UnicodeString by default.
It would make life a bit easier.
(And yes I know you would have to deal with composed characters
(grapheme defined by more than 1 16-bit word)).


That's a can of worms! UTF8 forces you to write "correct code" (at least 
try it) for any character >127, with UnicodeString you get the false 
apparence that everything magically works until everything cracks when a 
string with surrogate pairs come in play :-) and ALL you text handling 
must be rewritten, and most of them completly rewritten.



There are no tests for MatchesWindowsMask() yet.

I tested that extensively on my machine with all scenarios I could think of.
But others most likely can think of scenarios I did not test.
It was based on current behaviour of Windows NT platform (Win7 at the
time to be precise).

Who defines which are right and which are wrong ?

Well, I did ;-)
(Nobody else bothered at the time, and nobody complained either.)


And mostly will not as almost everything matches the expected behaviour 
for an user, like typical "*.txt" but there are some non supported cases 
like:


Filename:='test.txt'
Mask:='test??.txt?'
Match must be true

This is the doc from my code about Windows matching, Quirks can be 
enabled or disabled for compatibility:


8<8<-
Windows mask works in a different mode than regular mask, it has too 
many quirks and corner cases inherited from CP/M, then adapted to DOS 
(8.3) filenames and adapted again for long file names.


Anyth?ng.abc= "?" matches exactly 1 char
Anyth*ng.abc= "*" matches 0 or more of chars

--- Quirks ---

--eWindowsQuirk_AnyExtension
  Anything*.* = ".*" is removed.

--eWindowsQuirk_FilenameEnd
  Anything??.abc  = "?" matches 1 or 0 chars (except '.')
 (Not the same as "Anything*.abc", but the same
  as regex "Anything.{0,2}\.abc")
  Internally converted to "Anything[??].abc"

--eWindowsQuirk_Extension3More
  Anything.abc= Matches "Anything.abc" but also
   "Anything.abc*" (3 char extension)
  Anything.ab = Matches "Anything.ab" and never
   "anything.abcd"

--eWindowsQuirk_EmptyIsAny
  ""  = Empty string matches anything "*"

--eWindowsQuirk_AllByExtension (Not in use anymore)
  .abc= Runs as "*.abc"

--eWindowsQuirk_NoExtension
  Anything*.  = Matches "Anything*" without extension

8<8<-

--

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Juha Manninen via lazarus
On Wed, Feb 24, 2021 at 1:00 PM Bart via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> > > There are no tests for MatchesWindowsMask() yet.
> I tested that extensively on my machine with all scenarios I could think
> of.
>

Please add your tests to the project I mentioned.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] Lazarus Release 2.0.12

2021-02-24 Thread Mattias Gaertner via lazarus
The Lazarus team is glad to announce the release of Lazarus 2.0.12.

This release was built with FPC 3.2.0.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_2.0.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.0

Windows users should be careful with -O3 or higher optimization, due to
bug https://bugs.freepascal.org/view.php?id=37305.

Here is the list of fixes for Lazarus 2.0.x:
http://wiki.freepascal.org/Lazarus_2.0_fixes_branch

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 2.0.12" directory.

Checksums for the SourceForge files:
http://www.lazarus-ide.org/index.php?page=checksums#2_0_12

Minimum requirements:

Windows:
  2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.

FreeBSD/Linux:
  gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.

Mac OS X:
  Cocoa (64bit) 10.12 to 10.15, Carbon (32bit) 10.5 to 10.14, qt and
  qt5 (32 or 64bit).

The svn tag is
http://svn.freepascal.org/svn/lazarus/tags/lazarus_2_0_12

For people who are blocked by SF, the Lazarus releases from SourceForge
are mirrored at: ftp://ftp.freepascal.org/pub/lazarus/releases/


Mattias
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread José Mejuto via lazarus

El 24/02/2021 a las 11:47, Bart via lazarus escribió:

On Wed, Feb 24, 2021 at 10:02 AM Bart  wrote:


Of course that is NOT a reason not to improve it: O(n^4) is just terrible.


To put this discussion in a little perspective.
Given a string S (UTF8 encoded) with Utf8Length=1000.
GetCodePoint(S,1000) on my laptop takes 0.00439 msecs to perform.
So 10 thousand of these lookups cost appr. 44 ms.
This is kind of a worst case scenario.
You are not very likely to have strings that long in TMask.MatchesMask
(and certainly not in a MaskEdit).


Hello,

The worst case scenario is not based in GetCodePoint time, is in the 
TMask logic when "*" is found, it enters in recursive scan from that 
point, if it founds a new "*" it recurses again and if it finally fails 
in comparison it rolls back to the first "*". So specially crafted masks 
makes it recurse a lot.


String:='This is a test string';
Mask:='*T*h*s*n*x';

Of course this is not a day by day use ;-)

Note: Just to put in context, my "explore" in the TMask world started 
when writing my NTFS filesystem reader, when all file names are read 
(400,000) I can search for them using masks. When compiled in fpc 
(Lazarus) the "*.txx" search takes 1-2 seconds (not measured) and when 
compiled with Delphi it takes +/- 0.3 seconds, so I stated to write my 
own TMask.



--

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 11:22 AM José Mejuto via lazarus
 wrote:

> In my code there is non 100% unicode compatibility when using the
> "CaseInsensitive" mode as as it uses lowercase mask and lowercase string
> to perform the test which is wrong by definition

Currently Masks unit does the same.

> 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 us 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.

Sometimes I wish we would migrate to using UnicodeString by default.
It would make life a bit easier.
(And yes I know you would have to deal with composed characters
(grapheme defined by more than 1 16-bit word)).

> > There are no tests for MatchesWindowsMask() yet.
I tested that extensively on my machine with all scenarios I could think of.
But others most likely can think of scenarios I did not test.
It was based on current behaviour of Windows NT platform (Win7 at the
time to be precise).

> Who defines which are right and which are wrong ?
Well, I did ;-)
(Nobody else bothered at the time, and nobody complained either.)

-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 10:02 AM Bart  wrote:

> Of course that is NOT a reason not to improve it: O(n^4) is just terrible.

To put this discussion in a little perspective.
Given a string S (UTF8 encoded) with Utf8Length=1000.
GetCodePoint(S,1000) on my laptop takes 0.00439 msecs to perform.
So 10 thousand of these lookups cost appr. 44 ms.
This is kind of a worst case scenario.
You are not very likely to have strings that long in TMask.MatchesMask
(and certainly not in a MaskEdit).

-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread José Mejuto via lazarus

El 24/02/2021 a las 10:31, Juha Manninen via lazarus escribió:

José Mejuto's code is a major rewrite for Masks. It supports Unicode in 
masks, too.
I try to make it compatible by changing some class and method names, and 
then run the unit tests.


Hello,

In my code there is non 100% unicode compatibility when using the 
"CaseInsensitive" mode as as it uses lowercase mask and lowercase string 
to perform the test which is wrong by definition but I was unable to 
find a method to test codepoints case insensitive without pulling in big 
unicode tables.


I was thinking in import the NTFS (the filesystem) case comparison 
tables which are 128 KB "only".



Comprehensive unit tests are a way to prevent breaking things.


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.



There are no tests for MatchesWindowsMask() yet.


Who defines which are right and which are wrong ? There is no official 
DOS/Windows mask strategies, only inherited behaviour since CP/M. Maybe 
the behaviour of CMD.EXE ? Which version of CMD.EXE ?


--

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Juha Manninen via lazarus
I will not touch MaskEdit. Don't worry.

On Wed, Feb 24, 2021 at 11:03 AM Bart via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Without a major rewrite (which increases the cange of breaking
> compatibility).
>

José Mejuto's code is a major rewrite for Masks. It supports Unicode in
masks, too.
I try to make it compatible by changing some class and method names, and
then run the unit tests.
Comprehensive unit tests are a way to prevent breaking things.
Please everybody provide more test cases. The project is in
components/lazutils/test.
There are no tests for MatchesWindowsMask() yet.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Bart via lazarus
On Wed, Feb 24, 2021 at 9:11 AM Juha Manninen via lazarus
 wrote:

>> TMask (unit masks) deals with masks with wildcards (*,? and sets of
>> single byte chars).
...
> TMask also supports ranges and sets. See the unit test.
> Eg.  '[a-b]', '[!a-b]', '[abc]', '[0-9]'

By single byte chars I meant ASCII only.
You cannot have '[ä..ë]' in a TMask (a constraint that is a side
effect of the implementation, but this would be sort of an undefined
range as well).

> Now I found documentation for TCustomMaskEdit.EditMask. It explains the syntax
It is the soucecode (has been there from the beginning) and in the wiki.

> and it looks like the MaskUtils syntax.
Again: it's the other way around: the code of MaskUtils looks like the
code of MaskEdit.

>> As you have pointed out before, the GetCodePoint function in the Masks
>> unit needs overhoaling.
>
>
> It is much worse than that!
> Yes, GetCodePoint does its own nested loops and useless copies.
> But then it and other UTF8...() functions are called inside a loop, 
> effectively causing many nested loops.
> The scalability is maybe O(n^3) or O(n^4).
> José Mejuto's Mask unit looks promising. He mentioned in a private mail 
> (which should be public IMO, no deep secrets there) that a pattern
>  "*something*to*write*here*"
> "which with current mask it takes a lot of time to be processed. If matchable 
> string is of more than 200 chars long it could take seconds to be resolved. 
> My classes are typically O(n)."
> Many seconds in a modern computer is a lot.

I use this Mask unit extensively for my backup program.
Resolving TMaskMatches even for long strings and mask take orders of
magnitude less time then accessing the file (just opening it).

Of course that is NOT a reason not to improve it: O(n^4) is just terrible.
Mind you, the GetCodePoint/SetCodePoint originally was just a quick
(as in: simple, stupis, short code) hack to get the UTF8 functionality
in MaskEdit.
After changing all SomeString[i] to either GetCodePoint(SomeString,i)
or SetCodePoint(SomeString,i, ACodePoint) the MaskEdit unit was UTF8
capable at once.
Without a major rewrite (which increases the cange of breaking compatibility).

Mind you that the first implementation of GetCodePoint was even more
"simple", it simply called Utf8Copy(SomeString, i, 1)...

So, yes re-implement GetCodePoint/SetCodePoint or the internal logic
of the Masks unit by all means, but as far as the MaskEdit unit is
concerned the function signature should not change. There is no need
for a major rewrite of that unit: it deals with user input and even if
you make it 100 times slower as it is now, user will not notice it.

-- 
Bart
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] unit Masks vs. unit FPMasks

2021-02-24 Thread Juha Manninen via lazarus
On Wed, Feb 24, 2021 at 12:08 AM Bart via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> TMask (unit masks) deals with masks with wildcards (*,? and sets of
> single byte chars).
> It is mainly used for matching filenames (similar to the Path supplied
> to FindFirst).
>
> TMaskEdit gives you the possibility to constrain user input to almost
> anything you like,
> Can be used for e.g. ZIP codes, only numbers etc.
>

TMask also supports ranges and sets. See the unit test.
Eg.  '[a-b]', '[!a-b]', '[abc]', '[0-9]'

Now I found documentation for TCustomMaskEdit.EditMask. It explains the
syntax and it looks like the MaskUtils syntax.
It was documented, good! I missed it earlier.
I know filename wildcards and I know regular expressions. Now learning this
Mask thingy...


As you have pointed out before, the GetCodePoint function in the Masks
> unit needs overhoaling.
>

It is much worse than that!
Yes, GetCodePoint does its own nested loops and useless copies.
But then it and other UTF8...() functions are called inside a loop,
effectively causing many nested loops.
The scalability is maybe O(n^3) or O(n^4).
José Mejuto's Mask unit looks promising. He mentioned in a private mail
(which should be public IMO, no deep secrets there) that a pattern


* "*something*to*write*here*""which with current mask it takes a lot of
time to be processed. If matchable string is of more than 200 chars long it
could take seconds to be resolved. My classes are typically O(n)."*
Many seconds in a modern computer is a lot.


(It is the same as in TMaskEdit, but that only reacts to user input
> with strings <=255 chars, so speed is not required there: I'ld love to
> see someone typing faster that the code in TMaskEdit calculates what
> needs to be done.)
>

True, but the code should be cleaned anyway and maybe reuse some other code.
Code has aesthetic values, too.


Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus