Golang 1.5.3 security advisory

Go 1.5.3 has been released, and includes a security fix. Programs have to be recompiled against 1.5.3  https://groups.google.com/forum/#!topic/golang-announce/MEATuOi_ei4
Hashicorp is rolling out new updated versions of their packages. We'll need to repackage our rpms and containers.
Please add affected packages to this ticket, we can break out each one separately in other issues:

[x] consul
[x] consul-template (PR #1012)
[ ] terraform
[ ] vault
[ ] haproxy-consul
[ ] traefik  https://github.com/emilevauge/traefik/issues/163
[ ] mesos-consul (is this built on 1.5x?)
[ ] etcd (RH/Centos package)

Traefik has been updated: https://github.com/emilevauge/traefik/releases/tag/v1.0.alpha.364
Consul has been updated: https://releases.hashicorp.com/consul/0.6.2/
Vault has been updated: https://releases.hashicorp.com/vault/0.4.1/

etcd needs to be updated to v2.2.4

@loshkovskyi for etcd, we'll have to wait for a RH/Centos fix http://mirror.centos.org/centos/7.2.1511/extras/x86_64/Packages/

consul updated to 0.6.3

mesos-consul is build with 1.4

The vault-ssl branch includes vault 0.4.1 which will take care of vault when it is merged.

etcd is built with 1.4.2 and not affected:
# rpm -q etcd
etcd-2.1.1-2.el7.x86_64
# strings /usr/bin/etcd | grep go1
go1.4.2

As of 0.6.10, terraform is still built with 1.5.1 on OS X:
./terraform --version
Terraform v0.6.10

$ strings ./terraform | grep go1
go1.5.1

Given that terraform is run via the cli (and the difficulty of exploring this but on 64 but systems), we're not going to let this block 0.6.

Haproxy container has been updated:
docker run ciscocloud/haproxy-consul:latest strings /usr/local/bin/consul-template | grep go1
go1.5.3

Awesome work everyone! We the merge of vault #1045 we can close this issue.


Ability to create/update a variable with a single command

This is more a FR kind of how vset worked before. It's useful to have a single command that can take care of creating/updating a variable if it already exists.
I wonder if a -c[reate] can be added to variable:update or a -u[pdate] to variable:create, or both, or create a new command?

Would like to bump this one to see if it's possible to add?

That definitely sounds like a good thing


[Actions] Bump hramos/needs-attention to v2.0.0

Summary:
This diff bumps hramos/needs-attention to v2.0.0
v2.0.0 is a latest BREAKING release with a number of improvements made by @Pranav-yadav i.e. me 😎
P.S. Just to have node16 across RN workflows I did that work 🤣 and released the v2 :)
Major Improvements:

Bump Node.js to v16
Bump actions/checkout to v3
Add TypeScript
Generate and publish fully compiled dist (with deps) instead of node_modules

Ref.:

Full Changelog for v2.0.0: https://github.com/hramos/needs-attention/releases/tag/v2.0.0
Marketplace v2.0.0: https://github.com/marketplace/actions/needs-attention?version=v2.0.0

Changelog:
[GENERAL] [SECURITY] - Bump hramos/needs-attention to v2.0.0
Test Plan

Workflow should add and remove respective labels as usual.

/rebase

ping @cortinico, is there anything that needs to be done from my side?
Rebased :)

ping @cortinico, is there anything that needs to be done from my side?

yup, we'd like to move needs-attention to react-native-community before merging this

ping @cortinico, is there anything that needs to be done from my side?

yup, we'd like to move needs-attention to react-native-community before merging this

Yeah, that would be great.
But, I'm not the owner, Héctor Ramos owns the repo.
You may ping him.

I've messaged him and will get back to you once we can unblock this

@Pranav-yadav are you still interested in merging this? If so, we'll need to rebase + apply the suggestion I added

/rebase

/rebase


Added gentest utility for generating of test files

tesgen accepts as input parameter

absolute path to the directory
package id
nothing (process current working directory)

In the destination directory are required two files with static
names for creation of testing file:

test.yml: contains recipe ingredients for creation of tests
test.tmpl: is template providing info how to work with data
from the YAML file

With https://github.com/gofed/symbols-extractor/pull/17 merged more tests should pass.

There is planned change of format of tests in YAML yet. I will do that hopefully tomorrow. For now, binary expressions should be covered by tests now and another issues of the tests are fixed too - like load of functions into the symtab.

Thanks for that. Looking forward to the functions tests.

https://github.com/gofed/symbols-extractor/pull/30 merged, feel free to rebase


Add ousleyp to owners list

In this PR I would like to welcome @ousleyp as a reviewer and an approver for the OpenShift Virtualization operator alerts runbook.
@ousleyp is a technical writer that will help us with the effort to improve the quality of the alert runbooks.

@machadovilaca @orenc1 please review

Looks good to me
Given the recent open source xz package, can you update the description introducing Pan and link the GitHub profile @ousleyp

/lgtm


Revert "Revert "[REVERT] Don't enforce OSABI""

Reverts hermitcore/rusty-loader#111.
There are issues with using the latest toolchain with RustyHermit's rusty-demo, so that has to be resolved first.

bors r+


Unable to bulk insert multiple class types via common base class

