perl.perl5.porters

perl.perl5.porters https://www.nntp.perl.org/group/perl.perl5.porters/ ... Copyright 1998-2023 perl.org Wed, 06 Dec 2023 21:31:37 +0000 ask@perl.org Re: Summary: Proposed change to Corinna OOP system by Martijn Lievaart via perl5-porters Op 06-12-2023 om 07:57 schreef Ovid: > On Wed, Dec 6, 2023 at 2:04 AM Chris Prather <chris@prather.org> wrote: > > I really just want `method foo() { }` with no visibility attribute > to be a compile time error and not to default to `method foo > :private () {}`. > > Being rather tired of pushing the rock up the hill, I was tempted to > not post my summary reply. Now I'm glad I did because it's clear that > I misunderstood your intent. > > I would be /delighted/ if a method with no visibility attribute was a > compile-time error. It's more typing and devs will complain, but this > suggestion neatly solves the problem. Interfaces are explicit and > intentional. (well, maybe not the latter, but at least someone can't > blame Perl for the mistake this time). I think we would still need a > single attribute for visibility, but this gets us much closer. > And it still doesn't rule out an explicit default given in the use statement, for those that want that (I know I would use that to default to private). HTH, M4 https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267496.html Wed, 06 Dec 2023 18:04:09 +0000 Re: Post-mortem: Security Releases of this weekend by James E Keenan On 12/6/23 07:25, sisyphus wrote: > > Where can we view the changes that were made in order to fix these 2 > security issues ? > Have they been applied to blead ? > See, for example, commit ff1f9f59360afeebd6f75ca1502f5c3ebf077da3. https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267495.html Wed, 06 Dec 2023 12:43:12 +0000 Re: Post-mortem: Security Releases of this weekend by sisyphus On Wed, Dec 6, 2023 at 9:58â¯PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote: > The intention of the task was to create 3 new releases all at once, > as a "surprise" because they contained security-related fixes. > Where can we view the changes that were made in order to fix these 2 security issues ? Have they been applied to blead ? Cheers, Rob https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267494.html Wed, 06 Dec 2023 12:25:17 +0000 Re: Summary: Proposed change to Corinna OOP system by "Ruud H.G. van Tol" via perl5-porters On 2023-12-06 07:57, Ovid wrote: > On Wed, Dec 6, 2023 at 2:04 AM Chris Prather <chris@prather.org> wrote: > > I really just want `method foo() { }` with no visibility attribute > to be a compile time error and not to default to `method foo > :private () {}`. > > Being rather tired of pushing the rock up the hill, I was tempted to > not post my summary reply. Now I'm glad I did because it's clear that > I misunderstood your intent. > > I would be /delighted/ if a method with no visibility attribute was a > compile-time error. It's more typing and devs will complain, but this > suggestion neatly solves the problem. Interfaces are explicit and > intentional. (well, maybe not the latter, but at least someone can't > blame Perl for the mistake this time). I think we would still need a > single attribute for visibility, but this gets us much closer. Then I think it would be good to have an independent 'default' dimension. For that, Corinna likely needs to have some before-/after-/around-hooks. With such, one can then make all methods to be private by default, or all methods with a name matching C</^_\w+$/aa>, etc. -- Ruud https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267493.html Wed, 06 Dec 2023 12:07:27 +0000 Re: Post-mortem: Security Releases of this weekend by Sam James "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes: > The intention of the task was to create 3 new releases all at once, > as a "surprise" because they contained security-related fixes. Those > fixes had been distributed as patches to vendors in the two weeks > prior, so this was the determined time to make it public. As such, it > was a little difficult to work too much out in the open, as would be > the case for a normal blead-point or maint release. Normal maintenance > policy said we should keep 5.38 and 5.36 updated, but we decided since > we're doing two releases anyway, adding a third didn't make it much > worse, so I was building all of 5.34.2, 5.36.2 and 5.38.1. Thank you for writing this up, and I should say, all of it is understandable and it didn't bother us downstream really. These things happen. > [...] > > Suggestions to fix avoid in future > > * Fix up many of the scripts to work in git worktrees > > * Early bailout if run using systemperl for those scripts that must > be run on the built perl > > * Tooling to help automate the Module::CoreList process. At the very > least its own module should always be updated in every block; as > should B::Opcode and Config. > > * Further consider if we need to keep the "next upcoming release" in > blead's Module/CoreList.pm at all; as it complicates > out-of-sequence maint releases in this process > > * Streamlining of the RMG to reduce the number of steps overall, > combine more testing phases, less build/clean/build/clean... > > * Also update the wording / formatting of the RMG, making it much > easier to see which steps apply to which kinds of release > > * Fix up / skip / ignore the always-failing or flaky CI tests, so > that failure messages become useful signals and not noise. These all sound like decent steps as well. In particular making sure worktrees are fine (given they're likely to make life easier for working on branches, we really don't want people to be scared of them), and reducing confusion between just-built and system perl. thanks, sam https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267492.html Wed, 06 Dec 2023 11:13:22 +0000 Post-mortem: Security Releases of this weekend by Paul "LeoNerd" Evans The intention of the task was to create 3 new releases all at once, as a "surprise" because they contained security-related fixes. Those fixes had been distributed as patches to vendors in the two weeks prior, so this was the determined time to make it public. As such, it was a little difficult to work too much out in the open, as would be the case for a normal blead-point or maint release. Normal maintenance policy said we should keep 5.38 and 5.36 updated, but we decided since we're doing two releases anyway, adding a third didn't make it much worse, so I was building all of 5.34.2, 5.36.2 and 5.38.1. Since I was building three sets of tarballs all at once, I got myself a large-CPU machine and used three separate "git worktree" directories, one on each of the maint-5.34, maint-5.36 and maint-5.38 branches. This meant I could build them all concurrently, rather than constantly having to switch between all three branches. This saved much time. A timeline of what steps I took: 1. Prepared tarballs by following RMG, these were tested as RC1 from a private server URL. 2. Some of these needed some minor fixes to documentation, two were then tested as RC2. 3. Now found to be OK, I prepared the real tarballs. These were then uploaded to PAUSE. 4. The PAUSE indexer failed on these because they were not marked as "stable" according to the META.json file inside them. 5. I rebuilt the tarballs with updated META.json 6. Because PAUSE doesn't let you create the same file again, these were uploaded with "a" suffix on the filename. 7. The tests in these were still failing; specifically t/porting/regen.t At this point I decided I wasn't going to have a third attempt, as I was not in a good mental state to continue. I took a step back to have another look the next day. After some poking around the weekend we eventually came to the conclusion to abandon those version numbers and rebuild the next numbers - 5.34.3, 5.36.3, 5.38.2. What went wrong: 1. First time, I forgot to rebuild META.json - because it's a separate manual step in the RMG, somewhat hard to notice because of the wording of the RMG. Also I wasn't really thinking it would be a discrete step, since when using more regular tools for building CPAN modules ("./Build dist" or "make dist") that would be included there anyway. 2. I rebuilt the META.json file by running "perl" not "./perl" so it wrote the wrong version number of JSON::PP into the file. This wouldn't normally really matter, except for the fact that t/porting/regen.t demands a byte-for-byte perfect copy to be recreated. 3. Also Module::CoreList was wrong in several ways; having missed the update of itself in any of the releases, and also declaring information about the upcoming 5.39.6 release that didn't even exist at that point. Extenuating factors: * Many porting scripts differ in behaviour. Some work in workdirs, some do not. Some require `git clean -dxf`, some require the built perl * Some porting scripts *require* the built perl but do not complain if not run using it, and therefore break in subtle ways * Module::CoreList continues not to have any tooling around updating it, especially for nontrivial setups like this * CI tests did in fact pick up on these issues, but I didn't notice, because CI tests *always* fail for various spurious reasons. I have taken to ignoring any failure notifications. Example: i386 never works - https://github.com/Perl/perl-security/actions/runs/7020092773/job/19099577640 Win32 never works - https://github.com/Perl/perl-security/actions/runs/7020092773/job/19099579131 Suggestions to fix avoid in future * Fix up many of the scripts to work in git worktrees * Early bailout if run using systemperl for those scripts that must be run on the built perl * Tooling to help automate the Module::CoreList process. At the very least its own module should always be updated in every block; as should B::Opcode and Config. * Further consider if we need to keep the "next upcoming release" in blead's Module/CoreList.pm at all; as it complicates out-of-sequence maint releases in this process * Streamlining of the RMG to reduce the number of steps overall, combine more testing phases, less build/clean/build/clean... * Also update the wording / formatting of the RMG, making it much easier to see which steps apply to which kinds of release * Fix up / skip / ignore the always-failing or flaky CI tests, so that failure messages become useful signals and not noise. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267491.html Wed, 06 Dec 2023 10:58:47 +0000 Re: Summary: Proposed change to Corinna OOP system by Darren Duncan On 2023-12-05 10:52 p.m., Ovid wrote: > Tempting because that gets us back to a single keyword and avoids the > attribute collision problem—until you extend that beyond public/private and > needs attributes for metadata and those attributes are tied to a single > keyword (e.g., `¸trusted foo () :access(Some::Classes) { ... }` ) Does anyone think there is value to support naming the trusted classes on a per-method basis rather than simply on a per-class basis? I previously recommended just enumerate the trusted classes at the class level and the only thing on the method itself is the boolean :trusted. Even Raku which is the only language I know of to have trusts on a per-class basis in contrast to being on a per-library basis, declares the list at the class level, per this example from the Raku docs: class A { trusts B; has $!foo; method !foo { return-rw $!foo } method raku { "A.new(foo => $!foo)" } }; And AFAIK the Raku version doesn't have per-method granularity at all; you just declare at the class level the trusts and then any method of B may call any method of A. I feel we can do better than Raku at marking individual methods for trusting, meaning we can still also have other methods that are actually private, per the example of C#/Java/etc. -- Darren Duncan https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267490.html Wed, 06 Dec 2023 09:03:47 +0000 Re: Summary: Proposed change to Corinna OOP system by Ovid On Wed, Dec 6, 2023 at 2:04â¯AM Chris Prather <chris@prather.org> wrote: > I really just want `method foo() { }` with no visibility attribute to be a > compile time error and not to default to `method foo :private () {}`. > Being rather tired of pushing the rock up the hill, I was tempted to not post my summary reply. Now I'm glad I did because it's clear that I misunderstood your intent. I would be *delighted* if a method with no visibility attribute was a compile-time error. It's more typing and devs will complain, but this suggestion neatly solves the problem. Interfaces are explicit and intentional. (well, maybe not the latter, but at least someone can't blame Perl for the mistake this time). I think we would still need a single attribute for visibility, but this gets us much closer. Best, Ovid https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267489.html Wed, 06 Dec 2023 06:58:02 +0000 Re: Summary: Proposed change to Corinna OOP system by Ovid On Wed, Dec 6, 2023 at 6:38â¯AM Oodler 577 <oodler577@sdf-eu.org> wrote: > Why not just trade "method" for "public" or "private"; it seems > obvious what follows. I can't read Moose so idk if I got this correct, > looking at what Java does having "method" there at all seems redundant Tempting because that gets us back to a single keyword and avoids the attribute collision problemâuntil you extend that beyond public/private and needs attributes for metadata and those attributes are tied to a single keyword (e.g., `Â¸trusted foo () :access(Some::Classes) { ... }` ) Corinna is down to four keywords: `class`, `role`, `field`, and `method`. Those represent the four fundamental capabilities. The attributes are used to adjust those capabilities. So making `public` and `private` replacements for `method` not only goes back down the road of keyword-proliferation, it violates our KIM syntax guideline <https://ovid.github.io/articles/language-design-consistency.html>. Best, Ovid https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267488.html Wed, 06 Dec 2023 06:52:17 +0000 Re: Summary: Proposed change to Corinna OOP system by Oodler 577 via perl5-porters * Chris Prather <chris@prather.org> [2023-12-05 20:03:57 -0500]: > On Tue, Dec 5, 2023 at 4:21?AM Ovid <curtis.poe@gmail.com> wrote: > > > > > Chris Prather would have supported the idea if it could be known at > > compile time if `$object->foo` was trying to call a method it can't call, > > but given Perl's nature, that's probably impossible. I *think* he might > > have supported it if all methods had to declare their visibility. > > > > > I really just want `method foo() { }` with no visibility attribute to be a > compile time error and not to default to `method foo :private () {}`. > > Take for example the following scenario. > > We have code that generates an index page in our site generator: > ``` > package Index; > use Moose; > > has entries => ( > isa => 'ArrayRef[Object]', > traits => ['Array'], > required => 1, > handles => { > entries => 'elements', > size => 'count', > }, > ); > > sub render_fragment_HTML ($self, $renderer) { > return join "\n" => ( > '<div class="index">' , > map { $_->render_fragment($renderer) } $self->entries, > '</div>' > ); > } > ``` > If I were to hand this to a new-to-perl developer and say "update this to > use the class feature" this is IMO the obvious translation: > ``` > class Index { > field $entries :param; > > method entries { @$entires } > method size { scalar @$entries } > > method render_fragment_HTML ($renderer) { > return join "\n" => ( > '<div class="index">' , > map { $_->render_fragment($renderer) } @$entries, > '</div>' > ); > } > } > ``` Why not just trade "method" for "public" or "private"; it seems obvious what follows. I can't read Moose so idk if I got this correct, looking at what Java does having "method" there at all seems redundant. ``` class Index { field $entries :param; private entries { @$entires } private size { scalar @$entries } public render_fragment_HTML ($renderer) { return join "\n" => ( '<div class="index">' , map { $_->render_fragment($renderer) } @$entries, '</div>' ); } } ``` But idk, this might conflict somehow with something else. I just saw that and wanted to mention it. Cheers, Brett > Under the proposal this would throw a runtime error because we changed the > visibility of `render_fragment_HTML` from public to private. Preventing it > from then ending up in production relies on one of the following: > * someone notices the _abscence_ of `:public` in a code review ? not > traditionally something humans are good at > * someone notices an error message in what might be a noisy stream of > logging information ? not traditionally something humans are good at > * a test suite that is comprehensive enough for this to cause a test > failure ? not traditionally something codebases are good at > > A compile time exception IMO gives us the best chance to catch it before > production. > > -Chris -- oodler@cpan.org ~> oodler577@sdf-eu.org SDF-EU Public Access UNIX System - http://sdfeu.org irc.perl.org #openmp #pdl #native gopher://sdfeu.org/1/users/oodler577/ Carl Spackler: [preparing to dynamite the gopher tunnel] In the immortal words of Jean Paul Sartre, Au revoir, gopher. https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267487.html Wed, 06 Dec 2023 05:38:56 +0000 Re: Summary: Proposed change to Corinna OOP system by Darren Duncan On 2023-12-05 5:03 p.m., Chris Prather wrote: > On Tue, Dec 5, 2023 at 4:21 AM Ovid <curtis.poe@gmail.com> wrote: >> Chris Prather would have supported the idea if it could be known at >> compile time if `$object->foo` was trying to call a method it can't call, >> but given Perl's nature, that's probably impossible. I *think* he might >> have supported it if all methods had to declare their visibility. > > I really just want `method foo() { }` with no visibility attribute to be a > compile time error and not to default to `method foo :private () {}`. I agree with you, and would prefer that it is mandatory to have a visibility trait, and there is no default. So what if it is a bit more verbose, its only one extra short word per method, not per line, and helps avoid so many bugs, or lost developer productivity from looking at code and trying to figure out what it does. -- Darren Duncan https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267486.html Wed, 06 Dec 2023 04:10:26 +0000 Perl 5 Commit Summary by Perl 5 commit summary Perl 5 commit summary, activity since Saturday Current branch blead 32 commits. 4 unique authors. 3 unique committers. 18 files changed, 986 insertions(+), 217 deletions(-) Thanks, applied: Karl Williamson (1) Snapshot: http://github.com/Perl/perl5/tarball/450676c25a73a935 perldebug.pod: Fix broken link Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/450676c25a73a935 x-yuri is now a Perl author Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/e38a781ec51e0ab0 perldebug: clarify the readline support x-yuri 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/79950615ae6d4a4c perldelta for fea90cfbe1f Tony Cook 1 file changed, 5 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/20b9297558d49b1e grow the tmps (mortal) stack exponentially rather than linearly Tony Cook 1 file changed, 6 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/fea90cfbe1f221d5 [MERGE] unwrap, optimise pp_aassign() and friends David Mitchell 2 parents https://github.com/Perl/perl5/commit/7fbd97b4e807873b fix Perl_rpp_is_lone() for immortals. David Mitchell 3 files changed, 36 insertions(+), 4 deletions(- https://github.com/Perl/perl5/commit/efc99d519efd5227 pp_aassign: move UID/GID code into separate fn David Mitchell 1 file changed, 98 insertions(+), 83 deletions(- https://github.com/Perl/perl5/commit/f54903ed18841195 pp_aassign: optimise: just zero hash stack elems David Mitchell 1 file changed, 19 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/a2677daf97ded4a3 pp_aassign: optimise: just zero array stack elems David Mitchell 1 file changed, 6 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/2a2c64dd01fc7424 pp_aassign: optimise: lelem++ at end of loop David Mitchell 1 file changed, 21 insertions(+), 15 deletions(- https://github.com/Perl/perl5/commit/971e9b5a17aced68 pp_aassign: optimise: store NULLs in L elem slots David Mitchell 1 file changed, 88 insertions(+), 9 deletions(-) https://github.com/Perl/perl5/commit/295ebb578ae1ffef pp_aassign: skip copying scalars back to stack David Mitchell 1 file changed, 4 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/443b64a02939b4e8 pp_aassign: add is_list local variable David Mitchell 1 file changed, 6 insertions(+), 5 deletions(-) https://github.com/Perl/perl5/commit/a2515f4c681acde6 use rpp_foo_NN() variants in pp_aassign, pp_rv2av David Mitchell 1 file changed, 24 insertions(+), 20 deletions(- https://github.com/Perl/perl5/commit/4d8fbc55082bc848 Add some _NN variants of rpp_() functions. David Mitchell 5 files changed, 265 insertions(+) https://github.com/Perl/perl5/commit/cc49ed3d254ee601 use rpp_replace_at_norc in refassign, aassign David Mitchell 2 files changed, 22 insertions(+), 28 deletions( https://github.com/Perl/perl5/commit/0cf81d166744bf23 add rpp_replace_at_norc() to API David Mitchell 5 files changed, 48 insertions(+) https://github.com/Perl/perl5/commit/f11efeed3a5b76aa pp_aassign: fix "RC==1" optimisation checks David Mitchell 1 file changed, 15 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/8915a2954e1e7a90 pp_aassign: remove panic check under PERL_RC_STACK David Mitchell 2 files changed, 16 insertions(+), 13 deletions( https://github.com/Perl/perl5/commit/12e444f71226b832 pp_aassign: optimise SV branch under PERL_RC_STACK David Mitchell 1 file changed, 3 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/5a8fb493e89e0884 pp_aassign: optimise HV branch under PERL_RC_STACK David Mitchell 1 file changed, 56 insertions(+), 8 deletions(-) https://github.com/Perl/perl5/commit/39a2e63986dff01f pp_aassign: optimise AV branch under PERL_RC_STACK David Mitchell 1 file changed, 72 insertions(+), 9 deletions(-) https://github.com/Perl/perl5/commit/dba1d971bd26e7a0 make RC-stack-aware: unwrap pp_aassign() David Mitchell 1 file changed, 40 insertions(+), 26 deletions(- https://github.com/Perl/perl5/commit/eb535a3b7c3f7f88 make RC-stack-aware: unwrap pp_undef() David Mitchell 1 file changed, 18 insertions(+), 16 deletions(- https://github.com/Perl/perl5/commit/b5e6ad2a94d4362c make RC-stack-aware: unwrap pp_refassign() David Mitchell 1 file changed, 42 insertions(+), 17 deletions(- https://github.com/Perl/perl5/commit/604c0355d21cd2bd op/array.t: skip \$#{[]} test under PERL_RC_STACK David Mitchell 1 file changed, 11 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/a98ee9eadd3d547a make RC-stack-aware: unwrap pp_emptyavhv() David Mitchell 2 files changed, 21 insertions(+), 15 deletions( https://github.com/Perl/perl5/commit/14403447b7488675 Hash-Util-FieldHash: fixup test on PERL_RC_STACK David Mitchell 1 file changed, 5 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/313c8957d3078015 add lvalue scalar alias tests to lvref.t David Mitchell 1 file changed, 18 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/b98a30fe2d289132 add list context tests to t/op/lvref.t David Mitchell 1 file changed, 84 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/823fcbfd95001ebd document ref assignment in list context David Mitchell 1 file changed, 10 insertions(+) https://github.com/Perl/perl5/commit/08368a773f179335 Current branch smoke-me/khw-env 164 commits. 1 unique author. 1 unique committer. 146 files changed, 3484 insertions(+), 1139 deletions(-) Snapshot: http://github.com/Perl/perl5/tarball/096dc4d4f45301b5 cleanup Karl Williamson 2 files changed, 7 insertions(+), 5 deletions(-) https://github.com/Perl/perl5/commit/096dc4d4f45301b5 pp_study: hook Karl Williamson 1 file changed, 4 insertions(+) https://github.com/Perl/perl5/commit/020a4c2e0baea632 perl.h: Fixup FAKE_MINGW Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/6016a7a7eada7794 lib/locale.t start of setlocale failure Karl Williamson 1 file changed, 11 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/d05bd63fcc721c16 wrap uselocale Karl Williamson 1 file changed, 31 insertions(+), 14 deletions(- https://github.com/Perl/perl5/commit/7c56ac4d44bf2a71 openbsd mismatched ctype hints Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/cfe5060386db608d openbsd hints Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/abca44dde6314840 openbsd: Not thread safe locales Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/8ce118e2187057ae openbsd Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/df8debf119c3b5a6 Revert "locale_threads.t: Skip on OpenBSD and DragonFly threaded builds" Karl Williamson 1 file changed, 2 deletions(-) https://github.com/Perl/perl5/commit/84f78d25b7112e57 Revert "langinfo.t" Karl Williamson 1 file changed, 3 insertions(+), 12 deletions(-) https://github.com/Perl/perl5/commit/7f791574181c5c75 langinfo.t Karl Williamson 1 file changed, 12 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/77e16b3ee04ba725 Don't do thread-safe locales emulation on mingw Karl Williamson 2 files changed, 5 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/0753cc1684c2453c locale_threads.t: Better handle weird locales Karl Williamson 1 file changed, 4 insertions(+), 6 deletions(-) https://github.com/Perl/perl5/commit/2e6ee7220e2f4e2f langinfo_l Karl Williamson 1 file changed, 27 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/fe97886031b3ef69 final commit Karl Williamson 1 file changed, 15 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/f8ea1f61e5699512 Enable DEBUG_SETLOCALE_INCONSISTENCIES Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/c4e39fb9d2de8bb4 Add DEBUG_SETLOCALE_INCONSISTENCIES Karl Williamson 1 file changed, 25 insertions(+) https://github.com/Perl/perl5/commit/e4e0325111463ee5 makedef.pl: Move comment Karl Williamson 1 file changed, 1 insertion(+), 3 deletions(-) https://github.com/Perl/perl5/commit/e44553e18af1b570 makedef.pl: PL_cur_locale_obj is only POSIX 2008 multiplicity Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/c15d749e7c26bc9a XXX perl.h maybe drop Karl Williamson 1 file changed, 10 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/13a546f149a20334 Experimentally enable per-thread locale emulation Karl Williamson 3 files changed, 12 insertions(+), 4 deletions(- https://github.com/Perl/perl5/commit/15abb9f1991d57aa femul Karl Williamson 2 files changed, 2 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/53a00e228c7fe01f more emul Karl Williamson 1 file changed, 5 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/01e7bc7d51b6947e more emul Karl Williamson 5 files changed, 55 insertions(+), 21 deletions( https://github.com/Perl/perl5/commit/8ab79d2ee6d81aa5 Add ability to emulate thread-safe locale operations Karl Williamson 14 files changed, 967 insertions(+), 100 deletio https://github.com/Perl/perl5/commit/ea80b0af50f9d742 locale.c: Avoid a recalculation Karl Williamson 1 file changed, 6 insertions(+) https://github.com/Perl/perl5/commit/74cb7030ada0da41 locale.c: Avoid unnecessary locale changes Karl Williamson 1 file changed, 18 insertions(+), 11 deletions(- https://github.com/Perl/perl5/commit/c1f5fbcc639730db S_my_langinfo_i: Be sure to return in both places Karl Williamson 1 file changed, 9 insertions(+) https://github.com/Perl/perl5/commit/3a51c783ab6d27d6 lib/locale_threads.t: Add debugging info Karl Williamson 1 file changed, 7 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/96b8b4ba280b827b lib/locale_threads.t: Change variable names Karl Williamson 1 file changed, 20 insertions(+), 20 deletions(- https://github.com/Perl/perl5/commit/af12c4e05dc697a8 locale.c: Change macro calls to shorter form Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/fdfca0a1e950b541 XXX msg locale.c: Refactor an #ifdef Karl Williamson 1 file changed, 9 insertions(+), 11 deletions(-) https://github.com/Perl/perl5/commit/49f4afea7076027a locale.c: Rmv warning and unnecessary declaration Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/90f163b634661aae add FAKE MING Karl Williamson 3 files changed, 11 insertions(+), 9 deletions(- https://github.com/Perl/perl5/commit/74e92f8c07b70a75 debug thread xs Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/75212e415189a00e locale.c: If strftime() fails, use a platform errno Karl Williamson 1 file changed, 17 insertions(+), 6 deletions(-) https://github.com/Perl/perl5/commit/64247d808f080ad7 strtod_l Karl Williamson 1 file changed, 26 insertions(+), 5 deletions(-) https://github.com/Perl/perl5/commit/d3c7d6b6fb5d5286 strtod Karl Williamson 1 file changed, 39 insertions(+), 61 deletions(- https://github.com/Perl/perl5/commit/4e164f55b2792d33 locale.c: XXX Move codeset to separate function Karl Williamson 1 file changed, 255 insertions(+), 244 deletions https://github.com/Perl/perl5/commit/43b28213e3046f5b mismatched ctype Karl Williamson 1 file changed, 14 insertions(+), 9 deletions(-) https://github.com/Perl/perl5/commit/5f652024edeae1d1 locale.c: Move code to within only block using it Karl Williamson 1 file changed, 2 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/8111e041e10516c7 locale.c: Comments and white space Karl Williamson 1 file changed, 13 insertions(+), 5 deletions(-) https://github.com/Perl/perl5/commit/f916427bc23f2abc locale.c: Add shortcut ruling out locale being UTF8 Karl Williamson 1 file changed, 14 insertions(+) https://github.com/Perl/perl5/commit/02135a9b61d1058b locale.c: Fix up some comments Karl Williamson 1 file changed, 10 insertions(+), 7 deletions(-) https://github.com/Perl/perl5/commit/84ec2bb79a334ed4 locale.c: Move code into another function Karl Williamson 1 file changed, 54 insertions(+), 43 deletions(- https://github.com/Perl/perl5/commit/83393e8525d3d596 locale.c: Move declarations, add comments Karl Williamson 1 file changed, 9 insertions(+), 10 deletions(-) https://github.com/Perl/perl5/commit/8608ae069651735d locale.c: Tighten rules for detecting locale UTF-8ness Karl Williamson 1 file changed, 3 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/db33a41b3773f451 locale.c: S_is_locale_utf8(): "C" locale not UTF-8 Karl Williamson 1 file changed, 4 insertions(+) https://github.com/Perl/perl5/commit/77dff2679e5b2306 debug populate localeconv Karl Williamson 1 file changed, 8 insertions(+) https://github.com/Perl/perl5/commit/f42c31ba67ec84fd Do localeconv() adjustments immediately unthreaded Karl Williamson 1 file changed, 60 insertions(+), 16 deletions(- https://github.com/Perl/perl5/commit/dcb35661dddf924b locale.c: Do an adjustment in a critical section Karl Williamson 1 file changed, 7 insertions(+), 32 deletions(-) https://github.com/Perl/perl5/commit/1297ff03e8938175 locale.c: Add struct definition as a fallback Karl Williamson 1 file changed, 44 insertions(+) https://github.com/Perl/perl5/commit/566dd3cd0b73639a locale.c: White space only Karl Williamson 1 file changed, 91 insertions(+), 92 deletions(- https://github.com/Perl/perl5/commit/be0da6a08af824b2 Return C values if localeconv() not available Karl Williamson 4 files changed, 44 insertions(+), 58 deletions( https://github.com/Perl/perl5/commit/86bd6ba8d6a06e93 funusedarg Karl Williamson 1 file changed, 2 deletions(-) https://github.com/Perl/perl5/commit/19d20b36446d4dd9 Remove unimplemented macros Karl Williamson 1 file changed, 2 deletions(-) https://github.com/Perl/perl5/commit/20874e94c0e648df XXX fleash outlocale.c: Revamp localeconv() Win32 handling Karl Williamson 1 file changed, 68 insertions(+), 61 deletions(- https://github.com/Perl/perl5/commit/8801da88fe38d0ba Avoid unnecessary mutex lock on Windows Karl Williamson 1 file changed, 18 insertions(+), 6 deletions(-) https://github.com/Perl/perl5/commit/9eacdc75b56b9674 locale.c: Combine some preprocessor directives Karl Williamson 1 file changed, 45 insertions(+), 23 deletions(- https://github.com/Perl/perl5/commit/ae0167e995e567fd localeconv: Need to toggle current locale to desired one Karl Williamson 1 file changed, 17 insertions(+), 7 deletions(-) https://github.com/Perl/perl5/commit/fad376cdd057322f f rmv numeric lock from localeconv Karl Williamson 1 file changed, 1 deletion(-) https://github.com/Perl/perl5/commit/ecc5134e560a6dbc locale.c: Avoid unnecessary work around localeconv() Karl Williamson 1 file changed, 6 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/93fd61df03f1f63b locale.c: Skip locale utf8ness calculation if feasible Karl Williamson 1 file changed, 2 insertions(+), 7 deletions(-) https://github.com/Perl/perl5/commit/d1c3a5efa2417b8f locale.c: Use out-of-bounds value for illegality Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/a239776a7d9a07dd locale.c Special case localeconv for C locale Karl Williamson 1 file changed, 77 insertions(+), 77 deletions(- https://github.com/Perl/perl5/commit/6c501b430807e2b1 locale.c: Move some code Karl Williamson 1 file changed, 13 insertions(+), 14 deletions(- https://github.com/Perl/perl5/commit/0f88d4fb72dda88d Special case localeconv when NUMERIC, MONETARY must be C Karl Williamson 4 files changed, 182 insertions(+), 61 deletions https://github.com/Perl/perl5/commit/e1293b220c6539ad locale.c: Use parallel array to simplify Karl Williamson 3 files changed, 35 insertions(+), 30 deletions( https://github.com/Perl/perl5/commit/941005d44b607f06 locale.c: Special case some C locale values Karl Williamson 1 file changed, 30 insertions(+), 11 deletions(- https://github.com/Perl/perl5/commit/949a41974fe89c83 locale.c: Add some #defines Karl Williamson 1 file changed, 7 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/3a3cdf419ed71594 locale.c: Remove unused #define Karl Williamson 1 file changed, 2 deletions(-) https://github.com/Perl/perl5/commit/a3791ecd1df09a0d locale.c: Reorder some statements in a switch() Karl Williamson 1 file changed, 8 insertions(+), 9 deletions(-) https://github.com/Perl/perl5/commit/8189848434ad6dfa locale.c: Move code to earlier in function Karl Williamson 1 file changed, 42 insertions(+), 37 deletions(- https://github.com/Perl/perl5/commit/598c35d42a18f66f locale.c: Don't need an explicit U32 Karl Williamson 3 files changed, 4 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/cf1380aa7db90613 locale.c: Simplify some localeconv() code Karl Williamson 1 file changed, 9 insertions(+), 31 deletions(-) https://github.com/Perl/perl5/commit/2a8d43d9fbdf5fdb locale.c: Change parameter specification Karl Williamson 1 file changed, 14 insertions(+), 14 deletions(- https://github.com/Perl/perl5/commit/0d980ad66d15dbe1 locale.c: Change two #define names Karl Williamson 1 file changed, 11 insertions(+), 11 deletions(- https://github.com/Perl/perl5/commit/459d1f4c4f116735 locale.c: Simplify loop Karl Williamson 1 file changed, 9 insertions(+), 18 deletions(-) https://github.com/Perl/perl5/commit/9ddfea21c0f8c408 locale.c: Add braces, indent code Karl Williamson 1 file changed, 30 insertions(+), 27 deletions(- https://github.com/Perl/perl5/commit/821a30cbbf0adf82 locale.c: Silence some compiler warnings Karl Williamson 1 file changed, 10 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/e12e638c5716abca locale.c: Use shorter macro form Karl Williamson 1 file changed, 8 insertions(+), 8 deletions(-) https://github.com/Perl/perl5/commit/891aa3272c27f89c Revert "define numeric values to be C when no USE_NUMERIC" Karl Williamson 3 files changed, 2 insertions(+), 7 deletions(-) https://github.com/Perl/perl5/commit/f41f4a537c4f83ff define numeric values to be C when no USE_NUMERIC Karl Williamson 3 files changed, 7 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/ac3fc3c9d4b2e709 Revert "locale_threads: start of using platform locales" Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/b5421a991f92c646 locale_threads: start of using platform locales Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/e72441bfc29edc43 Revert "pp.c" Karl Williamson 1 file changed, 52 deletions(-) https://github.com/Perl/perl5/commit/d9bef675e7ad5443 Revert "pp" Karl Williamson 1 file changed, 39 deletions(-) https://github.com/Perl/perl5/commit/a0dffc7084619776 pp Karl Williamson 1 file changed, 39 insertions(+) https://github.com/Perl/perl5/commit/5c48011df77f313b XXX more work mingw Karl Williamson 1 file changed, 3 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/a514a755a17daee4 locale.c: Win32: We don't know the locale here Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/b1e1ac1360dacb30 f perlembed Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/75b397275d8a0bd5 XXX t/run/locale.t Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/1e82e65120ca9f08 XXX config Karl Williamson 3 files changed, 3 insertions(+) https://github.com/Perl/perl5/commit/b45b72957b77e0ec perllocale Xxx start of changes Karl Williamson 1 file changed, 9 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/3e4d88819feeae5e perlmod Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/254e453c8a9a7ba6 perlxs Karl Williamson 2 files changed, 488 insertions(+), 20 deletions https://github.com/Perl/perl5/commit/dbe9eeb6f3ce747a reentr.pl: XXX about needing mutex Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/78205119e30020c3 iperlsys.h: TODO need to look at adding mutexes Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/d1b716b80f76f13e XXX incomplete perlhacktips: Karl Williamson 1 file changed, 34 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/0f080abe22fb1776 locale.c: Change some -DLv statements to -DL Karl Williamson 1 file changed, 6 insertions(+), 6 deletions(-) https://github.com/Perl/perl5/commit/b77d5ed8f765c785 Debug wrap wset Karl Williamson 1 file changed, 2 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/985e604c146859b1 XXX util add thread to mem_log Karl Williamson 1 file changed, 15 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/767e2c8307bf431f XXX Win32 mem log Karl Williamson 2 files changed, 11 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/85e01981bc55763f locale.c: Slightly change wording of DEBUG messages Karl Williamson 1 file changed, 16 insertions(+), 15 deletions(- https://github.com/Perl/perl5/commit/4fb7969006be9120 Time-Piece: notes to myself Karl Williamson 1 file changed, 4 insertions(+) https://github.com/Perl/perl5/commit/2a5ecdb906373fd3 XXX Time::Piece strftime Karl Williamson 1 file changed, 39 insertions(+), 22 deletions(- https://github.com/Perl/perl5/commit/011e1f6be8ff092b Time::Piece: Add critical sections Karl Williamson 4 files changed, 74 insertions(+), 12 deletions( https://github.com/Perl/perl5/commit/a578d340219fa945 thread.h: White space only Karl Williamson 1 file changed, 19 insertions(+), 19 deletions(- https://github.com/Perl/perl5/commit/1cc7df0f9bcb7211 Time-Piece: Use isSPACE_LC, not isspace; etc Karl Williamson 1 file changed, 39 insertions(+), 39 deletions(- https://github.com/Perl/perl5/commit/146a24c97b7372e8 Time-Piece: Use foldEQ_locale() if available Karl Williamson 1 file changed, 18 insertions(+), 12 deletions(- https://github.com/Perl/perl5/commit/8875859d28fcaf03 Time::Piece: Use reentrant API Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/6bb29ba58779a4e1 add is_cur_locale_utf8 Karl Williamson 4 files changed, 88 insertions(+) https://github.com/Perl/perl5/commit/4e1f9160ac0a9375 customized.dat for before Time Piece Karl Williamson 1 file changed, 5 deletions(-) https://github.com/Perl/perl5/commit/4d7f8c3c8112e79d locale_threads: debugging Karl Williamson 1 file changed, 124 insertions(+) https://github.com/Perl/perl5/commit/c5c86bdd259dbf12 locale_threads: add a commented out yield Karl Williamson 1 file changed, 3 insertions(+) https://github.com/Perl/perl5/commit/6b6ae7c6ff582914 t/run/locale.t: debug Karl Williamson 1 file changed, 5 insertions(+) https://github.com/Perl/perl5/commit/b7366c0dae488389 Enable thread-safe locales on some freebsd versions Karl Williamson 1 file changed, 9 insertions(+), 7 deletions(-) https://github.com/Perl/perl5/commit/d8a569d40d5a1164 darwin Karl Williamson 1 file changed, 2 deletions(-) https://github.com/Perl/perl5/commit/ebeb7ee9804f6539 pp.c Karl Williamson 1 file changed, 52 insertions(+) https://github.com/Perl/perl5/commit/828b5f091abd6981 darwin hints querylocale race in earlier darwins? Karl Williamson 1 file changed, 4 insertions(+) https://github.com/Perl/perl5/commit/e3f5d5e39c187ecd XXX experimental: Define setlocale_i() on unsafe threaded builds Karl Williamson 1 file changed, 8 insertions(+) https://github.com/Perl/perl5/commit/3c7add7d8152008b locale.c: Add a debugging statement Karl Williamson 1 file changed, 3 insertions(+) https://github.com/Perl/perl5/commit/24bb74c7e6cbfacc savepv if threaded, unused I think Karl Williamson 1 file changed, 9 insertions(+) https://github.com/Perl/perl5/commit/ecad75915ab72c2d S_bool_setlocale_i: Add entry assertion Karl Williamson 1 file changed, 5 insertions(+) https://github.com/Perl/perl5/commit/29509fa064c9bede S_querylocale_2008_i: Add entry assertion Karl Williamson 1 file changed, 4 insertions(+) https://github.com/Perl/perl5/commit/6a3b34a634acdbb1 loc_tools: XXX Debug Karl Williamson 1 file changed, 59 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/6e0e8635012da897 S_find_locale_from_environment: Handle disparate LC_ALL Karl Williamson 1 file changed, 36 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/4e49d3717df8afd6 customized.dat Karl Williamson 1 file changed, 7 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/ee0863cf16f12d21 drop, bug have to recompute md5 Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/4ff35450da6fb608 07locale.t: Add some Windows locales to try Karl Williamson 2 files changed, 70 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/a5dcc4a91a4681aa XXX perl.h: Debugging mutex lock' Karl Williamson 1 file changed, 17 insertions(+) https://github.com/Perl/perl5/commit/0d7835f29e66a938 lib/locale.t Karl Williamson 1 file changed, 2 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/f590e260f9608e0b lib/locale.t FILE debug Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/750a63e709fa4382 XXX temp: lib/locale.t: debug Karl Williamson 1 file changed, 7 insertions(+) https://github.com/Perl/perl5/commit/b0b65eabe8bd96f4 threads.xs DEBUG_U Karl Williamson 1 file changed, 64 insertions(+) https://github.com/Perl/perl5/commit/60939fc1e327b617 debug thread Karl Williamson 2 files changed, 18 insertions(+) https://github.com/Perl/perl5/commit/b1ca88fdafe0225f XXX memlog Karl Williamson 3 files changed, 6 insertions(+), 6 deletions(-) https://github.com/Perl/perl5/commit/240cb131e89fd5bf S_clear_placeholders(): Fix compiler warning Karl Williamson 2 files changed, 2 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/a2bf7cc3f8928452 uvoffuni_to_utf8_flags_msgs(): Fix compiler warning Karl Williamson 3 files changed, 3 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/dee52f2f14d7d178 regnode_after(): Fix compiler warning Karl Williamson 2 files changed, 2 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/ce3767f0c6cb55cf newSVbool(): Fix compiler warning Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/168912d0929fa8b8 ruler Karl Williamson 1 file changed, 2 insertions(+) https://github.com/Perl/perl5/commit/7c57ace7b3535e10 perl.h: Fake up win32 compile a bit Karl Williamson 1 file changed, 4 insertions(+), 2 deletions(-) https://github.com/Perl/perl5/commit/a9cc48ba2cb9a265 XXX temporary: Allow undef LC_ALL Karl Williamson 2 files changed, 15 insertions(+), 2 deletions(- https://github.com/Perl/perl5/commit/734064e665d2dfd9 XXX skip syslog tests because fail without LC_TIME Karl Williamson 2 files changed, 2 insertions(+) https://github.com/Perl/perl5/commit/71aa33a52b5476eb XXX temp to test broken lconv on non-Windows Karl Williamson 1 file changed, 6 insertions(+) https://github.com/Perl/perl5/commit/e1f3fc84e2e13717 XXX skip cmp_version.t because of sym links Karl Williamson 1 file changed, 2 insertions(+) https://github.com/Perl/perl5/commit/046b590919746c4b XXX skip Archive-Tar because of symlinks Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/61e53ba5bf70d1da version 07locale.t should use LC_NUMERIC, not ALL Karl Williamson 2 files changed, 5 insertions(+), 5 deletions(-) https://github.com/Perl/perl5/commit/1bf41048fd628359 XXX skip cmp_version.t prob. due to 5.38 tag issue Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/6a1fcea3d91fd51b version::07locale.t: Use I18N::Langinfo, not POSIX::localeconv() Karl Williamson 2 files changed, 17 insertions(+), 4 deletions(- https://github.com/Perl/perl5/commit/4149884393176b38 XXX run/locale.t: maybe f move test Karl Williamson 1 file changed, 18 insertions(+), 15 deletions(- https://github.com/Perl/perl5/commit/5ef49866f20eab64 run/locale.t: more debug Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-) https://github.com/Perl/perl5/commit/4acd191e64d8b5ec Revert "XXX test.pl: dont unlink temps" Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/25b6e4f23c5d7524 XXX test.pl: dont unlink temps Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-) https://github.com/Perl/perl5/commit/0c09b3994e7e2f7f Split t/uni/variables.t into multiple tests Karl Williamson 27 files changed, 384 insertions(+), 17 deletion https://github.com/Perl/perl5/commit/545e20b5195e4596 XXX temp: dist/Tie-File/t/29a_upcopy.t: Up alarm Karl Williamson 21 files changed, 592 insertions(+), 5 deletions https://github.com/Perl/perl5/commit/bb0bb26d30e4a642 XXX skip cpan testing Karl Williamson 1 file changed, 6 insertions(+) https://github.com/Perl/perl5/commit/1a86398006736819 skip bincompat.t Karl Williamson 1 file changed, 1 insertion(+) https://github.com/Perl/perl5/commit/46e7ceb763e1f62d XXX skip croak.t under sanitizer Karl Williamson 1 file changed, 3 insertions(+) https://github.com/Perl/perl5/commit/f61838c07ab6566b XXX t/harness temp tweaks Karl Williamson 1 file changed, 8 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/f291806148c9a09e BlackBox dont use rare scripts Karl Williamson 1 file changed, 136 insertions(+) https://github.com/Perl/perl5/commit/9e41ef7af8c8296c mktables more verbose Karl Williamson 6 files changed, 25 insertions(+), 12 deletions( https://github.com/Perl/perl5/commit/bd55a40ab19b663c Current branch smoke-me/tonyc/21661-no-warn-ck 2 commits. 1 unique author. 1 unique committer. 97 files changed, 1084 insertions(+), 161 deletions(-) Snapshot: http://github.com/Perl/perl5/tarball/72efebc0b5e4d07f safer cleanup when failing to compile regexps Tony Cook 2 files changed, 37 insertions(+), 30 deletions( https://github.com/Perl/perl5/commit/72efebc0b5e4d07f add tests for #21661 Tony Cook 1 file changed, 17 insertions(+), 1 deletion(-) https://github.com/Perl/perl5/commit/a28a6c184ced58a3 New branch davem/rc5 6 commits. 1 unique author. 1 unique committer. Snapshot: http://github.com/Perl/perl5/tarball/408102c3f022dd75 remove unused tryAMAGICunTARGETlist macro David Mitchell 1 file changed, 47 deletions(-) https://github.com/Perl/perl5/commit/408102c3f022dd75 make RC-stack-aware: pp_readline(), pp_glob() etc David Mitchell 4 files changed, 366 insertions(+), 81 deletions https://github.com/Perl/perl5/commit/ccf9d66e8acd5f1e expand tryAMAGICunTARGETlist() macro David Mitchell 3 files changed, 80 insertions(+), 2 deletions(- https://github.com/Perl/perl5/commit/eb7b2708f8cd2c8e IO::getline() handle OPf_STACKED better David Mitchell 1 file changed, 10 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/ebb1b1fd72233a35 IO::getline(): use CALLRUNOPS David Mitchell 1 file changed, 5 insertions(+), 4 deletions(-) https://github.com/Perl/perl5/commit/3b66035813f06f9f make RC-stack-aware: unwrap pp_index() David Mitchell 1 file changed, 30 insertions(+), 16 deletions(- https://github.com/Perl/perl5/commit/877112385c9ef694 Deleted branch davem/rc4 Ignored 49 GitHub auto-generated merge commits https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267485.html Wed, 06 Dec 2023 03:11:40 +0000 Re: Summary: Proposed change to Corinna OOP system by Chris Prather On Tue, Dec 5, 2023 at 4:21â¯AM Ovid <curtis.poe@gmail.com> wrote: > > Chris Prather would have supported the idea if it could be known at > compile time if `$object->foo` was trying to call a method it can't call, > but given Perl's nature, that's probably impossible. I *think* he might > have supported it if all methods had to declare their visibility. > > I really just want `method foo() { }` with no visibility attribute to be a compile time error and not to default to `method foo :private () {}`. Take for example the following scenario. We have code that generates an index page in our site generator: ``` package Index; use Moose; has entries => ( isa => 'ArrayRef[Object]', traits => ['Array'], required => 1, handles => { entries => 'elements', size => 'count', }, ); sub render_fragment_HTML ($self, $renderer) { return join "\n" => ( '<div class="index">' , map { $_->render_fragment($renderer) } $self->entries, '</div>' ); } ``` If I were to hand this to a new-to-perl developer and say "update this to use the class feature" this is IMO the obvious translation: ``` class Index { field $entries :param; method entries { @$entires } method size { scalar @$entries } method render_fragment_HTML ($renderer) { return join "\n" => ( '<div class="index">' , map { $_->render_fragment($renderer) } @$entries, '</div>' ); } } ``` Under the proposal this would throw a runtime error because we changed the visibility of `render_fragment_HTML` from public to private. Preventing it from then ending up in production relies on one of the following: * someone notices the _abscence_ of `:public` in a code review â¦ not traditionally something humans are good at * someone notices an error message in what might be a noisy stream of logging information â¦ not traditionally something humans are good at * a test suite that is comprehensive enough for this to cause a test failure â¦ not traditionally something codebases are good at A compile time exception IMO gives us the best chance to catch it before production. -Chris https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267484.html Wed, 06 Dec 2023 01:04:11 +0000 Re: Summary: Proposed change to Corinna OOP system by Lukas Mai On 05.12.23 22:05, Ovid wrote: > On Tue, Dec 5, 2023 at 7:09 PM Paul "LeoNerd" Evans > <leonerd@leonerd.org.uk <mailto:leonerd@leonerd.org.uk>> wrote: > > Already existing Perl attributes have no worries about duplicate > application. > >   $ perl -E 'my $n; sub x :lvalue :lvalue { $n } x = 123; say $n' >   123 > > So suddenly disallowing it in places like this would be a departure > from that behaviour. > > `perldoc attributes` says this: > > "WARNING: attribute declarations for variables are still evolving. The > semantics and interfaces of such declarations could change in future > versions. They are present for purposes of experimentation with what the > semantics ought to be. Do not rely on the current implementation of this > feature." > > As far as I can tell, duplicate attribute behavior is not specified. Kind of besides the point, but the quoted section is specifically about variable attributes, not subs. https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267483.html Tue, 05 Dec 2023 21:08:33 +0000 Re: Summary: Proposed change to Corinna OOP system by Ovid On Tue, Dec 5, 2023 at 7:09â¯PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote: > Already existing Perl attributes have no worries about duplicate > application. > > $ perl -E 'my $n; sub x :lvalue :lvalue { $n } x = 123; say $n' > 123 > > So suddenly disallowing it in places like this would be a departure > from that behaviour. `perldoc attributes` says this: "WARNING: attribute declarations for variables are still evolving. The semantics and interfaces of such declarations could change in future versions. They are present for purposes of experimentation with what the semantics ought to be. Do not rely on the current implementation of this feature." As far as I can tell, duplicate attribute behavior is not specified. Further, this doesn't answer my original question. If we disallow duplicate attributes, many potential bugs go away. What does this mean? field $size :param(width) :param(height) ;param(depth); Or if we supply :weak twice, does it get weakened twice? Certainly a class can't take multiple :isa attributes, can it? I'm sure we can find plenty of other potential attributes which, if duplicated, might be surprising. Nor does it address my original concern: "Eliminating the potential for many bugs or surprising behaviors seems like a win if the price we pay is eliminating an uncommon edge case." So that brings up the next question: is this a common edge case? If it's not, why cater to it when the behavior is not specified and the docs clearly state that semantics might change? Corinna is a huge addition to the Perl language. It's important we take the time to get this right. I'm not saying that I'm right (I concede I lost the argument about :public), but these questions should at least be answered. Best, Ovid https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267482.html Tue, 05 Dec 2023 21:05:31 +0000 Re: Summary: Proposed change to Corinna OOP system by Paul "LeoNerd" Evans On Tue, 5 Dec 2023 18:01:06 +0100 Ovid <curtis.poe@gmail.com> wrote: > Or if we supply :weak twice, does it get weakened twice? Certainly a > class can't take multiple :isa attributes, can it? I'm sure we can > find plenty of other potential attributes which, if duplicated, might > be surprising. Already existing Perl attributes have no worries about duplicate application. $ perl -E 'my $n; sub x :lvalue :lvalue { $n } x = 123; say $n' 123 So suddenly disallowing it in places like this would be a departure from that behaviour. Most attributes just turn on some behavioural flag; specifying them multiple times is idempotent. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267481.html Tue, 05 Dec 2023 18:09:21 +0000 Re: Summary: Proposed change to Corinna OOP system by Ovid On Tue, Dec 5, 2023 at 3:53â¯PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote: > > I can't find the reference in the spec (I should add one), but the > > assumption was that no attribute could be reused on a single > > field/method. > > That's definitely not true. E.g. it's totally valid to provide multiple > `:reader`s: > > class Cube { > field $size > :reader(get_width) :reader(get_height) :reader(get_depth); > ... > } If we disallow duplicate attributes, many potential bugs go away. What does this mean? field $size :param(width) :param(height) ;param(depth); Or if we supply :weak twice, does it get weakened twice? Certainly a class can't take multiple :isa attributes, can it? I'm sure we can find plenty of other potential attributes which, if duplicated, might be surprising. The rare cases where we might want duplicate attributes can be handled better. class Cube { field $size :param; method get_width {$size} method get_height {$size} method get_depth {$size} } It's not too onerous to allow that (IMHO) because it's a rare case. Eliminating the potential for many bugs or surprising behaviors seems like a win if the price we pay is eliminating an uncommon edge case. Best, Ovid https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267480.html Tue, 05 Dec 2023 17:01:21 +0000 Re: Summary: Proposed change to Corinna OOP system by Veesh Goldman also valid as a reasonable options in the case we're discussing if you'd like your method to be accessible by subclasses AND a specific list of trusted classes. On Tue, Dec 5, 2023 at 4:53â¯PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote: > On Tue, 5 Dec 2023 15:44:13 +0100 > Ovid <curtis.poe@gmail.com> wrote: > > > I can't find the reference in the spec (I should add one), but the > > assumption was that no attribute could be reused on a single > > field/method. > > That's definitely not true. E.g. it's totally valid to provide multiple > `:reader`s: > > class Cube { > field $size > :reader(get_width) :reader(get_height) :reader(get_depth); > ... > } > > -- > Paul "LeoNerd" Evans > > leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS > http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ > https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267479.html Tue, 05 Dec 2023 15:03:16 +0000 Re: Summary: Proposed change to Corinna OOP system by Paul "LeoNerd" Evans On Tue, 5 Dec 2023 15:44:13 +0100 Ovid <curtis.poe@gmail.com> wrote: > I can't find the reference in the spec (I should add one), but the > assumption was that no attribute could be reused on a single > field/method. That's definitely not true. E.g. it's totally valid to provide multiple `:reader`s: class Cube { field $size :reader(get_width) :reader(get_height) :reader(get_depth); ... } -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267478.html Tue, 05 Dec 2023 14:53:11 +0000 Re: Summary: Proposed change to Corinna OOP system by Ovid On Tue, Dec 5, 2023 at 11:30â¯AM Lukas Mai <lukasmai.403+p5p@gmail.com> wrote: > I don't think you can spec your way out of invalid attribute > combinations this way. What if someone does 'method foo > :restricted(Some::Class) :restricted :restricted(isa) {}'? I can't find the reference in the spec (I should add one), but the assumption was that no attribute could be reused on a single field/method. > Also, does trusting Some::Class mean we transitively trust anything that > isa Some::Class? > Trust only happens on a "per-method" basis. If a method is listed as "trusted", any class that is trusted can read that method. That's all it means. It doesn't mean it can read other methods (unless public) or that the other methods can read non-public methods of the trusted class. Best, Ovid https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267477.html Tue, 05 Dec 2023 14:44:26 +0000 Re: Summary: Proposed change to Corinna OOP system by "Ruud H.G. van Tol" via perl5-porters On 2023-12-05 13:06, Darren Duncan wrote: > [...] But a leading underscore can serve as a shorthand for common > cases as follows... > > These 2 things have the same meaning: > >     method foo {...} >     method foo :public {...} > > And these 2 things have the same meaning: > >     method _foo {...} >     method _foo :private {...} > > So a method without a leading underscore has a DEFAULT interpretation > of :public, and a method named with a leading underscore has a DEFAULT > interpretation of :private. Warning: abstraction ahead. Such a thing can also be orthogonal, implemented as a general way to imply attributes by name-patterns of (types of) things. Then it doesn't need to be part of Corinna, but could be used by it. -- Ruud https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267476.html Tue, 05 Dec 2023 12:19:18 +0000 Re: Summary: Proposed change to Corinna OOP system by "Ruud H.G. van Tol" via perl5-porters On 2023-12-05 12:35, Martijn Lievaart via perl5-porters wrote: > Op 05-12-2023 om 10:40 schreef Ruud H.G. van Tol via perl5-porters: >> On 2023-12-05 10:21, Ovid wrote: >>> [...] >>> The current spec assumes a boolean for visibility: private or not >>> private. That's far too limiting, so having a single attribute would >>> be warranted here to allow for future expansion. [...] >> >> I would still like to be able to set the method-default to private >> lexically, so for my own code corner. >> I didn't think through how that would best be facilitated, so I'm >> just brain-farting here: >> use Corinna qw( :default(methods:private) ); > > In general, I like this method. But I'd say it needs some > bikeshedding, as I find the implementation ugly and non trivial to > remember. Hard pressed to come up with an alternative though. How about: > use Corinna qw(:methods_private); Indeed, that is as canonical as it can be. Probably better to not have a plural in there, somehow seems better to stick to the keyword. I presume this will become supported: use Corinna :private( method, ... ); -- Ruud https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267475.html Tue, 05 Dec 2023 12:10:11 +0000 Re: Summary: Proposed change to Corinna OOP system by Darren Duncan On 2023-12-05 1:21 a.m., Ovid wrote: > `method _foo` uses current conventions, but it's kind of a hack that > overloads the identifier meaning. Opinions were mixed. Further, if we want > to have things like trusted and protected methods, what would it mean if a > leading underscore meant "private" and then we declared a method to be > trusted or protected? (same issue with using `my` and protected and trusted) I still feel that changing visibility based on the name is a bad idea and I would rather we didn't have it. However... As a compromise, I propose the following... The primary way to indicate visibility is with traits like :private/:public/etc, and for any methods where these are present, they unambiguously take priority. But a leading underscore can serve as a shorthand for common cases as follows... These 2 things have the same meaning: method foo {...} method foo :public {...} And these 2 things have the same meaning: method _foo {...} method _foo :private {...} So a method without a leading underscore has a DEFAULT interpretation of :public, and a method named with a leading underscore has a DEFAULT interpretation of :private. If there are ANY explicit visibility traits, all defaults are ignored. For any other visibility levels, it is mandatory to use the trait to get them. > `method foo :private` is the current spec, but it creates another potential > issue. If we have more types of visibility (trusted or protected), we might > ultimately create a situation we worked hard to avoid with field variable > attributes: illegal combinations. > > method foo :private :trusted(Some::Class::*) :protected ($bar) { ... } > > The above doesn't make sense and we don't want to write code that needs to > validate all attribute combinations are valid. That will likely be buggy, > slower, and the code could be more confusing. One way to resolve this is to raise an error that either prevents compilation (ideally) or dies at runtime when an illegal combination is detected. An alternate way to resolve this is to logically "or" all of the explicit visibility traits; if any used trait allows a caller, the caller is allowed, even if other traits don't. That said, the only situation where I would consider a combination useful is to combine trusted with protected, in the scenario where the subclasses may be written by third parties. So while possibly hackish and risking a combinatorial explosion (but probably not), we could have 5 traits which cover everything: "private", "trusted", "protected", "trusted_or_protected", "public". Now on a related matter, I strongly believe that defining the list of classes we trust at the method level is a bad idea for the general case of verbosity. What if you want to trust say 30 classes because that's how big your library is, and each one might call 100 methods. I believe it is best for every visibility trait on the method itself to just be a boolean without arguments, and that the list of classes being trusted should be defined elsewhere. If we don't want to have the separately defined library thing, then each class should just define once for the entire class what other classes it trusts, and then that list is used for any methods marked :trusted. For example: class Foo { trusts Bar, Baz; method quux :trusted {...} } -- Darren Duncan https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267474.html Tue, 05 Dec 2023 12:06:53 +0000 Re: Summary: Proposed change to Corinna OOP system by Darren Duncan On 2023-12-05 2:30 a.m., Lukas Mai wrote: > Also, does trusting Some::Class mean we transitively trust anything that isa > Some::Class? It depends what you mean by that. The whole point of trusting is to define an exclusive list, which in this case means one can only be called by methods defined in Some::Class itself, and not by methods defined in sub-classes of Some::Class. So trusting should work when Some::Class is subclassed, but it shouldn't be a way for authors who didn't write Some::Class to invite themselves to the exclusive access of our class. -- Darren Duncan https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267473.html Tue, 05 Dec 2023 11:45:41 +0000 Re: Summary: Proposed change to Corinna OOP system by Martijn Lievaart via perl5-porters Op 05-12-2023 om 10:40 schreef Ruud H.G. van Tol via perl5-porters: > > On 2023-12-05 10:21, Ovid wrote: >> [...] >> The current spec assumes a boolean for visibility: private or not >> private. That's far too limiting, so having a single attribute would >> be warranted here to allow for future expansion. [...] > > I would still like to be able to set the method-default to private > lexically, so for my own code corner. > > I didn't think through how that would best be facilitated, so I'm just > brain-farting here: > use Corinna qw( :default(methods:private) ); > In general, I like this method. But I'd say it needs some bikeshedding, as I find the implementation ugly and non trivial to remember. Hard pressed to come up with an alternative though. How about: use Corinna qw(:methods_private); HTH, M4 https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267472.html Tue, 05 Dec 2023 11:35:30 +0000 Re: Summary: Proposed change to Corinna OOP system by Lukas Mai On 05.12.23 10:21, Ovid wrote: > `method foo :private` is the current spec, but it creates another > potential issue. If we have more types of visibility (trusted or > protected), we might ultimately create a situation we worked hard to > avoid with field variable attributes: illegal combinations. > >     method foo :private :trusted(Some::Class::*) :protected ($bar) { ... } > > The above doesn't make sense and we don't want to write code that needs > to validate all attribute combinations are valid. That will likely be > buggy, slower, and the code could be more confusing. > > The current spec assumes a boolean for visibility: private or not > private. That's far too limiting, so having a single attribute would be > warranted here to allow for future expansion. Just spit-balling: > >     method foo { ... }                                      # public >     method foo :restricted { ... }                          # private >     method foo :restricted(isa) { ... }                     # protected > (only this class and subclasses) >     method foo :restricted(Some::Library) { ... }           # only > visible to that library, something we don't currently have >     method foo :restricted([Class::One,Class::Two]) { ... } # > enumerated list of classes I don't think you can spec your way out of invalid attribute combinations this way. What if someone does 'method foo :restricted(Some::Class) :restricted :restricted(isa) {}'? > > I think `:restricted` is somewhat clear, but I'm not quite sold on it. > (`:visibility` is better, but too verbose and private would probably > need `:visibility(undef)` and that would be bad). Also, note that if we > have a library named `isa`, that would conflict with `:restricted(isa)`. Bikeshedding: :scope? :trusted? Also, does trusting Some::Class mean we transitively trust anything that isa Some::Class? https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267471.html Tue, 05 Dec 2023 10:30:24 +0000 Re: Summary: Proposed change to Corinna OOP system by Paul "LeoNerd" Evans On Tue, 5 Dec 2023 11:22:56 +0100 Lukas Mai <lukasmai.403+p5p@gmail.com> wrote: > On 05.12.23 10:40, Ruud H.G. van Tol via perl5-porters wrote: > > > > I would still like to be able to set the method-default to private > > lexically, so for my own code corner. > > > > I didn't think through how that would best be facilitated, so I'm > > just brain-farting here: > > use Corinna qw( :default(methods:private) ); > > > > > > Or maybe a "private method" needs a new keyword, like my_method. > > Doesn't the current Object::Pad implementation use 'method $foo() { > ... }' and $obj->$foo() for private (lexical) methods? It does, but only because it couldn't alter the way that `my` or method invocation works. Ideally I'd like to see this in core as my method f () { ... } $self->&f(); -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267470.html Tue, 05 Dec 2023 10:29:15 +0000 Re: Summary: Proposed change to Corinna OOP system by Lukas Mai On 05.12.23 10:40, Ruud H.G. van Tol via perl5-porters wrote: > > I would still like to be able to set the method-default to private > lexically, so for my own code corner. > > I didn't think through how that would best be facilitated, so I'm just > brain-farting here: > use Corinna qw( :default(methods:private) ); > > > Or maybe a "private method" needs a new keyword, like my_method. Doesn't the current Object::Pad implementation use 'method $foo() { ... }' and $obj->$foo() for private (lexical) methods? https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267469.html Tue, 05 Dec 2023 10:23:06 +0000 Re: Summary: Proposed change to Corinna OOP system by Nicolas Mendoza via perl5-porters Den 05.12.2023 10:21, skrev Ovid: > … > `my method foo` would possibly entail calling it via > `$self->&foo`. This isn't bad, but we need the metadata to be > available in the MOP. The `my` keyword, in this context, is now doing > more than just declaring something to be lexical. Is this subtle > overloading an issue? > > `method _foo` uses current conventions, but it's kind of a hack that > overloads the identifier meaning. Opinions were mixed. Further, if we > want to have things like trusted and protected methods, what would it > mean if a leading underscore meant "private" and then we declared a > method to be trusted or protected? (same issue with using `my` and > protected and trusted) > Promising to not beat this horse further, but just some cents: Letting attributes always override _foo prefix is what I would expect at least. It is as hacky as double sigils in other languages. I think letting the average (most) users just use `method foo` and `method _bar` and things just work as expected would be positive in every day coding. Personally I would like to avoid as much explicit attribute usage as possible. -- Nicolas Mendoza https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267468.html Tue, 05 Dec 2023 09:52:29 +0000 Re: Summary: Proposed change to Corinna OOP system by "Ruud H.G. van Tol" via perl5-porters On 2023-12-05 10:21, Ovid wrote: > [...] > The current spec assumes a boolean for visibility: private or not > private. That's far too limiting, so having a single attribute would > be warranted here to allow for future expansion. [...] I would still like to be able to set the method-default to private lexically, so for my own code corner. I didn't think through how that would best be facilitated, so I'm just brain-farting here: use Corinna qw( :default(methods:private) ); Or maybe a "private method" needs a new keyword, like my_method. -- Ruud https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267467.html Tue, 05 Dec 2023 09:40:21 +0000 Summary: Proposed change to Corinna OOP system by Ovid Hi all, Out of the discussions on that thread <https://www.nntp.perl.org/group/perl.perl5.porters/2023/11/msg267373.html>, I got the following out of it. TL;DR: I lost, but we still have something to fix. Summary: I proposed that we make methods private by default to ensure that developers would have to think about their contracts and explicitly add `:public` to a method to make it a public method. This would make it more consistent with how field variables are handled and makes it easier to avoid exposing behavior we did not intend. The Consensus: Interesting idea, but probably not workable in that form. For the following, I will use these definitions: 1. public: a method that anything can call on an instance 2. private: a method that only the class of the instance can call (no "isa" check) 3. protected: a method that only a class of subclass of an instance can call 4. trusted: a method that can be called by classes identified as trusted Chris Prather would have supported the idea if it could be known at compile time if `$object->foo` was trying to call a method it can't call, but given Perl's nature, that's probably impossible. I *think* he might have supported it if all methods had to declare their visibility. Various approaches to declaring private methods were proposed: - my method foo - method _foo - method foo :private (current spec) All three of those have issues. `my method foo` would possibly entail calling it via `$self->&foo`. This isn't bad, but we need the metadata to be available in the MOP. The `my` keyword, in this context, is now doing more than just declaring something to be lexical. Is this subtle overloading an issue? `method _foo` uses current conventions, but it's kind of a hack that overloads the identifier meaning. Opinions were mixed. Further, if we want to have things like trusted and protected methods, what would it mean if a leading underscore meant "private" and then we declared a method to be trusted or protected? (same issue with using `my` and protected and trusted) `method foo :private` is the current spec, but it creates another potential issue. If we have more types of visibility (trusted or protected), we might ultimately create a situation we worked hard to avoid with field variable attributes: illegal combinations. method foo :private :trusted(Some::Class::*) :protected ($bar) { ... } The above doesn't make sense and we don't want to write code that needs to validate all attribute combinations are valid. That will likely be buggy, slower, and the code could be more confusing. The current spec assumes a boolean for visibility: private or not private. That's far too limiting, so having a single attribute would be warranted here to allow for future expansion. Just spit-balling: method foo { ... } # public method foo :restricted { ... } # private method foo :restricted(isa) { ... } # protected (only this class and subclasses) method foo :restricted(Some::Library) { ... } # only visible to that library, something we don't currently have method foo :restricted([Class::One,Class::Two]) { ... } # enumerated list of classes I think `:restricted` is somewhat clear, but I'm not quite sold on it. (`:visibility` is better, but too verbose and private would probably need `:visibility(undef)` and that would be bad). Also, note that if we have a library named `isa`, that would conflict with `:restricted(isa)`. Suggestions are welcome here. We could punt on defining libraries if we have an explicit list of enumerated classes which can read a method. Also, while I've thought of ideas that would make it harder for someone to fork a module to get at methods they should not, I think this is an arms race with little practical value. Let people hang themselves, but don't give 'em the rope. Best, Ovid https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267466.html Tue, 05 Dec 2023 09:21:17 +0000 Re: PSC #123 2023-11-09 by Elvin Aslanov Optional Chaining is interesting âï¸ Is it possible to track the implementations? In a public banch, fork, docs etc On Mon, Dec 4, 2023, 5:56 PM Philippe Bruhat (BooK) <book@cpan.org> wrote: > As noted by Dave Cross in a recent email, this report slipped through > the cracks. This was during the quiet period where we were quietly busy > with the security issues. > > Here's what we planned on reporting: > > We skipped the meeting last week (2023-11-02). This week was a quiet > week too, so we donât have much to report. > > We talked a bit about the PPCs currently being implemented. PPCs 14 > (English names) and 21 (optional chaining) have people implementing them > - we hope to have some progress to publish soon. > > -- > Philippe Bruhat (BooK) > > The world is a gamble and the only "sure thing" is that cheaters > eventually > lose. (Moral from Groo The Wanderer #23 > (Epic)) > https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267465.html Mon, 04 Dec 2023 17:29:40 +0000 Re: PSC #126 2023-11-30 by Elvin Aslanov > We took note of what projects we have in flight (e.g. PPCs > being implemented) and may find a way to keep that list > published and updated I think employing Notion could be more suited to this task rather than Spreadsheets On Mon, Dec 4, 2023, 4:21 PM Philippe Bruhat (BooK) <book@cpan.org> wrote: > We met Thursday (sorry for the delay). > > Three Perl releases have been published this past week, containing > patches for security issues CVE-2023-47038 and CVE-2023-47039. This > kept us busy for the past few weeks (explaining the somewhat thinner > recent updates). > > * Paul will publish a post-mortem on the recent releases, looking at > what went wrong and some thoughts on how to improve it so those don't > happen again > * We discussed a plan to improve documentation of the security > disclosure process > * We took note of what projects we have in flight (e.g. PPCs > being implemented) and may find a way to keep that list > published and updated > > -- > Philippe Bruhat (BooK) > > Everyone's life seems easier from the outside. > (Moral from Groo The Wanderer #45 > (Epic)) > https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267464.html Mon, 04 Dec 2023 17:26:48 +0000 PSC #123 2023-11-09 by book As noted by Dave Cross in a recent email, this report slipped through the cracks. This was during the quiet period where we were quietly busy with the security issues. Here's what we planned on reporting: We skipped the meeting last week (2023-11-02). This week was a quiet week too, so we don’t have much to report. We talked a bit about the PPCs currently being implemented. PPCs 14 (English names) and 21 (optional chaining) have people implementing them - we hope to have some progress to publish soon. -- Philippe Bruhat (BooK) The world is a gamble and the only "sure thing" is that cheaters eventually lose. (Moral from Groo The Wanderer #23 (Epic)) https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267463.html Mon, 04 Dec 2023 15:40:53 +0000 PSC #126 2023-11-30 by book We met Thursday (sorry for the delay). Three Perl releases have been published this past week, containing patches for security issues CVE-2023-47038 and CVE-2023-47039. This kept us busy for the past few weeks (explaining the somewhat thinner recent updates). * Paul will publish a post-mortem on the recent releases, looking at what went wrong and some thoughts on how to improve it so those don't happen again * We discussed a plan to improve documentation of the security disclosure process * We took note of what projects we have in flight (e.g. PPCs being implemented) and may find a way to keep that list published and updated -- Philippe Bruhat (BooK) Everyone's life seems easier from the outside. (Moral from Groo The Wanderer #45 (Epic)) https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267462.html Mon, 04 Dec 2023 15:13:10 +0000 Re: TONYC Grant Report October 2023 by wolfsage On Wed, Nov 29, 2023 at 4:54â¯AM Tony Cook <tony@develop-help.com> wrote: > > Approximately 45 tickets were reviewed or worked on, and 8 patches > were applied. > Thanks Tony, +1 from me. -- Matthew Horsfall (alh) https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267461.html Mon, 04 Dec 2023 13:38:40 +0000 Re: Proposed change to Corinna OOP system by Darren Duncan I formally request that any alterations to Corinna in this current discussion about public/private on methods also takes into account the assumption of additional visibility levels for methods, particularly "internal" or whatever we want to name it, and the solution we come up with needs to work when there are 3 or more options to choose from, not just a total of 2. It should be able to assume that an effective mechanism exists for knowing at regular application compile and run time what "library" (or other term) a Perl package / Corinna class belongs to, and that any package/class belongs to exactly 1 library, and the meaning of putting the "internal" scope on a method is to make it public-like but only for subs/methods in those packages. The current discussion doesn't need to concern with how a library is defined, just that it exists. Note that if not otherwise declared we can consider each Perl package to belong to its own library consisting of only that 1 package, which should be reasonable semantics. While private/internal/public are all mutually exclusive, we should also design for the assumption of adding a "protected" or analogy additional visibility scope, which is NOT mutually exclusive with the above, and can be paired with either private or internal, and its effect in the latter case is, visible to a class in the same library OR that is a subclass. -- Darren Duncan https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267460.html Sat, 02 Dec 2023 20:20:11 +0000 Re: Pre-RFC: Propose explicit library entity for Corinna/Perl by Branislav Zahradník On Sat, 2 Dec 2023 at 07:49, Darren Duncan <darren@darrenduncan.net> wrote: > On 2023-12-01 10:13 p.m., Branislav ZahradnÃk wrote: > > If for information: isn't this information already available via > distribution's > > MANIFEST? > > Does the MANIFEST get installed somewhere persistent that Perl can see at > runtime during the normal post-install course of running an application? > > The whole point of my proposal is to have a sense of a collection of Perl > modules that are considered a unit and this information is available > post-install to a regular application. > so install it :-) > > > if for subpackages / private packages, Ovid contemplated about it some > time ago, > > would be worth to look at it as well > > The "internal" thing I mention isn't the same as the concept of > sub-packages or > private packages, as the latter exist entirely within a host package and > are > only used within that one host, while my proposal involves a group of peer > packages such that in the general case more than one might contribute to > the > public API of the library and any of them may be used by multiple other > packages > in the same library but at least part of their API isn't public. > > In the general case, my proposal is to allow any single package to have a > mixture of routines such that some are intended to be public to all, > others > usable only by other packages in the same library, and others only usable > by the > same class. > how inheritance should work? how tests should work? how tests written by 3rd party will work (eg integration tests testing new version of X before starting full matrix tests) > > -- Darren Duncan > > > https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267459.html Sat, 02 Dec 2023 20:18:18 +0000 Though about qt by Branislav Zahradník Read lot of qt being about to be implemented lately, and one though occured: qt and current interpolation shouldn't mix in one context (readability and so) so imho qt shouldn't be extra syntax but only feature altering behaviour of current interpolated contexts. Brano https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267458.html Sat, 02 Dec 2023 06:51:09 +0000 Re: Pre-RFC: Propose explicit library entity for Corinna/Perl by Darren Duncan On 2023-12-01 10:13 p.m., Branislav Zahradník wrote: > If for information: isn't this information already available via distribution's > MANIFEST? Does the MANIFEST get installed somewhere persistent that Perl can see at runtime during the normal post-install course of running an application? The whole point of my proposal is to have a sense of a collection of Perl modules that are considered a unit and this information is available post-install to a regular application. > if for subpackages / private packages, Ovid contemplated about it some time ago, > would be worth to look at it as well The "internal" thing I mention isn't the same as the concept of sub-packages or private packages, as the latter exist entirely within a host package and are only used within that one host, while my proposal involves a group of peer packages such that in the general case more than one might contribute to the public API of the library and any of them may be used by multiple other packages in the same library but at least part of their API isn't public. In the general case, my proposal is to allow any single package to have a mixture of routines such that some are intended to be public to all, others usable only by other packages in the same library, and others only usable by the same class. -- Darren Duncan https://www.nntp.perl.org/group/perl.perl5.porters/2023/12/msg267457.html Sat, 02 Dec 2023 06:49:05 +0000