add swarm protocol code

Currently there does not exist a protocol code for Ethereum's Swarm content hashes (https://swarm-guide.readthedocs.io/en/latest/usage.html#bzz-url-schemes).
This makes it difficult to use multiaddr in Ethereum Improvement Proposal #1577 (https://github.com/ethereum/EIPs/pull/1577).

Is this a hash function or a transport protocol?

@stebalien Swarm is a content addressed store, just like ipfs.

Yes, but which parts need multicodecs for what. That is:

we have multicodecs for hash functions.
we have multicodecs for IPLD formats (eth, git, dagcbor, etc.)
we have multicodecs for protocols in multiaddrs (ip4, tcp, quic, etc.)

It looks like you need an IPLD format but I'm not sure.

We need a multiaddr protocol, so we can address, eg, /swarm/hash. The necessary hash functions are already in place.

To clarify, our end goal is to have a content field that can contain either a swarm hash or an IPFS hash (or other related content identifiers). If multiaddr isn't the appropriate way to do that, please let  us know.

We generally distinguish between names and addresses. Addresses generally tell you where to look for some resource (multiaddr), names generally tell you what resource to look for (peer ID, content ID).
So, a multiaddr in an ENS record would address some endpoint (network or otherwise), not a piece of content. To name a piece of content, you'd probably just want a free-form path. For example, /ipns/Qm..., /ipns/a.com, /ipfs/Qm.../path/to/file.txt, /ipld/.../path/to/data, etc.
(One of the motivations in switching away from using /ipfs/$PEER_ID in multiaddrs was to remove this ambiguity).

Is there a multiformat suitable for encoding an ipfs hash or path? Storing text isn't ideal due to the high cost of onchain storage.

It looks like multicodec might be suitable? Would it make sense to add ipfs and swarm multihash types to the public multicodec table?

@Stebalien can you take ownership of these issues for ENS?

I think what you're looking for here are CIDs. CIDs are (multicodec, multihash) tuples where the hash is the hash of the content and the codec indicates how one should interpret the content. We use this datastructure in IPLD to support arbitrary merkle-dag formats (e.g., ETH, git, etc.).

That sounds right. What's the value of the multicodec field, though? Or are you saying it's a multicodec type prefix, followed by multihash content? Isn't that what we're already proposing?

Okay, I see I misunderstood multicodec - it's only a prefix, the spec doesn't include the data.
We're already adding a field to ENS for content hashes; this discussion is trying  to determine what it will look like. I assume you're not saying we'd have to add another field in addition to that.
I am a little confused, though, because I don't see a multicodec value for IPFS content-hashes anywhere in the table. What value do CIDs used?

That sounds right. What's the value of the multicodec field, though? Or are you saying it's a multicodec type prefix, followed by multihash content? Isn't that what we're already proposing?

Yes. Well, specifically, it's: (<multibase>)<cid-version=1><content-multicodec><content-multihash>.

Okay, I see I misunderstood multicodec - it's only a prefix, the spec doesn't include the data.

Yes. Well, really, the term "multicodec" is a bit overloaded. It refers both to the codec itself and formats of the form <multicodec><data>. When I say multicodec, I almost always mean the codec, not formats of the form <multicodec><data>.

but we're already adding a field to ENS for content hashes; this discussion is trying to determine what it will look like.

Ah. Sorry, I thought multiaddr support in ENS was already a done deal (the EIP was merged). My point was that we could try to unify multiaddr and other paths into a master path spec if that were the case.
If not, and if you just need to be able to reference content, CIDs are the way to go.

I am a little confused, though, because I don't see a multicodec value for IPFS content-hashes anywhere in the table. What value do CIDs use?

TL;DR: There is no "IPFS" multicodec.

In a CID, the multicodec describes the data being referenced, not the CID itself.
The multicodec doesn't describe how or where to get the data. A CID describes the data, not where to find it.
We use multiple multicodecs and multiple data formats (DagPB, DagCBOR, Raw, etc.) in IPFS/IPLD. We also have support for Git, Ethereum, Bitcoin, etc.

So, how would this work for swarm? We'd define a new multicodec for swarm and then, in ENS, you'd use CIDs of the form <cid-version=1><swarm-multicodec><multihash> (where the multihash is a sha3 mutlihash).

Yes. Well, specifically, it's: ()<cid-version=1>.

Can we reasonably omit the multibase prefix if we specify it'll always be in binary format?

Ah. Sorry, I thought multiaddr support in ENS was already a done deal (the EIP was merged). My point was that we could try to unify multiaddr and other paths into a master path spec if that were the case.

It's merged, but still only a draft. I think we'd  rather harmonise now rather than deprecate later.

If not, and if you just need to be able to reference content, CIDs are the way to go.

I think that's what we want. Are you implying the existence of other, more flexible options, though?

In a CID, the multicodec describes the data being referenced, not the CID itself.
The multicodec doesn't describe how or where to get the data. A CID describes the data, not where to find it.

Hm, that seems like a  problem for this approach. We need to be able to look at the data in the ENS record and know which distributed storage system to query (and what identifier to use to query it); it sound like that's not going to be doable as-is, since the CID metadata doesn't describe the storage system, just the stored data?

Can we reasonably omit the multibase prefix if we specify it'll always be in binary format?

Yes, sort of. See: https://github.com/ipld/cid/pull/28
Basically, you can always turn a CID into text (well, the EIP doesn't have to specify how to do this but the CID spec does). However (while some may say otherwise...) there's no reason to waste the byte if the encoding can't be anything other than "raw bytes".

It's merged, but still only a draft. I think we'd rather harmonise now rather than deprecate later.

Got it.

I think that's what we want. Are you implying the existence of other, more flexible options, though?

Not at the moment, no. My point is that CIDs address content by hash and that's all. However, multiaddrs address network endpoints. If you need something that does both, CIDs won't cut it.

Hm, that seems like a problem for this approach.

So, in this case, it shouldn't actually be an issue. Given that you only support one data format, you can just say "if it's a swarm object, look it up in swarm".
More generally, I'd be careful about bundling content addressing with location addressing. For example, what if the same data is available through multiple storage systems? What if you need to migrate from one to another?
Really, you almost want something like a magnet/meta link. That is a CID along with some description of where the content might be found. I'm not familiar enough with ENS to give concrete suggestions but I'd consider a separate field with location hints. Alternatively, we could try to come up with some way to bundle location hints with a CID but I'm not really sure about the best way to do that (usually, I'd pass those hints along out-of-band, e.g., in a separate field).

So, in this case, it shouldn't actually be an issue. Given that you only support one data format, you can just say "if it's a swarm object, look it up in swarm".

That implies "and everything else should be looked up in IPFS", though, which isn't either very neutral or very extensible.

More generally, I'd be careful about bundling content addressing with location addressing. For example, what if the same data is available through multiple storage systems? What if you need to migrate from one to another?
Really, you almost want something like a magnet/meta link. That is a CID along with some description of where the content might be found. I'm not familiar enough with ENS to give concrete suggestions but I'd consider a separate field with location hints. Alternatively, we could try to come up with some way to bundle location hints with a CID but I'm not really sure about the best way to do that (usually, I'd pass those hints along out-of-band, e.g., in a separate field).

We want to store an identifier sufficient for the end user to fetch the content. While I recognise that "this is the content hash" is distinct from "and here is the system to look for it in", realistically due to different systems having different methods of hashing, chunking, and building trees, the chances of having the same content hash accessible in different systems seems low-to-nil.
I think it makes the most sense to combine content hash and location metadata together into a single identifier for that reason.
I'm afraid this still leaves me in the dark as to what the best solution is, however - everything proposed so far seems to have significant issues.

Is the plan to have multiple entries in ENS, one for each underlying "codec"? In this case, wouldn't referencing the same content in ipfs (codec 0x01a5) and swarm (if swarm codec was 0x0622) just two records comprising for example:

Not if one uses CIDs. You'd have one identifying the content and another hinting at where to find the content.
I guess you could also have multiple CIDs (for "alternative" versions of the content).

That implies "and everything else should be looked up in IPFS", though, which isn't either very neutral or very extensible.

Not really. An application wishing to resolve CIDs to data would use a pluggable (parallel and/or hierarchical) resolver. Ideally, it would have:

Type-specific resolvers for resolving:

Swarm blocks with Swarm.
Ethereum blocks.
Git objects with GitHub or GitLab.
etc...