Here is what to include in your request to make sure we implement a solution as quickly as possible.
1. Description
Im trying to bulk insert a load of different types of metrics data that all extends the same base class.
I am able to insert all these data via AddRangeAsync from entity framework core without an issue, it is able to figure out which table each data belongs to.
Doing so with BulkInsertAsync from this package results in getting an "Unable to cast object of type 'x' to type 'x'."
i would stick with AddRangeAsync but the reason im trying to use this package is to access the options your function provides.
2. Exception
If you are seeing an exception, include the full exception details (message and stack trace).
Exception message: Unable to cast object of type 'TimeSeriesShared.Timescale.MemoryMetrics' to type 'TimeSeriesShared.Timescale.CpuMetrics'.
Stack trace:
   at Microsoft.EntityFrameworkCore.Metadata.Internal.ClrPropertyGetter`2.GetClrValue(Object entity)
   at .`1.( , String )
   at .( , DbConnection , DbTransaction )
   at .Execute(List`1 actions)
   at Z.BulkOperations.BulkOperation.Execute()
   at .BulkInsert[T](DbContext this, IEntityType entityType, IEnumerable`1 list, Action`1 options, SavingSelector savingSelector, Boolean forceSpecificTypeMapping)
   at .BulkInsert[T](DbContext this, IEnumerable`1 entities, Action`1 options, Boolean isBulkSaveChanges)
   at DbContextExtensions.BulkInsert[T](DbContext this, IEnumerable`1 entities, Action`1 options)
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task.<>c.<.cctor>b__272_0(Object obj)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
   at DbContextExtensions.`1.MoveNext()
   at TimeSeriesShared.TimeScaleWriterClient.<InsertMetrics>d__7.MoveNext() in F:\Repo\Pluto\Source\MicroServices\TimeSeriesShared\TimeScaleWriterClient.cs:line 31

3. Fiddle or Project
    public async Task InsertMetrics(IEnumerable<TimescaleBase> metrics)
    {
          var context = DbContext.CreateDbContext();

          // await context.AddRangeAsync(metrics); <- works
          await context.BulkInsertAsync(metrics); // <- exception thrown!

          await context.SaveChangesAsync();
    }

    public class CpuMetrics: TimescaleBase
    {
        public int CpuPercentage { get; set; }

        public int? CpuTemperature { get; set; }
    }
    public abstract class TimescaleBase
    {
        [Required]
        [HypertableColumn]
        [Column(TypeName = "timestamp with time zone")]
        public DateTime TimeStamp { get; set; }

        [Required]
        [HypertableColumn]
        [Column(TypeName = "TEXT")]
        public string TargetId { get; set; }

        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public Guid Id { get; set; } = new Guid();
    }

    public class MemoryMetrics : TimescaleBase
    {
        public uint TotalMemoryKB { get; set; }

        public uint TotalMemoryUsedKB { get; set; }

        public uint? TotalSwapKB { get; set; }

        public uint? TotalSwapUsedKB { get; set; }
    }

4. Any further technical details
Package version: Z.EntityFramework.Plus.EFCore 6.14.4
DB: Postgresql

Hello @Snazzie ,
The BulkInsert method is an immediate operation exactly like SaveChanges. So you should not call SaveChanges after calling the BulkInsert method as the data would already have been inserted.
That being said, you are probably looking for the BulkSaveChanges method:
var context = DbContext.CreateDbContext();

await context.AddRangeAsync(metrics);

await context.BulkSaveChangesAsync();

Since you use different classes, that means entities must be added to different DbSet, and a saving order needs to be created as they might have some dependencies. The BulkSaveChanges methods will be able to handle this.
Let me know if that answers correctly to your question.
Best Regards,
Jon

Yes that fixed it, thanks!.


DesktopNav Chakra-UI Link causes full page refresh

The following causes full page load on clicking nav item url.
              <Link
                p={2}
                href={navItem.href ?? '#'}
                fontSize={'sm'}
                fontWeight={500}
                color={linkColor}
                _hover={{
                  textDecoration: 'none',
                  color: linkHoverColor,
                }}>
                {navItem.label}
              </Link>

Using Next.js Link component with "as"  solves the full page refresh problem.
<Link href="/flip" as="/flip" >Flip</Link>
But Wrapping Chakra-UI Link with Next.js Link creates conflict with  PopoverTrigger.

use to instead of href

Something like this does not work
<Link to="/flip" >Flip</Link>
I am trying to implement "With Sub-Navigation & CTA" code mentioned at https://chakra-templates.dev/navigation/navbar

Something like this does not work <Link to="/flip" >Flip</Link>
I am trying to implement "With Sub-Navigation & CTA" code mentioned at https://chakra-templates.dev/navigation/navbar

Have you got it to work now?
Maybe the docs can help:
https://nextjs.org/docs/api-reference/next/link
https://chakra-ui.com/docs/navigation/link
And if you want to combine both, check out this blogpost:
https://jools.dev/using-nextjs-link-with-chakra-ui-link


describe subjectaccessreview

@devin-donnelly re-opened in response to https://github.com/kubernetes/kubernetes.github.io/pull/1219#issuecomment-247180184

This change is

Thanks much.

Does this address the docs need for this feature?
https://github.com/kubernetes/features/issues/37

Does this address the docs need for this feature?
kubernetes/features#37

Yes, for 1.4


Make object/class member variables public by default

To be consistent and simple, make the default access for class/object member variables public.
If a member variable name starts with an underscore, then it is private.

No way to declare a member read only? It's a shame to sacrifice safety for marginal simplicity. And with a performance hit thrown it; it's almost 4x slower using a Getter(). The main goal of vim9script is performance.
=== assign micro-prof ===
     50    100    200 : nLoops (usec/op)
  0.044  0.044  0.043 : var local = n_value            ###-A
  0.036  0.035  0.034 : var local = C.static_var       ###-D
  0.050  0.047  0.046 : var local = a_class.this_var   ###-G
  0.173  0.170  0.164 : var local = a_class.Getter()   ###-J

No way to declare a member read only? It's a shame to sacrifice safety for
marginal simplicity. And with a performance hit thrown it; it's almost 4x
slower using a Getter(). The main goal of vim9script is performance.

If we want to keep the object method and member accessibility consistent,
then we need this PR.   Otherwise we can keep the current behavior.

If we want to keep the object method and member accessibility consistent

maybe adding another keyword 'readonly',
but make the default (if did not specify) then it is 'prevent' (vs not the 'public') means in pkg.
// if so, if we are working all with 'keyword', then i again recommend you use 'private' keyword too (vs not leading underscore)
--
shane.xb.qian

simplest way was just basic class which none (get rid) of those keyword, i'm ok with that, it's good enough for scripting.
or the most complex one: not only change control but also access control, adding 'readonly', and all control with keyword.

If we want to keep the object method and member accessibility consistent,
then we need this PR.

I don't understand that. Currently there is _ for private methods/members; public for for public. Nicely consistent. The issue revolves around what does it mean if there is no access modifier?
I thought read only member by default was elegant; it's simple to explain and offers both safety and performance. Here's some ways to look at it

Require an access modifier, currently _ and public
There is no default, and other access schemes, like introducing a readonly modifier for member, can be implemented in a source compatible way.
Default is public, get rid of the public access modifier, it's not needed. If simplicity is the goal, it's clutter.
Members/methods are public by default. Can introduce a readonly access modifier for current capability.
Keep the current.
Is it too complex/confusing that a method is not read only but by default a member is? members and methods are different; most languages don't have a concept of writing to a method.

I would definitely weigh in in favor of changing the current system, where an unadorned member is read-only, given that it's different from most (all?) other mainstream languages.
errael's second option (default public, _ private, readonly keyword) feels like the cleanest way to retain all current capabilities, though I personally wouldn't mourn the loss of readonly either, given that the semantics of vim9script's read-only members is unique as well.

If we want to keep the object method and member accessibility consistent,
then we need this PR.

I don't understand that. Currently there is _ for private methods/members;
public for for public. Nicely consistent.

The public keyword is used only for object/class members and not for methods.
The methods are public by default and private if the name starts with an underscore.

The issue revolves around what does it mean if there is no access modifier?

Yes.

I thought read only member by default was elegant; it's simple to explain and
offers both safety and performance.

With the latest code, you will get this behavior (without this PR).  If this is the
desired behavior, then we don't need to make any further changes.

Here's some ways to look at it

Require an access modifier, currently _ and public
There is no default, and other access schemes, like introducing a
readonly modifier for member, can be implemented in a source compatible
way.
Default is public, get rid of the public access modifier, it's not
needed. If simplicity is the goal, it's clutter.  Members/methods are
public by default. Can introduce a readonly access modifier for current
capability.

This PR introduces the behavior in 2 except for the readonly keyword.

Keep the current.
Is it too complex/confusing that a method is not read only but by default
a member is? members and methods are different; most languages don't have
a concept of writing to a method.

For 3, as described above, we don't need to make any further changes.
If we all agree approach 3 is acceptable (even though it is not consistent between
methods and members), then we don't need any additional changes.
Regards,
Yegappan

Default is public, get rid of the public access modifier, it's not
needed. If simplicity is the goal, it's clutter.  Members/methods are
public by default. Can introduce a readonly access modifier for current
capability.

This PR introduces the behavior in 2 except for the readonly keyword.

The PR also takes out the internal support for readonly, rather than just at the parsing/specification level.
I was looking at what it would take to introduce a readonly keyword, before asking how adding that would be received.  If this PR left the infrastructure for readonly, it would be a lot simpler to provide that capability.

+1 for readonly and making members public by default (removing public altogether).
I don't think it's needed to make it an exclusive keyword, it can just be checked inside classes before member declaration, as other 'keywords' currently work (extends, implements, etc.).

Retain some parts of the read only member access code

Thanks. Assuming you're not planning to do read only, I'll take a look tomorrow. (What other plans?).
Idea is basically put back public using readonly; has_readonly instead of has_public. Tweak as needed and flavor with tests.

Oh, and readonly is the only one I've heard floated; haven't thought of anything else that's perfect. I could live with read or ronly. Once everything else is in place, it's simple to change the word.

readable...paint it green!

When I build objmember, with no modifications, and run this I see two problems

Able to access private static
Compile error when trying to write public static

Here's a test
vim9script
class C
    this._mpfoo: number
    static _spfoo: number
    this.mfoo: number
    static sfoo: number

    def new()
        this._mpfoo = 1
        _spfoo = 2
        this.mfoo = 201
        sfoo = 202
    enddef
endclass

def F()
    var o = C.new()
    #echo "_mpfoo" o._mpfoo
    echo "_spfoo" C._spfoo  ### <<<<<<<<< able to access private static
    echo "mfoo" o.mfoo
    echo "sfoo" C.sfoo

    o.mfoo = 301
    #C.sfoo = 302       ### <<<<<<<<< compilation fails
    echo "mfoo" o.mfoo
    echo "sfoo" C.sfoo
enddef
F()
finish

Oh, and this is what I'm running
 hg glog -r ::objmember -l 2
@  changeset:   18285:bdb16ee51e4c
|  bookmark:    objmember
|  tag:         default/objmember
|  tag:         tip
|  parent:      18253:025bc462c74c
|  user:        Yegappan Lakshmanan<EMAIL_ADDRESS>|  date:        Sun Aug 27 07:59:56 2023 -0700
|  summary:     Make object/class member variables public by default
|
o  changeset:   18253:025bc462c74c
|  user:        zeertzjq<EMAIL_ADDRESS>~  date:        Sun Aug 27 11:17:39 2023 +0200
   summary:     patch 9.0.1792: problem with gj/gk/gM and virtual text

Has readonly ever worked? I just ran some tests with vim I built yesterday, standard vim9 stuff. Happily writes to read only variable.

I looked around to get a feel... The following fixes the "access to private static" var in the example, if you want to include it. Not tested much.
diff --git a/src/vim9expr.c b/src/vim9expr.c
--- a/src/vim9expr.c
+++ b/src/vim9expr.c
@@ -434,14 +434,25 @@
     {
        // load class member
        int idx;
+       ocmember_T *m;
        for (idx = 0; idx < cl->class_class_member_count; ++idx)
        {
-           ocmember_T *m = &cl->class_class_members[idx];
+           m = &cl->class_class_members[idx];
            if (STRNCMP(name, m->ocm_name, len) == 0 && m->ocm_name[len] == NUL)
                break;
        }
        if (idx < cl->class_class_member_count)
        {
+           // TODO: Would kindof prefer (@yegappan what do you think)
+           //       even though it's more likely to get a cache miss.
+           // if (m->ocm_access == VIM_ACCESS_PRIVATE
+           //                                      && !inside_class(cctx, cl))
+           // Maybe not, *name == '_' is simple to look at but...
+           if (*name == '_' && !inside_class(cctx, cl))
+           {
+               semsg(_(e_cannot_access_private_member_str), m->ocm_name);
+               return FAIL;
+           }
            *arg = name_end;
            return generate_CLASSMEMBER(cctx, TRUE, cl, idx);
        }

Hi,
On Mon, Aug 28, 2023 at 12:14 PM errael @.***> wrote:

When I build objmember, with no modifications, and run this I see two
problems

Able to access private static
Compile error when trying to write public static

I am able to reproduce the second issue even using a two months old image.
It looks like writing to a class member from a def function never worked.
Regards,
Yegappan

Here's a test
vim9script
class C
this._mpfoo: number
static _spfoo: number
this.mfoo: number
static sfoo: number
def new()
    this._mpfoo = 1
    _spfoo = 2
    this.mfoo = 201
    sfoo = 202
enddef

endclass
def F()
var o = C.new()
#echo "_mpfoo" o._mpfoo
echo "_spfoo" C._spfoo  ### <<<<<<<<< able to access private static
echo "mfoo" o.mfoo
echo "sfoo" C.sfoo
o.mfoo = 301
#C.sfoo = 302       ### <<<<<<<<< compilation fails
echo "mfoo" o.mfoo
echo "sfoo" C.sfoo

enddef
F()
finish

Hi,
On Mon, Aug 28, 2023 at 6:47 PM errael @.***> wrote:

I looked around to get a feel... The following fixes the "access to
private static" var in the example, if you want to include it. Not tested
much.
diff --git a/src/vim9expr.c b/src/vim9expr.c
--- a/src/vim9expr.c
+++ b/src/vim9expr.c
@@ -434,14 +434,25 @@
{
// load class member
int idx;

  ocmember_T *m;
  for (idx = 0; idx < cl->class_class_member_count; ++idx)
  {

      ocmember_T *m = &cl->class_class_members[idx];

      m = &cl->class_class_members[idx];
      if (STRNCMP(name, m->ocm_name, len) == 0 && m->ocm_name[len] == NUL)
          break;
  }
  if (idx < cl->class_class_member_count)
  {

      // TODO: Would kindof prefer<EMAIL_ADDRESS>what do you think)

      //       even though it's more likely to get a cache miss.

      // if (m->ocm_access == VIM_ACCESS_PRIVATE

      //                                      && !inside_class(cctx, cl))

      // Maybe not, *name == '_' is simple to look at but...

      if (*name == '_' && !inside_class(cctx, cl))

      {

          semsg(_(e_cannot_access_private_member_str), m->ocm_name);

          return FAIL;

      }
      *arg = name_end;
      return generate_CLASSMEMBER(cctx, TRUE, cl, idx);
  }

This is the proper fix for this issue.  A similar check is used before this
block of code for
readonly object members.  Can you open a PR for this with a test for this
condition?

Yegappan

Can you open a PR for this with a test for this condition?

OK, but not tonight, tomorrow. I haven't looked at the "write public static compile error".
For my current work area, I took your objmember PR, transplant to work area, rebased to current master, added the readonly parse, I'll need to unwind and stash. I just saw compile_assign_unlet I believe that's the spot for the readonly check. The lhs_T looks like is has all the info needed for the check VIM_ACCESS_READ before any instructions are generated (3 for storing into the object when object is in local var).

A similar check is used before this block of code for
readonly object members

Assuming you meant private.

upd & link & refer : https://github.com/vim/vim/issues/11827

readonly is working AFAICT. I still need to put together some tests. I can't try writing to a readonly static because of the compilation failure bug that prevents writing to class statics. One nice thing about readonly is that it doesn't affect anything unless you use it.
I'm going to put this on the shelf while I put together the PR for preventing writing to private members.
The readonly PR is based on this PR. So this PR, #12932, has to go in before I can open a PR for readonly. Is this PR ready to go?

Is there some strong objection to requiring a keyword modifier?  Why is a default needed at all?
We could require private and keep the required underscore as well.  This is is already done for functions/methods which require an uppercase character.
The language uses strictly unnecessary keywords everywhere.  In declarations, in particular, they're cheap and clear.
This would also obviate the problem with initialised declarations looking the same as plain assignments.

@errael before asking for this PR to be merged, can you show your code with the readonly implementation? Because I was also working on an implementation but it's incompatible with this PR. So I'd like to discuss how we should implement readonly first.
My take is here (WIP, not working).
Basically I wanted readonly to work as in C#:

both private and public members can be readonly
readonly means the member can still be changed (set) by the constructor, but not later
readonly is only for object members (this.), not for class members (static) because the constructor can change it

So it's different from const, that could be actually implemented to have readonly class (static) members.

The implementation I'm working is the current read only semantics that you get by default and is described in the current documentation; see ":he vim9-class-member", it says "anybody can read, only class can write", no other rules. Note that even this has been considered by some as too complex. What you describe seems to go beyond the goal of simplicity.
The change I'm working on is about access control,  and does not affect object constructin. It affects both members/statics.
There's a comment from Bram somewhere that a problem with using the readonly keyword is that it meant something else in another language (I'm guessing C#). Maybe readable would be a better keyword to avoid possible confusion. Fortunately changing the keyword is straightforward.
It seems like what you are working on is orthogonal to what I'm doing. It is a different mechanism entirely, which could be added at some point.

The problem with the semantics Bram came up with, is that they're different from any other language (the use of public for example). The semantics for readonly you are proposing follow this line of thought. readonly should mean the member can't be written by anybody, otherwise it's not readonly. Just like public should mean publicly accessible, not publicly writable.
So I'm against your proposal. I think it doesn't matter what the current specification says, because mostly it doesn't work (do abstract classes and interfaces actually work?). The class specification should be considered a WIP all around so.
Rather than confusing simplicity, familiarity and consistence of semantics (on the base of what they already mean in other languages) is more important here. Then you say it's more complex but I don't even think it is.
Let's hear what @yegappan says.

The same concept of anybody can read, only class can write, I don't think it exists in any other language. So it's not simple.

I think it doesn't matter what the current specification says, because mostly it doesn't work

I have written a project using the current readonly semantics and I like them quite a bit. In particular I have a presentation class that presents a readonly view of some internal structures. This is easy to implement allowing concise code and doesn't require the much lower performance getters.

readonly should mean ...

OK, I guess the access modifier readable is the way to go.

Also readable doesn't exist anywhere else. If simplicity is the ultimate goal, I'd say this PR is ok in just removing public. We can live without readonly but even more so without stuff invented for vimscript that doesn't exist anywhere else.

so let me summarize: the current proposal is to remove the public keyword completely (?) and make all attributes public by default (unless they start with _)? So by removing this keyword, no-one complains that private keyword is also missing?
I like that approach, it makes it easier to spot private members directly in the code. But I am probably not the one going to use this a lot, so I am not having any saying here :)

Hi Christian,
On Tue, Aug 29, 2023 at 12:06 PM Christian Brabandt <
@.***> wrote:

so let me summarize: the current proposal is to remove the public keyword
completely (?) and make all attributes public by default (unless they start
with _)? So by removing this keyword, no-one complains that private
keyword is also missing?

Yes.  The only supported keyword for members/methods is "static" for
declaring class members and methods.
If a member or method name starts with an underscore, then it is private.
Otherwise it is public.
Regards,
Yegappan
I like that approach, it makes it easier to spot private members directly

in the code. But I am probably not the one going to use this a lot, so I am
not having any saying here :)

Hi,
On Tue, Aug 29, 2023 at 11:03 AM Gianmaria Bajo @.***>
wrote:

Also readable doesn't exist anywhere else. If simplicity is the ultimate
goal, I'd say this PR is ok in just removing public. We can live without
readonly but even more so without stuff invented for vimscript that
doesn't exist anywhere else.
I agree.  I think this will be simple and less confusing.

Regards,
Yegappan

Just to mention another alternative:
this.member     # full access from everywhere
this._member    # semi-private: read-only from outside the class
this.__member   # fully private

Able to access private static

Compile error when trying to write public static

There's another one (a real shocker).
It's OK to write to a private member.
vim9script

class C
    this._m: number
    #static _s: number
    def Dump()
        echo this._m
    enddef
endclass

def F()
    var o = C.new()
    o.Dump()
    o._m = 5
    o.Dump()
    #var s = C._s
enddef
F()

I put in the Dump() because I had to see it to believe it.

Should the example here https://github.com/vim/vim/blob/d01a0df61d2a322645fb393ed704fcec38e0d0fe/runtime/doc/vim9class.txt#L186-L200
also be changed to use underscores? Otherwise we wouldn't need the and Set() function, right?

There's another one (a real shocker).
It's OK to write to a private member.

Confirmed, but only inside a def, it works at script level.

Can you open a PR for this with a test for this condition?

I got everything wrapped up as a follow up to this PR, and it doesn't look like that will work out. So no.

Hi,
On Tue, Aug 29, 2023 at 1:42 PM Christian Brabandt <
@.***> wrote:

Should the example here
https://github.com/vim/vim/blob/d01a0df61d2a322645fb393ed704fcec38e0d0fe/runtime/doc/vim9class.txt#L186-L200
also be changed to use underscores? Otherwise we wouldn't need the and
Set() function, right?

Yes. This example needs to be updated.
Regards,
Yegappan

Hi,
On Tue, Aug 29, 2023 at 1:38 PM errael @.***> wrote:

Able to access private static
Compile error when trying to write public static
There's another one (a real shocker).
It's OK to write to a private member.
vim9script
class C
this._m: number
#static _s: number
def Dump()
echo this._m
enddef
endclass
def F()
var o = C.new()
o.Dump()
o._m = 5
o.Dump()
#var s = C._s
enddef
F()
I put in the Dump() because I had to see it to believe it.

I have created the PR https://github.com/vim/vim/pull/12963 to address this.
Regards,
Yegappan

Just to mention another alternative:
this.member     # full access from everywhere
this._member    # semi-private: read-only from outside the class
this.__member   # fully private

vim9 is for scripting mostly, i think better be making it simple.
// @yegappan double (or more) leading __ perhaps should be a err.

Yes. The only supported keyword for members/methods is "static" for declaring class members and methods. If a member or method name starts with an underscore, then it is private. Otherwise it is public.

ok, i think we can live with it (at least me), and actually this is the better one, leading underscore is acceptable if so.
// though i think should be not much people really would use vim9 to write OOP script.

Is there some strong objection to requiring a keyword modifier? Why is a default needed at all?

Are you suggesting private/public for functions, members, static.

Yes, all class features where the modifier is applicable.  I was, however, assuming there'd be more than the two; there will be one day. :)

so let me summarize: the current proposal is to remove the public keyword completely (?) and make all attributes public by default (unless they start with _)? So by removing this keyword, no-one complains that private keyword is also missing?
I like that approach, it makes it easier to spot private members directly in the code. But I am probably not the one going to use this a lot, so I am not having any saying here :)

