proposal: Go 2: support read-only and immutable values in Go

The full proposal is here: https://github.com/go101/immutable-value-proposal
Basically, this proposal can be viewed as a combination
of issue#6386
and issue#22876.
This proposal also has some similar ideas with
evaluation of read-only slices written by Russ.

Reading the proposal, I kind of like the idea of having final values, which are immutable var values. But I don't like the idea of having to annotate my function parameters with .reader and .writer everywhere. The compiler should be smart enough to the right thing without annotations.

The compiler should be smart enough to the right thing without annotations.

How to do it without any hints for compilers? I think there must be some hints for compilers to prevent some behaviors.
BTW, the syntax is :reader, not .reader, and there is not :writer.

I do think the :reader part is less necessary than the final part in Go.
Not supporting read-only package-level values in Go is a more acute problem.
Maybe this proposal can be simplified as final values are also reader values,
by discarding the `:reader" syntax part.

I think so, after all a final value is read only by definition. Please consider updating your proposal with this in mind.

It is not that simple. Final values are also reader values has its only drawbacks and problems. The complexity in the current one has its rationals. I will try to make a new one for final values are also reader values when I think it clearly.

Hi, author of proposal: Go 2: immutable type qualifier here!
First, I'm glad to hear people talk about this topic more and more! Go lacks important compiler-enforced safety features and while I can live without compile-time memory safety (O&B) - living without read-only types is dangerous. My proposal is currently on hold since I don't have much time investigating the const-poisoning problem which is a blocker and I hope you heard of it.
1. a final is immutable, except that it's not?!

Please note that, although a final itself can't be modified, the values referenced by the final might be modifiable. (Much like JavaScript const values and Java final values.)

 I'd even go as far as calling it an "anti-safety feature" because it's very misleading and error prone! It makes const x look like a constant, but when it's a reference or includes references - it's totally mutable. An object of type T is what it's made of, including member references, so if you're saying that x in final x T is immutable while its members like x.y are not - it's misleading and dangerous IMO.
I've gone the other way in my proposal: an immutable type makes all its members immutable, which make all their members immutable, recursively. If you see var x immut *T you'll know for sure that x won't be able to mutate any referenced memory, ever.
2. The more exceptions there are to a rule - the worse the rule is.

:reader is not allowed to appear in type declarations, except it shows up as function parameter and result roles.

IMO, in an imperative (non-functional) language mutability is a property of types, not a property of values. A type may reference a value but it can't protect it from other mutable types referencing it. Go is not a functional language, it can't guarantee value immutability (FP-style immutability can have significant performance impacts and would be unacceptable in case of Go), it can only protect memory from being mutated through certain references ultimatelly making the code easier to read and debug. The only immutable values in Go are constants, but those are primitive-types only for good reasons.
If immutability is a property of types, then why can't we make this rule universally applicable to all types without exceptions?
3. final and :reader imply transitive immutability, which is what I was initially trying to avoid for a reason.
The mechanism I proposed is very flexible, you can define immutable slices of immutable pointers to mutable values: var immut []* mut T, you can define mutable pointers to immutable values: var * immut T and so on. I don't see this possibility with final and :reader because they're applied to variables rather than types.
What happens, if the developers needs this kind of fine-grained control over what's mutable and what's not in a type-chain? Exactly, he/she will throw immutability out the window if it's too limiting and this is obviously not what we'd want to happen I suppose.
A safety-feature that covers only simple cases but fails to cover rather complex cases isn't a safety feature.
4. The :reader syntax doesn't look promising
Even if you make immutability a property of types it still doesn't particularly look very sexy IMHO:
// proposal 31464:
var x []:reader *:reader T:reader
var y []:reader * T:reader

// proposal 27975:
var x immut []*T
var y immut [] mut * immut T

// proposal 31464 (with MQP):
var x []*T:reader
var y []:reader *:writer T:reader

BTW, I called this feature Mutability Qualification Propagation, it reduces verbosity quite substantially.
P.S.
I apologize if I happened to misinterpret your proposal because I only had so much time to glance through it quickly.

immutable and read-only are different. An immutable can't be modified in any (safe) routines., but read-only values can. Final values themselves are immutables, but the values referenced by them might not. In fact, the values referenced by a final value might be a read-only value, an immutable value, a writable value, depend on how this final value is declared. An example:
var s = []int{1, 2, 3}
final x = []int{1, ,2 ,3} // the elements referenced by x are immutable
final y = s:reader        // the elements referenced by y are read-only (through y).
final z = s               // the elements referenced by z are writable (through z)

Please note the y example is like the one var x immut *T your mentioned in your proposal.
I agree JavaScript's const qualifier is bad, which is why I think final values need :reader values to cooperate to satisfy all kinds of needs.

IMO, in an imperative (non-functional) language mutability is a property of types, not a property of values.

I agree mutability is a property of types, but I think read-only is not. Instead, read-only is a mainly a property of values. As I have said in my proposal, Although roles are properties of values, to ease the syntax designs, we can think they are also properties of types.

If immutability is a property of types, then why can't we make this rule universally applicable to all types without exceptions?

The reason is the following notations are all invalid:
[]([]int:reader):reader
*(T:reader):reader
struct {
    x T:reader
}

// including the ones you made:
[]:reader *:reader T:reader
[]:reader * T:reader
[]:reader *:writer T:reader

A reader value represents a read-only value chain, so only one :reader is needed.

... which is what I was initially trying to avoid for a reason. The mechanism I proposed is very flexible, you can define immutable slices of immutable pointers to mutable values: var immut []* mut T, you can define mutable pointers to immutable values: var * immut T and so on

This is my proposal ties to avoid, for this brings much complexity and such needs are rare in practice.
And I;m some confused by your description. In your first example, var x immut *T, you say x won't be able to mutate any referenced memory, ever. So you mean var x immut *T is equivalent to var x immut * immut T, instead var x immut * mut T? If true, then no confusion for this now. In my opinion, the syntax is too verbose.

The :reader syntax doesn't look promising

Sorry, the following notations are invalid by my proposal.
// proposal 31464:
var x []:reader *:reader T:reader
var y []:reader * T:reader

they should be:
// proposal 31464:
var x []*T:reader
var y []*T:reader

And there is not a :writer notation, the following one is impossible by my proposal.
var y []:reader *:writer T:reader

There won't be any "real" immutability in Go because it's not a functional language, actual immutability can only be achieved in languages that don't support the assignment operator. Introducing immutability would imply introducing PDS (Persistent Data Structures) to improve performance, otherwise we might end up having to copy the hell out of every final.

Final values themselves are immutables, but the values referenced by them might not.

I'm strictly against such kind of magic, because it's misleading and error prone! It makes a variable look immutable, but it doesn't make it immutable because a variable value isn't just the address of the referenced data, it's the data itself (recursively).
var s = []int{1, 2, 3}
final z = s // the elements referenced by z are writable (through z)

Actual immutability is a nice concept (especially for application programming), it makes code readable and safe, but since Go is a general purpose non-FP language and does support assignments it's better to leave real immutability out of Go to keep it simple and consistent and stick to read-only types IMHO. This way you could, for example, write your own PDS libraries using read-only types (in combination with generics this could be great) but the language itself doesn't force you to follow any particular concept.
I refer to "immutable" when a value is referenced by read-only references exclusively and is thus virtually immutable (you can only modify it through unsafe pointers, but this is okay, we can't forbid people to shoot themselves in the foot, it's called "unsafe" for a reason). If you want to make a variable read-only then make it have a read-only type and use mut -> immut casting:
var s = []int{1, 2, 3}
var x = immut []int {1, 2 ,3} // the elements referenced by x are immutable
y := immut []int(s)           // the elements referenced by y are read-only (through y).
h := [] immut int(s)          // the elements are writable, but the slice is not.

IMO this is better, because it's much more readable, you can see what's mutable and what's not, you don't have to assume:
w := &T{}             // mutable
r := immut *T(w)      // write-protected (recursively)
v := immut * mut T(w) // address is read-only, but the underlying data is writable

I agree mutability is a property of types, but I think read-only is not. Instead, read-only is a mainly a property of values. As I have said in my proposal, Although roles are properties of values, to ease the syntax designs, we can think they are also properties of types.

Again, Go is a non-FP language, there won't be immutable values, because it's fundamentally imperative and supports assignment.  We can't make Go an FP language and we shouldn't try to make it  pseudo-FP. There won't be immutable values in Go.

This is what my proposal tries to avoid, for this brings much complexity and such needs are rare in practice.

That's where our opinions differ. I'd prefer a flexible tool, that could safe me in complex situations (but I'd still try to avoid complex situations as much as possible of course), rather than a toy, that's okay for 90% of cases but practically useless in the really difficult 10%, this ain't a safety feature then IMO.

And I'm some confused by your description. In your first example, var x immut *T, you say x won't be able to mutate any referenced memory, ever.

x is a read-only pointer to a read-only instance of T, that's correct because...

So you mean var x immut *T is equivalent to var x immut * immut T, instead var x immut * mut T? If true, then no confusion for this now. In my opinion, the syntax is too verbose.

This is called MQP (Mutability Qualification Propagation). MQP reduces verbosity, but gets rid of transitive qualifiers. It may not be obvious at the first glance but it's very simple: a mutability qualifier propagates to the right in a type chain, until it's canceled out by another qualifier:
// with MQP
var p immut *T
var m immut map[string][]string
var x immut [][] mut T

// without MQP
var p immut * immut T
var m immut map[immut string] immut [] immut string
var x immut [] immut [] T

Sorry, the following notations are invalid by my proposal.

I got that, that's why I explicitly stated: "Even if you make immutability a property of types it still doesn't particularly look very sexy IMHO:". But I should probably have written: "Even if you remove transitive qualification"

And there is not a :writer notation, the following one is impossible by my proposal.

I know, it was just a hypothetical example.

Again, Go is a non-FP language, there won't be immutable values, because it's fundamentally imperative and supports assignment.

Yes, we can use unsafe do many things to break the type system. The fact has already existed, so it is not a drawback of this proposal.
Imperative immutability is a real need of many Go programmers. It is very useful.
I think you have got it clearly what are differences between the two proposals. The main intention of my one is to keep the syntax simple and concepts clear, which stick to Go style.
Let's agree on what we agree and disagree on what we disagree. :)

Yes, we can use unsafe do many things to break the type system. The fact has already existed, so it is not a drawback of this proposal.

Sure, I just wanted to emphasize that in an imperative language where assignment is allowed - immutable values don't exist by nature. There may be read-only references and virtually immutable objects (referenced by read-only references exclusively), but no actually immutable values/memory.

Imperative immutability is a real need of many Go programmers. It is very useful.

I do absolutely agree. Makes code safer and APIs clearer. It does have some drawbacks like const-poisoning which I couldn't yet investigate but it's probably solvable.

I think you have got it clearly what are the differences between the two proposals.

feature
#31464
#27975

concept
final and :reader
immutable types

qualification
transitive qualification applied on variables
mixable qualification applied on types with MQP

immutable struct fields
no?
yes (immutable after initialization)

read-only methods
yes
yes

Those aren't all differences I suppose, but I didn't have the time to investigate it in full detail yet. Please correct me if there's something wrong/missing.

The main intention of my one is to keep both the syntax and concepts simple, which sticks to Go style.

Those are good intentions, but I disagree on the way you're trying to achieve them. IMO immutable/read-only types are easier and way more consistent than having two concepts final and :reader.
There's also some inconsistencies like:

We can't send values to final channels.
We can't receive values from final channels.

Why? we already have read-only channels in Go. Why do we need yet another variant?

Something to note:

MQP also applies to reader values.
fields of final structs are immutable struct fields.

Why? we already have read-only channels in Go. Why do we need yet another variant?

It is not a special rule. It is just a consistent general rule for all kinds of types in this proposal, it is channel direction unrelated. It is just that final values are not modifiable, whatever their types are. There are not no-directions channels, right? Final is a stronger property than single-direction.

MQP also applies to reader values.

What do you mean by that? MQP is necessary for mixed mutability type chains to reduce verbosity. If I understood correctly there's no mixed qualification with :reader but transitive qualification instead.

fields of final structs are immutable struct fields.

What I'm talking about is this:
type User struct {
  Name      immut string
  BirthDate immut *time.Time
  Devices   immut [] mut Device
}

u := U{
  Name:     "initial name",
  BirthDate: nil,
  Devices:   []Device{Device{Name: "initial name"}}
}

u.Name = "new name"                       // compile-time error!
u.Devices[0] = Device{Name: "new device"} // compile-time error!
u.Devices[0].Name = "new device name"     // OK

Final values themselves are immutables, but the values referenced by them might not.

If final only applies to the variable but not necessarily its referenced contents then why can't we read/write a final channel? A channel is just a reference to an internally shared thread-safe queue, it's a reference type. I'd rather assume that c in final c chan int is just not reassignable, but still writable/readable.

What do you mean by that? MQP is necessary for mixed mutability type chains to reduce verbosity.

OK, I misused it. It should be IMQP, immutability Qualification Propagation. :)

u.Devices[0].Name = "new device name"

I deliberately discarded the partial read-only/immutability feature. Please read the end of my proposal for details. This feature brings many confusions and complexities.

A channel is just a reference to an internally shared thread-safe queue. A channel is just a reference to an internally shared thread-safe queue, it's a reference type.

I don't like the reference type terminology. It brings many confusions. But here I use it for your convenience. It is true that a channel is just a reference to an internally shared thread-safe queue. Our dispute is that whether or not the internal queue should belong to the channel itself or to the value the channel references. I choose the former interpretation, you choose the latter. I think my choice is better. Not only do I think the internal queue should belong to the channel itself, the elements stored in the queue (or received from and sent to the channel) should also belong to the channel itself. That is it.

We should inspect channels in logic, not in the internal implementation. Channels are different to slices and maps.

Thanks for the detailed proposal.
The :reader and :writer syntax just isn't Go like.  There are no similar constructs in the language.
:reader and :writer seems to be used with both values and types, but it's not clear what that means.  I'm also unclear on whether a :reader type can only be assigned to another :reader type; that is, are these type qualifiers that must appear on all uses of the type?
It's not obvious to me how final works in a case like final sub = s[:5] where the backing array of the slice is shared with a mutable value.
The number of extra rules necessary to make this work, even assuming that it is complete, seems very large compared to the benefit to the rest of the language.
The problem area remains interesting to investigate, but we aren't going to adopt this proposal.

@ianlancetaylor
I think it is not a good idea to close this issue when there are so many questions you still have.
There is not the :writer notation in this proposal. It is welcome to suggest an alternative for the :reader syntax. The syntax is not the core of this proposal.

I'm also unclear on whether a :reader type can only be assigned to another :reader type; that is, are these type qualifiers that must appear on all uses of the type?

I don't very understand this question. Could you show an example to help me understand it?

The number of extra rules necessary to make this work, ...

I don't think the number of extra rules in this proposal is large. The rule set is quite small IMHO.

It's not obvious to me how final works in a case like final sub = s[:5] where the backing array of the slice is shared with a mutable value.

In fact, I have an alternative proposal which makes a little modification this one.
If you re-open this issue, I will post it. Otherwise, I will create a new issue to post it.

I will reopen this issue because you requested it.  But I want to be clear that I see no possibility of anything like this proposal being adopted for Go.  I asked questions not because the answers affect the decision for this proposal, but as pointers for future work in a different direction.
The :reader syntax may not be the core of the proposal but it seems that it will start to appear in many places in Go code.  That is also what I meant by the question about :reader as a type qualifier.  We do not want to adopt a proposal that will lead people to scatter annotations across all Go code, and will then lead them to remove those annotations as code changes.  This is the "const-poisoning" problem.

@beoran
I will submit a new proposal which only support reader and read-only values. Final values will be removed.
@romshark
I found a flaw in the current proposal version (v9.1) in channel rules.
// By the current rule, we can't send values to (or receive values from) c.
final c = make(chan int, 1)

// p is deduced as a reader value
var p = &c

// c1 is deduced as a reader value.
// By the current rule, we can send values to (or receive values from) c.
// It is broken!
var c1 = *p

In the next version (v9.a), the final value concept will be removed, also the related channel rules.
@ianlancetaylor
As some flaws are found in this current version (v9.1), and the difference between v9.1 and the next version v9.a is large. I will close this proposal and make a new one.

The new proposal is here: https://github.com/golang/go/issues/32245

@ianlancetaylor
Abut read-only-poisoning, I think it is really a problem, but it is not a serious problem.
There are benefits than drawbacks of read-only values.
There have already been many such poisoning alike situations,
for example, when the name of a parameter type is changed,
all the corresponding parameter type names in called functions must be also changed.
Read-only memory zone has negative impacts on run-time performance.


No Module named Compressor

Hola, I keep getting this errors:
File "", line 986, in _gcd_import
File "", line 969, in _find_and_load
File "", line 956, in _find_and_load_unlocked
ImportError: No module named 'compressor'

This is strange, did you see any error when you installed requirements.txt?
Can you activate your virtualenv, run this and paste it here?
``pip freeze | grep compressor


Data Science with Python :  Steps for Machine Learning "MLops "

Description
Description### Description
Welcome to 'DSWP' Team, good to see you here
a machine learning model go through more than one step, it does not just make a machine learning algorithm and turned the parameters there are important steps before this like data cleaning, preparation, visualizations, exploratory, normalization and, splitting for example
your task is to make a tutorial explaining how machine learning pipelines work
check this picture for more details

To get assigned to this issue, add your serial numbers mentioned in the spreadsheet of "Data Science with Python", the approach one would follow and choice you prefer (Documentation, Audio, Video). You can go with all three or any number of options you're interested to work on.
If you had referred any resources, add them up in "DS Resources". Similarly if you had used datasets, include them in "DS Datasets".
Domain: Machine Learning
Mentors Assigned : @Kareem-negm / @DhruvBajaj01
Points to Note :
The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Changes should be made inside the Datascience_With_Python/ directory & Datascience_With_Python branch.
Follow Contributing Guidelines & Code of Conduct before start Contributing.
This issue is only for 'GWOC' contributors of 'DSWP' domain.
All the best. Enjoy your open source journey ahead. 😎
Domain
Datascience with Python
Type of Contribution
Video, Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

Issue assigned to @Sera001 for documentation


FileNotFoundError: [Errno 2] No such file or directory: '/opt/ml/model/model.pth'

I am using my own model.pth file and I've followed the structure that is stated and uploaded it to an s3 bucket. However, when I run the inference ipynb file, all goes smoothly until remote_model.deploy. After around 20 minutes the following error message occurs:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\<USER>\AppData\Local\Programs\Python\Python38\lib\site-packages\sagemaker\model.py", line 524, in deploy
    self.sagemaker_session.endpoint_from_production_variants(
  File "C:\Users\<USER>\AppData\Local\Programs\Python\Python38\lib\site-packages\sagemaker\session.py", line 3193, in endpoint_from_production_variants
    return self.create_endpoint(endpoint_name=name, config_name=name, tags=tags, wait=wait)
  File "C:\Users\<USER>\AppData\Local\Programs\Python\Python38\lib\site-packages\sagemaker\session.py", line 2711, in create_endpoint
    self.wait_for_endpoint(endpoint_name)
  File "C:\Users\<USER>\AppData\Local\Programs\Python\Python38\lib\site-packages\sagemaker\session.py", line 2975, in wait_for_endpoint
    raise exceptions.UnexpectedStatusException(
sagemaker.exceptions.UnexpectedStatusException: Error hosting endpoint model-deploy: Failed. Reason:  The primary container for production variant AllTraffic did not pass the ping health check. Please check CloudWatch logs for this endpoint..

I checked the cloud logs which gave the following:
Traceback (most recent call last):
  File "/opt/conda/bin/torch-model-archiver", line 10, in <module>
    sys.exit(generate_model_archive())
  File "/opt/conda/lib/python3.6/site-packages/model_archiver/model_packaging.py", line 60, in generate_model_archive
    package_model(args, manifest=manifest)
  File "/opt/conda/lib/python3.6/site-packages/model_archiver/model_packaging.py", line 37, in package_model
    model_path = ModelExportUtils.copy_artifacts(model_name, **artifact_files)
  File "/opt/conda/lib/python3.6/site-packages/model_archiver/model_packaging_utils.py", line 150, in copy_artifacts
    shutil.copy(path, model_path)
  File "/opt/conda/lib/python3.6/shutil.py", line 245, in copy
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/opt/conda/lib/python3.6/shutil.py", line 120, in copyfile
    with open(src, 'rb') as fsrc:

AND
FileNotFoundError: [Errno 2] No such file or directory: '/opt/ml/model/model.pth'

Repeated over and over again. I'm not sure what is wrong here...

This initial error was mitigated through changing the framework_version in d2_inference.ipynb from "1.6.0" to "1.5.0" i.e.:
remote_model = PyTorchModel(
                     name = model_name,
                     model_data=model_url,
                     role=role,
                     sagemaker_session = sess,
                     entry_point="inference.py",
                     # image=image,
                     framework_version="1.6.0",
                     py_version='py3'
                    )

to
remote_model = PyTorchModel(
                     name = model_name,
                     model_data=model_url,
                     role=role,
                     sagemaker_session = sess,
                     entry_point="inference.py",
                     # image=image,
                     framework_version="1.5.0",
                     py_version='py3'
                    )

Still has an error with file Base-RCNN-FPN.yaml not found, because the folder structure in the instructions on the README (in the "Bring Your Own model.pth Workflow to Deploy" section), so I didn't include it. I'm testing it now with the included Base-RCNN-FPN.yaml and will get back to you on results with this new change

The endpoint is up and running, but invoking it gives the following issue:
ModelError: An error occurred (ModelError) when calling the InvokeEndpoint operation: Received server error (500) from model with message "local variable 'pred' referenced before assignment". See https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#logEventViewer:group=/aws/sagemaker/Endpoints/detectron2modelfinal-deploy in account<PHONE_NUMBER>68 for more information.

I have resolved this. It was an issue with my config.yaml file. So sorry about that!

Glad it worked out for you! :) Let me know if there are any documentation/pointers that you could've benefited more from :)

I don't know the details surrounding how to add this, but my initial error of No such file or directory: '/opt/ml/model/model.pth' was solved through changing:
remote_model = PyTorchModel(
                     name = model_name,
                     model_data=model_url,
                     role=role,
                     sagemaker_session = sess,
                     entry_point="inference.py",
                     # image=image,
                     framework_version="1.6.0",
                     py_version='py3'
                    )

to
remote_model = PyTorchModel(
                     name = model_name,
                     model_data=model_url,
                     role=role,
                     sagemaker_session = sess,
                     entry_point="inference.py",
                     # image=image,
                     framework_version="1.5.0",
                     py_version='py3'
                    )

i.e. setting the framework version to 1.5.0 rather than 1.6.0, which for some reason solved the problem. Other than that I think the documentation is fantastic!

Just remembered, also the model_url that you set for the s3 bucket apparently has to contain the keyword sagemaker, or else a new bucket is created? That's what happened to me anyway

I think changing the PyTorch version from 1.6.0 -> 1.5.0 may have been to comply with the training environment for when you trained your model -- can you double check your training environment's PyTorch version for me? Would love to clarify.
Regarding the keyword "sagemaker" being in the model_url S3 path, you are correct! The default permissions given to a SageMaker role only allows it to touch S3 buckets that have the keyword "sagemaker" in its name. I built this workflow with the principle of least privilege in mind, but good finding!

 I just checked and I did use PyTorch 1.5.0 so I know see why I would have gotten that error! Thanks so much!

If there was a kudos system for Github, I would 100% give you kudos or points or whatever : )

Haha thanks! Happy to help :)


add description property to a Feature

We are currently working on the devcontainer/features repository. In this repo I aim to auto-generate documentation given a feature's devcontainer-feature.json.  To store more metadata useful for a README, I hope to add a new, optional attribute called "description".
This property is already included in the features proposal

Merged with the features PR.


Running pod install for example project gives error

Running pod install for the example project give this error:
[!] Unable to satisfy the following requirements:

- `loudspeaker (from `../`)` required by `Podfile`
- `loudspeaker (from `../`)` required by `Podfile`
- `loudspeaker (= 0.1.2)` required by `Podfile.lock`

Fixed with commit https://github.com/amco/loudspeaker/commit/233f40d8e4e0eb66da9e10b290e8a422fef145d1 in PR https://github.com/amco/loudspeaker/pull/9.


Long YouTube songs begin playback from cached time after initial playback.

This is the same as when YouTube remembers your time in a song when you leave and come back. It's not expected behavior.
This only happens if the video is started on YouTube first and then played in Streamus

Doubt they'll ever fix this. :(


Manager rbac for taints

Issue #, if available:
Description of changes:
allow the manager clusterrole to create kubeadmconfigtemplates, required for reconciling taints.
Testing (if applicable):
directly modified the controller clusterrole to allow create and everything worked as expected.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm


Add github identity provider to ichqx89w realms

Describe the issue
Add GitHub  identity provider to ichqx89w  realms in dev, test, and prod.
Additional context
Add any other context, attachments or screenshots
Definition of done
Users using apps integrated with the ichqx89w  realm can login  using their GitHub account

Github Idp has been added please verify.


Don't report circularly referenced variables as being accessed

local t = {}
function t.func() print(t) end
t[t] = t

t should be reported as being unaccessed; the only accesses are circular references.

After this, the following case will still fail:
local t = {}
t[1], t[2] = t, t

I'm choosing not to support multiple assignment circular references; luacheck doesn't already track which of the rhs assignments provides the access to var, so far as I can tell, so it's not feasible to check.

Actually, in checking for that case, it looks like my current code possibly improperly improperly reports this as being unused:
local t = {}
function t.func() print(t) return 1 end
t[t] = t.func()

It handles metatables right, but it's not considering that functions can have side-effects.

Fixed the second issue ^^


Chore rexong update dg

Codecov Report
Base: 65.68% // Head: 65.86% // Increases project coverage by +0.17% :tada:

Coverage data is based on head (390e424) compared to base (2c4a902).
Patch coverage: 85.71% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #338      +/-   ##
============================================
+ Coverage     65.68%   65.86%   +0.17%
- Complexity      683      685       +2
============================================
  Files           113      113
  Lines          2244     2244
  Branches        256      256
============================================
+ Hits           1474     1478       +4
+ Misses          665      663       -2
+ Partials        105      103       -2

Impacted Files
Coverage Δ

...seedu/address/logic/commands/AddClientCommand.java
78.94% <85.71%> (ø)

...ddress/logic/parser/DeleteClientCommandParser.java
100.00% <0.00%> (+28.57%)
:arrow_up:

...dress/logic/parser/DeleteMeetingCommandParser.java
100.00% <0.00%> (+33.33%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


buildParamTypeDefinitions method takes up too much memory space when executing batch insertion of a large number of fields

Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it

There are more than 300 fields needed to do the batch insert. I'm looking for a more efficient way to do it. As I researched, bulk copy is a good way. But unfortunately, I have some fields whose type is datetime, bulk copy cannot be used for it. I can only do batch insert through the doExecutePreparedStatementBatch method in SQLServerPreparedStatement. As I monitor the JVM, I found that full GC is very frequent. The following code in the batch loop generates too many String and Char[] objects.
boolean hasNewTypeDefinitions = buildPreparedStrings(batchParam, false);
buildParamTypeDefinitions method in buildPreparedStrings generates exactly the same String value every time. Is it necessary to make this judgment every time? In the case of a large number of fields or data items, performance will be affected.
Describe the preferred solution

Is it possible to consider other ways to determine the variable hasNewTypeDefinitions? For example, compare the order of the Parameter[] array instead of directly generating String value.

Hi @CrazyJerryC, a quick look at the doExecutePreparedStatementBatch makes me think there is probably a more efficient than building the strings. The team is a little busy right now but I will try to squeeze in some time to look at this after the 9.5.0 Pre-Release.


Non-documented (critical) feature.

isTokenExpired() function has a critical undocumented (sorry for wrong title) optional parameter (time offset, in seconds) that, if ommited and the client is in any other timezone than GMT 0, will cause the function to return the wrong result.
Why not make it automatic (if no offset is passed) and use new Date().getTimezoneOffset() * 60 instead of assuming no offset?

Nevermind...


MM-17076 - fixed i18n message

Summary
I18N fix
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-17076

@reflog
Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Fetching origin
+++ Updating remotes done...
+++ Creating local branch automated-cherry-pick-of-#3228-upstream-release-5.14-1563975745
Branch 'automated-cherry-pick-of-#3228-upstream-release-5.14-1563975745' set up to track remote branch 'release-5.14' from 'upstream'.
+++ Downloading patch to /tmp/3228.patch (in case you need to do this again)

+++ About to attempt cherry pick of PR. To reattempt:
  $ git am -3 /tmp/3228.patch

Applying: fixed i18n message
Using index info to reconstruct a base tree...
M	i18n/en.json
Falling back to patching base and 3-way merge...
Auto-merging i18n/en.json
CONFLICT (content): Merge conflict in i18n/en.json
Patch failed at 0001 fixed i18n message
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

+++ Conflicts detected:

UU i18n/en.json

+++ Aborting in-progress git am.

+++ Returning you to the master branch and cleaning up.

@reflog Please cherry-pick the PR.

@amyblais already done!


Publish on Maven Central

Firstly thanks for this library!
For the last 24+ hours jitpack went down, which broke the build pipeline for apps using fingerprintjs-android.
Have you considered publishing on a more reputable repository such as Maven Central, instead of just jitpack?

Hey! Yes, that was a major outage. We have our own maven repository, we decided to migrate the library there after the holidays. I'll close the issue when it's completed.

@Alexey-Verkhovsky any update on maven publish?

@vikashprajapati not yet, we'll let you know here when it happens

Did you mean the holidays 2023 or 2024? 🤡

Hi, is publishing this library to Maven Central something this team is still open to? I would like to incorporate FingerprintJS into my SDK and not requiring downstream apps to add a Jitpack repository to their buildscript is a requirement.
In my experience, plugins like this make it fairly straightforward to publish to Maven Central, but I'm sure it's possible with the existing maven-publish plugin that this repo is already using.


When using a model, add_row doesn't populate row fields

Describe the bug
Using a model works fine when setting self.tabulator.data, but not when calling self.tabulator.add_row.
To Reproduce
This app is a modified version of the Tabulator example: https://anvil.works/build#clone:57OSEZIF52F47MED=EJIMR6LNBWQQ6DF5FZFB6MIC
It uses a model object instead of dicts (the model object is solely to test some ideas).  When run initially, the model object is queried and the row fields populated.
Clicking the Add Row button generates a model instance in the same way, but calls add_row to add it to the tabulator.  The fields are not populated initially, but if you click into them (e.g. the favorite color editor) the right value shows.
Expected behavior
I'd expect add_row with model objects to work the same way that setting self.tabulator.data does, populating the row fields with the values from the model object.

@jshaffstall - if you could check the development branch - it should work now.
I'll leave this on Dev for a bit before pushing to published... I imagine you might find a few more issues while you're hacking away.

Can confirm this works on development, both in the test app and the real one.  Will let you know if I run into anything else.


Installer and download links don't work when repository is specified with .git

On github, the canonical clone url for repository ends with .git (https://github.com/user/repo.git), while the canonical url for the web interface doesn't have .git (https://github.com/user/repo).
However, you still can clone repo with url without the .git and go to the web interface by url that has git.
This creases some confusion between those two, and with cargo book saying that "The repository field should be a URL to the source repository for your package.", it's not clear which url should be used. There are about 5.5k crates on crates.io that specify the repository url with .git and around 88k without.
However, you can't use .git url to create release urls, so specifying such a url makes cargo-dist create invalid urls in the downloads table and in the installers.

We should absolutely do this


[iLQR Refactor 1] Refactor the computation into separate files/functions

Splits up our iLQR implementation into

Problem definition (dynamics + cost)
Calculator which optimizes the problem and gives a trajectory output
Params struct

Not super happy with how long this PR is, but it's hard to do a partial refactor :/ Open to ideas if it's too long to review
This will be one of many refactors trying to clean up the implementation.

Closing as we are doing a different direction


Letsencrypt Failing to install

I used EE to set up my server and install a site. The site is live and working, however, I am getting the error below when I try and install letsencrypt.
Unable to setup, Let's Encrypt
Please make sure that your site is pointed to
same server on which you are running Let's Encrypt Client
 to allow it to verify the site automatically.

I run hostname on my Ubuntu server and it gives the correct hostname. Any idea what is going wrong?

I also got this error until I added: www to my cname record for the domain.
point it to host: @  ... basically you have to make sure www and non-www
points to your server. hope that helps
On Sat, Jan 9, 2016 at 2:28 PM, Deric Cain<EMAIL_ADDRESS>wrote:

I used EE to set up my server and install a site. The site is live and
working, however, I am getting the error below when I try and install
letsencrypt.
Unable to setup, Let's Encrypt
Please make sure that your site is pointed to
same server on which you are running Let's Encrypt Client
to allow it to verify the site automatically.
I run hostname on my Ubuntu server and it gives the correct hostname. Any
idea what is going wrong?
—
Reply to this email directly or view it on GitHub
https://github.com/EasyEngine/easyengine/issues/663.

Thanks for the reply! I tried that and still no luck. I made the change to the DNS last night and tried again this morning but still get the same error. Here is my DNS config:
dericcain.com. 1800 IN A <IP_ADDRESS>
dashboard.dericcain.com. 1800 IN A <IP_ADDRESS>
www.dericcain.com. 1800 IN A <IP_ADDRESS>

I also got this error until I added: www to my cname record for the domain.
point it to host: @  ... basically you have to make sure www and non-www
points to your server. hope that helps

Hii @dericcain
Could you please provide output of tail -n100 /var/log/ee/ee.log

I found some information that may help. I changed my webroot to be current instead of htdocs, so I created a symlink htdocs -> current. Reason being, I use Rocketeer for deployment and this is how it is setup. Here is the output:
2016-01-10 07:15:21,434 (DEBUG) ee : Command Output: Updating 684ff01..1182dcf
Fast-forward
 acme/.pylintrc                                     | 383 +++++++++++++++++++++
 acme/acme/challenges.py                            |   2 +-
 acme/acme/crypto_util.py                           |   2 +-
 acme/acme/messages.py                              |   4 +-
 bootstrap/_deb_common.sh                           |  48 ++-
 letsencrypt-apache/letsencrypt_apache/parser.py    |  71 +++-
 .../tests/apache-conf-files/apache-conf-test       |   3 +-
 .../letsencrypt_apache/tests/parser_test.py        |   2 +-
 tox.ini                                            |   2 +-
 9 files changed, 485 insertions(+), 32 deletions(-)
 create mode 100644 acme/.pylintrc
,
Command Error: From https://github.com/letsencrypt/letsencrypt
   684ff01..1182dcf  master     -> origin/master
 * [new branch]      earlier-renewal -> origin/earlier-renewal
   77ec944..3c70af7  non-interactive -> origin/non-interactive
   b1e67f2..3cddb15  pyopenssl  -> origin/pyopenssl

2016-01-10 07:15:21,434 (DEBUG) ee : Running command: ./letsencrypt-auto certonly --webroot -w /var/www/dericcain.com/htdocs/ -d dericcain.com -d www.dericcain.com --email<EMAIL_ADDRESS>--text --agree-tos
2016-01-10 07:15:34,445 (DEBUG) ee : Command Output: Updating letsencrypt and virtual environment dependencies......
Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot -w /var/www/dericcain.com/htdocs/ -d dericcain.com -d www.dericcain.com --email<EMAIL_ADDRESS>--text --agree-tos
,
Command Error: The webroot plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('/var/www/dericcain.com/htdocs/ does not exist or is not a directory',)

2016-01-10 07:15:34,446 (ERROR) ee : Unable to setup, Let's Encrypt
2016-01-10 07:15:34,447 (ERROR) ee : Please make sure that your site is pointed to
same server on which you are running Let's Encrypt Client
 to allow it to verify the site automatically.
2016-01-10 10:21:00,783 (DEBUG) ee : logging initialized for 'ee' using LoggingLogHandler
2016-01-10 10:21:01,062 (DEBUG) ee : ['/usr/local/bin/ee', 'site', 'update', 'dericcain.com', '--letsencrypt']
2016-01-10 10:21:01,062 (DEBUG) ee : collecting arguments/commands for <ee.cli.controllers.base.EEBaseController object at 0x7f69e2cf9f28>
2016-01-10 10:21:01,064 (DEBUG) ee : collecting arguments/commands for <ee.cli.plugins.site.EESiteController object at 0x7f69e2d08438>
2016-01-10 10:21:01,066 (DEBUG) ee : collecting arguments/commands for <ee.cli.plugins.site.EESiteUpdateController object at 0x7f69e2d08b38>
2016-01-10 10:21:01,070 (INFO) ee : Initializing EasyEngine Database
2016-01-10 10:21:01,080 (INFO) ee : Letsencrypt is currently in beta phase.
Do you wish to enable SSl now for dericcain.com?
2016-01-10 10:21:03,477 (DEBUG) ee : Changing directory to /opt/letsencrypt
2016-01-10 10:21:03,478 (DEBUG) ee : Running command: git pull
2016-01-10 10:21:03,840 (DEBUG) ee : Command Output: Updating 1182dcf..3cddb15
Fast-forward
 .travis.yml                         |  2 ++
 acme/acme/challenges.py             |  9 +++++++-
 acme/acme/challenges_test.py        |  4 ++--
 acme/acme/crypto_util.py            | 45 ++++++++++++++++++-------------------
 acme/acme/crypto_util_test.py       | 39 +++++++++++++++++++++++++++-----
 acme/acme/jose/json_util.py         |  4 ++--
 acme/acme/jose/json_util_test.py    |  4 ++--
 acme/acme/jose/jws.py               |  2 +-
 acme/acme/jose/jws_test.py          | 11 +++++----
 acme/acme/jose/util.py              | 31 ++++++++++++++++---------
 acme/acme/jose/util_test.py         | 21 +++++++++--------
 acme/acme/messages_test.py          |  4 ++--
 acme/acme/standalone_test.py        |  4 ++--
 acme/acme/test_util.py              | 16 +++++++++----
 acme/acme/testdata/cert-100sans.pem | 44 ++++++++++++++++++++++++++++++++++++
 acme/acme/testdata/cert-idnsans.pem | 30 +++++++++++++++++++++++++
 acme/acme/testdata/csr-100sans.pem  | 41 +++++++++++++++++++++++++++++++++
 acme/acme/testdata/csr-idnsans.pem  | 27 ++++++++++++++++++++++
 acme/setup.py                       |  5 +++--
 letsencrypt-apache/setup.py         |  1 +
 letsencrypt-nginx/setup.py          |  1 +
 letsencrypt/cli.py                  |  2 +-
 letsencrypt/client.py               |  4 ++--
 letsencrypt/crypto_util.py          |  2 +-
 letsencrypt/plugins/standalone.py   |  2 +-
 letsencrypt/renewer.py              |  2 +-
 letsencrypt/tests/cli_test.py       |  4 ++--
 letsencrypt/tests/client_test.py    |  6 ++---
 letsencrypt/tests/renewer_test.py   |  7 ++++--
 letsencrypt/tests/test_util.py      | 16 +++++++++----
 setup.py                            |  1 +
 tox.ini                             |  9 +++++++-
 32 files changed, 309 insertions(+), 91 deletions(-)
 create mode 100644 acme/acme/testdata/cert-100sans.pem
 create mode 100644 acme/acme/testdata/cert-idnsans.pem
 create mode 100644 acme/acme/testdata/csr-100sans.pem
 create mode 100644 acme/acme/testdata/csr-idnsans.pem
,
Command Error: From https://github.com/letsencrypt/letsencrypt
   1182dcf..3cddb15  master     -> origin/master

2016-01-10 10:21:03,841 (DEBUG) ee : Running command: ./letsencrypt-auto certonly --webroot -w /var/www/dericcain.com/htdocs/ -d dericcain.com -d www.dericcain.com --email<EMAIL_ADDRESS>--text --agree-tos
2016-01-10 10:21:19,205 (DEBUG) ee : Command Output: Updating letsencrypt and virtual environment dependencies......
Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot -w /var/www/dericcain.com/htdocs/ -d dericcain.com -d www.dericcain.com --email<EMAIL_ADDRESS>--text --agree-tos
IMPORTANT NOTES:
 - The following 'urn:acme:error:unauthorized' errors were reported by
   the server:

   Domains: dericcain.com, www.dericcain.com
   Error: The client lacks sufficient authorization
,
Command Error: Failed authorization procedure. dericcain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://dericcain.com/.well-known/acme-challenge/ADC6a5yg8s4IzxPhdgAOVQ0haUJy8fddBz8mrLYwjmo [<IP_ADDRESS>]: 404, www.dericcain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.dericcain.com/.well-known/acme-challenge/wXqkSGZwaoIZsa6IRE8QyKluEsY7Rcq-Ygulwg5iFCo [<IP_ADDRESS>]: 404

Okay, I got it to work. The trick is not to delete the webroot that EE creates. I deleted my site and recreated it and just changed the nginx config to point to the directory that I need it to point to, after installing the SSL, and everything works as it should.

There's another issue related to --le that can happen if you've added  --le to a site, then removed it or deleted the site and tried to recreate the site on the same server.  I'm opening another ticket as it may be a seperate issue from yours - though I have a feeling they're related.

If anyone else wants to know a workaround for this, just create a symlink that links the .well-known folder to the root folder of your site/application. This way letsencrypt can verify the site when it's not in the default folder that EE uses out of the box.

try with sudo command

Hi,
The same problemwhere:
  Domain: www.externatorainhadonaamelia.pt    Type:   connection    Detail: DNS problem: SERVFAIL looking up CAA for    www.externatorainhadonaamelia.pt

These can resolve the SERVERFAIL?
https://sslmate.com/caa/
And add a CAA record?

Ok
CAA records added
The problem is thesame...

And from DNS CAA Tester
Is OK

Any clue?!

Or i need add CAA record with www to?

Come on someone help out. Still need a fix for this.


Implement SIP 64 as non-experimental

For the new syntax of givens and context bounds, see the diffs in reference/syntax.md.

Who would like to gve this a review? It's all pretty straightforward. Biggest real changes are in the docs.

Playing a bit with the implementation, I noticed some details that I believe weren't clear from the spec:
Context bounds for type members
I love this feature but I wonder if it could be used to bring extension methods in scope too:
trait Serializable[T]:
  extension (x: T) def serialize: String

trait Base:
  type Elem: Serializable

def test0(b: Base) =
  summon[Serializable[b.Elem]] // ok
  b.serialize // error

Naming context bounds
I expected the as bounds on classes and traits to create public given members:
case class CC1[X: Serializable as s](x: X):
  type Elem = X

def test1(c: CC1[?]) =
  c.s // error
  summon[Serializable[c.Elem]] // error

Adding a public alias isn't enough to have it summon-able like in the context bounds for type members example above:
case class CC2[X: Serializable as s](x: X):
  type Elem = X
  given s1: Serializable[Elem] = s

def test2(c: CC2[?]) =
  c.s1 // ok
  summon[Serializable[c.Elem]] // error

Even if we directly extend from a trait defining a context bound for a type member, I guess because of dealiasing:
case class CC3[X: Serializable](x: X) extends Base:
  type Elem = X

def test3(c: CC3[?]) =
  summon[Serializable[c.Elem]] // error
  val b: Base = c
  summon[Serializable[b.Elem]] // ok

Ultimately, I wish member selection worked as well for regular type bounds than context bounds:
case class Foo[T <: Serializer](x: T)
Foo(1).serialize
// vs
case class Foo[T: Serializable](x: T) // maybe with `as s` so I still have the ability to not retain a reference to the typeclass instance
Foo(1).serialize

I don't see a clear path to get there so this is more food for thought than a PR review.

@smarter I think these additions would be good to have as feature requests.


Fix(kclvm-runner): fix linker bug.

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[ ] N
[x] Y

issue #225
2. What is the scope of this PR (e.g. component or file name):
kclvm-runner
3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

[x] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Other

add "-Wl, -w" to clang arguments.
4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

[x] N
[ ] Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

[ ] Unit test
[x] Integration test
[ ] Benchmark (add benchmark stats below)
[ ] Manual test (add detailed scripts or steps below)
[ ] Other

6. Release note

Please refer to Release Notes Language Style Guide to write a quality release note.
None

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1131 unchanged lines in 17 files lost coverage.
Overall coverage decreased (-1.0%) to 58.846%

Files with Coverage Reduction
New Missed Lines
%

kclvm/3rdparty/rustc_span/src/source_map.rs
1
27.95%

kclvm/ast/src/ast.rs
1
93.6%

kclvm/ast/src/token_stream.rs
1
78.57%

kclvm/runner/src/assembler.rs
1
97.86%

kclvm/sema/src/ty/into.rs
1
78.33%

kclvm/compiler/src/codegen/llvm/module.rs
3
89.29%

kclvm/parser/src/parser/tests.rs
3
96.14%

kclvm/parser/src/lexer/mod.rs
4
80.18%

kclvm/sema/src/ty/unify.rs
7
93.91%

kclvm/sema/src/ty/mod.rs
35
66.02%

Totals

Change from base Build<PHONE_NUMBER>:
-1.0%

Covered Lines:
21092

Relevant Lines:
35843

💛  - Coveralls


Added example for CPP Dll useage

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[X] Other, please describe:

This is basically an example of using tauri within a dll library (windows).
So that the webview is generated / run from within the dll.
The idea being you can run / call the dll from an existing C / C++ project for interop with the project.
Does this PR introduce a breaking change?
Nope

Really, really interesting!

I was hoping to use this method to write a freecad extension which normally uses python / dll's normally written in c++
the idea being to write a rust / tarui dll library that could be loaded instead.

Amazing

Let me know if anything else needs changing

Ok made some more changes, let me know if you spot anything else

Maybe the example could also show how to interop with C code?

Maybe the example could also show how to interop with C code?

It may be different based on which platform you're using which might complicate things.
(which is why I did it in rust as that has a lot of polish / abstracts away the implementation)
Typically in real life you'd probably use something like https://github.com/eqrion/cbindgen
or https://github.com/rust-lang/rust-bindgen or https://cxx.rs/ for the interop to generate the needed headers
But basically all you're doing from the C side is calling a function in a dll or shared library.


Properly destruct everything on App destructor

Some memory leaks are left, needs fixing. Should exit gracefully with no ASAN leaks after Autobahn and tons of various testing.
App destructor should clean everything up, except for some things attached to the Loop which should destruct in Loop destructor

Autobahn leaves one leak in both SSL and non-SSL:
SSL:
=================================================================
==15622==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 31 byte(s) in 1 object(s) allocated from:
    #0 0x7ff831b1a458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x559037e8228c in __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /usr/include/c++/7/ext/new_allocator.h:111
    #2 0x559037e7b096 in std::allocator_traits<std::allocator<char> >::allocate(std::allocator<char>&, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:436
    #3 0x559037e74c7a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long) /usr/include/c++/7/bits/basic_string.tcc:153
    #4 0x559037e7a996 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) /usr/include/c++/7/bits/basic_string.tcc:317
    #5 0x559037e748dc in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned long) /usr/include/c++/7/bits/basic_string.tcc:370
    #6 0x559037e70484 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const*, unsigned long) /usr/include/c++/7/bits/basic_string.h:1235
    #7 0x559037e78b75 in uWS::AsyncSocket<true>::write(char const*, int, bool, int) ../src/AsyncSocket.h:179
    #8 0x559037e80965 in uWS::AsyncSocket<true>::uncork(char const*, int, bool) ../src/AsyncSocket.h:202
    #9 0x559037e80f75 in _ZZN3uWS16WebSocketContextILb1ELb1EE4initEvENKUlPT_PciE0_clI13us_ssl_socketEEDaS3_S4_i ../src/WebSocketContext.h:264
    #10 0x559037e8e064 in _ZZN3uWS16WebSocketContextILb1ELb1EE4initEvENUlPT_PciE0_4_FUNI13us_ssl_socketEEDTcldtdeLPv0EonclscOS3_fp_scOS4_fp0_scOifp1_EES3_S4_i ../src/WebSocketContext.h:250
    #11 0x559037ea6972 in ssl_on_data ../uSockets/src/ssl.c:219
    #12 0x559037ea7a65 in us_internal_dispatch_ready_poll ../uSockets/src/loop.c:218
    #13 0x559037ea4f88 in us_loop_run ../uSockets/src/eventing/epoll.c:49
    #14 0x559037e6c111 in uWS::Loop::run() ../src/Loop.h:133
    #15 0x559037e6c125 in uWS::run() ../src/Loop.h:145
    #16 0x559037e740ae in uWS::TemplatedApp<true>::run() ../src/App.h:256
    #17 0x559037e64fcb in main ../misc/main.cpp:68
    #18 0x7ff8305abb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: 31 byte(s) leaked in 1 allocation(s).

non-SSL:
=================================================================
==21981==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 31 byte(s) in 1 object(s) allocated from:
    #0 0x7fe028b0b458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x55d145794ee6 in __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /usr/include/c++/7/ext/new_allocator.h:111
    #2 0x55d14578de4c in std::allocator_traits<std::allocator<char> >::allocate(std::allocator<char>&, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:436
    #3 0x55d145787c7a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long) /usr/include/c++/7/bits/basic_string.tcc:153
    #4 0x55d14578d74c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) /usr/include/c++/7/bits/basic_string.tcc:317
    #5 0x55d1457878dc in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned long) /usr/include/c++/7/bits/basic_string.tcc:370
    #6 0x55d145783484 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const*, unsigned long) /usr/include/c++/7/bits/basic_string.h:1235
    #7 0x55d14578b8a2 in uWS::AsyncSocket<false>::write(char const*, int, bool, int) ../src/AsyncSocket.h:179
    #8 0x55d1457936e3 in uWS::AsyncSocket<false>::uncork(char const*, int, bool) ../src/AsyncSocket.h:202
    #9 0x55d145793bcf in _ZZN3uWS16WebSocketContextILb0ELb1EE4initEvENKUlPT_PciE0_clI9us_socketEEDaS3_S4_i ../src/WebSocketContext.h:264
    #10 0x55d1457a0cb0 in _ZZN3uWS16WebSocketContextILb0ELb1EE4initEvENUlPT_PciE0_4_FUNI9us_socketEEDTcldtdeLPv0EonclscOS3_fp_scOS4_fp0_scOifp1_EES3_S4_i ../src/WebSocketContext.h:250
    #11 0x55d1457ba6b1 in us_internal_dispatch_ready_poll ../uSockets/src/loop.c:218
    #12 0x55d1457b7bd4 in us_loop_run ../uSockets/src/eventing/epoll.c:49
    #13 0x55d14577f111 in uWS::Loop::run() ../src/Loop.h:133
    #14 0x55d14577f125 in uWS::run() ../src/Loop.h:145
    #15 0x55d1457870ae in uWS::TemplatedApp<false>::run() ../src/App.h:256
    #16 0x55d145777fcb in main ../misc/main.cpp:68
    #17 0x7fe02759cb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: 31 byte(s) leaked in 1 allocation(s).

Triggered by test 5.15, something wrong with uncorking websockets

This is a bug in the corking logic of AsyncSocket. If uncorking a closed socket, it should not try and send anything but simply reset the cork buffer. This makes it pass entire Autobahn with no leaks and clean exit.

Seems to be completely fixed for now


ares: init at 125.1

Motivation for this change
Newer Higan fork.
Semi-depends on https://github.com/NixOS/nixpkgs/pull/145199/commits/86630d9a5fbcecf04178e2d1f110f075ff3f8763 from #145199
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@SuperSandro2000 Done.
Went ahead and merged the other commit into the first to keep things clean.

thanks.
@Madouura please rebase on master to solve the merge conflict.

ares v126 has been released.

@ofborg eval

@SuperSandro2000 Could you reevaluate it?
The error doesn't seem to be on the PR's side.

I think you need to rebase the PR on master to fix the check.


add other summary cohorts

e.g. UK10K: ftp://ngs.sanger.ac.uk/production/uk10k/UK10K_COHORT/REL-2012-06-02/
this will make max_aaf_all more powerful for whole-genome studies.

Is it a VCF with frequencies? I can't open the link

It is. VT decompose then we do something like
gemini annotate -f UK10K_COHORT.20140722.sites.VT.confint.vcf.gz -o min,min,min -t float,float,float -e AF,AF_lowCI,AF_upCI -c UK10K_AF,UK10K_AF_lowCI,UK10K_AF_upCI $INPUTPROJECT.VT.VEP.db

I hear two WGS databases of ~20k samples each are coming out soonish.


ENH:  Added ability to redirect to external pages

Added a config variable to specify redirects.
An Example:-
If in lecture-python, _config.yml file
redirects:
        heavy_tails:
          "url" : "file:///Users/u6533564/Documents/Office/Quantecon/lecture-python-intro/lectures/_build/html/heavy_tails.html"
          "redirect_text": "This page has been redirected from intro/heavy_tails.html"

Then, the page at heavy_tails in lecture-python will be redirected to the target URL,  with information about where it is redirected from and the content in the URL. Like:-
 ?redirected_from=/Users/u6533564/Documents/Office/Quantecon/lecture-python.myst/lectures/_build/html/heavy_tails.html&content=This page has been redirected from intro/heavy_tails.html
The target page, on detecting the variables in the URL, displays the following admonition:

thanks @AakashGfude I will take a closer look at this soon.
So this detects incoming redirect and would display the admonition for any traffic coming from the old location?

So this detects incoming redirect and would display the admonition for any traffic coming from the old location?

Yes, that's right @mmcky.


API Gateway domain security policy set to TLS_1_2

  - id: API_GW_DOMAIN_SECURITY_POLICY_TLS1_2
    message: API Gateway domain name must use TLS 1.2
    resource: aws_api_gateway_domain_name
    severity: FAILURE
    assertions:
      - key: security_policy
        op: eq
        value: "TLS_1_2"
    tags:
      - api_gateway


Fixed issue #441

Description
Fixed issue #441
Fixes #441
Type of change

Bug fix (non-breaking change which fixes an issue)
Documentation update

Testing steps
N/A

Codecov Report

Merging #480 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #480   +/-   ##
=======================================
  Coverage   80.56%   80.56%
=======================================
  Files          15       15
  Lines        1636     1636
=======================================
  Hits         1318     1318
  Misses        221      221
  Partials       97       97

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 1ea0e1a...34444bd. Read the comment docs.


Add liquidate_sim method to Sim Controller

Summary of Changes

Refactor the simulated liquidation logic into a liquidate_sim function. Currently, the simulated liquidation logic (which mints the necessary token to the liquidator) is contained in the after_trades method.

Tests
Passing, except for those which require the data files.

Just run python scripts/download_prices_data.py then can get the data files~

Passing, except for those which require the data files.


[Android] Elevation inside a FlatList doesn't work

Is this a bug report?
Yes

Have you read the Contributing Guidelines?
Yes
Environment

Environment:
OS:  macOS Sierra 10.12.6
Node:  8.6.0
Yarn:  1.1.0
npm:  5.4.2
Watchman:  4.9.0
Xcode:  Xcode 9.0 Build version 9A235
Android Studio:  2.3 AI-162.3871768
Packages: (wanted => installed)
react: 16.0.0-beta.5 => 16.0.0-beta.5
react-native: 0.49.1 => 0.49.1
Target Platform: Android 8.0.0/7.0.0
Steps to Reproduce

Having a shadow inside a flat list(in footerComponent, headerComponent, emptyListComponent and Item) using elevation for android shows nothing, while using shadow props for iOS works perfectly.
Expected Behavior

There should be a shadow in android.
Actual Behavior
No shadow is shown.

Reproducible Demo

renderItem = ({ item }) => {
    return (
        <View style={{
            shadowColor: '#000',
            shadowOffset: { width: 0, height: 2 },
            shadowOpacity: 0.1,
            shadowRadius: 1.5,
            elevation: 3,
            borderWidth: 1,
            borderColor: '#ccc',
            flex: 1,
            height: 42,
            backgroundColor: '#fff',
        }} />
    );
}

render() {
    return (
        <FlatList
            data={this.props.data}
            keyExtractor={item => item.id}
            renderItem={this.renderItem}
        />
    );
}

https://facebook.github.io/react-native/docs/shadow-props.html shadow props are only for iOS. Ran into the same issue.

Shadow is for iOS but the elevation should draw a shadow, right?

elevation: 3,

@nim23 I am using shadow props for iOS and elevation for Android, which normally should add a shadow to the view I am applying it on.

@am-een can u try this?
const StyleElements = () => (
  <ScrollView style={styles.container} contentContainerStyle={styles.content}>
    <View elevation={3}>
      <View style={styles.cardContent}>
        <Text>{'Hola'}</Text>
      </View>
    </View>
  </ScrollView>
);

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'white',
  },
  content: {
    flex: 1,
    paddingHorizontal: 20,
    paddingTop: 10,
  },
  cardContent: {
    alignItems: 'center',
    justifyContent: 'center',
    alignSelf: 'stretch',
    height: 200,
  },
});

elevation can be applied as a View prop as well.

I upgraded react-native and it looks like it has been fixed in the rn-0.50.2
Closing issue.

give margin to renderItem View...


ci: Package using yarn v3

This change should unblock the deployment on master. We've been using npm to package and deploy (via vsce) because its yarn support is limited to v1.
This has been fine until one of our dependencies (@appland/scanner) added a dependency via GitHub, causing npm list --prod to fail during packaging. yarn handles this case without failure, but rolling the version back is not an option because it'll break our ability to link to other projects also using yarn v3.
The solution here was to switch vsce to package with yarn, using a shim to translate the v3 output back down to the expected v1 output. This appears to be working fine.
This PR has many yarn.lock, .yarn/releases changes so reviewing commit by commit is advised. The actual amount of changes that are not automatically generated is low.

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

v0.44.1
GitHub release

Your semantic-release bot :package::rocket:


Rename "ExecutionPlan" as "SiddhiApp"

As we discussed on last review meeting. Shall we do $subject ?

@suhothayan


Organize ORT Community Day

Organize in March a 1 day day for the ORT community to come together to discuss:

User issues
New features of improvements
Improvements to ORT community ways of working

Created below doodle for people to register interest and indicate which dates would work for the in March.
https://doodle.com/meeting/participate/id/aQkqE0qd

As FOSS Backstage is happening March 13-14, 2023, in Berlin anyway, maybe it makes sense to put our community day adjacent to it, like on Wednesday, Match 15?

Voting on doodle will close Monday February 20th any time on earth.

Can we have a remote option for the Community Day ?

Agenda ideas:

@heliocastro to demo new orthw script rewritten in Python
Hack on initial Bazel support

I can offer to present
a) the ORT-use in our current setup and
b) the outlook for an overall Open Source Management setup and ORTs role in it

Furthermore I would appreciate if we can have a slot to discuss the homepage and fix concrete next steps.

Per ORT community meeting with the ORT community day will be March 15 - 16 in Berlin

Hi Thomas, concerning the venue: shall we do it in the IoT campus or at your site. If we could fix this, then I would appreciate if we could have a landing page somewhere with date and preliminary agenda, that we could spread the news using such a link to that landing page. What do you think?

@mkurzman I send you an email to discuss venue and already set up a landing page where people can RSVP.

The ORT Community Day is a wrap! Thank you all, it was a pleasure!


#8415: Prevent the database password from being exported along with the dashboards

CATEGORY
Choose one

[x] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY
During export, ehre is a check now if the field is named 'password' and it's not exported if so.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API
[x] Fixes #8415

REVIEWERS

Reopening to trigger Travis CI

@villebro it's nested in: datasources -> __SqlaTable__ -> database -> __Database__ -> password, and it's the same password that is used provided when connecting to the new datasource, which is later replaced with XXX... in sqlalchemy_uri

Codecov Report

Merging #8416 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #8416      +/-   ##
==========================================
+ Coverage   67.61%   67.61%   +<.01%
==========================================
  Files         448      448
  Lines       22482    22486       +4
  Branches     2364     2364
==========================================
+ Hits        15201    15204       +3
- Misses       7143     7144       +1
  Partials      138      138

Impacted Files
Coverage Δ

superset/utils/core.py
88.55% <100%> (ø)
:arrow_up:

superset/common/query_object.py
50% <0%> (ø)
:arrow_up:

superset/db_engine_specs/bigquery.py
53.52% <0%> (+1.28%)
:arrow_up:

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 1e533db...58fc4ca. Read the comment docs.

I'm still not able to reproduce this; can you provide any additional context on how this comes about? I only see "database_id", but no nested database object. If you create a new dashboard, does it still export the password? Wondering if this is a remnant from some old version..

@villebro you're right, it's not occurring for newly created dashboards. I was previously working on version 0.29 and it's possible that I was using this version, while I've noticed exposed password, as I'm not able to reproduce it for the newest version. Although, can we keep this check to ensure it won't be exposed to other cases/configurations?


The Twitter sign in dialogue asks for too many things.

We don't need to read or post tweets on behalf of the user. Maybe we should fix this on Twitter's developer website? (Don't add read/write permissions there?)

I changed the app on Twitter's developer site to read-only. (screenshot below)
I think it's much better, but @EditDojo still needs to be able to post (write) tweets. But it turns out, tokens generated BEFORE changing the permission settings still have the same permissions. So, we can just keep using the same tokens to write tweets. If ever we need to refresh the tokens in the future, maybe we can temporarily change the permission settings, recreate tokens, and then change the settings back? lol


Setup prettier

@mfix22 @nicolaskruchten
@tarzzz @shannonlal @kndungu
I've noticed that prettier has an option to ignore files without a pragma (see this commit for an example of how it works).
I've also added husky to setup a git hook, so that prettier runs automatically before a git commit.
If you all are happy with this incremental approach, let's merge this PR.
Closes #475

I would be more in favour of running it over a larger/complete set of files early on, otherwise it will make PR reviews in the future more challenging as we will have "ran prettier" interspersed with other commits...

💯
It's about time 🎆
Suggestion: Consider adding "arrowParens": "always" to the Prettier config
Will turn
const addOne = param => param + 1

To
const addOne = (param) => param + 1

@kndungu I can't believe I've missed that option! Of course, I'll add it.

@nicolaskruchten @kndungu @tarzzz Let's be pragmatic about the temporary use of pragmas. I'm not going to run prettier on the whole code base just before an on-prem release.
The benefit of having DawnLabs' contributions formatted right away outweighs the nuisance of adding a pragma.

Since you asked for my feedback, I gave it: I favour the all or nothing
approach, whether your consider that pragmatic or not. That said, my
opinion doesn’t count any more than anyone else’s here: if others feel it’s
an improvement then let’s do it.
On Thu, Jul 5, 2018 at 16:31 Nicolas Riesco<EMAIL_ADDRESS>wrote:

@nicolaskruchten https://github.com/nicolaskruchten @kndungu
https://github.com/kndungu @tarzzz https://github.com/tarzzz Let's be
pragmatic about the temporary use of pragmas. I'm not going to run
prettier on the whole code base just before an on-prem release.
The benefit of having DawnLabs' contributions formatted right away
outweighs the nuisance of adding a pragma.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/plotly/falcon-sql-client/pull/482#issuecomment-402843835,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbA5q5gLGvjYkZZ6BPhvoXCBCHLGKGks5uDneKgaJpZM4VEOHS
.

@mfix22 You see most people but me want to run prettier on the whole code base. I will do that after the on-prem release, but if you want to be able to use prettier with your contributions before, I'll merge this PR now, so that you can do so.

I'm closing since there is no interest in merging before the onprem release.


feat(optimizer): distinct agg.

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
PLEASE DO NOT LEAVE THIS EMPTY !!!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
I add DistinctAgg rule to transform distinct aggregates according to Eric's comment.

How does this PR work? Need a brief introduction for the changed logic (optional)

Describe clearly one logical change and avoid lazy messages (optional)

Describe any limitations of the current code (optional)
Because the backend implementation of selective aggregates is still in progress, no e2e test can be added now.

Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
The rule will convert pattern agg -> input to pattern agg -> agg -> expand -> input.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Plan change.

Refer to a related PR or issue link (optional)
related #3589

Try this case select count(*) as cnt, count(distinct v2) from t.
Make sure that when t is an empty table, cnt can return 0.
By the way, what's the difference between AggKind::COUNT and AggKind::ROW_COUNT.

Try this case select count(*) as cnt, count(distinct v2) from t.
Make sure that when t is an empty table, cnt can return 0.

Because selective aggregates is not fully supported, I can't add e2e tests now and just planner test is available. I will add this test when selective aggregates is ready.

By the way, what's the difference between AggKind::COUNT and AggKind::ROW_COUNT.

IIUC, AggKind::COUNT is used to denote normal count(e.g. count(v1), while AggKind::ROW_COUNT was used to denote special count(i.e. count()).  But we do not use AggKind::ROW_COUNT to denote count() anymore(AggKind::COUNT with zero argument instead). cc @skyzh

As sync'ed offline, the following special cases will be handled in upcoming PR:

count returns 0 rather than null in https://github.com/singularity-data/risingwave/issues/3717#issuecomment-1178597987
agg0(distinct) and agg1(order by) cannot be in the same query.


Fix Fortran result values

The result declaration in Fortran defines the name of the result variable, not the type. The result type is not necessarily c_int, either. The value returned is an enum.
The hipfort bindings for hipsolver handles this correctly, so this this change is to define the hipsolver API return types in the same way that hipfort does.

Well, I clearly did this wrong. That's what I get for trying to be lazy about this. I bought a Fortran book. I suppose this afternoon I'll read it. Converting to draft.

The result type is not necessarily c_int, either. The value returned is an enum.

@EdDAzevedo discussed this a bit. I figured I'd share some of what I've learned.
GCC defines the compatible type for enums in Structures, Unions, Enumerations, and Bit-fields:

Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int. If -fshort-enums is specified, then if there are negative values it is the first of signed char, short and int that can represent all the values, otherwise it is the first of unsigned char, unsigned short and unsigned int that can represent all the values.

This means that hipSOLVER enums on Linux are compatible with unsigned int. Fortran does not have unsigned integers, but on all supported platforms, int and unsigned int are bitwise-identical in the range [0, INT_MAX]. So, there should be no problem as long as we don't use any enum values exceeding that.
On Windows, it seems that enums are of type int. The MSVC guide on C enumeration declarations states:

In ANSI C, the expressions that define the value of an enumerator constant always have int type. That means the storage associated with an enumeration variable is the storage required for a single int value.

I don't think any of this affects anything of importance. Just leaving it here for posterity.

It will be a while before the CI is in a passing state.


Request for ROS2 branch. Already depolyed cartograher_ros on turtlebot, ros2 crystal.

Hi all
I have been successfully depolyed cartographer_ros on both turtlebot2 and turtlebot3, based on https://github.com/ROBOTIS-GIT/cartographer.
Thereby, I request for ros2 branch to share my code :).
Thanks a lot!

See here for a new discussion on ROS2: https://github.com/cartographer-project/cartographer_ros/issues/1536
Closing this one.


Fixes crash when encountering QED keyword during error recovery

Fixes #60
Turns out calling std::vector<T>.pop_back() on an empty vector is undefined behavior. In this case, it manifested as the vector size being set to -1 and thus set to the largest possible value size_t, so later attempts to serialize that vector of the entire memory of the computer did not succeed. Yet another reason to love C++!


Shader hot-reloading in WGPU example

This is the the test a did 1-2 weeks ago on hot-reloading of shaders, haven't had time to continue on it but do think we should clean it up and get it in to the all the example runners
It does have a problem with spirv-builder where that somehow causes every iteration in cargo-watch to rebuild core and everything, it seems like.  I did test before to not have the spriv-builder build path at all and just load .spv directly from the target folder and that worked flawlessly when iterating, could potentially disable the spriv-builder path when one has the hot-reload feature enabled as it is not needed then

https://github.com/EmbarkStudios/rust-gpu/pull/423 does the same thing as this and isn't a draft, so closing this!


Add link to Athenaion - similar to AoC but for math and stats

Has problems in statistics, geometry, calculus, physics and more general puzzles.
Problem descriptions seem similar to Advent of Code, just not a calendar format.

Summary by CodeRabbit

New Features

Added a new resource link for "The Athenaion" in the "Other Challenges" section of the README.

Thanks!


Alternative config format(s)

Not a priority at all but:

Oops. I didn't realize that clicking would submit my vote, so I voted for TOML. I've never heard of TOML and JSON is fine, in my opinion :D

I don't mind TOML until it gets to the nested arrays, that gets pretty unintuitive unless you specify it like this which looks weird IMO
name = "api"
description = "Some API for whatever"

[hooks]

build = "make build"
clean = "make clean"

[environment]

FOO = "here"
BAR = "here"

[cors]

allowed_origins = ["example.com"]
allowed_methods = ["GET"]
max_age = 123123

[lambda]

memory = 1024
timeout = 5

[dns]

zones = [
  {
    name = "apex.sh",
    records = [
      {
        name = "blog.apex.sh",
        type = "CNAME",
        ttl = 300,
        value = ["......."]
      }
    ]
  }
]

could see YAML getting unwieldy too, maybe need to re-shape some of the config to suit these better later
name: "api"
description: "Some API for whatever"

hooks:
  build: "make build"
  clean: "make clean"

environment:
  FOO: "here"
  BAR: "here"

cors:
  allowed_origins: ["example.com"]
  allowed_methods: ["GET"]
  max_age: 123123

lambda:
  memory: 1024
  timeout: 5

dns:
  zones:
    - name: "apex.sh"
      records:
        - name: "blog.apex.sh"
          type: "CNAME"
          ttl: 300
          value: ["...."]

shit I forgot one, markdown! https://github.com/tj/mdconf

Voted for JSON. Yaml is next best alternative. Your markdown conf is third simply because it looks cool 😆

Voted for HCL. My only experience with it is with terraform, but it's the best config format I've tried so far. So much better than CL's yaml or json files both when reading and writing

I like HCL too, great for arrays, I haven't tried it outside of TF yet, not sure if you can specify root-level vars? That might be a bit of a deal breaker for me

I think this is the way they're handle in terraform: https://github.com/hashicorp/hcl/blob/master/test-fixtures/decode_tf_variable.hcl

ah bummer

@tj nevermind that, it actually supports top-level variables and looks actually pretty good.
name = "api"
description = "Some API for whatever"

hooks {
  build = "make build"
  clean = "make clean"
}

environment {
  FOO = "here"
  BAR = "here"
}

Made a quick gist to show what it would look like if you want to test: https://gist.github.com/olivoil/1348a7e78db264c5e6ca876140fb1948

sickkkk

will the files be compossible? mixing general config options w/ ENV secrets feels odd to me
(i'd want to be able to gitignore any ENV)

I like the second option for DNS with singular names and maps with the name as the key, it feels more idiomatic after working with TF.
HCL doesn't have any built-in mechanism to include other files by itself, but it shouldn't be too hard to implement. It could be something like environment = "${file(secret.json)}" like TF does, or reading all files in a config folder maybe and you could just add the one you don't want to commit to .gitignore

@harlow .environment is just for non-secret env vars, secrets will need an alternative, but since Lambda env vars are immutable (shipped w/ the Lambda) having up env set .. etc won't work unless I roll my own on top of KMS (totally feasible). Opened an issue for it #90

Something that allows comments (i.e not JSON)

Agree with @nitely - the fact that you can't add comments to JSON is a major drawback.  I can live with the picky syntax and too much quoting, just about...  so I'd like YAML (preferably the StrictYAML subset).
TOML would be OK but isn't as readable as YAML - StrictYAML simplifies YAML making it easier to parse, while still solving some problems with TOML.

Heard of JSON5? It's like JSON, less strict and can handle comments. :boom:


Redesign in Kafka tests

I didn't change functionality, but I did some changes in the tests.
There are less connections/disconnections to Kafka. CDI container is running during all the execution of the tests.

I have run this 1944 times and there were no issues.
Previously, I was able to find an issue after running it 370 times.


Formatting in links is silently deleted

For example running vmd over this:
[`code`](link)
[**bold**](link)
[*italic*](link)

Results in this:
[](link) [](link) [](link)

I realize this and will fix it shortly. It hadn't come up because there has so far been no formatting in the void-docs repository. I don't see why code blocks would be used inside a link, but that's more of an editing decision.

I fixed this. Thank you for testing.


Azure cli shows some of SecureString parameters in plain text

Describe the bug
Input parameters of type @secured in bicep template are accepted, but some of the secure string are displayed in plain text in the logs.
To Reproduce

Define a bicep template for e.g. Azure Container App with secured parameters. For example:

  @secure()
  param storePassword string
  @secure()
  param clientSecret string
   ...

Deploy the template with Azure CLI:

  az deployment group create \
    -g my-resource-group \
    -n my-container-app \
    --template-file my-container-app.bicep \
    --parameters storePassword=$STORE_PASSWORD\
    --parameters clientSecret=$CLIENT_SECRET \
    ...
   --debug

Then some of the secured parameters such as clientSecret are displayed in the logs.
DEBUG: cli.knack.cli: Command arguments: ['deployment', 'group', 'create', '-g', 'my-resource-group', '-n', 'my-container-app', '--template-file', 'my-container-app.bicep', '--parameters', 'storePassword=[MASKED]', '--parameters', 'clientSecret=plain text of secret','--debug']

Expected behavior
All secured string should be masked as follows:
DEBUG: cli.knack.cli: Command arguments: ['deployment', 'group', 'create', '-g', 'my-resource-group', '-n', 'my-container-app', '--template-file', 'my-container-app.bicep', '--parameters', 'storePassword=[MASKED]', '--parameters', 'clientSecret=[MASKED]','--debug']
Environment summary
Azure CLI version 2.42.0 and 2.44.1
Additional context
The values of variables such as $STORE_PASSWORD or $CLIENT_SECRET come from gitlab ci/cd variables or from azure through azure cli. The plain text of secured string can also be displayed in other log statements such as:
DEBUG: cli.azure.cli.core.sdk.policies: Request body:
DEBUG: cli.azure.cli.core.sdk.policies: {"properties" .....

@zhoxing-ms for awareness

Hi @zhoxing-ms, Are there any updates about this issue? Do you need further information?

Hi @zhoxing-ms , I just found that there is a small difference between version 2.42.0 and 2.44.1. For parameter values comming from azure cli (i.e. the value is retrieved from our azure environment through Azure CLI), it will always be displayed in plain text though the parameter is defined as a @secure() string. For parameter values from our Gitlab CI/CD variables, it occurs only in the version 2.42.0.
Are there any further update regarding this?

The masking, which is displayed as [MASKED] should be enabled from Gitlab CI/CD variables. Despite this the value of secured string/object should not be displayed in the logs according to the documentation here:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/data-types#secure-strings-and-objects


Fix GeoJSON syntax

Purpose
Fix syntax error in GeoJSON file that prevented the "where we are" map from loading/previewing correctly. (the page would infinitely appear to load when previewing the file from github)
Summary of changes

Fixed missing bracket that prevented map from loading
Made indentation more consistent (IDE auto-reformat)

Thanks for looking into this! But there's still a bracket mismatch - the { at line 276 needs a friend.

there's still a bracket mismatch - the { at line 276 needs a friend.

I have to confess I'm not seeing the reported mismatch when using the new version on this branch... odd.
I tried the following things:

Counted braces to check for mismatch (67 opening brackets/ 67 closing brackets)
Confirmed that file serializes to and from valid JSON, and previewing it now gives a map
Ran a copy through jshint and jsonlint syntax checkers (old file version failed with errors, new one passes)

Whoops, right you are - I was looking at the wrong branch. Thanks for this!


Problem with AccountId type

Keep receiving the following error:
failed to fetch block Error: createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec<Extrinsic>"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(Call):: Call: failed decoding session.setKeys:: Struct: failed on args: {"keys":"Keys","proof":"Bytes"}:: decodeU8a: failed at 0x64ddfc9ae90fce0966d382b6fe38930d… on keys: (AccountId,AccountId,AccountId,AccountId):: decodeU8a: failed at 0x0400…: AccountId:: Invalid AccountId provided, expected 32 bytes, found 2
Seems that the same problem was discussed in https://github.com/polkadot-js/apps/issues/6172

Hello @bgodlin!

what are you trying to accomplish?
what SDK version are you using?
What chain are you trying to connect to?

Hello @bgodlin!

what are you trying to accomplish?
what SDK version are you using?
What chain are you trying to connect to?

Index KILT network using Subquery to further apply business logic. As for the first goal, receive certain extrinsics and calculate the account's rewards.
All dependencies are in the corresponding branch.
Connecting wss://peregrine.kilt.io endpoint.

Index KILT network using Subquery to further apply business logic. As for the first goal, receive certain extrinsics and calculate the account's rewards.
All dependencies are in the corresponding branch.
Connecting wss://peregrine.kilt.io endpoint.

We are thinking more of APIs for mobile and other applications to interact with. Thus, we are trying to leverage the usage of the corresponding services such as Subquery or Subsquid.

The current blockchain runtime uses the new metadata structure, which renders type definitions obsolete. So I would suggest to not use this repo anymore, and rely solely on the runtime-injected types.

Sorry for the delay in answer - solved the issues by generating types based on a script https://github.com/polkadot-js/apps/blob/51835328db5f0eb90a9efcc7bf5510704a7ab279/packages/apps-config/src/api/spec/kilt.ts


repository 'https://github.com/unbalancedparentheses/yamerl.git/' not found

make stops on erro just after deps/thorerl
Cloning into '/***/dev/erlang/gut/deps/yamerl'...
remote: Repository not found.
fatal: repository 'https://github.com/unbalancedparentheses/yamerl.git/' not found
/bin/sh: line 0: cd: /***/dev/erlang/gut/deps/yamerl: No such file or directory
make: *** [/***/dev/erlang/gut/deps/yamerl] Error 1

I am migrating gut to go. It is easier to generate stand alone binaries.
For the moment I will not fix the erlang code.
El El dom, 3 may 2015 a las 22:42, Laurent Roger<EMAIL_ADDRESS>escribió:

make stops on erro just after deps/thorerl
Cloning into '//dev/erlang/gut/deps/yamerl'...
remote: Repository not found.
fatal: repository 'https://github.com/unbalancedparentheses/yamerl.git/' not found
/bin/sh: line 0: cd: //dev/erlang/gut/deps/yamerl: No such file or directory
make: *** [/***/dev/erlang/gut/deps/yamerl] Error 1
—
Reply to this email directly or view it on GitHub
https://github.com/unbalancedparentheses/gut/issues/108.

Also noticed this, and the dep_jsx line is missing "master", for future reference.

@essen and @lc3t35 I am migrating gut to go, I will check this when I finish. I love erlang, it is awesome for server side apps, but it is way easier to create clients/standalone executables with go. In 2 o 3 weeks I hope to have reimplemented in go.

resolved with #109

Cheers!

works fine now, just a warning from dialyzer
make
./rebar compile
==> ibrowse (compile)
rebar get-deps
==> jsx (get-deps)
rebar compile
==> jsx (compile)
 APP    jsxn.app.src
==> mixer (compile)
==> mixer (eunit)
  All 22 tests passed.
  Checking whether the PLT /Users/laurent/dev/erlang/gut/.gut.plt is up-to-date...
dialyzer: Could not find the PLT: /Users/laurent/dev/erlang/gut/.gut.plt
Use the options:
   --build_plt   to build a new PLT; or
   --add_to_plt  to add to an existing PLT

For example, use a command like the following:
   dialyzer --build_plt --apps erts kernel stdlib mnesia
Note that building a PLT such as the above may take 20 mins or so

If you later need information about other applications, say crypto,
you can extend the PLT by the command:
  dialyzer --add_to_plt --apps crypto
For applications that are not in Erlang/OTP use an absolute file name.

make[1]: *** [dialyzer] Error 1
./rebar compile
==> sync (compile)
./rebar compile
==> sync (compile)
 APP    colorerl.app.src
./rebar compile
==> sync (compile)
 APP    colorerl.app.src
./rebar compile
==> sync (compile)
 APP    thorerl.app.src
 APP    yamerl.app.src
 ERLC   gut.erl gut_cleanup.erl gut_commands.erl gut_compile.erl gut_config.erl gut_escriptize.erl gut_generators.erl gut_path.erl gut_port.erl gut_readme.erl gut_suffix.erl gut_sup.erl gut_utils.erl
 APP    gut.app.src

awesome. I am working on another project. As soon as I have some spare time next week it I will finish the migration to go.

make escript not good enough? :-)

@essen yes and no :v:. I want to make gut a general tool for any platform/language. I want to generate standalone binaries for any platform. go is awesome for that and it has the best cross compilations tools I known. I have checked haskell, ocaml and nim and could not find something as good as https://github.com/laher/goxc


False positive ng-mocks not in JIT

v13.0.0 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Add ViaPolling and Always matchers

@apoydence In addition to line comments (which I'll make soon), we're still supporting 1.6, so we probably can't use onpar yet.  Honestly, I'm not sure if expect is complicated enough to warrant using onpar, anyway.

I updated the commit that I hope address the concerns.

LGTM
When 1.8 comes out (or when onpar supports 1.6), we can revisit using it here.


feat(apps/pfod/tekton/configs/triggers): enable enterprise build for tidb on feature release branches

without plugins.
Signed-off-by: wuhuizuo<EMAIL_ADDRESS>

/approve


Fix Classification Relation is not relevant for Concepts

Coming from #1280

Collecting allowedEntitiesPatern from both sides and condition for rendering classifications when right side entity opened
commit 45b900f866a25282dc4760f67c9db34b2634bbe8

@adammertel should it be reopened related to discussion?