General-purpose resolvers for resolving arbitrary blocks (e.g., IPFS's bitswap).

Now yes, the data exchange protocol IPFS uses (bitswap) can fetch arbitrary blocks, but that's just because it's a general-purpose data exchange protocol.
Really, the issue here is that CIDs are entirely neutral. They don't say anything about how the data should be retrieved (although this can sometimes be inferred from the type).

While I recognise that "this is the content hash" is distinct from "and here is the system to look for it in", realistically due to different systems having different methods of hashing, chunking, and building trees, the chances of having the same content hash accessible in different systems seems low-to-nil.

If Swarm gains traction, the chances are pretty high: go-ipfs will almost certainly get a plugin for resolving Swarm CIDs with Swarm. Once fetched, the data would be cached in the local IPFS datastore and made available over bitswap.
This is the entire point of IPLD (CIDs are a part of the IPLD spec): interoperability between merkledag systems.
However, I do agree that hints indicating where content can likely be found is important for performance. On the other hand, I'm still not convinced bundling location hints with content identity is a good idea.

and another hinting at where to find the content.

but that would be multiple "anothers" if there are multiple locations, right? (IPFS, Swarm...)

They don't say anything about how the data should be retrieved (although this can sometimes be inferred from the type).

Maybe this inference is enough for ENS?

but that would be multiple "anothers" if there are multiple locations, right? (IPFS, Swarm...)

We'd only need one field type. If ENS is like DNS, you'd repeat the field once per system. Alternatively, you could encode a list of systems.

Maybe this inference is enough for ENS as a case?

Maybe? For swarm, it should be.
Also, a "location" hint can always be added after the fact as a new (optional) field if that becomes an issue.

On the other hand, I'm still not convinced bundling location hints with content identity is a good idea.

On second thought, I can see a reason to bundle these if ENS supports multiple "alternative" records like DNS does. That is, can I have:
CONTENT=<swarm_content>
CONTENT=<something_else>
...

Where the client should pick the first supported data source? If so, then it make sense to bind these location hints to the records themselves (although I'm not sure what the best way to do this is).

If Swarm gains traction, the chances are pretty high: go-ipfs will almost certainly get a plugin for resolving Swarm CIDs with Swarm. Once fetched, the data would be cached in the local IPFS datastore and made available over bitswap.

If CIDs don't encode information on where to get content, what makes something a Swarm CID, and how does IPFS know how to fetch it from swarm?

Not if one uses CIDs. You'd have one identifying the content and another hinting at where to find the content.

How does a CID hint at where to find the content?
Also, if CIDs don't do that, then what's the purpose of storing a CID in ENS over just a multihash?

Swarm uses a custom merkledag format (Swarm-Hash?). CIDs pointing to swarm content would be .

I really think we must be talking at cross-purposes here.
As I understand it, your position is that identifiers should be purely content identifiers, and shouldn't integrate information about the location of that content. Is that correct?
But at the same time, you seem to be suggesting using metadata about the content identifiers, like what sort of hashing they use, to identify where to find the data.
This seems like it has the same effect as including hints about content location, but less reliably, since it's possible that there could be multiple storage locations for a single content hash.
What am I misunderstanding? Can you give a concrete example of what you think an ENS record pointing to a resource that can be either IPFS or Swarm would look like?

Sorry, one record/field identifying the content (with a CID) and one (or more) record(s)/field(s) indicating where content related to the ENS name can be found.

What do you mean "content related to the ENS name"? The goal isn't to store ENS information in Swarm or IPFS, it's to point to Swarm and IPFS resources from ENS.

CIDs tell you how to interpret the referenced merkledag. A bare multihash is sufficient to identify the content but it doesn't tell you if the content is just a raw binary object, a swarm merkletree, a git object, an ethereum block, etc.

So, what is the canonical format for an IPFS identifier, such as those that users enter into their browsers today? Is it a multihash, or a CID? Isn't any of this metadata stored with the actual IPFS object?

A multicodec has been added in https://github.com/multiformats/multicodec/pull/104 but it's not currently a "multiaddr" codec. However, given that multiaddrs are defined as <multicodec><value>..., we can always choose to redefine this later.


trigger 2.6.0 release

@getquill/maintainers
@fwbrasil
^^ who else should I tag?
Also the old release notes mentioned 2.6.0 snapshot so I proceeded with releasing 2.6.0 instead of 2.5.5. The 2.5.x build were broken somehow anyway.
I hope that the CHANGELOG is not automatically generated :) I obtained it using
curl -s 'https://api.github.com/repos/getquill/quill/pulls?state=closed&per_page=100' | jq -c '.[] | [.title, .url, .merged_at]'

and manually removed all the dependency bumps.

@juliano

thank you @letalvoj! you just need to mention @getquill/maintainers since it includes all maintainers. Looking at the changelog, it seems to include things that were in previous releases. For instance, this PR is from May 2, but the last release was on May 22.
We should look into automating the changelog, and even maybe automate the build to produce a release once a week

Oh, should be better now, sorry for the inconvenience. The PRs were ordered by the time of creation, not the time of merge. Fixed:
curl -s 'https://api.github.com/repos/getquill/quill/pulls?state=closed&per_page=100' | jq -c 'sort_by(.merged_at)[] | [.title, .url, .merged_at]' | grep -v '^\["Update' | tac

I took everything above trigger 2.5.0 release.

no worries at all, thanks for the contribution :)


npm Warn Error about package.json

Nice project, thanks for sharing with the community!
Not positive this is really an issue but having some problems and wanted to make sure.
When running "install npm" in project directory, get a warning:
"npm WARN package.json<EMAIL_ADDRESS>No repository field."
Is this a warning I should be concerned with or just an alert?
Thanks for your time.

Nothing to be concerned with. NPM puts warnings if things like a repo and a read me are not available because they are needed for the package page. PHP-Webkit has a package.json to load dependencies, set configuration, and for NW.js but is not in itself an NPM package. I haven't had time to maintain this project. But I update it with a repo when I get a chance. Until then there is no harm.

Good deal, thank much.


Added developer resources for Token-metadata-api

Added developer resources ( Discord channel, blog and youtube link) to the sidebar.
Fixes https://github.com/hirosystems/docs/issues/439

This branch is weird as the local changes are not reflected when this branch is pushed to remote. Hence closing this PR.


Merge changes from 'staging' to 'main' (PR #208)

Change Summary
Summarise your changes in points

This PR includes changes from staging PR: https://github.com/ujala-singh/github-repository-dispatch-receiver/pull/208"

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code refactoring (restructuring existing code without changing any functionality)
[ ] This change requires a documentation update

Documentation/Release Plan

Problem Statement doc
Feature documentation
Release plan

Testing Checklist
Changes tested on

[ ] development
[ ] production
[ ] MABL Tests Link (if any)
[ ] Successful Workflow Links (if any)

Hey @ujala-singh, your main branch PR has been automatically created. In order to merge the PR, Please test your changes on staging (pre-prod) and update the change summary and checks accordingly.


GCE health check does not pick up changes to pod readinessProbe

Importing this issue from https://github.com/kubernetes/kubernetes/issues/43773 as requested.
Kubernetes version (use kubectl version): 1.4.9
Environment:

Cloud provider or hardware configuration: GKE
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

What happened:
I created an ingress with type GCE
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: admin-proxy
  labels:
    name: admin-proxy
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
    - secretName: ingress-admin-proxy
  backend:
    serviceName: admin-proxy
    servicePort: 80

This set up the health-check on the google cloud backend endpoint to call "/" as documented.
Unfortunately my service doesn't return 200 on "/" and so I added a readinessCheck to the pod as suggested by the documentation.
What you expected to happen:
I expected the health check to be automatically updated.
Instead I had to delete the ingress and re-create it in order for the health-check to update.
How to reproduce it (as minimally and precisely as possible):

Create a deployment with no readiness probe.
Create an ingress pointing to the pods created by that deployment.
Add a readiness probe to the deployment.

Anything else we need to know:

Comment by @nicksardo:
There's actually a TODO for deciding what to do in this case https://github.com/kubernetes/ingress/blob/6ed6475e87588494dd29ba5d33bac167ae8acfdd/controllers/gce/healthchecks/healthchecks.go#L71 The controller doesn't want to overwrite handmade changes. We could probably update the settings if they have the default value.

But updating from default value would lead to confusing behavior where only
the first change is propagated, and it's not even possible to go back to
default, by changing the ingress, right?
I think it's reasonable to assume that if the ingress controller knows how
to manage a setting, it will overwrite manual changes.

I agree that it's reasonable and would be an easy solution. However, I worry about unsuspecting users who upgrade their master and find their load balancer throwing 502s. Would creating an event on health check update be sufficient? Thoughts from other users?

Is there any way that the "ingress controller"? can track whether the value was set automatically?

The controller does not have persistent storage. One option would be to convert the health check settings to JSON and store the state in the HealthCheck's optional description field for tracking diffs, but this seems very ugly.

cc @ibawt

What do you mean by "creating an event on health check update"?

If the controller sees a health check with settings different from default/readinessProbe, it updates the check then could create a K8s event for each parent ingress. If readiness probe exists, event could say, "Health Check for port 3XXXX updated to readinessProbe settings". If probe doesn't exist, "Health check for port 3XXXX updated to default settings (see ingress docs for defining settings via readinessProbe)".
There's already an event being created at HC creation, but it doesn't seem very useful to me: https://github.com/kubernetes/ingress/blob/987540f8f61f86d07314cd776fe32e150724b48c/controllers/gce/controller/utils.go#L603

Just my 2c: As a kubernetes user, I have no idea how to use events — they
seem too transient to be useful (i.e. it's impossible to see when they
actually happened, and I've never seen an event that's helped me to run my
cluster better).
It might just be a UI problem — if there was a way of just tailing the
event logs, then I might comprehend them better, so maybe it's ok to add
one and assume that they'll be fixed upstream
Sent via Superhuman<EMAIL_ADDRESS>On Tue, Apr 11, 2017 at 10:10 AM, Nick<EMAIL_ADDRESS>
If the controller sees a health check with settings different from
default/readinessProbe, it updates the check then could create a K8s event
for each parent ingress. If readiness probe exists, event could say,
"Health Check for port 3XXXX updated to readinessProbe settings". If probe
doesn't exist, "Health check for port 3XXXX updated to default settings
(see ingress docs for defining settings via readinessProbe)".
There's already an event being created at HC creation, but it doesn't seem
very useful to me: https://github.com/kubernetes/ingress/blob/
987540f8f61f86d07314cd776fe32e150724b48c/controllers/gce/controller/utils.
go#L603
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/ingress/issues/582#issuecomment-293332045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFwQP-D0IkTqISjn40vKGBNilNOffRjks5ru7QNgaJpZM4M5mnb
.

Is there any workaround to make it pick up the changes, even manually?

To answer my own question and for everybody landing here with the same problem, rotate the name of the service in your rule or backend and the controller will pick up the path correctly. I assume this could be done with 0 downtime creating a new rule and deleting the old one.

We actually encountered an issue yesterday in regards to readinessProbes and health checks on GCE. A while ago we had some difficulties with setting up the health-check correctly through Kubernetes, adding that it doesn't pick up changes, we decided to manually update the health-check on the GCE side, everything worked.
Yesterday we updated our master to 1.6.4, and suddenly all manual set health-check updates were reset to the defaults, probably because Kubernetes (re)set them again.
But, reading this issue, it should never update health-checks. I cannot re-trigger an update now, so it doesn't seem that this functionality has been added. But for sure the master upgrade did trigger this, is that expected behaviour?

Another gotcha, when using the example provided, https://github.com/kubernetes/ingress/blob/6ed6475e87588494dd29ba5d33bac167ae8acfdd/controllers/gce/examples/health_checks/health_check_app.yaml, if you remove the ports.containerPort, the GCE ingress health check sets defaults, and can't process the readinessProbe. This might be expected behavior, but at least for us, it wasn't.
All our reset health-checks didn't have a ports.containerPort set.

@bviolier
Regarding your last comment, containerPort is a required attribute for defining a port of a container. How would you expect to serve network traffic without defining it?
Regarding your loss of manual health check settings, the latest version of the controller creates a newer-type of health check (compute.HealthCheck instead of the legacy compute.HTTPHealthCheck). This chance was made to make HTTP and HTTPS health checks more manageable by the controller and to make future features of the load balancer easier to consume.
What settings are you trying to override with the readiness probe? Just the path?

@nicksardo Thanks for the information!
I was not aware that the containerPort was a required attribute. But, the pod/services also worked fine without it. The health-check was also working (although after manual editing the path), so traffic could get into the pods through the port specified in the readinessProbe, and without the containerPort.
Makes sense if it created a new type of health-check, thanks for the explanation. I do think more people that manually edited their health checks will run into this issue, but, manually editing health checks is also not the best thing to do ;-)
The most important changes we make with readinessProbe is indeed the path. But occasionally we also change the timeout, interval, and failureThreshold.