For the record, I have been complaining for a year about some of the quirky class definition syntax.
Limiting this to private underscore for the moment and since you have no dog in the fight, maybe you could take the hit and elaborate on why "spot private members in the code" is of such obvious value that we need a new identifier naming rule?  My blind spot is huge.
It seems to me to be a completely arbitrary partial Hungarian notation with semantics.  There are several attributes I'm interested in at the call site, accessibility is only one of them and not the most interesting.
In my experience the underscore idiom was developed in languages that didn't enforce accessibility and doesn't make much sense in those that do.  I'm assuming this feels natural to people who already use the idiom in other languages.  I find it extremely ugly in a language that I otherwise find consistent and quite pretty in its Vim 9 release state.
When you lump this in with required 'this' qualification one has to prefix every private field with six characters of extremely dubious value.  A few variables on the same line and I'm already cobbling together a syn-conceal group to ease the pain.
This is largely bike-shedding, of course, but isn't that what surface level language design is all about? :)

why "spot private members in the code" is of such obvious value

I agree with most everything you've said (and although I've used (and like quite a bit) python, I've never used it in a larger project where _ was used.
But now that my beloved readable is in the trash, I will rarely have an unadorned field name; everything is private. I'd find it more useful to visually flag something public so the warning bells go off in my head.

For the record, I am not insisting on any of this and the reason I have not yet merged is, I'd like to see what the dicussion results in :)
But since you seem to be asking me directly 😎
Code tends to be read more often then written and for me, being able to see while reading existing code, ah this must be a private member outweights the disadvantage that the _ brings as part of the changes in semantics of the language. (I think Bram brought this argument as well at some time). Yes you need to know that _foobar has a special meaning, but if you are writing code, you should know where to lookup the specifics of your language anyhow.
there is another disadvantage, that one cannot easily refactor code, but I suppose this is not done so often. So for me this is okay.
and finally whether one uses this._member or this.member doesn't make such a huge difference for me.
But then I am not a developer in my profession and I don't know what other languages tend to do, so my opinion is as good or bad as anybody elses here :)

I'd like to see what the dicussion results in :)

In that case
I'm disappointed that there was no response to the observations/concerns with the performance hit of not having direct read access. Of the possible responses, e.g. "not that important", no response is the worst.
In the discussion on simplicity, there wasn't much discussion of the visual clutter introduced by requiring getters. Recall that the vim9class doc carefully shows how simple a class can look for common cases; vim9script is a scripting language. Safety was traded off in favor of not having public and adding visual clutter. And one of the "key" discussion points was that anything new or innovative could not be simple, I don't accept that.

I'm disappointed that there was no response to the observations/concerns with the performance hit of not having direct read access. Of the possible responses, e.g. "not that important", no response is the worst.

I don't follow. By default we have public access, so that shouldn't have any negative performance impact.

In the discussion on simplicity, there wasn't much discussion of the visual clutter introduced by requiring getters. Recall that the vim9class doc carefully shows how simple a class can look for common cases; vim9script is a scripting language. Safety was traded off in favor of not having public and adding visual clutter. And one of the "key" discussion points was that anything new or innovative could not be simple, I don't accept that.

You need Getters only for private members, right? For common cases using public members you wouldn't need it, right?

I'm disappointed that there was no response to the observations/concerns with the performance hit of not having direct read access. Of the possible responses, e.g. "not that important", no response is the worst.

I don't follow. By default we have public access, so that shouldn't have any negative performance impact.

I don't use public, it is unsafe. The performance hit is that Getters are required.
https://github.com/vim/vim/pull/12932#issuecomment-1694703159

In the discussion on simplicity, there wasn't much discussion of the visual clutter introduced by requiring getters. Recall that the vim9class doc carefully shows how simple a class can look for common cases; vim9script is a scripting language. Safety was traded off in favor of not having public and adding visual clutter. And one of the "key" discussion points was that anything new or innovative could not be simple, I don't accept that.

You need Getters only for private members, right? For common cases using public members you wouldn't need it, right?

Public members are OK for tiny things, but public members are not safe. I think you are mistaken; for a stongly typed OOP, public members are not the common case. As a project grows, allowing arbitrary actors to modify internal state is not a common design pattern. Make everything private and add Getter() is what one needs to do with the proposed semantics.

What @errael wants, is members that can be publicly read but not written, so that you don't need to set up Getters for them (with the associated performance hit). I think it's a valid case after all.
Other OOP languages have ways to define this behaviour (for example with properties) but we only want simple stuff here, certainly not properties, but it would be convenient to have here. I still think readable is a bad name, as is readonly for this. Maybe restrict or similar.

even 'public' it actually was default in pkg only as my understanding, so I was said actually it was 'prevent' was the correct default.
I supposed this can reduce your safety concern, though I still think not much people really would use vim9 to wrote OOP script.
--
shane.xb.qian

Found it, here's some comments from Bram about this topic
In the email thread
https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
The only comment I saw from Bram in the thread specifically about default public versus read-only has to do with simple versus safe. From the thread, in response to a suggestion that public should be the default:
About public/private/read-only: Making the default public is certainly
possible. I think most languages have it that way, even though it's not
a safe choice.

I do like the read-only access. Quite often you want to disallow any
code outside of the class to change a member, so that you can make sure
the value is valid. But making it private means you have add a
"getter" and call it. [...]

can reduce your safety concern, though I still think not much people really would use vim9 to wrote OOP

But we are specifically talking about OOP. Someone using it should be assumed when considering a comment.

Other OOP languages have ways to define this behaviour...

I still think readable is a bad name, as is readonly for this. Maybe restrict or similar.

The discussion should be about whether or not the semantics should be available in vim9script.
I think it best to not discuss specific names, that derailed previous discussions.

@yegappan  I appreciate that in your position you want to observe and let the discussion flow. But I would appreciate if you can find a way to express your opinions on the various topics. Not just state the facts.
How useful are read-only semantics? How big are projects going to get (I've never written vimscript or looked into the ecosystem, but I've seen projects grow and grow no matter the language). How important is safety (it is strongly typed...) and how do the available syntax/semantics affect that. What do you think about the performance hit. Anything else?

Currently public isn't even needed by the way. I learned of it with this PR.
vim9script

class C
    this.str: string
endclass

def F()
    var tvar = C.new()
    echo tvar.str
    tvar.str = "a"
    echo tvar.str
enddef

F()

How useful are read-only semantics? How big are projects going to get (I've
never written vimscript or looked into the ecosystem, but I've seen projects
grow and grow no matter the language). How important is safety (it is
strongly typed...) and how do the available syntax/semantics affect that.
What do you think about the performance hit. Anything else?

I developed and maintain the following large and widely used Vim plugins:
https://github.com/yegappan/lsp
https://github.com/yegappan/taglist
https://github.com/yegappan/mru
Based on this experience, I can say that type safety and access control
are important.  I have spent quite a bit of time optimizing these plugins
and found that reducing functions calls definitely helps.  So having a
readonly access to the members will help.

Currently public isn't even needed by the way. I learned of it with this PR.

This is a bug.  I will open a PR to address this.

have spent quite a bit of time optimizing these plugins and found that reducing functions calls definitely helps. So having a
readonly access to the members will help.

I am there with you too specially lsp plugin :smile:
as my limit experience, readonly normally was not part of general OOP, but you may make const and final work on class var.
with the here public default and const or final then concern solved.
// anyway I supposed we were choosing the simplest way (vs that most complex) which I indicated two ways in above comment.
--
shane.xb.qian

so I guess we should then leave it as it?

merger this pr
make const and final work on class var.
// then concern solved.

// P.S: double or more leading underscore may  should be an err.
--
shane.xb.qian

Currently public isn't even needed by the way. I learned of it with this PR.

This is a bug. I will open a PR to address this.

@yegappan If we get this PR, #12932, settled along with what semantics for access will be supported, and a list of outstanding access control features that are problems and need fixing. Then I can assist; I've got some work done, but stopped when it became unclear what was needed.
Not sure the best way to enumerate the issues and at indicate who is working on what.

so I guess we should then leave it as it?

merger this pr 2. make const and final work on class var. // then concern solved. // P.S: double or more leading underscore may should be an err.
…
-- shane.xb.qian

@Shane-XB-Qian You might have a misunderstanding of the read-only semantics under discussion. In the vim9class docs it says
anybody can read, only class can write

The traditional const/final do not meet this criteria.

okay, so I guess we should then leave it as it? Seems like that is prefered from the community point of view instead...

@chrisbra Can you give a timeline on when this will be finalized. I'm unable/unwilling to work on issues until it's clear what needs to be done.

Currently public isn't even needed by the way. I learned of it with this PR.

This is a bug. I will open a PR to address this.

And specifically, I've got a fix that handles ACCESS_PRIVATE/ACCESS_READ in compile_assign_unlet. Which I think covers this particular issue.

it's not clear to me what you want.
But to be clear, there is no rush, if you want something fixed, then just open an issue/PR and mention you are working on this. I am not in a hurry to release anything. We can tag this with the vim 9.1 Milestone and only when this is done get the release done.
For the Vim9 oop semantics, I trust you and Yegappan to let me know once you thing this is in a state that is ready to be released :)
And of course anybody else

From: errael @.>
Sent: Thursday, August 31, 2023 1:34:17 AM
To: vim/vim @.>
Cc: Shane-XB-Qian @.>; Mention @.>
Subject: Re: [vim/vim] Make object/class member variables public by default (PR #12932)
so I guess we should then leave it as it?

merger this pr 2. make const and final work on class var. // then concern solved. // P.S: double or more leading underscore may should be an err.
…
-- shane.xb.qian

@Shane-XB-Qianhttps://github.com/Shane-XB-Qian You might have a misunderstanding of the read-only semantics under discussion. In the vim9class docs it says
anybody can read, only class can write
The traditional const/final do not meet this criteria.
—
Reply to this email directly, view it on GitHubhttps://github.com/vim/vim/pull/12932#issuecomment-1699583778, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADHMHQJHQIMPMYI3424D4Q3XX52RJANCNFSM6AAAAAA4ALZBAE.
You are receiving this because you were mentioned.Message ID: @.***>

it's not clear to me what you want.

The first thing is a decision on what access semantics are going to be supported in vim9script for the 9.1 release. That is still an open issue AFAICT.
The other problem is that access control was mostly not implemented at all as of last week. There's not been an issue opened. @yegappan and others have been addressing them as they come up; they have mostly been mentioned in unrelated PRs. There are/have-been to many specific cases to open an issue for each one (at least that's how it has been); but then again, I'm only saying what I've seen, accuracy might be off.
Maybe a discussion, with the access matrix, what's been tested, what works, ..., If someone wants to address a specific case, they could say so.

On 23/08/30 10:34AM, errael wrote:

so I guess we should then leave it as it?

merger this pr 2. make const and final work on class var. // then concern solved. // P.S: double or more leading underscore may should be an err.
…
-- shane.xb.qian

@Shane-XB-Qian You might have a misunderstanding of the read-only semantics under discussion. In the vim9class docs it says
anybody can read, only class can write

The traditional const/final do not meet this criteria.

maybe let's focus on your concern : 'safety' and 'getter()'
i donot understand that doc (your pasted) about 'read-only' what's that going to be (any OOP like that?)
or anyway, this part bram should be actually not impl yet, meant doc was just a rough design (in vim9 doc somewhere had said that too),
and const even different in legacy vim script and vim9, so supposed ok if a bit different in vim9 class var too (if really required).
--
shane.xb.qian

Currently public isn't even needed by the way. I learned of it with this PR.

This is a bug. I will open a PR to address this.

And specifically, I've got a fix that handles ACCESS_PRIVATE/ACCESS_READ
in compile_assign_unlet. Which I think covers this particular issue.

Please feel free to open a PR with this fix and a test.

Currently public isn't even needed by the way. I learned of it with this PR.

This is a bug. I will open a PR to address this.

And specifically, I've got a fix that handles ACCESS_PRIVATE/ACCESS_READ
in compile_assign_unlet. Which I think covers this particular issue.

Please feel free to open a PR with this fix and a test.

Until there is a decision on access control syntax/semantics that's not going to happen (at least by me). So as long as you're not in a hurry... I'll do it when there's some decisions, otherwise it's potentially throw away code.
How should co-ordination, specifically about access control, be handled? It's currently a bit of a hodge-podge.

i am ok with current had made decision which is:
only static keyword, default is public and remove that keyword, and one leading underscore is private.
only left thing is your concern about 'readonly', if above explaination or suggestion cannot solve it, then i have no idea...
// then same like chrisbra, i left this to you guys to find a better or workable one.. :smile:
--
shane.xb.qian

Maybe a discussion, with the access matrix, what's been tested, what works, ..., If someone wants to address a specific case, they could say so.

Feel free to open as discussion. I am not in the position to test this currently.

Maybe a discussion, with the access matrix, what's been tested, what works, ..., If someone wants to address a specific case, they could say so.

Feel free to open as discussion. I am not in the position to test this currently.

@yegappan You're the vim9script lead in this benign dictatorship. Whatever, if anything, we do must have your blessing or it's not worth doing.
@chrisbra Is there a timeline for when a decision will be made? Nothing to do or work on if there's no target.

Just in case there is a doubt. I would favor closing this PR without merging as described by @yegappan in the comment below extracted from https://github.com/vim/vim/pull/12932#issuecomment-1699493034
To anyone who wishes to make clear their preference, keeping in mind that this is not a vote. Please be brief. There has been plenty of discussion.

to continue to support the existing readonly default access,
[...]
We then don't need the changes in this PR and can keep
the existing behavior.

keeping in mind that this is not a vote

this is a some kinds of 'vote' and discussion, otherwise where was this PR came from?
anyway, seems @yeggapan changed mind again which this was discarded vs #12978 opened.
// 'public' & 'readonly' & '_' looks odd, but if that's final version, then let it be~
--
shane.xb.qian

Maybe a discussion, with the access matrix, what's been tested, what works, ..., If someone wants to address a specific case, they could say so.

Feel free to open as discussion. I am not in the position to test this currently.