@bviolier
In case you aren't aware, if your service is using externalTraffic=Global (default), then the other settings aren't very useful.  Traffic from the load balancer hits any of the nodes and kube-proxy will route the traffic to a random node. This makes health checking close to useless as you won't have consistent data for a node. readinessProbes/livenessProbes are the way to go for pod health.

This issue was moved to kubernetes/ingress-gce#39


Inquiry About Upcoming Release Version 4.0.0

Hi,
First of all, thank you for your incredible work on this project!
I’ve noticed that the main branch includes new features like pressable support for TextInput, which are exactly what I need for my project. Could you please let me know when you plan to release version 4.0.0 from the main branch?
Thank you

Hi @jirawat-tokenx, idk exact date, as I have quite a lot to do with my main job, but you can try yarn add react-native-autocomplete-dropdown@next


Remove displayDate method from utils.jsx

Fixes mattermost/mattermost-server#12243
JIRA
https://mattermost.atlassian.net/browse/MM-18581

@Willyfrog Thanks for the input. I have made the changes and amended to the same commit.

looking better, but I've run it and it's showing like this. Can you take a look into that?

the fork repository was removed.

the fork repository was removed.
@cpanato can i close this pr and reopen it again?

@cpanato Is that going to cause any issues for the build system? GitHub isn't complaining, so I think we can still merge this fine as long as no further changes are needed to it

we can merge that, i just make a note that the head repo is deleted

adding bob to do the QA


migrate from databaseUsername to databaseAccount and fully use MariaDBAccount

Lead Jira: OSPRH-4095