@yegappan You're the vim9script lead in this benign dictatorship. Whatever, if anything, we do must have your blessing or it's not worth doing.

I have started a discussion (https://github.com/vim/vim/discussions/12979) to capture the
access matrix.  I have tested the various access controls for an object method and the
different ways it can be accessed.  All of these works as expected.  Let me know if I missed
any cases.
Accessing a class member variable from a def function currently doesn't work.

On Thu, Aug 31, 2023 at 6:50 AM errael @.***> wrote:

I have started a discussion (#12979
https://github.com/vim/vim/discussions/12979) to capture the
access matrix.
Thank you. I'll take a look. I would have done something if you'd said "go
ahead" .
I have marked the failing cases with "BUG".  Most of these are related to
writing to
a class member variable in a def function.


add a comment based on pr title and story title similarity

Add comments by comparing story title and PR title
Very different

    Knock Knock! 🔍

    Just thought I'd let you know that your PR title and story title look quite different. PR titles
    that closely resemble the story title make it easier for reviewers to understand the context of the PR.

    An easy-to-understand PR title a day makes the reviewer review away! 😛⚡

Story Title
ES build for zoids and publish it to npm

PR Title
use a temp branch to test comments

    Check out this guide to learn more about PR best-practices.

Slightly Different

    Let's make that PR title a 💯 shall we? 💪

    Your PR title and story title look slightly different. Just checking in to know if it was intentional!

Story Title
ES build for zoids and publish it to npm

PR Title
feat: ES build for zoids

      Check out this guide to learn more about PR best-practices.

LGTM
I'm a bot and I 👍 this PR title. 🤖

This feature can be skipped by adding a config skip-comments: true

Comment for huge PR
This PR is too huge for one to review :broken_heart:

Files changed
18 :no_good_woman:

Addtions
2000 :no_good_woman:

    Consider breaking it down into multiple small PRs.

      Check out this guide to learn more about PR best-practices.

Updated the README.md with the new feature addition

Thanks, @rheaditi for the content of the comments

Sorry for this hiccup :point_up: in local, the pre-commit threw error but still committed the changes so I used the same commit message for a different fix

@rheaditi will add test cases and do a few more refactoring if I some free time next week.


glyf table __setitem__ append to glyphOrder but doesn't invalidate _reverseGlyphOrderDict

The table__g_l_y_f class holds a mutable reference to the TTFont.glyphOrder list, in its decompile method it calls ttFont.getGlyphOrder() like this:
https://github.com/fonttools/fonttools/blob/41bd3a143d3182ccb5604b7b01d1cf088da75e94/Lib/fontTools/ttLib/tables/_g_l_y_f.py#L92
Then its __setitem__ method appends the new glyph name to self.glyphOrder, which at the same time automatically updates the global TTFont.glyphOrder (they are the same list object):
https://github.com/fonttools/fonttools/blob/41bd3a143d3182ccb5604b7b01d1cf088da75e94/Lib/fontTools/ttLib/tables/_g_l_y_f.py#L299-L302
However, if one calls ttFont.getGlyphID or ttFont.getReverseGlyphMap after setting a new glyph in the glyf table, one gets an incorrect result because the _reverseGlyphOrderDict cached value is not invalidated and getReverseGlyphMap returns the one computed before setting the new glyph.
from fontTools.ttLib import TTFont, newTable
font = TTFont()
font.setGlyphOrder([".notdef"])
glyphMap = font.getReverseGlyphMap()  # this caches _reverseGlyphOrderDict

glyf = font["glyf"] = newTable("glyf")
glyf.glyphs = {".notdef": Glyph()}
glyf.glyphOrder = font.getGlyphOrder()

# now we add a new glyph via __setitem__
glyf["a"] = Glyph()

print(font.getGlyphOrder())  # => [".notdef", "a"]

print(font.getReverseGlyphMap())  # => {".notdef": 0}   ... whereas it should have been {".notdef": 0, "a": 1}

print(font.getGlyphID("a"))  # => None ... instead of 1!

This is a bit problematic. On the one hand, glyf's __setitem__ modifes the TTFont's own global glyphOrder (indirectly via mutable ref) without invalidating the reverse glyph map cache. On the other hand, it doesn't have a ref to the parent TTFont to be able to invalidate the said cache..
Current workarounds include: calling ttFont.getReverseGlyphMap(rebuild=True) to force rebuilding the cache before geting glyph ids from names; avoid using glyf __setitem__ altogether and explicitly set TTFont.setGlyphOrder() when finished appending to the glyf table.

The fact that glyf table has a glyfOrder is bizarre to be honest.

It's probably an old implementation detail, I honestly don't remember why it's there. If we can get rid of it that would be great.

it appears to be used to resolve glyphID<=>glyphNames when decompiling/compiling (see the glyf table class' getGlyphName and getGlyphID methods). Both the decompile/compile methods take a ttFont parameter so they can extract the TTFont.getGlyphOrder() and potentially pass it down; one problem I see is with lazy decompilation, whereby glyphs are decompiled upon request. Even if we don't want to store a reference to the TTFont.glyphOrder we might still have to store a back-reference to the parent TTFont inside the glyf table object to be able to decompile lazily.

@justvanrossum, @behdad
I think this issue is also impacting my Egyptian OpenType project. I have been using FontTools version 4.38.0 to avoid hitting this, but I'd like to upgrade.
My code injects empty glyphs into a font:
function addGlyph(font, glyph_name):
font['glyf'][glyph_name] = Glyph()
font['hmtx'][glyph_name] = (0,0)
return font.getGlyphID(glyph_name)
This works fine on FontTools 4.38.0 but returns "KeyError" with FontTools 4.39 and later:
File "....\fontTools\ttLib\ttFont.py", line 669, in getGlyphID return self.getReverseGlyphMap()[glyphName]
I'd appreciate suggestions for a workaround or a fix, thank you!

So, I broke this in ca06c9530c6a196ad5b2570afc1f19734fb756bc
I probably can come up with a cheaper way to keep the previous behavior. @anthrotype @justvanrossum please advise.

@xadxura Can you please test https://github.com/fonttools/fonttools/pull/3582 ?

Thank you, @behdad, just tested. I'm still getting an error with getReverseGlyphMap. Made a comment with possible solution on #3582.

Re: #3582, I wonder if the glyf table should also keep a reference to the global _reverseGlyphOrderDict object that TTFont has, similarly to the way it keeps a ref to TTFont's glyphOrder. I see it keeps its own cache (named slightly differently glyf._reverseGlyphOrder) and uses it in a similar fashion to implement its own getGlyphID method, in turn used when compiling glyph components.
If we modify glyf to reuse the same global map of glyph names to indices (a dict to be modified in place as opposed to the current rebuilding anew) then it could keep supporting its lazy-loading without keeping a reference to the entire TTFont object (which is the reason it has its own glyphOrder attribute, a ref to the TTFont.glyphOrder list), and it would know what to do when setting or deleting a glyph; in the first case, just do a self._reverseGlyphOrderDict[glyphName] = len(self.glyphOrder); in the second case, clear the cache in-place and rebuild (changes which would propagate to the TTFont as well given the same dict is shared by both.

If we do the above, then TTFont.getGlyphID can continue to assume that the glyphOrder and its reverse dict are in sync and the latter doesn't need to be rebuilt when a glyphName is missing, because the only places where the glyphOrder is modified also are responsible for updating or rebuilding the cache.


Automated Package Upgrade

:tada: This PR is included in version 2.0.59 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Unable to parse traceback

Input traceback
ValueError: invalid literal for int() with base 10: 'None'
  File "flask/app.py", line 1982, in wsgi_app
    response = self.full_dispatch_request()
  File "flask/app.py", line 1614, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "flask_cors/extension.py", line 161, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "flask/app.py", line 1517, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "flask/_compat.py", line 33, in reraise
    raise value
  File "flask/app.py", line 1612, in full_dispatch_request
    rv = self.dispatch_request()
  File "flask/app.py", line 1598, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "<decorator-gen-39>", line 2, in ci
  File "geetest_client.py", line 209, in captcha_counter_decorator
    return func(*args, **kwargs)
  File "company.py", line 305, in ci
    company = get_company_info(company_id)
  File "company.py", line 129, in get_company_info
    return get_company_info_from_es(company_id) or get_company_info_from_element(company_id)
  File "company.py", line 144, in get_company_info_from_es
    annuals = choose_and_prettify_annual(company_id, result.get('extra', {}).get('类型', ''))
  File "company.py", line 174, in choose_and_prettify_annual
    result = prettify(annuals, is_llc=is_llc, show_all=show_all)
  File "prettify/annual.py", line 45, in prettify
    year = int(annual.get('year') or 0)

Error:
Traceback (most recent call last):
  File "/Users/messense/.local/bin/git-stacktrace", line 11, in <module>
    sys.exit(main())
  File "/Users/messense/.local/venvs/git-stacktrace/lib/python3.6/site-packages/git_stacktrace/cmd.py", line 45, in main
    traceback = api.parse_trace(blob)
  File "/Users/messense/.local/venvs/git-stacktrace/lib/python3.6/site-packages/git_stacktrace/parse_trace.py", line 195, in parse_trace
    raise ParseException("Unable to parse traceback")
git_stacktrace.parse_trace.ParseException: Unable to parse traceback

@messense thank you for the bug report, The issue is I assume each line in the traceback includes source code, but   File "<decorator-gen-39>", line 2, in ci does not. I am working on a fix now.

@messense can you confirm that https://github.com/pinterest/git-stacktrace/pull/11 fixes your issue.

Fixed, thanks.

Fix released in 0.7.1


feat(build): Add extra version information

Introduce shadow-rs as a dependency. This gives some additional git information for version info, and integrates with clap very nicely.
Fixes #361
Signed-off-by: Brad P. Crochet<EMAIL_ADDRESS>rh-pre-commit.version: 2.2.0
rh-pre-commit.check-secrets: ENABLED

Closing in favor of #418


Why is find_package for gtest saying that the version is incompartible?

I am using Visual Studio Code for my C++ project. I have added

"cmake.configureSettings": {
        "CMAKE_TOOLCHAIN_FILE": "c:/vcpkg/scripts/buildsystems/vcpkg.cmake"
    }

to my settings.json file.
This is my manifest file

"$schema": "https://raw.githubusercontent.com/microsoft/vcpkg/master/scripts/vcpkg.schema.json",
    "name": "libqxx",
    "version": "0.1.0",
    "builtin-baseline": "b1b4808228377515acd849b8706ee2ad25ba455d",
    "license": "MIT",
    "features": {
        "examples": {
            "description": "build package examples",
            "dependencies": [
                {
                    "name": "fmt",
                    "version>=": "7.1.3#5"
                }
            ]
        },
        "tests": {
            "description": "build package test",
            "dependencies": [
                "gtest"
            ]
        }
    }
}

this is how I am including the features in the main cmake file
if (ENABLE_BUILD_TESTS)
    list(APPEND VCPKG_MANIFEST_FEATURES "tests")
    message(STATUS "${PROJECT_NAME}: building tests")
    enable_testing()
    add_subdirectory(tests)
endif()

if (ENABLE_BUILD_EXAMPLES)
    list(APPEND VCPKG_MANIFEST_FEATURES "examples")
    message(STATUS "${PROJECT_NAME}: building examples")
    add_subdirectory(examples)
endif()

And my cmake file that requires GTest library - the relevants parts at least
find_package(GTest CONFIG REQUIRED)
add_executable(${PROJECT_NAME}-tests main.cpp)
target_link_libraries(${PROJECT_NAME}-tests PRIVATE ${PROJECT_NAME}::${PROJECT_NAME} GTest::gtest)
add_test(NAME ${PROJECT_NAME}::tests COMMAND ${PROJECT_NAME}-tests)

When I run the Cmake build command it finds GTest but fails to complete the process. Here is the log
Building folder: libqxx
[main] Configuring folder: libqxx
[proc] Executing command: C:\msys64\mingw64\bin\cmake.exe --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=c:/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=C:\msys64\mingw32\bin\gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=C:\msys64\mingw32\bin\g++.exe -Hc:/C:/Users/Me/Projects/libqxx-Bc:/C:/Users/Me/Projects/libqxx/build -G "MinGW Makefiles"
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Running vcpkg install
[cmake] Detecting compiler hash for triplet x64-windows...
[cmake] All requested packages are currently installed.
[cmake]
[cmake] Total elapsed time: 3.9 us
[cmake]
[cmake] -- Running vcpkg install - done
[cmake] CMake Error at C:/vcpkg/scripts/buildsystems/vcpkg.cmake:792 (_find_package):
[cmake]   Could not find a configuration file for package "GTest" that is compatible
[cmake]   with requested version "".
[cmake]
[cmake]   The following configuration files were considered but not accepted:
[cmake]
[cmake]     C:/Users/Me/Projects/libqxx/build/vcpkg_installed/x64-windows/share/GTest/GTestConfig.cmake, version: 1.11.0 (64bit)
[cmake]
[cmake] Call Stack (most recent call first):
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "C:/Users/Me/Projects/libqxx/build/CMakeFiles/CMakeOutput.log".
[cmake]   tests/CMakeLists.txt:1 (find_package)

Why is it saying the version is incompatible?

version: 1.11.0 (64bit)

means you are building for 32 bit and not 64 bit

"cmake.configureSettings": {
        "CMAKE_TOOLCHAIN_FILE": "c:/vcpkg/scripts/buildsystems/vcpkg.cmake"
    }

add "VCPKG_TARGET_TRIPLET": "x64-windows"

add "VCPKG_TARGET_TRIPLET": "x64-windows"

probably not what is wanted:

Executing command: C:\msys64\mingw64\bin\cmake.exe
-DCMAKE_C_COMPILER:FILEPATH=C:\msys64\mingw32\bin\gcc.exe

but "VCPKG_TARGET_TRIPLET": "x86-mingw-dynamic" could be what is wanted

you are right, i was fooled by vcpkg_installed/x64-windows/share/GTest/GTestConfig.cmake (the x64-windows triplet in which vcpkg found the dependency)

so it looks like anyway that the manifest mode worked out of the box without any specific triplet by the user in x64-windows mode, but then vcpkg didn't select the same triplet when building the master project. Is it right?

I believe it's that we cannot detect the "correct" triplet when the user is using mingw. We automatically fell back to x64-windows, but they really wanted an x86-mingw variant.

Closing this issue for now seems there is no any concern.


Various fixes for swift 4

Fixes #16 with urlSesson double free or corruption
Fixes #14 with large paramters

FYI @jthomas

@dubeejw take a look now


Ctrl+A doesn't work in GUI runner's filter edit

Ctrl+C, Ctrl+V, Ctrl+X etc. all work as expected, but Ctrl+A does not?
I seem to run into this issue surprisingly often.
Can be worked around with an OnKeyDown listener - not sure that's an appropriate fix though, doesn't address why it's not working in the first place. It should be native behavior form the underlying control right? Something is interfering with that?
procedure TGUIVCLTestRunner.edtFilterKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
begin
  if (Shift = [ssCtrl]) and (Key = vkA) then
    edtFilter.SelectAll;
end;

I use D10.4UP2, if that's relevant, and this is with latest Commit d9dca123 2024-07-29

I'll take a look at this. I don't remember any reason it would be by design. Sometimes another shortcut property gets set by accident and takes precedence...


bottom navbar shows on files page

issue:
bottom navbar shows on files page. I guess we should probably just disable sidebar in mobile view and should fix (hopefully) a few of these tickets.
screenshot:

This is covered when we fix the issues around the double navbar right @Jekrimo? Closing for now but open again if I got it wrong!
https://github.com/Satellite-im/Uplink/issues/1347

This is covered when we fix the issues around the double navbar right @Jekrimo? Closing for now but open again if I got it wrong!
#1347

Quite right good chap!


SCons: Bump C standard: C11→C17

As the leap from C11 to C17 is fairly minor, functioning mostly as a bugfix release^1, it feels like a reasonable addition now that the C-Standard is properly added in msvc builds. The only context where the C-Standard wouldn't be updated is for anyone using VS2017, but they're already not specifying a C-Standard outright so it's not exactly dealbreaking.

This should probably be done in godot-cpp and godot-cpp-template as well.

Good call! Those should get the extra msvc C-Standard checks at the same time; I'll look into that sometime tomorrow

Will this allow for some more compiler optimizations when building?


Crawler is blocking all other HTTP requests while it's running

Since all those requests from roomid-handler are filling the queue in  Xhr's RateLimiter so other requests have to wait in the queue for a long time. I added a RateLimiter on roomid-handler to give other clients a chance to sneak in their requests.
Also, in some scenarios rooms with activities are not added to db, so simplified add_to_db handling to purely rely on raffle.
As a side note, I notice that you are using node.js 11+ features, like optional offset in Buffer.writeUInt32BE(), and since @type.node is asking for a version 13.x, maybe you want to update node.js badge to increase the required version?

I'm good with the use of RateLimiter. As for the add_to_db part, I'd like to keep the original implementation. I believe there should be a higher limit (at least two gifts from the same room) to be considered eligible for adding to the db.  At that, I want to keep the original implementation of FixedGuardMonitor too. Its add_to_db simply serves to update the timestamp of a room.

https://github.com/Billyzou0741326/bilibili-live-monitor-ts/blob/5258cac652286d98537404aa29fb79255f7565b2/src/client/tcp-client.ts#L101
Indeed I forgot to specify the offset, I meant to use the one compatible for 10.x.x

k, updated

Great, thank you


POD - Add categories

add ability to add one or more categories to each episode/item.

...and send Jenny the test feed for the Scene.

Done


SARIF output fixes.

Use relative path for URIs.
Fix description/summary stability (due to map insertion order not being preserved), and sort by <ECOSYSTEM> < <GHSA> < <CVE> for extracting descriptions.
Remove an extraneous period.

Sample report: https://github.com/oliverchang/osv-fork/security/code-scanning/53

Codecov Report

Merging #547 (efee4c9) into main (5971841) will increase coverage by 0.07%.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #547      +/-   ##
==========================================
+ Coverage   78.36%   78.43%   +0.07%
==========================================
  Files          77       77
  Lines        5251     5269      +18
==========================================
+ Hits         4115     4133      +18
  Misses        971      971
  Partials      165      165

Files Changed
Coverage Δ

internal/output/identifiers.go
100.00% <100.00%> (ø)

internal/output/sarif.go
91.24% <100.00%> (+0.47%)
:arrow_up:

I can't see the sample report because I think the code scanning tab is only visible to maintainers.

I can't see the sample report because I think the code scanning tab is only visible to maintainers.

Added a screenshot to the description.

Hmm about changing to relative file paths, this does not work for outputs where we only have absolute paths (e.g. the example in fixtures/test-vuln-result-a.sarif), it is not a valid uri, which is why I changed it to always be an absolute path.
It seems like GitHub does support absolute paths: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#specifying-the-root-for-source-files

Yeah, but it didn't work for us :/
Even GitHub recommends using relative paths: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#physicallocation-object
I think for absolute paths to work, invocation.workingDirectory.uri has to be set: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#run-object
Should we just scope this SARIF support explicitly to GitHub for now? Trying to make this work more generally seems pretty complicated, because I'm not sure what path we'd set in other environments (or we'll have to get the user to provide their own).

A quick solution for now is to do the stripGithubWorkspace function, then check if the resulting path is still an absolute path, if it is, add the file:// in, otherwise, just put the relative path in. This should make it be valid for most cases, while still working on github actions (if whoever is running it don't check the repo out to a custom location).

Hmm about changing to relative file paths, this does not work for outputs where we only have absolute paths (e.g. the example in fixtures/test-vuln-result-a.sarif), it is not a valid uri, which is why I changed it to always be an absolute path.
It seems like GitHub does support absolute paths: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#specifying-the-root-for-source-files

Yeah, but it didn't work for us :/
Even GitHub recommends using relative paths: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#physicallocation-object
I think for absolute paths to work, invocation.workingDirectory.uri has to be set: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#run-object
Should we just scope this SARIF support explicitly to GitHub for now? Trying to make this work more generally seems pretty complicated, because I'm not sure what path we'd set in other environments (or we'll have to get the user to provide their own).

A quick solution for now is to do the stripGithubWorkspace function, then check if the resulting path is still an absolute path, if it is, add the file:// in, otherwise, just put the relative path in. This should make it be valid for most cases, while still working on github actions (if whoever is running it don't check the repo out to a custom location).

Done!


Small fixes

Make LOG_LEVEL optional

Codecov Report

Merging #64 (6fa7f13) into master (e369868) will decrease coverage by 0.06%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master      #64      +/-   ##
==========================================
- Coverage   89.28%   89.22%   -0.07%
==========================================
  Files          65       65
  Lines        1307     1309       +2
==========================================
+ Hits         1167     1168       +1
- Misses        140      141       +1

Impacted Files
Coverage Δ

config/initializers/create_checks_worker.rb
84.61% <50.00%> (-6.30%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e369868...6fa7f13. Read the comment docs.


How to generate samples?

How to generate samples?

If you want to keep generating samples along the training process, just use the argument --dump_result. If you want to generate samples while testing trained models, you can simply fetch self.model.fake_img.

After generating samples along the training process, how to use visualize_training.py to create gif?

Taking CIFAR10 for example, use the command python visualize_training .py --h 32 --w 32 --c 3 --n 8 --output_file visualized_sample --train_dir train_dir/default-CIFAR10_lr_0.0001_update_G5_D1-20170101-194957

Thank you for your quick reply!


tag a release to include the wss fix?

I'm referring to this one: https://github.com/livereload/livereload-js/pull/29

I'd like to see a release that includes the wss fix, too.

Just released version 2.2.2.

Thank you!

Just released version 2.2.2

Where is this release? I see the commit e1d943628005ad8d18a50ee1e8c29858ca748d10, but it's doesn't show up on Bower because there's no tag.


brew cask support?

it'd be super nice to have brew cask support for this awesome app
https://github.com/Homebrew/homebrew-cask

It actually already exists from the original repo:
https://github.com/Homebrew/homebrew-cask/blob/master/Casks/glance.rb
Not sure if a new entry should be created, or just overwrite this file. Probably should use a new entry since file paths / package names have changed which would interfere with the brew's zap uninstaller, I believe.

Thank you!


Specify unit on the axis instead of in the title

Before:

After:

@tgrabiec looks good, but is ops the right unit for timeouts per seconds?

@tzach "ops" stands for operations per second. In the context of "read timeouts" it reflects how many read operations timeouted per second. I couldn't find a more specific unit.

@tgrabiec can we close this?

@amnonh What's the commit which fixes this?

@tgrabiec It's just been fixed gradualy for the last two years, for example:
33cc238c20aeb51e1f0c3d6be80f80bd952abd70
660ec837059ed9f042dfbaf98915da83b6028ba1

We should also drop the "per Second" from the title.


Changing mcpu option as power10

As compiler enabled mcpu option as power10, changing it from future.

GCC commit for reference : https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9913aa6fbc42eab81fc9599a7d4636de2f92c00b


OpenGov. Governance page. Search

As a user I want to be able to search through referendums
To do:

[ ] Search input
[ ] Filter by index, title

Figma link

Status verification: ⏳
What has been verified:

Search by id
Search by name
Switch between Networks
https://github.com/novasamatech/nova-spektr/issues/1905
Empty results
https://github.com/novasamatech/nova-spektr/issues/1906

Status verification: ✅


config for erlang:now() vs os:timestamp()

This relates to the issue mentioned here
https://github.com/SyncFree/antidote/issues/151
erlang:now() is a well known scalability bottleneck, which is what we are currently using for clock si
os:timestamp() should scale, but can go backwards which makes clock si unsafe (rare but possible)
This branch is a temporary fix allowing you to use one or the other through a define in antidote.hrl
Eventually this will be fixed by upgrading to a new version of erlang that has the new timekeeping.

Why not just always use os timestamp and add a check for clock going backwards?
					Marc

Le 1 déc. 2015 à 15:34, tcrain<EMAIL_ADDRESS>a écrit :
This relates to the issue mentioned here
#151 https://github.com/SyncFree/antidote/issues/151
erlang:now() is a well known scalability bottleneck, which is what we are currently using for clock si
os:timestamp() should scale, but can go backwards which makes clock si unsafe (rare but possible)
This branch is a temporary fix allowing you to use one or the other through a define in antidote.hrl
Eventually this will be fixed by upgrading to a new version of erlang that has the new timekeeping.
You can view, comment on, or merge this pull request online at:
https://github.com/SyncFree/antidote/pull/173 https://github.com/SyncFree/antidote/pull/173
Commit Summary
replace now with os:timestamp
Merge branch 'master' into timediff
added flag in antidote.hrl
File Changes
M include/antidote.hrl https://github.com/SyncFree/antidote/pull/173/files#diff-0 (4)
M src/clocksi_interactive_tx_coord_fsm.erl https://github.com/SyncFree/antidote/pull/173/files#diff-1 (6)
M src/clocksi_interactive_tx_coord_sup.erl https://github.com/SyncFree/antidote/pull/173/files#diff-2 (2)
M src/clocksi_readitem_fsm.erl https://github.com/SyncFree/antidote/pull/173/files#diff-3 (2)
M src/clocksi_static_tx_coord_sup.erl https://github.com/SyncFree/antidote/pull/173/files#diff-4 (2)
M src/clocksi_updateitem_fsm.erl https://github.com/SyncFree/antidote/pull/173/files#diff-5 (2)
M src/clocksi_vnode.erl https://github.com/SyncFree/antidote/pull/173/files#diff-6 (8)
M src/dc_utilities.erl https://github.com/SyncFree/antidote/pull/173/files#diff-7 (15)
M src/inter_dc_repl_update.erl https://github.com/SyncFree/antidote/pull/173/files#diff-8 (2)
Patch Links:
https://github.com/SyncFree/antidote/pull/173.patch https://github.com/SyncFree/antidote/pull/173.patch
https://github.com/SyncFree/antidote/pull/173.diff https://github.com/SyncFree/antidote/pull/173.diff
—
Reply to this email directly or view it on GitHub https://github.com/SyncFree/antidote/pull/173.

Since the readers and writers are multi-threaded, then we would need an extra amount of state to share between them about what clock they have seen, putting an extra serialisation point either through messages or an ets table.  This is probably a perfectly acceptable solution and better than using erlang:now(), but I would guess that the new implementation of erlang's time module handles this much better at a lower level and it keeps the code cleaner, but this is all just speculation of course.

I would for the moment merge this patch, but suggest using the "safe" and correct, alas slow version as default.


Add ability to multi-select boundaries

Add ability to multi-select boundaries

@jedpittman @mcdonoughsh if it makes sense in the context of developing this functionality, I think it would be helpful to change the default order of the boundaries shown in the prototype. Specifically, something like the following (I mentioned in another thread to Jed that I think we should drop the two boundaries that start with BPDA):

Greater Mattapan Zoning Boundary
PLAN: Mattapan Boundary
Greater Mattapan Merged Boundary
Mattapan Square Boundary
Blue Hill Ave Boundary
Cummins Highway Boundary
Morton Street Boundary (to be added)
River Street Boundary

Thank you!

This has been closed by a merge request


Not moving forward after --'INFO: Device: realme RMX1971 (Android 10)'

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: [e.g. Debian, Windows, macOS...]
scrcpy version: [e.g. 1.12.1]
installation method: [e.g. manual build, apt, snap, brew, Windows release...]
device model:
Android version: [e.g. 10]

Describe the bug
A clear and concise description of what the bug is.
On errors, please provide the output of the console (and adb logcat if relevant).
Please paste terminal output in a code block.

Please do not post screenshots of your terminal, just post the content as text instead.

@rom1v  ..i can record my screen and  get saved file ...but not able to see display of my mobile in laptop

INFO: scrcpy 1.16 https://github.com/Genymobile/scrcpy
E:\zscreen\scrcpy-server: 1 file pushed, 0 skipped. 12.1 MB/s (33622 bytes in 0.003s)
[server] INFO: Device: realme RMX1971 (Android 10)
...after this ..there is no chage

after updating drivers it is working now


Added Combined Results Table. All tests passing

Added a combined Results table for Search All.
I'd still like to add an option for Search All with Separate Tables (as now) but I thought the diff was already getting a bit big.
I can remove/change the lovely Orange headings :-)

This relates to #28 but there is still a piece I'd like to add (flag for keeping separate tables)


Support for acyclic directed relationships

When defining a directed relationship on a StructuredNode class (i.e. RelationshipTo, RelationshipFrom) it would be nice to have the option to specify that the relationship should be acyclic.
As a use case, let's say we have the following class defined:
class Person(StructuredNode):
   ...
   parents = RelationshipTo('Person', 'PARENT')

The above StructuredNode class defines a Person with a relationship called parents.  In most cases, we would want to prevent a person from becoming their own ancestor. To accomplish this, we would need to ensure that each time a node is connected to a Person through the parents relationship, it won't create a cycle.
I've cloned the neomodel repository and taken an initial crack at the implementation (Raznic@d68f1174903879207763c19674b1da3c906a24f7). Before I submitted a pull request I wanted to see if there would be any interest in getting this feature back into the main project, or if there were any other suggestions for the feature.

Super made a comment on the commit. This is brilliant that you.

To overcome the race condition: can't you just check if the start.id and end.id are the same without any cypher query? Since you have self.id and node.id, you would just have to check if they are equal, right? Or am I missing something out?
Regards.

@croccam thanks for the input! That is one way to check when we create a relationship from a node back to itself. That is definitely an edge case and something I need to check for. I think in most use cases the nodes will be different, so the ID check wouldn't work for those instances. We would still need to run the Cypher query to see if there is currently a path from the end node back to the start. If so, adding a relationship from the start node to the end node would introduce a cycle. In order to overcome the race condition, I wrapped the check/relationship creation inside of a database transaction. However, I need to check if there is currently a transaction already taking place before starting a new one. Sorry for the lack of forward progress on this, hoping to make some movement on it this week.

My bad, I read it so fast that I misunderstood your original issue. I get it now, thanks for your answer. Transactions seem like a good solution. I would also be really interested on how to overcome the possible performance issues if there were too many long branches to check, maybe not for the parent use case, but for other use cases.

Yeah, I haven't tested against any large databases, so I'm not sure how it performs once you grow beyond a simple development instance. If you're aware of any place I could get my hands on some test data, let me know. I'd definitely be interested to see how it handles under load.

@Raznic Has there been any progress with this?
I think that it would be worth adding a Relationship parameter like prevent_loops but that would cover cycles of length zero only. Avoiding cycles would be a much more difficult check to perform at the level of neomodel.
The loop check can be performed on asserting that the start_node and end_node have different node ids.
Can you please let me know if that was the original intention?

Sorry for the delayed reply. So the original intention was to detect cycles of any length. The plan was to check if there was a path from the end_node to the start_node. If that path existed, then adding the relationship from start_node to end_node would create a cycle and the code would raise an exception. It was pretty simple to implement, but the part I got hung up on was how to do this in an atomic fashion. You would need to ensure that no new relationships can be added during the transaction of checking for the end_node to start_node path and creating the relationship. If you do, you may run in to a race condition that ends up creating a cycle.
Shortly after reaching this conundrum, the project that I was working on using nemodel switched over to a different database, so I never really swung back to complete this feature. If anyone wants to pick up development and finish this feature, they're more than welcome to take a look at the work I've already done on this branch. Just a heads up, I haven't merged with the official project in almost 2 years, so it's probably well out-of-date. Still, hopefully it can provide some insight on at least getting started.

@Raznic Thank you very much for coming back to us about this. Having worked on the problem of extracting the "cycle spectra" of a graph but in a different setting (basically, a histogram of the number of cycles of length n, with n being an integer), I can say that identifying ANY cycle within a dataset is an incredibly hard problem.
To make it tractable, we would have to limit n within a reasonable range and possibly make the check "eventual" by pushing it out to its own thread. It is not something that you can do in a few milliseconds.
In any case, I have included this as an "enhancement" and see how we can incorporate this aspect into neomodel later on.
All the best


Thread Exception: Only the original thread that created a view hierarchy can touch its views

Hi I am trying to run it on API 21, But in FrameAnalyser.kt line no 164  boundingBoxOverlay.invalidate() will through exception.
Please help me I am a beginner Thanks in advance.
E/AndroidRuntime: FATAL EXCEPTION: Thread-3
Process: com.example.facerecognition, PID: 12921
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7809)
at android.view.ViewRootImpl.invalidateChildInParent(ViewRootImpl.java:1338)
at android.view.ViewGroup.invalidateChild(ViewGroup.java:5446)
at android.view.View.invalidateInternal(View.java:14749)
at android.view.View.invalidate(View.java:14713)
at android.view.View.invalidate(View.java:14697)
at com.example.facerecognition.FrameAnalyser$analyze$1$1.run(FrameAnalyser.kt:150)
at java.lang.Thread.run(Thread.java:762)

@SarfarazAliToori, please check if the issue is resolved in the latest commit.

@SarfarazAliToori, please check if the issue is resolved in the latest commit.

@shubham0204 It does not work the project is going to crush. I don't know what's the problem.

@shubham0204 It does not work the project is going to crush. I don't know what's the problem.


Consider removing Internet Explorer support

Its official support is ending, so we could probably save a bit on Babel resource usage. This would technically be a breaking change though, not sure how we'd want to deal with that.

 This could be a good ~excuse~ reason to do so.

@nickmccurdy There's barely anything IE relevant in this codebase :)  Closest I can see looking at a build artifact is:
  for (var _len = arguments.length, funcs = new Array(_len), _key = 0; _key < _len; _key++) {
    funcs[_key] = arguments[_key];
  }

I agree it'd be nice to put out v5 at some point. My biggest questions are still around ecosystem compat with the types.

I'm mostly referring to how the Babel/browserslist config explicitly support IE in the build. Is that explicitly tested though?

Yeah, I'm just saying that Redux's code is so minimal, and it's so FP-oriented, that there's almost nothing in the current code that would matter for IE beyond a couple bits of ES6 syntax.  So, sure, we ought to remove that setting in the next major.  There just won't be much of a size difference because it's a small lib and there's only a couple tiny bits of syntax that would be affected.

That's fair. Would a draft PR to test dropping it help, or would you rather wait until the types are more ready?

Dead in the 5.0 alphas!


Support OPENJ9_SHA

OPENJ9_SHA is openj9 pull request sha and it is an optional value.
It is created to support openj9 PR builds.
In openj9 PR builds, upstream build will provide test build OPENJ9_SHA.
Signed-off-by: lanxia<EMAIL_ADDRESS>

Tests:

to make sure this change does not break existing build:
https://ci.adoptopenjdk.net/view/work in progress/job/TestBuild_Sandbox2/200
to make sure this change works with OPENJ9_SHA provided in openj9 Jenkins:
https://ci.eclipse.org/openj9/view/Test/job/Test-Sanity-Functional-JDK8-linux_390-64_cmprssptrs/25/
to make sure this change works without OPENJ9_SHA in openj9 Jenkins:
https://ci.eclipse.org/openj9/view/Test/job/Test-Sanity-Functional-JDK8-linux_390-64_cmprssptrs/26/


Add region_code to the client

I see I can retrieve the region name but not the region code.

@rodrigoaguilera Ok new version released v1.3.0


Add ADR 0005

Decision on how to structure file system for config.
Also a few tiny changes to remove warnings on other files and show <local-path> which was otherwise hidden in preview

ideally should put the preferred solution first


chore: webpack-bundle-analyzer to ^4.1.0

Fixes: #6091

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Underlying tools
[x] Other, please describe: upgrade dependency webpack-bundle-analyzer to ^4.1.0

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:

LGTM👍

LGTM 👍


Correct example placement in how-it-works.md

Switched links to examples for viewing commit history and issues so they are associated with the correct section.

bradyjoslin:patch-1

@bradyjoslin Sorry for the delay and thanks for this PR! Do you think you can rebase it please?

@AnandChowdhary - you're welcome! Rebase done.


chore(mk/run): use npx to execute netlify-cli

In order to use the netlify-cli without installing it globally we can use npx.
$ make run
netlify dev
bash: netlify: command not found
make: *** [run] Error 127

@johncowen can you merge pls? 🙂

Oh sorry 🤦 !


[WIP] Helm 3 Support

What this PR does / why we need it:
The current Helm chart doesn't work on Helm 3. This moves the custom resources definitions to the new crd folders for the Helm 3 breaking changes.
Special notes for your reviewer:
I'm not sure how to make this backwards-compatible with Helm 2 - if anyone knows how to query the Helm version from within a chart, we can make this backwards compatible too (Leave in original crds.yaml files and only run them on Helm 2).

@abrenneke thanks for the PR, but you need to sign the CLA. If you sign the CLA I will help you get this landed.

thanks @pmorie, I did sign it when I made this PR but there's some email mismatch I haven't had time to figure out yet

Hi @abrenneke, thank you for the inspiration, I have pushed your solution a bit further by maintaining the compatibility with Helm2. please see https://github.com/kubernetes-sigs/kubefed/pull/1189

Thanks @gregov!


[master] linux: copy defconfig on deploy stage

There were three problems with saving and copying the
defconfig in the configure phase:

the deploy directory may not exist by the time it's
copied, and
it was wrong in the first place to deploy anything in the
configure phase, and
DEPLOY_DIR_IMAGE should not be used in do_deploy, anyway.

This patch moves that whole operation to the deploy phase,
using the right DEPLOYDIR mechanism (sstate-safe).
Signed-off-by: Daniel Díaz<EMAIL_ADDRESS>

Same tonic as with the Morty pull request. This can be cherry-picked onto Pyro.


Refactors remove member functions

Ticket Link
Groupings-1243
List of squashed commits

Readded Jasmine testing to pom.xml
Removed prepBatchRemove()
Renamed multiRemovePromptModal -> multiRemoveModal and multiRemoveConfirmationModal -> multiRemoveResultModal
Renamed returnMemberObjectFromUserIdentifier -> returnMemberObject, changed it to take in listName instead of currentPage as parameter
Renamed handleMemberRemove() to handleSuccessfulRemove() to match handleSuccessfulAdd()
Changed $scope.sanitizer to take in either a string or array as the parameter then return a string or array depending on what was passed in; Removed its joiner functionality.
Depreciated $scope.manageOwners and replaced it with $scope.manageMembers.
Created functions $scope.createSuccessfulMultiRemoveModal() and $scope.closeSuccessfulMultiRemoveModal() that are called when the multi-removal is successful
Renamed removeOwners() in general.controller.js to removeOwnersWithTrashcan()
Renamed removeOwners() in groupings.service.js to removeOwnerships() to match addOwnerships()
Added and updated Jasmine tests, removed duplicate removeMember test in admin.controller.test.js

Test Checklist

[x] Unit Tests Passed:
[x] Jasmine Tests Passed:
[x] General Visual Inspection:

For the Codacy issues, I think we can ignore "Found fs.open with non literal argument at index 0." Other times Codacy has marked that issue as fixed when I push changes to this PR.

I think I remember making the $scope.sanitizer take a array of names so that we can loop through a list of user's or just one user instead of having to manually do it everytime we call that $scope.sanitizer since it's common to sanitize multiple users. I just wanted to confirm that the places where you removed the userToRemove is not broken.
Feel free to ask me more about that if you need help or have questions.

The $scope.sanitizer still maintains that functionality of looping through a list of users or a single user. It now has a new feature where it can accept a string as the input. All places where userToRemove (now memberToRemove) is removed are all functioning.


docs(LinuxCommand): add linux command grep

Description

a complete introduction to the command 'grep' is added to doc

[x] add basic usage format of command grep
[x] add arguments of command grep
[x] add considerations of command grep
[x] add typical examples of command grep
[x] add descriptions of command grep

Resolves: #41
How Has This Been Tested?

grep.md has passed local mdl test according to .markdownlint.json as rules
Types of changes

Documentation (non-breaking change which updates documentation)

Checklist:

[x] Code follows the code style of this project.
[x] Changes follow the CONTRIBUTING guidelines.
[x] Update necessary documentation accordingly.
[x] Lint and tests pass locally with the changes.
[x] Check issues and pull requests first. You don't want to duplicate effort.

@BobAnkh I am curious what is wrong with my pr and commit mesage. gitmagic pointed that there is sth. wrong with the titles but i cannot find.  some help is needed! onegai~

You missed a space after : :joy:

got it! that is so tricky😂

Still facing space problem :joy:
Don’t underestimate this space, it’s an important detail to help us get style consistency

@BobAnkh  finished fixing typo and suggestion in yesterday's review has been adopted！

my fault，i push the wrong version again😂i will correct this very soon

To be honest, as a first-timer, you actually did much greater than others :smile: Keep on moving!

If you are ready for review and resolve the problem I proposed, please reply to the review and resolve conversation, then comment to me

If you are ready for review and resolve the problem I proposed, please reply to the review and resolve conversation, then comment to me

I think it is time for reviewing! :D

I think it is time for reviewing! :D

If you are ready for review and resolve the problem I proposed, please reply to the review and resolve conversation, then comment to me

I think it is time for another reviewing! :D

Ok I will review it and please next time reply to the reveiw before resolve it to make sure you don't resolve it unintentionally

Great job! But still some things need to be changed
replying to the review is doing something like this,is it?

You are doing a great job!
I will merge it soon.

thanks! I will turn to investigating tool tree soon.

You should reply to that issue and then I will assign it to you


AnimationPlayer NodePath function arg grabs the wrong path

Godot version:
3.2
OS/device including version:
ArcoLinux
Issue description:
Attempting to assign a node path to a function arg in an animation.  The value is wrong in all cases,  as it seems to try to grab the path from the position of a node higher in the hierarchy.  A unique case occurs when attempting to target the immediate parent, and I'm not entirely sure how it manages to arrive at the path it does.

This is the result of attempting to get the path of the immediate parent of the AnimationPlayer (Activator).  When selecting the AnimationPlayer, or another node at its level, it simply refers to its own name (where it should be something like ../AnimationPlayer or ../CollisionShape2D).  Attempting to reference the TextBox results in the path AnimationPlayer/TextBox.
As you might expect, these paths make no sense from the perspective of AnimationPlayer, and so they always fail to find a node.

Fixed in 3.2 (the issue is from before stable)


how to change language

how to change language

Google Bard doesn't support multiple languages, you need to use translate API to translate the messages to another language