[x] controller calls EnsureMariaDBAccount up front to make sure MariaDBAccount is present
[x] error code from EnsureMariaDBAccount is handled, Conditions are amended when error is returned
[x] controller calls NewDatabaseForAccount instead of NewDatabase
[x]  GetAccountAndSecret is used to retrieve account /secret to populate template
[x]  GetDatabaseByName() , normally used for delete finalizers, replaced with GetDatabaseByNameAndAccount
[x]  CreateOrPatchAll() used to patch the Database, replacing CreateOrPatchDB / CreateOrPatchDBByName
[x]  controller calls DeleteUnusedMariaDBAccountFinalizers when launched pods are definitely running on a new MariaDBAccount, returns error code if present
[x]  PasswordSelectors that refer to database are removed
[x]  all databaseUser replaced with databaseAccount inside of all XYZ_types.go
[x] all databaseUser replaced with databaseAccount inside of all kuttl/*.yaml
[x] all default databaseUser names become databaseAccount, replacing underscores with dashes inside of all XYZ_types.go
[x] all default databaseUser names become databaseAccount, replacing underscores with dashes inside of all kuttl/*.yaml
[x] MariaDBAccountSuiteTests are used in controller ginkgo tests if it has them
[x] 184 is merged and replaces from go.mod are removed

/retest

/retest

/test precommit-check

/test telemetry-operator-build-deploy
/test telemetry-operator-build-deploy-kuttl
/test images

/retest

/retest

cc @csibbitt @jlarriba  this is ready for merge.


fix(filetype): improve htmldjango filetype detection

I found htmldjango filetype detection regex is only match small number of Django tags which results in high false negative. This PR adds the rest of the tags based on https://docs.djangoproject.com/en/5.0/ref/templates/builtins/#built-in-tag-reference.
In addition, the supplied lines for matching is too few and might result in high false negative too. Increasing it to 40 lines should reduce the false negative. (I picked 40 as I think it is close to the most common height of terminal in a 1080p screen.)
Let me know if you have any suggestion :D
Related PR on Neovim: https://github.com/neovim/neovim/pull/29377

getzola.html (I just put random valid Django tags in line 27-33)
<!DOCTYPE html>

    <meta charset="UTF-8" />
    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="description"
          content="Everything you need to make a static site engine in one binary." />
    <meta name="author" content="Vincent Prouillet" />
    <title>Zola</title>
    <link rel="stylesheet" href="https://www.getzola.org/site.css" />
    <link rel="icon" href="https://www.getzola.org/favicon.ico" />

      Zola

            Docs

            Themes
            {% for letter in name %}
              {% if loop.index % 2 == 0 %}
                {{ letter }}
              {% else %}
                {{ letter }}
              {% endif %}
            {% endfor %}

            Forum

            GitHub

          <input id="search" type="search" placeholder="🔎 Search the docs" />

Your one-stop static site engine

Forget dependencies. Everything you need in one binary.

        Get started

No dependencies

              Zola comes as a single executable with Sass compilation, syntax
              highlighting, table of contents and many other features that
              traditionally require setting up a dev environment or adding some
              JavaScript libraries to your site.

Blazing fast

              The average site will be generated in less than a second,
              including Sass compilation and syntax highlighting.

Scalable

              Zola renders your whole site as static files, making it trivial to
              handle any kind of traffic you will throw at it at no cost without
              having to worry about managing a server or a database.

Easy to use

              From the CLI to the template engine, everything is designed to be
              intuitive. Don't take my word for it though, look at the
              documentation
              and see for yourself.

Flexible

              Zola gets out of your way so you can focus on your content, be it
              a blog, a knowledge base, a landing page or a combination of them.

Augmented Markdown

              Zola comes with
              shortcodes
              and
              internal links
              to make it easier to write your content.

      ©2017-2024 —
      Vincent Prouillet
      and
      contributors

Benchmark - v9.1.0496
Extra options: [./getzola.html]
Measured: 1000 times

Total Average: 34.784228 msec
Total Max:     49.700000 msec
Total Min:     32.567000 msec

  AVERAGE       MAX      MIN
-----------------------------
10.457772 17.086000 9.816000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/scripts.vim
 8.263982 16.024000 7.661000: $VIMRUNTIME/defaults.vim
 7.888493 14.534000 6.894000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/html.vim
 6.442452 13.005000 5.972000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/filetype.vim
 4.165122  6.824000 3.555000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/css.vim
 2.372461  4.785000 2.058000: opening buffers
 1.191531  2.253000 1.094000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/syntax.vim
 1.074161  2.060000 0.985000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/synload.vim
 0.959106  1.832000 0.875000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/syncolor.vim
 0.814663  2.589000 0.139000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent/html.vim
 0.798495  2.008000 0.679000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/vb.vim
 0.743085  1.548000 0.680000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/colors/lists/default.vim
 0.722137  1.687000 0.665000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/autoload/dist/ft.vim
 0.601083  5.272000 0.448000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/xml.vim
 0.590685  1.550000 0.510000: loading plugins
 0.444061  1.610000 0.340000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/netrwPlugin.vim
 0.409015  1.613000 0.176000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/ftplugin/html.vim
 0.357351  1.357000 0.327000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/autoload/htmlcomplete.vim
 0.321859  0.985000 0.157000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/gzip.vim
 0.307834  1.333000 0.265000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/javascript.vim
 0.290907  0.911000 0.253000: inits 1
 0.261815  0.863000 0.236000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent/javascript.vim
 0.228887  0.587000 0.202000: Termcap init
 0.221801  1.247000 0.162000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/dtd.vim
 0.207667  1.194000 0.187000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/autoload/dist/script.vim
 0.181571  1.159000 0.157000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/logiPat.vim
 0.166000  1.160000 0.137000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/zipPlugin.vim
 0.161232  0.833000 0.112000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/tarPlugin.vim
 0.153213  0.774000 0.138000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/matchparen.vim
 0.153137  1.129000 0.112000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/vimballPlugin.vim
 0.138751  0.381000 0.124000: reading viminfo
 0.104928  0.282000 0.095000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/tohtml.vim
 0.078912  0.260000 0.065000: Allocated generic buffers
 0.062385  0.228000 0.051000: loading packages
 0.058042  0.172000 0.051000: sourcing vimrc file(s)
 0.057891  0.190000 0.048000: locale set
 0.057653  0.265000 0.049000: init highlight
 0.054203  0.144000 0.040000: parsing arguments
 0.051885  4.457000 0.039000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/getscriptPlugin.vim
 0.042481  0.240000 0.037000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/ftplugin.vim
 0.040831  0.276000 0.017000: setting raw mode
 0.031475  0.118000 0.027000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/manpager.vim
 0.026592  0.156000 0.023000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent.vim
 0.023915  0.149000 0.019000: BufEnter autocommands
 0.022762  0.234000 0.020000: loading after plugins
 0.019370  0.110000 0.016000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/spellfile.vim
 0.011791  0.065000 0.009000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/rrhelper.vim
 0.010684  0.122000 0.008000: shell init
 0.007985  0.146000 0.006000: clearing screen
 0.007761  0.038000 0.006000: inits 2
 0.007190  0.137000 0.004000: --- VIM STARTING ---
 0.003960  0.037000 0.002000: inits 3
 0.003451  0.057000 0.002000: start termcap
 0.002349  0.023000 0.001000: window checked
 0.001440  0.012000 0.001000: editing files in windows
 0.000965  0.015000 0.000000: expanding arguments

Benchmark - this PR
Extra options: [./getzola.html]
Measured: 1000 times

Total Average: 23.924577 msec
Total Max:     77.414000 msec
Total Min:     22.659000 msec

 AVERAGE       MAX      MIN
----------------------------
8.126958 14.449000 7.601000: $VIMRUNTIME/defaults.vim
6.948326 11.118000 6.590000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/htmldjango.vim
6.658676 10.850000 6.318000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/html.vim
6.369272 10.919000 5.904000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/filetype.vim
3.726768  7.875000 3.537000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/css.vim
2.516440 56.652000 2.178000: opening buffers
1.517111  2.792000 1.413000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent/htmldjango.vim
1.452128  2.733000 1.357000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent/html.vim
1.176347  2.541000 1.086000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/syntax.vim
1.062174  2.429000 0.983000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/synload.vim
0.949410  2.270000 0.876000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/syncolor.vim
0.738344  1.875000 0.679000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/colors/lists/default.vim
0.733362  1.855000 0.682000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/vb.vim
0.717830  1.562000 0.664000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/autoload/dist/ft.vim
0.698953  5.362000 0.638000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/ftplugin/htmldjango.vim
0.607166  5.260000 0.554000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/ftplugin/html.vim
0.573874  1.383000 0.517000: loading plugins
0.419413  1.369000 0.341000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/netrwPlugin.vim
0.358076  0.958000 0.328000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/autoload/htmlcomplete.vim
0.289125  0.743000 0.155000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/gzip.vim
0.285238  0.458000 0.253000: inits 1
0.276131  0.881000 0.250000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/javascript.vim
0.261158  0.873000 0.237000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent/javascript.vim
0.222587  0.440000 0.200000: Termcap init
0.177072  0.598000 0.157000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/logiPat.vim
0.154263  0.763000 0.137000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/zipPlugin.vim
0.152174  0.660000 0.138000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/matchparen.vim
0.145474  0.557000 0.113000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/tarPlugin.vim
0.137828  0.408000 0.125000: reading viminfo
0.136794  0.680000 0.112000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/vimballPlugin.vim
0.119750  1.111000 0.107000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/django.vim
0.103716  0.369000 0.095000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/tohtml.vim
0.077158  0.223000 0.065000: Allocated generic buffers
0.061122  0.300000 0.051000: loading packages
0.056886  0.152000 0.050000: sourcing vimrc file(s)
0.056629  0.171000 0.049000: init highlight
0.056209  0.130000 0.047000: locale set
0.053205  0.175000 0.042000: parsing arguments
0.045615  0.295000 0.039000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/getscriptPlugin.vim
0.042225  0.211000 0.037000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/ftplugin.vim
0.038852  0.098000 0.019000: setting raw mode
0.031795  0.182000 0.028000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/manpager.vim
0.026885  0.206000 0.023000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/indent.vim
0.024276  0.130000 0.020000: BufEnter autocommands
0.022838  0.139000 0.020000: loading after plugins
0.019793  0.143000 0.017000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/syntax/xml.vim
0.018806  0.133000 0.016000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/spellfile.vim
0.011443  0.118000 0.009000: /home/mangkoran/.local/share/mise/installs/vim/9.1.0496/share/vim/vim91/plugin/rrhelper.vim
0.010383  0.068000 0.008000: shell init
0.007826  0.193000 0.006000: inits 2
0.007808  0.141000 0.006000: clearing screen
0.006664  0.050000 0.004000: --- VIM STARTING ---
0.003842  0.084000 0.002000: inits 3
0.003314  0.033000 0.002000: start termcap
0.002235  0.019000 0.001000: window checked
0.001469  0.003000 0.001000: editing files in windows
0.000934  0.003000 0.000000: expanding arguments

I wonder why on the first benchmark (v9.1.0496) the scripts.vim was executed, while on the second benchmark (this PR) it did not?

thanks, let me include this.


Client Types - Language

Be good if clients starting sending type information as well as names (e.g. Go, Node, Java, Ruby)

This is present and updated for most major clients.


Support zeronull.Text in addition to pgtype.Text in pgx mode

What do you want to change?
When using pgx/v5 for the sql_package, to create a null string you need to construct a pgtype.Text{Valid: false}. The zeronull package exists to make it easier to handle zero values and to represent them as nulls.
Both zeronull.Text and pgtype.Text share the same interface, database/sql/driver.Valuer, but sqlc uses pgtype.Text explicitly. It is possible to override the type to use this interface. This allow a user to supply either zeronull.Text or pgtype.Text, making it a bit easier to handle optional NULLs.
sqlc.yaml:
[..]
        sql_package: "pgx/v5"
        overrides:
          - db_type: "text"
            nullable: true
            go_type:
              import: "database/sql/driver"
              # (database/sql/driver is aready imported, this is a trick to allow us to import it again)
              package: duplicate_driver
              type: "Valuer"

This allow you to use do something along these lines:
	somepkg.New(db).Insert(ctx, somepkg.InsertParams{
		NullableField: zeronull.Text(""),
		Field: pgtype.Text{Valid: true, String: "value"),
	})

All of this works fine so I'm just asking why this is not the default behaviour? :) Changing the default to be driver.Valuer should also be a backwards compatible change.
Implemented in the playground:
https://play.sqlc.dev/p/ec8426251a7a77a415ecd6a4d3e1c8970c5dd36c09530ffbddd4f30c85147b86
What database engines need to be changed?
PostgreSQL
What programming language backends need to be changed?
Go

All of this works fine so I'm just asking why this is not the default behaviour?

The Valuer interface doesn't provide any true type-safety. You could easily provide any database type for Text and the compiler wouldn't compile. Overrides exist so that you can choose this behavior, but we won't be changing the default.


feat(issues): new format for issue templates

Merged the issue templates into a single template in order to simplify triage, reduce miscategorization and duplicates, and reduce work to submit while still requiring sufficient information.
Provides opportunities to add reproduction-steps for bugs, desired behavior for feature-requests, and guides support questions to Stack Overflow without disallowing the cross-post here.
Looking for feedback.

Pull Request Checklist

[x] Testing

Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change)
CLI change?: coordinate update of integration tests with team
cdk-init template change?: coordinated update of integration tests with team

[x] Docs

jsdocs: All public APIs documented
README: README and/or documentation topic updated
Design: For significant features, design document added to design folder

[x] Title and Description

Change type: title prefixed with fix, feat and module name in parens, which will appear in changelog
Title: use lower-case and doesn't end with a period
Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"

[x] Sensitive Modules (requires 2 PR approvers)

IAM Policy Document (in @aws-cdk/aws-iam)
EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
Grant APIs (only if not based on official documentation with a reference)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

@NGL321 make sure that the new template will automatically add the needs-triage tag to new issues. There's a way to do that, not sure exactly how...


param.Selector action does not update param.String

First, thanks to the panel team! Panel is a great and really useful package :smiley:
There may be a bug when changing the value of param.String when triggered by param.Selector (version panel-0.6.2).
Example:
import param
import panel as pn

pn.extension()

class Gui(param.Parameterized):
    text      = param.String('initial text')
    dropdown  = param.Selector(['1', '2', '3'])
    action    = param.Action(lambda x: x.param.trigger('action'), label='Action!')

    @param.depends('action', watch=True)
    def onaction(self, **params):
        self.text = 'action!'

    @param.depends('dropdown', watch=True)
    def ondropdown(self):
        self.text = 'dropdown!'
        self.param['action'].label = 'dropdown action'

gui = Gui()
pn.Column(gui.param)

I can modifying param.String with the action-button.
I can modify the param.Selector with the dropdown
I cannot modify the param.String with the dropdown :thinking:

I don't see any errors in the javascript console.

Thanks for reporting this. Can't immediately see what's going wrong here.

I try to modify the text param to "dropdown!" with a callback from the dropdown, which is somehow not working for me.
Changing text with the action button works.

Sorry should have been clearer, I can reproduce but couldn't immediately figure out why it doesn't work.


Building a Phoenix project

Thanks for an amazing project!
I know this is out of scope, but I'm wondering how to build a phoenix project.
I'm guessing this would have to be combined with https://github.com/svanderburg/node2nix?
So far, I've had to make two modifications, from the default config given.

replace pname with `name
add a src attribute

After that, this is the error I get
building
** (Mix) The task "compile.phoenix" could not be found. Did you mean "compile.elixir"?

not sure how to move forward. I'll be experimenting. Just opening this to keep track of the progress.
Any thought is welcome.

There is definitely a problem with the dependencies.
I tried adding a postConfigure hook like
  postConfigure = ''
    ls $TMPDIR/deps
  '';

And this is what I got
ls: cannot access '/private/tmp/nix-build-union-0.3.8.drv-0/deps': No such file or directory

It seems the dependencies are not properly passed to the buildMix function.

It appears to be a problem with install instructions.
I still see the Bootstrapping dependent libraries with comes from the original script. It seems the overlay is not being seen.

I tried on both nixos and macOS with the same result. I'm going to research more on overlays, trying to find out where the installation instructions are failing.

I am going to close this for now, there is a PR to build a mix-project on nixpkgs right now


add "task" for breaks

Right now, all breaks are the same. But there should be an optional popdown for break type: lunch, meditation, etc.
This list should be short (the long tail would just go to general breaks), so I think just we just need:

a drop-down with the existing options
a text field for adding new break types, at the bottom of that drop-down

I think I'm just going to get rid of the break button altogether.

I've been without the break button for a while now; I enter breaks in manually, like with any other PTN. I do want to be able to say that breaks don't need notes, but that's covered in #61. Closing this as wontfix.


Trying to fix: The route forgot-password could not be found #59

Trying to fix: The route forgot-password could not be found #59

@cawecoy did you have any time to take a look at the PHPStan issues? If not I can try to take a look at it :)

Closed due fix in #67


⚠ Fetchers has degraded performance

In 948367b, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 346 ms

Resolved: Fetchers performance has improved in 84f19ec.


Inat ObservationView

Creates an ObservationView when importing an iNat observation.
(script/refresh_cache expects them.)
Fixes #2479

coverage: 93.472%. remained the same
when pulling 9ed657e1d2e69de160a8588a0375cd78f50c3f5e on 2479-inat-observation_view
into 25d77b707bd62cd43ebfe531d30d864a9f855880 on main.


coding in erect remixes

What is your question?
How do you code in erect remixes? (a bit like this)

you need a different folder for the "ex" song.
then in your .json file, it should have "song":your-song-name
Replace the song name (IN THE .JSON FILE) with your ex song.
test it out.

thanks


Je/enikshay proxy

https://github.com/dimagi/commcare-hq-deploy/pull/170
This sets up the proxy for uatbc. I wanted to make this a bit more general since it's basically the same code for CAS and UATBC, but I decided not to when I realized our config uses globals for the certs
@proteusvacuum @czue

nice. yeah i don't think we need full site functionality.


Turn core.state into a defaultdict with values deafulting to False

The only state keys that aren't bools are the ones used for https://github.com/opensciencegrid/osg-test/blob/master/osgtest/tests/special_install.py

Much as I hate KeyErrors, using a regular dict as core.state makes typos easier to catch.

Good point


[Accessibility] [Screen Reader] Fix the "Add" button announcement for the Bot Explorer panel

Fixes ADO Issue: #63913
Describe the issue
If users Navigate on Side pane control and focus moves to the Add control under the Bot Explorer panel the screen reader announcement is not descriptive enough to identify the purpose of the control.
Actual behavior:
Screen reader descriptive information does not announce for Endpoint add control and Services add control, screen reader only add button announce and it confusing for users to know which control and what purpose of the control.
Expected behavior:
Screen reader descriptive information should be announced for Endpoint add control and Services add control so that users easily identify the purpose of the control and perform an action accordingly. E.g.: it should be announced as "Add endpoint button" and "Add services button".
Repro Steps:

Open Bot Framework Emulator installed on the system.
Bot Framework Emulator Application with Welcome screen opens.
Navigate on the welcome screen and select Create a New BOT configuration link.
New BOT Configuration dialog opens.
Navigate on the dialog and enter inputs in edit fields then select the save and connect button.
Navigate to BOT Explorer on the left pane and select it.
Bot Explorer Pane opens, navigate on the pane.
Verify that screen reader descriptive information announce for add control or not.

Changes included in the PR

Fixed the screen reader announcement for the Add  button

Screenshots
Test cases executed successfully

Coverage remained the same at 67.866% when pulling 64c1e26110d4ab448eeeafb7c788eb80e67c1fcb on southworks:external/southworks/fix/bot-explorer/fix-button-announcement into a09833d1b09d244ea22f51b77bf53ed763ce2ab4 on microsoft:main.


feat(#doc-1845): fix auto importing css

This PR is the best of both worlds, we generate the style.css files. If the user does not import them, we import them in JS and throw a warning.
TODO:

nuxt
docs
loooooots of testing

I disabled the path aliasing for testing or it it will just grab the style directly. I will un-comment after testing.

Why does the bundle size increase by ~200kb? 🤔

That is a good question. Standalone shouldn't even be affected 🤔

tested! lets get this in 😤


Questions about prerelease versions and independent mode

Hi,
this project looks very interesting and I'm evaluating if I can try it out to some of our monorepositories.
I have two questions first, which I couldn't find any answer in the docs.

The prerelease feature changes the version by appending the tag name. Is there a way to specify the npm dist-tag but keep the version as-is?
In our case when we create a release we publish to next dist-tag by default. Then when we want to promote the version to latest, we do so by running a script manually that assigns the version to latest. However, the version does not change from next to latest, only the dist-tag.
We also have canary releases, in which case the current implementation of a prerelease would work, as the version should change as well.

Is "independent" mode the only available mode?
In Lerna there are 2 modes: locked and independent. In our case we use locked mode. I don't see a big issue if we change to independent mode as a result of moving to changesets. I just want to understand if this is the only way or if there is another "hidden" option or something.

Thanks in advance, any feedback would be appreciated.

Ha, that's so weird. I literally just came here with the exact same questions.
I want to be able to have a fixed mode in changesets so all packages bump to the same version. Similar to how React / React-DOM works. I have packages that all need to bump together regardless of whether they change. Can't seem to figure out how to do it.

There is a linked config that should roughly do what u want here. Please recheck if it matches your expectations exactly

Regarding 1, I think it would be best to leverage the package manager for publish. If you use pnpm you may run pnpm publish -r --tag next and it will publish all the packages with the next tag.

There is a linked config

Ah, where can I find that?

I think it would be best to leverage the package manager for publish

I see, so I just use the version command to bump the versions (without using the prerelease feature) and then try to publish "normally" using e.g. Lerna?
Would it make sense to have it configurable in changesets, e.g. in the publish command or in the pre command? Or are there specific reasons not to do that?
Thanks for the quick feedback so far!

This one? https://github.com/atlassian/changesets/blob/master/docs/linked-packages.md

Yes, this is what I had in mind.

Would it make sense to have it configurable in changesets, e.g. in the publish command or in the pre command? Or are there specific reasons not to do that?

Well, currently the pre mode is designed to batch - often breaking - changes. It's mostly useful for developing the next major version of your project. It doesn't have to be limited to this use case, but to extend support for other use cases you would have to post an RFC describing your desired flow so this could be discussed in more depth.

you would have to post an RFC describing your desired flow so this could be discussed in more depth

Got it. If I have some time in the next days I can try to draft something up.

I have another question if you don't mind, as I'm trying things out.
I noticed that private packages also get a changelog, but only if the bumped version is within the dependencies, not the dev dependencies.
I'm a bit confused about this behavior and couldn't find any useful info in the docs/code. Could you explain that, if this is the expected behavior?
You can find an example PR here: https://github.com/commercetools/merchant-center-application-kit/pull/1486
What I expected instead is that private packages do not get a changelog, only the versions bump.
Thanks a lot in advance 🙏

I noticed that private packages also get a changelog, but only if the bumped version is within the dependencies, not the dev dependencies.

I think the same happens for public packages. Updating dev dep shouldn't affect the production release, that's why dev deps do not bump versions.

What I expected instead is that private packages do not get a changelog, only the versions bump.

Currently, it is not possible to bump the version without also changing the changelog (at least I don't think it is possible). A (somewhat) related comment/discussion about versioning private packages: https://github.com/atlassian/changesets/issues/339#issuecomment-619334412

Updating dev dep shouldn't affect the production release, that's why dev deps do not bump versions

Yes that's fine and it makes sense.
I asked because I got an error that the CHANGELOG.md file wasn't present, due to the fact that the version bumped of the private package was only a dev dependency.

You can see the full logs here.
I "solved" this by creating an empty CHANGELOG.md file in the private package. I suppose this was just an edge case and wanted to know what the behavior is with private packages.

@emmenko if you could create a simplified repro case this would be very helpful to get this fixed.

I guess this can be closed now. I've been using changesets across different repos for some time now and pretty much are use cases / requirements have been covered now. We're very happy with that! Thanks 🙏


Adjust error message

For some reason that capitalized "Inspector" bothers me.

Codecov Report

Merging #78 into master will decrease coverage by 0.51%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #78      +/-   ##
==========================================
- Coverage   81.78%   81.27%   -0.52%
==========================================
  Files           5        5
  Lines         582      582
==========================================
- Hits          476      473       -3
- Misses        106      109       +3

Impacted Files
Coverage Δ

dwave/inspector/server.py
74.21% <ø> (ø)
:arrow_up:

dwave/inspector/adapters.py
86.62% <0%> (-0.92%)
:arrow_down:

Continue to review full report at Codecov.

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


Add more tests for the dataframe interchange protocol

Here we add generic tests for the df protocol. These tests can be used for any product that works with dataframes. It is only necessary to change conftest, replace the existing constructor for pandas with the one necessary for the project that will be used.

@Rubtsowa could you please elaborate on what these tests are supposed to be testing? Going from what I see in the PR, this tests the protocol implementation of some pandas-like dataframe (the suites use pandas specific methods of df like df.columns.values, df.categorize, an assumption that string column has 'np.object' type, etc).
Is there a plan to make these tests more generic so not only pandas-like dataframes could be tested with them?

Thanks for the tests @Rubtsowa and for the initial review @dchigarev! @Rubtsowa it would be nice to fill in the PR description a bit, e.g., what are the main things this PR aims to cover, and are these tests written from scratch or taken from an existing implementation (cuDF, Vaex)?

Is there a plan to make these tests more generic so not only pandas-like dataframes could be tested with them?

That would be quite nice, and was indeed something that multiple maintainers of Pandas and other libraries have asked for.

@Rubtsowa, please leave comments what is fixed.

@rgommers please, check PR

@rgommers thanks for your comment.
tests/test_protocol.py::test_dataframe - In this test I see problem with function select_columns. I have error:
def select_columns(self, indices: Sequence[int]) -> '_PandasDataFrame':
>       if not isinstance(indices, collections.Sequence):
E       AttributeError: module 'collections' has no attribute 'Sequence'

tests/test_protocol.py::test_df_get_chunks, tests/test_protocol.py::test_column_get_chunks - Pandas do not plan to use more chunks than 1. Because assert len(chunks) == n_chunks will be don't correct. I fixed this.
tests/test_protocol.py::test_buffer - In this test was don't correct assignment. I fixed this.

@rgommers thanks for your comment.
tests/test_protocol.py::test_dataframe - In this test I see problem with function select_columns. I have error:
def select_columns(self, indices: Sequence[int]) -> '_PandasDataFrame':
>       if not isinstance(indices, collections.Sequence):
E       AttributeError: module 'collections' has no attribute 'Sequence'

tests/test_protocol.py::test_df_get_chunks, tests/test_protocol.py::test_column_get_chunks - Pandas do not plan to use more chunks than 1. Because assert len(chunks) == n_chunks will be don't correct. I fixed this.
tests/test_protocol.py::test_buffer - In this test was don't correct assignment. I fixed this.

Do the tests pass for you, and if so are you working from a different version of the protocol implementation for Pandas, or running the tests differently?

I would like the tests from this PR fit every implementation of the protocol, but not the implementation for pandas only.

I would like the tests from this PR fit every implementation of the protocol, but not the implementation for pandas only.

They should indeed. That was not the point of the comment though, I just had the wrong (in-progress) implementation of the protocol for Pandas. We should just link to https://github.com/pandas-dev/pandas/pull/46141, I think that's the right implementation and not the one in this repo.

Then Failed in tests which have @rgommers at the moment they will be present, but with the updated ramp, they will not occur.

So dataframe-interchange-tests now covers everything in this PR, except for asserting the actual data held in buffers e.g.
for idx, truth in enumerate(arr):
    val = ctype.from_address(dataBuf.ptr + idx * (bitwidth // 8)).value
    assert val == truth, f"Buffer at index {idx} mismatch"

I can mull doing something like this, similarly only in scenarios where checking the actually values of a buffer is easy (e.g. on CPU, and only when libraries are returning valid Column.dtype tuples in the first place).

Thanks @honno. I'll close this then. Can you migrate that last loose end to a new issue (or PR) on the dataframe-interchange-tests repo so it doesn't get lost?
Thanks a lot @Rubtsowa and @dchigarev. Given that:

after gh-81 the implementation (including all the existing tests) has been removed from this repo,
Pandas now has its own implementation merged with significant improvements compared to the prototype, and
https://github.com/data-apis/dataframe-interchange-tests covers protocol testing comprehensively now,
I will close this PR.

Thanks for opening this PR! And also for working on the Pandas prototype (I think).


Button spacing

I feel there is quite the gap between these two buttons at the bottom:

Hm, I guess this is done to separate the concerns that are clearly different? What is the reason to have a button to "Check out main", should that maybe be just removed? I wonder how related that action is to the PR?

The "Checkout 'main'" used to be "Exit review mode", which still just checked out main but which users found confusing. Since we checkout a branch when you check out a PR, we want to have a way to guide users off of that branch too when they're done working with the PR.

@hbons as well in case you have thoughts on this.

Adding some grouping and changing the checkout button to secondary could help here. Quick mockup:

Closing as I don't plan to address this.


Make cw721-base minter updatable via two-step ownership transfer.

This makes a breaking change to cw721-base in that it makes the minter field on cw721_base::MinterResponse optional.
Before:
pub struct MinterResponse {
    pub minter: String,
}

After:
pub struct MinterResponse {
    pub minter: Option<String>,
}

It also makes a breaking change to the ContractError enum in that it removes the Unauthorized variant in favor of cw-ownable's more descriptive OwnershipError.
It then extends the cw721_base, but not the cw721 standard's, ExecuteMsg with
cw-ownable's UpdateOwnership enum variant, and extends the QueryMsg with cw-ownable's Ownership {} query. Using these messages, the current minter on the contract may nominate a new minter, who may accept or reject this nomination.

@shanev , @JakeHartnell , @larry0x - i'd be interested in your feedback about this.
we'd like to use something like this in DAO DAO to allow NFT DAOs to bootstrap themselves. ICS-721 would possibly also benefit from a more flexible ownership scheme for as it could allow the owner to control rate-limits and other parameters relevant to their collection moving to other chains (where they could lose royalty protections, for example, when leaving Stargaze).
the change i've made here tries to limit API breakage by not renaming the minter field on the InstantiateMsg. we could further break the API by changing that field to owner. at the moment, $minter \iff owner$.

we could further break the API by changing that field to owner.

Damn, I really want to do this but feel it would be a pain for a lot of folks...

we could further break the API by changing that field to owner.

Damn, I really want to do this but feel it would be a pain for a lot of folks...

Opinions from @shanev @jhernandezb should be the most important regarding API breakages... What do you guys think about:

renaming the minter field in instantiate msg
delete QueryMsg::Minter and use QueryMsg::Ownership instead

@0xekez I think you can consider adding rust-version = "1.65" in the workspace Cargo.toml to enforce a minimum Rust version
(For context: cw-ownable uses a syntax only available since Rust 1.65)

I think it would be nice to have an example of how to migrate a contract from previous versions in case someone misses it and leaves a contract uninitialized.

I think it would be nice to have an example of how to migrate a contract from previous versions in case someone misses it and leaves a contract uninitialized.

The way I suggest to do this is to create an src/migrations folder with this structure:
contracts/
└── cw721-base/
    └── src/
        └── migrations/
            ├── mod.rs
            ├── v0_16.rs
            ├── v0_17.rs
            ├── v1_0.rs
            └── v1_1.rs

Each v*_*.rs will contain a single migrate function that contains the logic for migrating from the previous version to the current version. For example, v0_17.rs will contain the logic for migrating from v0.16 to v0.17.
To migrate a custom cw721 contract from v0.16 to v0.17, simply do:
#[entry_point]
fn migrate(deps: Deps, env: Env, msg: MigrateMsg) -> Result<Response, ContractError> {
    cw721_base::migrations::v0_17::migrate(deps, env, msg)?;
    Ok(Response::new())
}

I can imagine this would be tricky for Stargaze tho... Since each NFT collection is a separate contract, we have to migrate each one of them. It may be useful to create an sdk module that registers each collection, and provide a governance-gated message to migrate them all together.

I can imagine this would be tricky for Stargaze tho... Since each NFT collection is a separate contract, we have to migrate each one of them. It may be useful to create an sdk module that registers each collection, and provide a governance-gated message to migrate them all together.

I governance proposal would be a nice one to have, currently creators have admin and can do the migration themselves through our studio UI. Your proposed solution sounds good to me

I think it would be nice to have an example of how to migrate a contract from previous versions in case someone misses it and leaves a contract uninitialized.

good idea, i've added migration logic and added this to the README:
Updating the minter
For contract versions $> 0.16$ the minter has been replaced by an
owner which is updatable via the two-step ownership transfer process
of cw_ownable. To retrieve the
owner, QueryMsg::Ownership {} may be executed.
QueryMsg::Minter {} has not been removed, though after version 0.16
the response type has made the minter field optional as it may be
unset. For all intents and purposes, whenever the word minter is used,
it means owner, and owner in turn means minter, $minter \iff owner$.
Before 0.16:
pub struct MinterResponse {
    pub minter: String,
}

After 0.16:
pub struct MinterResponse {
    pub minter: Option<String>,
}

NFTs on version 0.16 may upgrade via MigrateMsg::From016 {}. For an
example of doing so, see
this
integration test.

i'll merge this tomorrow if there are no more comments before then

@0xekez @JakeHartnell I'd say this PR is ready to be merged! However, please don't cut a release for 0.17 yet. I say we include #106, perhaps also #107, and I also have a suggestion to how we do cw2 versioning in cw721-base which I'll do a PR shortly.

I say we include #106, perhaps also #107, and I also have a suggestion to how we do cw2 versioning in cw721-base which I'll do a PR shortly.


gnomeExtensions.gsconnect: 55 -> 56

Description of changes

Update of gnomeExtensions.gsconnect to v56 which works with Gnome 45 (unlike v55). See https://github.com/GSConnect/gnome-shell-extension-gsconnect/releases/tag/v56.
I must admit I did not know what pkgs/desktops/gnome/extensions/gsconnect/fix-paths.patch does, so I have just tried to adapt it to the new style of imports.
Fixes: https://github.com/NixOS/nixpkgs/issues/269566
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.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

[ ] Fits CONTRIBUTING.md.

Priorities
Add a :+1: reaction to pull requests you find important.

With the new modules, imports in each module are resolved before running any code so just porting the code to the new syntax will not work. You need to either convert all affected import statements to regular statements using top-level await (example) or move the typelib path manipulation to a separate file (example).

@jtojnar Thank you for the explanation and the links to example solutions. I have decided to follow the approach of moving the typelib path manipulation to a separate file, which I find a little less intrusive.

Looks good but I did not test.
Could please double check that the preferences in the extension app work?

I have tested successfully that I can pair a new device and that I can change the directory in which files sent from the device to the computer are stored.

I am getting this error in the Extensions app on Gnome 45 and gsconnect 56:
GLib.FileError: Failed to open file “/usr/local/share/glib-2.0/schemas/gschemas.compiled”: open() failed: No such file or directory

@iclanzan I do not get any errors in the Extensions app with gsconnect 56. I have also checked that there is no /usr/local/share/glib-2.0/schemas/gschemas.compiled on my machine; in fact, there is no /usr/local. Could it be that you have a version of the extension installed at<EMAIL_ADDRESS>via Gnome shell browser extension that does not have the NixOS paths?

I just tried on a fresh NixOS install on a different laptop and I am getting the same issue. Must be something about my nix config. I am installing gsconnect like this:
environment.systemPackages = [<EMAIL_ADDRESS>];

While it didn’t work at the time I made the original comment, this works now:
environment.systemPackages = [ pkgs.gnomeExtensions.gsconnect ];


File Settings get overwritten

I manually edited the file settings within the File Cabinet to allow for Extrernal access. However, when update from this plugin, the settings are overwritten.

Thanks for the issue. I have reproduced the issue and I believe I have fixed it. I will be pushing an update ASAP.


DBAAS1-106: Database Landing Table

Preview

Description

Makes DBaaS landing table according to spec

How to test

Enable the MSW
Go to /databases and make sure the landing table matches the proposed spec in the internal ticket description
Check responsiveness

The "Label" sort direction looks like it should match the styling of "Created" sort arrows according to the designs

Nice job! Two small things:

"Label" should be "Cluster Label"
"Created" should have the same sort arrow as "Label"

according to DBaaS MVP designs in "Cloud Manager Final" project (there are outdated designs posted elsewhere)

I changed Label to Cluster Label but I'm unsure of any action to do about the sort arrows. It is standard that you can only sort by one column at once. The default sort I chose is by label descencing.

Good point, I suppose its a little error in the designs, thanks!


Updating README file

Context

https://github.com/autotrader-plus/traderautoplus-app/issues/1
Your Changes
Description:

Simply updated README file
Type of change (select all that apply):

[x] New feature (additional functionality separate from existing code)
[x] Documentation update (adding more comments)

Testing
None required
Checklist

[x] Code is up to date with main branch (no merge conflicts)
[x] One or two people have reviewed this pull request

Looks good!


80 changing token sympol

Changing from chain_spec.rs doenst seem to be working as changes are not reflected on json file when generating it. So i have changed directly from json file, so running the node using json file will reflect the changes. At the mean time I will be investigating as to why chain_spec.rs is not doing exactly as intended

Codecov Report

Merging #81 (7294c36) into main (725d5f1) will decrease coverage by 2.37%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #81      +/-   ##
==========================================
- Coverage   64.42%   62.05%   -2.38%
==========================================
  Files          18       19       +1
  Lines        1293     1307      +14
==========================================
- Hits          833      811      -22
- Misses        460      496      +36

Impacted Files
Coverage Δ

node/src/chain_spec.rs
0.00% <0.00%> (ø)

runtime/src/lib.rs
3.07% <0.00%> (ø)

pallets/roles/src/mock.rs
100.00% <0.00%> (ø)

pallets/roles/src/tests.rs
100.00% <0.00%> (ø)

pallets/housing_fund/src/mock.rs
100.00% <0.00%> (ø)

pallets/housing_fund/src/tests.rs
100.00% <0.00%> (ø)

pallets/roles/src/weights.rs
0.00% <0.00%> (ø)

pallets/roles/src/helpers.rs
95.71% <0.00%> (+0.06%)
:arrow_up:

pallets/housing_fund/src/lib.rs
92.56% <0.00%> (+0.20%)
:arrow_up:

pallets/roles/src/structs.rs
96.66% <0.00%> (+0.23%)
:arrow_up:

... and 1 more

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 725d5f1...7294c36. Read the comment docs.

Hey @MrishoLukamba thanks for the PR, please remove the blockchain database  and the .idea.xml files
Let's wait with merging these for now, until you investigated how to integrate it in the chainspec.

Got it @ilhanu

Closing this as #97 got it covered


Update deprecated deployment label

Motivation
Warning: spec.template.spec.nodeSelector[beta.kubernetes.io/arch]: deprecated since v1.14; use "kubernetes.io/arch" instead

Solution
This label has been deprecated. Use kubernetes.io/arch instead.
PR Checklist

[ ] Added Tests - N/A
[ ] Added Documentation - N/A
[ ] Updated the changelog - I cannot find it :/

Codecov Report

Merging #292 (ec9e2d8) into main (a2dc598) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #292   +/-   ##
=======================================
  Coverage   39.42%   39.42%
=======================================
  Files          19       19
  Lines        5458     5458
=======================================
  Hits         2152     2152
  Misses       3306     3306

Flag
Coverage Δ

test
39.42% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 a2dc598...ec9e2d8. Read the comment docs.


Blog post celebrating the 50 adopters

Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

Also, prettier failed. 😅


Failed at the<EMAIL_ADDRESS>postinstall script 'opencollective postinstall'.

Can't install the package
~/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp(branch:development*) » npm i react-native-router-flux --save                            Almog@Almogs-MacBook-Pro

<EMAIL_ADDRESS>postinstall /Users/Almog/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp/node_modules/react-native-router-flux
opencollective postinstall

sh: opencollective: command not found
npm WARN enoent ENOENT: no such file or directory, open '/Users/Almog/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp/node_modules/react-native-drawer-layout/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/Users/Almog/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp/node_modules/react-native-drawer-layout-polyfill/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/Users/Almog/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp/node_modules/react-native-tab-view/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/Users/Almog/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp/node_modules/react-navigation/package.json'
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm ERR! Darwin 15.6.0
npm ERR! argv "/Users/Almog/.nvm/versions/node/v6.9.5/bin/node" "/Users/Almog/.nvm/versions/node/v6.9.5/bin/npm" "i" "react-native-router-flux" "--save"
npm ERR! node v6.9.5
npm ERR! npm  v3.10.10
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR<EMAIL_ADDRESS>postinstall: opencollective postinstall
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script 'opencollective postinstall'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-native-router-flux package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     opencollective postinstall
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-native-router-flux
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls react-native-router-flux
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/Almog/Full-Time-Employment/Construction-Cloud/RnD/CCMobileApp/npm-debug.log

beta v6 works - npm i<EMAIL_ADDRESS>--save

@xdamman Could you look at it?

@AlmogRnD Please try yarn yarn add<EMAIL_ADDRESS>@xdamman may fix it for npm, for next beta, I guess...

@aksonov thanks, Yarn works

Thanks for bringing my attention to this. What node version are you using? On a Mac?
I cannot reproduce it yet.
This is what I see

Mac, npm 4.2.0

and actually all the answers to my questions where in the log above ¯_(ツ)_/¯
node v6.9.5
npm v3.10.10
Still digging into this.

works for me with node v6.95 and npm v.3.10.10 🤔
and opencollective is not in my PATH. Not sure what else I can try...

So basically, this means that somehow it didn't link ./node_modules/.bin/opencollective to ./node_modules/opencollective/dist/bin/opencollective.js OR that it doesn't add automatically ./node_modules/.bin/ to the PATH when running npm install.

@xdamman Could we just run ./node_modules/.bin/opencollective instead to avoid that?

Does it work for you locally when you change the postinstall script to that command? (I couldn't reproduce the issue so cannot test)

@xdamman Yes, it works. I've just submitted it to PR #2015

Good to know that it solved the issue. That's weird that somehow npm is not considering ./node_modules/.bin as a source of executable files in your setup (but it does in mine). Curious if others have the same issue.
Thanks for spending the time to figure this out 👍

Should be fixed with v4 beta.8

~Two days ago that was working fine.

Thank you for reporting - but beta versions are not supported.
You can use resolutions in your package.json to lock the opencollective version to one that might work in your environment.


Principle 3.7: Not sure I agree with this principle

Sorry for raising this concern now, but I'm not sure I totally agree with principle 3.7. It might be a problem of not understanding correctly what the message is but the following sentences are very inconvenient in real-world scenarios:

The Information Package MUST be implemented by ONLY ONE implementation at any point in time.
However, it is not reasonable to have multiple implementations available at once as this would lead to unnecessary complexity in developing interoperable tools for creating, processing and managing Information Packages.

My understanding after reading these sentences is that IT IS NOT RECOMMENDED TO have several VERSIONS of the CSIP (or any of the other packages) in the same implementation at the same time. Well, this is very hard to implement in real-world scenarios. We currently have 10.000.000 AIPs in CSIP version 1.0 and will soon adopt version 2.0.0. There is no way we are going to upgrade all those AIP in a production system.
What will happen is that we will support both versions of the AIP. New AIPs will be created in the new version, and older AIPs will be supported as well, concurrently. And there is no hard in that.
What I'm lacking in the specification is a clear indication of which version of the spec is the actual package implementing so that is easy for a running system to parse the package with the right version of the software/library.
@karinbredenberg and @kuldaraas Any thoughts on this?

Moved forward due to need of taking care of the language to make the principle understandable. For now the text remains but its not its own principle. Adding the principle wont break backward compatibility.

Agree and closed, dupe of #178 also closed.


FIX(layout): align page margins of header and content

This PR fixes the margins of header and content of the website on small devices as mentioned in #129 .
Fixes #129

Looks like this now:

thx for fixing


MCXN94X CTIMER support

Added CTimer Support to the MCXN94X Platform

Please add counter to the .yaml file.

CTimer or Counter

Please update the doc file to indicate this support

Please update the doc file to indicate this support

Thank you, updated.


[Cherry-pick][Branch-2.4] Supports the agg function hll_raw to speed up the collection of full statistics

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

run starrocks_fe_unittest

run starrocks_be_unittest


Call Options menu doesn't dynamically scale/position when the window size is changed

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!
Upwork job link - https://www.upwork.com/jobs/~01ba0dff1eec1e5790

Expected Result:
When you resize the Expensify Cash window, the Call Options menu should dynamically scale within the window.
Actual Result:
When you resize the Expensify Cash application, the Call Options menu does not properly scale with the window. Sometimes it gets cut off, the position is off, and the spacing is wrong.
Action Performed:

Open Expensify.cash on Web or Desktop
Log into your account
Click into a chat with another user
Click the 📞 phone icon in the top-right, and see the Call Option menu
Click on any edge of the window and change the size of the window. See that the Call Option menu isn't dynamically moving with the size of the window.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Yes, Expensify is still usable and you can size the window in a way that allows you to select the options.

Platform:
Where is this issue occurring?

[X] Web
[X] Desktop App
[ ] iOS
[ ] Android
[ ] Mobile Web

Version Number: tested most recently on 1.0.22-1 (1.0.22-1)
Notes/Photos/Videos: See GIF recording below:

Expensify/Expensify Issue URL: https://github.com/Expensify/Expensify/issues/159934
View all open jobs on Upwork

Posted to Upwork today.

Triggered auto assignment to @tgolen (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

@michaelhaxhiu
The solution to this issue to update option box x,y coordinatewhen we resize the window. so to do this we need to add this code in VideoChatButtonAndMenu component and measureVideoChatIconPosition function already in code
componentDidMount() {
        window.addEventListener('resize', this.measureVideoChatIconPosition);
    }

    componentWillUnmount() {
        window.removeEventListener('resize', this.measureVideoChatIconPosition);
    }

Thanks

@aliabbasmalik8 Can you please update your proposal to conform to our cross-platform strategy (which can be found in the README of the repo).
Also, are there any performance concerns with your solution, and should it maybe use throttling or debouncing?

@tgolen Here is another solution
https://github.com/Expensify/Expensify.cash/blob/ba700bfa48c9b46cbd5e2bc9e05547207de6dcf1/src/components/VideoChatButtonAndMenu.js#L91-L94
We need to just update anchorPosition in these ways and it's working fine
anchorPosition={{
      right: 55,
      top: 52,
}}

NOTE: Can update this solution https://github.com/Expensify/Expensify.cash/issues/2517#issuecomment-825411911 according to your requirements but I think the new solution is more accurate.

@Luke9389 Would you mind chiming in on the above proposal to see what you think since you originally wrote some of this?

Just a few thoughts, I think the solution to this issue should be applied to POPOVER. So that it works for all menus like this.

Emoji Picker
Call.
Right-click Context menu.
...more.

Yes we can add default values in Popover component.
https://github.com/Expensify/Expensify.cash/blob/ba700bfa48c9b46cbd5e2bc9e05547207de6dcf1/src/components/Popover/index.js#L11

When I wrote this we were aware of this issue and decided to leave it. @roryabraham and I had discussed refactoring our popover menus and knew that this would be addressed then.
@aliabbasmalik8's most recent proposal resembles my initial approach to this problem. We sided against that because it absolutely positions the menu on the screen rather than "attaching" the menu to the button.
I think we should close this issue and address this on an Internal PR to refactor all of our Popover Menus. I know this is something @roryabraham  had expressed interest in doing.

@roryabraham what are your thoughts on this? How involved would it be to refactor the popovers? What would the refactor be doing?

Sorry, meant to reply to this yesterday.
The idea behind the refactoring @Luke9389 is referring to would be to create a generic menu component which would be reused between the CreateMenu, the VideoChatButtonAndMenu, etc... However, I sort of think that some of those menu components have diverged enough that the refactoring doesn't make sense anymore. Even so, the anchorPosition is always going to be supplied by the parent, so imo DRYing up the menus isn't the best way to solve this problem.
In regards to this issue, I think it can still be external. The task at hand is to remeasure the position of the Popovers' anchor point when the window dimensions change, and to then pass the updated anchorPosition to the Popovers.
I think that the best solution here is to refactor the withWindowDimensions (or create a new wrapper component) that takes in an onDimensionsChange prop that is debounced to execute every 200ms or so when the window dimensions change. Then, in each of the places we use onLayout or measureInWindow to dynamically determine a popover location, use that HOC or wrapper component to remeasure the position of the menu's anchor point and pass the updated anchorPosition prop to the Popover.

That means that I don't think the solution to this can be applied in the Popover itself as @parasharrajat has suggested, because it is the responsibility of the parent component to provide the anchor position, and the Popover itself shouldn't be changing its own props.

Looking into it some more, we could probably still do the generic menu component refactoring like @Luke9389 and I talked about – basically take BaseCreateMenu and make it a reusable component to DRY stuff up a bit. But I think that's a separate issue because it would still take in an anchorPosition as a prop, and it would still be the responsibility of the parent components to manage that piece of data. Hopefully that makes sense.

Yeah.anchorPosition should be managed by the parent. But then we have to manage the same logic at multiple places so I suggested moving that into Popover. Is it possible that we pass the ref of anchor down to Popover to manage its positions with some offset props to adjust it from a parent?
WithWindowDiminensions should be refactored at the moment, it is keeping the js thread busy unnecessarily. It should only emit when there is a resize event, oppose to what it does currently. Also, Debouncing would be good.

Is it possible that we pass the ref of anchor down to Popover to manage its positions with some offset props to adjust it from a parent?

It's possible, yes, but that seems quite convoluted to me.

WithWindowDiminensions should be refactored at the moment, it is keeping the js thread busy unnecessarily. It should only emit when there is a resize event, oppose to what it does currently.

There is also the concern that we don't want to create a bunch of duplicate onDimensionsChange listeners. Maybe we should consider nixing withWindowDimensions entirely, and instead leverage Onyx as the single source-of-truth for window dimensions and onDimensionsChange callbacks. @tgolen curious what you think of that? We could still provide the window width, height, and isSmallScreenWidth to the components that are currently using withWindowDimensions via withOnyx, but then we would have only one global onDimensionsChange listener.

Also, Debouncing would be good.

Of course, I agree debouncing would be good. I suggested 200ms because my rule-of-thumb (taken from some random StackExchange thread) is that it takes 250ms for the human eye to register visual changes/movement, so 200ms is as infrequent a debounce as possible to still have changes appear instant.

I really like the idea of storing this data in Onyx and let components subscribe to it whenever they need it. I like the debouncing idea as well. The way I think that could work is like this:

In Expensify.js use Dimensions.addEventListener()
When a dimension change happens, fire off a new action DimensionListener.set()
The new action handles the debounce (making sure to execute immediately for the first call) and then stores the value into Onyx
Any parents that are rendering a popover would subscribe to the new Onyx key and use those props to calculate the anchorPosition for any popovers
Bonus: replace withWindowDimensions everywhere

Yeah?

I think it would be overkill. Any specific reason for sure keeping it in persistent storage? Instead, create a top-level provider for Dimensions and consuming it in withWindowDimensions could be an option.

Instead, create a top-level provider for Dimensions

@parasharrajat For now, Onyx is the only mechanism we have in place for global event emission, and it just happens to rely on persistent storage. I've toyed with the idea of creating a subset of Onyx keys which aren't saved, and that could allow us to use Onyx as a pure event emitter for data that doesn't need to be persisted. Doing so could potentially reduce the footprint of the app and speed up event emission for those keys. But I think that solution would be overkill. So I'd suggest we just use Onyx as-is for now, and if there is some problem where we need to reduce the bundle size or we're seeing performance issues with onDimensionsChange event handling, then we can revisit.
Another alternate solution would be to use some other mechanism for global event emission, such as Node.js' EventEmitter, but again I feel it might be overkill introduce a new code pattern in the codebase when we can just use Onyx.

Looking for an update as 1 week as elapsed, which means the job is now priced at $500.00 (instead of the original $250.00). 💰
@aliabbasmalik8 and @parasharrajat, do either of you intend to take this job using the latest Onyx method suggested by @roryabraham & @tgolen?

@michaelhaxhiu I think someone is already working on this one so I didn't pick it.

@parasharrajat I'm certain this job is not yet assigned. 😺

@aliabbasmalik8 has expressed interest first and can choose to take on this job. But I'd like to hear a confirmation from that individual based on the latest discussions and onyx method, as they haven't commented in about 8 days.

If they don't respond in the next few days, I'm happy to give you this job if you are open to it @parasharrajat!

@michaelhaxhiu
Thanks for waiting for me but I didn't understand the latest suggested solution so no more interested in this job.
Thanks

@aliabbasmalik8 no problem and thanks for being responsive. In case you are interested in working another job, please take a look at our Upwork job list.
@parasharrajat I'm going to assign you and hire you in Upwork, can you please send an offer on the post here?

@michaelhaxhiu All set.

Hired ✅. Feel free to start on a PR in the next few days @parasharrajat


Fix iOS application crash when formatting TXTRecordData

This fix addresses the presented issue in #65 and implements the changes suggested.

Remove the package changes and I'll merge this 🙂

I reverted the changes and kept the version bump to 0.11.4

Thanks 👍


Make auto_offset_reset now work as expected for new consumer groups

Fixes #241

@ottomata Thanks for this!
@emmett9001 The build is hanging on:
test_consume (tests.pykafka.test_balancedconsumer.BalancedConsumerIntegrationTests) ...

Travis CI is killing it after hanging for 10 minutes. Any ideas?

Oh, I bet you that since auto_offset_reset=-1 works now, the test is now waiting for a new message to be produced, since it is trying to consume from the end of a topic.

It occasionally hangs on that test on my machine too - it's a quirk presumably inside BalancedConsumer that we've not figured out so far. I've restarted the build.

Hmmm, seems stuck again. Maybe it's not that quirk, and @ottomata's explanation is right - did you run the tests locally?

I was able to get tests to run by setting auto_offset_reset=-2 for the BalancedConsumers created by BalancedConsumerIntegrationTests.  I will submit a patch to do this, and I will try to add a new test that also tests auto_offset_reset=-1

@ottomata mind merging current master into this branch before continuing to test? I just updated it to use tox, which allows us to make sure bugfixes like this remain compatible with py34 and pypy.

@emmett9001 and I discussed this in IRC and agreed on a better solution.  I'll submit that in a new pull request.