Define "retry" logic

There is some language in the requirements around retrying a corroboration, but it is so far limited to the following (paraphrasing):

A retry of validation on a single perspective is not allowed. If a retry is required, all corroborations from previous attempts must be invalidated, and all perspectives need to retry.

The current API specification puts a further constraint on how a retry would function, by forcing a non-predictable-yet-deterministic selection of perspectives from the pool of known perspectives. This will select the same set of perspectives every time a check is run. It effectively mitigates the risk of an adversary retrying many a check times until enough hijacked routing tables are checked to result in a false quorum (with the assumption that the check selects a truly random set of perspectives each time).
This mitigation technique has the disadvantage of constraining what legitimate retry logic can be implemented, as it effectively forces the same perspectives to be tried over and over.
An alternative approach to mitigating the same risk, while enabling retry logic that interrogates distinct sets of perspectives, is to constrain the number of retries. This carries its own implementation complexity, however, since tracking the number of corroboration attempts per domain or IP target is a stateful concern and serverless functions should be stateless. And leaving tracking of retries as a burden for the API client to manage (i.e. not having an out-of-the-box risk mitigation against brute-force retries) is undesirable.
So, what designs are available to us if we want to enable effective retries while limiting the number of retry attempts?
I propose the following idea (@birgelee this may be more-or-less what you already have in mind):
Given a set P of all known perspectives, an interrogation subset size (perspective count) C <= |P| and ⌊|P|/C⌋ = N (integer division):

If N = 1, i.e., two disjoint subsets of perspectives of size C cannot be defined, then for any given domain or IP target T, a subset S ⊆ P should be defined based on a function f where S = f(P,C,T) and the same values for P, C, and T always yield the same S. Furthermore, S should not be easily predictable.
Example: P = {p0, p1, p2, p3, p4, p5, p6, p7}, |P| = 8, C = 6, and ⌊|P|/C⌋ = 1. Then one valid subset may be S = {p1,p2,p3,p4,p5,p6}. And it must be the same subset for the same target T each time.

Else if N > 1, i.e., N disjoint subsets of perspectives of size C can be defined, then it is valid to define N subsets and for corroboration to interrogate any of these subsets. This list of subsets should be defined based on a hashing function h where [S1..SN] = h(P,C,T) and the same values for P, C, and T always yield the same list of subsets [S1..SN]. Furthermore, the elements of each subset should not be easily predictable.
Example: P = {p0..p13}, |P| = 14, C = 6, and ⌊|P|/C⌋ = 2. two valid subsets are S1 = {p1,p2,p3,p4,p5,p6} and S2 = {p7,p8,p9,p10,p11,p12}, with S1 ∩ S2 = { }. And they must be the same subsets for the same target T each time.

Scenario 1 above is how the code currently works for all values of N.
Scenario 2 will require defining a function h that can deterministically sort the elements of P into N buckets of size C.
It may also be a good idea to have the subsets ordered deterministically relative to each other.
Example: P = {p0..p19, |P| = 20, C = 6, ⌊|P|/C⌋ = 3. Given T = example.com, h(P,C,T) always returns [{p1,p4,p7,p10,p13,p16}, {p2,p5,p8,p11,p14,p17}, {p3,p6,p9,p12,p15,p18}].
Such a setup allows for a max-attempts field to be made available in the API spec.

The MPIC service can first attempt corroboration with the first subset from h.
If it fails, then the service can carry out up to max_attempts - 1 retries as part of a single API call, since it can track what subset Sx is used for each remote corroboration attempt.
The service can have baked-in retry logic to use a previously-unused subset until no unused subsets remain.
If no max-attempts parameter is set, it can just use the first subset for its single corroboration attempt.

This would give the API client a certain level of flexibility. The client can retry as many separate API calls as they like, however each separate call will use the same set of remote perspectives. And the client can execute several corroboration attempts per API call, configured by max-attempts, with the above constraints on how perspective "cohorts" are determined.
It would also not force an upper bound on the number of retries, something that is good about the current implementation as well, while providing some more value to multiple retries, up to a point (effectively limited by how many remote perspectives the API owner is willing and able to deploy).
This setup also makes it as simple as it is today to meet the BR specification that any previous corroboration results must be discarded when executing a retry.
Edit: Adding that in all cases the perspective groups selected would adhere to BR requirements specifying a minimum of 2+ corroborating RIRs, and a minimum distance of (currently) 500km between perspectives.

I like this approach. I would add one point. There may still be some value in retries if N = 1 so long as P > C. Essentially this is the case where there are more available perspectives than the number being chosen but there are not twice as many so that two distinct cohorts can be produced. Imagine deployed perspectives P = 10 and chosen perspectives C = 6.
Here the perspective counts cannot be divided into multiple cohorts. However, there is still substantial potential for use of alternate perspectives. To improve performance in these cases, I propose an additional form of retry logic to be used when N = 1 and P > C.
Assume the chosen perspectives C are deterministically chosen given a random seed. On attempt one generate the seed from the hash of  h(domain | 0)   where | represents concatenation. On attempt two generate the seed from h(domain | 1) etc. Limit this behavior based on the max attempts value.
I think when N>=2 the proposed solution with cohorts is preferable because it ensures that for every retry no previous vantage points will be reused. However, I think there may be value in offering some retry logic even when N=1
My recommendation for the code would probably be a hybrid approach, the system attempts to derive cohorts if possible, but otherwise relies on this type of hash salting.

Seems like a good addition to me.
So, overall I'd say this is fairly complex logic. As far as the API spec is concerned, I suppose the only real implication is the new max-attempts parameter. Or should we describe the entirety of this logic within the API spec?
It feels complex enough that it may even warrant some kind of documentation based on formal notation (if not in the API spec, certainly in the open source implementation's docs). I'm not really practiced at that. Know anyone who is?

I would like to keep the logic out of the API spec. other implementations might conform to the spec but not implement logic this complex. I would add a max-attempts param to the API spec and keep it at that.
There should be some documentation. I'm not sure if there is a particular formal notation you had in mind. In a paper we would probably represent something like this in pseudocode. I could begin producing some documentation along with the implementation.
Another point: I would probably also recommend two separate parameters to control retry logic. The first is max-attempts which is a very simple control on how many times the API should retry. The second I would think of as something like max-perspective-sets which defines a hard cap on how many distinct sets of perspectives will be used for any particular identifier. If max-attempts > max-perspective-sets some number of retries with the same sets of perspectives may be used.

I agree that this logic doesn't have to be in the spec. (There's some documentation in the current spec regarding logic to prevent retry-based attacks within the perspective-count description, but we can revisit that later if it needs tweaking.)
The tests I plan to write will document the logic to some extent. Beyond that, I'll probably look at using some sort of formal notation, including set notation, just to keep things concise, and add some specification by example.
As for the max-perspective-sets suggestion, unless I'm not thinking about it right, that only makes sense for the N = 1 use case and only if the re-seeding retry logic is used as you suggested, and only if at some point you want the retries to start re-using the same perspective set before you run into the otherwise theoretical limit of perspective combinations which is P choose C. (Though that limit could still be reached if max-perspective-sets is set high enough.)
For N > 1, the number of perspective sets used is N since the idea is the sets are disjoint. Unless, that is, you are thinking of generating a new list of disjoint sets once the first one is exhausted with retries. But that feels to me like a pathway to defeating the idea of deterministic perspective selection.
Overall I kind of feel this additional parameter adds an element of complexity to what the client should even think about doing with these parameters, with rather little intuition around how these two parameters might interplay. But that's just my initial thinking on it.

I was thinking about this a bit more and there were two points I would bring up.

I think it probably makes sense to remove any reseeding logic if we opt for the cohort behavior simply to avoid having two relatively complex retry systems implemented. Towards this end I am currently leaning towards only using cohorts when N >= 2 and using fully deterministic selection when N = 1
I would still recommend a max-perspective-sets parameter not in API calls but in some sort of configuration. It could even be a .py config file that is not intended to be edited by the person doing the deployment. I would think of the number of perspective sets being max(N, max-perspective-sets) , It is simply a way of putting an upper bound on N because high N can cause a security degradation. I also do not like the idea of the number of sets used increasing if the API is deployed in more regions. I know some CAs have discussed having a ton of perspectives to cause a high degree of variability in terms of where the MPIC requests come from. However, if N alone determines perspective set counts, this high region deployment will counterintuitively degrade security because it will increase N.

I would personally go for max-perspective-sets = 2 as this is the strongest security stance that still permits retries. In other words, even if 15 perspectives are deployed and 5 are used (potentially allowing for 3 cohorts), only two will ever be used for any given identifier even though this deployment has N=3.
Also, to clarify I think cohorts should be selected deterministically based on a seed derived from the identifier queried.

Ok, I see what you're getting at.
So for the API spec, it's just a max-attempts parameter at the top level and the rest is implementation-specific, with perhaps some "must"/"should" language like the spec currently has about implementations.
(And I suppose the rest of this conversation is now squarely about the specific spec implementation and not the API spec per se, so we can maybe continue this conversation in an issue I'll open in the reference implementation repo. The rest of what I'd like to talk about is definitely implementation-specific.)

I am in favor of perspectives being moved to diagnostic only. Its quite helpful for some internal API call work we have done at Princeton so I would prefer that over it getting removed.
I would propose an optional max-attempts parameter under system-params since it affects both validation and caa behavior.

Max-attempts is now implemented in the retry-logic branch . If this looks good I will merge it in. I propose additional retry discussion move to the implementation repo.

Thanks @birgelee, that looks good.

Thanks @sciros . I merged in the branch and updated the version to 1.0.2 . I am closing this discussion here and additional discussion I propose move to the implementation repo.


Simplify get started - condensed

https://mlem-ai-simplify-get-st-rnmia5.herokuapp.com/doc/get-started
Here, I'll create an alternative where there is a single get-started scenario, but will use some alternative paths in this scenarios (so the user can choose).
Details:

used tabs for alternative model prediction (python, cli)
kept local model serving as a distinct stage (because it's "basic" and simple)
used tabs for alternative production deployments (docker, heroku) - we can add kubernetes here IMO. But I will wait with this until a more high level discussion about the structure is done

Hi @iterative/websites ! I would love your assistance in preparing this suggestion / use case
I would like to experiment with introducing alternative use-cases to the get-started scenario of mlem, similar to the "CML Use Cases" in cml.dev. Here, there's no need for a switcher (e.g. gh,gl,bb) just a one-level tab system which I would hopefully be able to embed and reuse 2-3 times in the get-started page.
It's totally fine if I would have to break the page down to multiple markdown pages or similar.
Currently the docs are "pure markdown" (meaning, I don't see an easy way for me to introduce this without changing the site's structure in addition to bringing-over/creating a tab component similar to JSONTabs in cmldev).
Can you please help me out with this - provide me some simple tab structure/component in this branch I can then use?
Would appreciate the help 🙏

@omesser, if you would like to make something like this (from https://cml.dev/doc/cml-with-dvc):

Then you need to use something like
<toggle>
<tab title="GitHub">
...
</tab>
<tab title="GitHub">
...
</tab>
</toggle>

see this file as an example https://raw.githubusercontent.com/iterative/cml.dev/master/content/docs/cml-with-dvc.md

In addition to @aguschin suggestion of using tabs, I think we can also use <details> tag if tabs don't make sense.
Example: https://dvc.org/doc/user-guide/overview#comparison-with-related-technologies
Usage:
<details>

### Title

...
content
...
</details>

@omesser, if you would like to make something like this (from https://cml.dev/doc/cml-with-dvc):
Then you need to use something like
<toggle>
<tab title="GitHub">
...
</tab>
<tab title="GitHub">
...
</tab>
</toggle>

see this file as an example https://raw.githubusercontent.com/iterative/cml.dev/master/content/docs/cml-with-dvc.md
Curious to see how it will look like)

Thanks @aguschin  - that toggle/tab system is exactly what I was looking for 🙏

In addition to @aguschin suggestion of using tabs, I think we can also use <details> tag if tabs don't make sense. Example: https://dvc.org/doc/user-guide/overview#comparison-with-related-technologies Usage:
<details>

### Title

...
content
...
</details>

Re<details> - thanks @yathomasi we're already using this quite extensively, was looking for tabs specifically!

@aguschin @mike0sv @jorgeorpinel  - please take a look and compare this with

what we have today
https://github.com/iterative/mlem.ai/pull/228

Would like to hear your thoughts

For me this feels like a lot of text for one page 😄 I mean that I'd probably cut a lot of extra explanations and leave just something like this "Here's how to do X: different approaches. It just works. Next, how to do Y...". I'll try to make a draft like this just to see how it looks

Agree with @mike0sv - I was thinking to hide serve/build/deploy behind a single toggle, TBH.
But this reminds me of discussion we had in https://github.com/iterative/mlem.ai/issues/190#issuecomment-1274105160, TLDR, there I suggested something like:
I have [ CV | Table data | NLP ] task
...<the selected part is shown>...

I want to [ serve | build | deploy ] my model
...<the selected part is shown>...

And this ^ is a configuration page to my mind, not a GS. So if we unite serve/build/deploy behind a single toggle, I'd like not to get this configuration page, but get a Get Started.

Have a look at #244
It's a lot messier that this but it showcases my point I guess

I would like to experiment with introducing alternative use-cases to the get-started scenario of mlem, similar to the "CML Use Cases" in cml.dev. Here, there's no need for a switcher (e.g. gh,gl,bb) just a one-level tab system which I would hopefully be able to embed and reuse 2-3 times in the get-started page.

@yathomasi, is there a way to achieve something similar? Like nested toggles?
Tried this and it doesn't work:
<toggle>
<tab title="API inference example">

tab content

<toggle>
<tab title="tgg">

subtab content

</tab>
</toggle>

</tab>
</toggle>

It is available. We have already started using nested tabs eg: https://dvc.org/doc/install/completion#what-shell-do-you-have.

I just checked with the exact code you have provided on the current branch and it seems to be working.
Can you try yarn clean and run it again? cc: @aguschin

Sorry, late review but I hope still relevant since there seems to be a plan to follow up on this per

@omesser will make another PR on top of this taking some changes from #244

I turned #244 into a draft for now, BTW.

feels like a lot of text for one page...
hide serve/build/deploy behind a single toggle

Yep, not sure why this is called condensed when it adds back several things we had previously consciously removed (e.g. mlem serve and build). We also introduced significant more structure and the titles are confusing (Deploy, then load, then Deploy again but it's actually about building/packaging...). GS should be straightforward. Again, we had already decided to leave some things out. I think we should be a bit more careful with GS changes and avoid going in circles.

a way to achieve something similar? Like nested toggles?

Keep in mind this requires a lot of clicking so it's not ideal for this doc. Not even sure about the plain tabs TBH (GS should be linear ideally) -- but I guess it can be fine as long as the "happy path" is always visible in the first tab/ option.

@jorgeorpinel in this case tabs should work better I think (similar to GitHub/GitLab) in CML. MLEM is not DVC. Get started doesn't have to be same and/or complicated as in DVC. It is condensed since it's a single page vs multiple, less clicks and text overall I hope. Other things - yes, we should be clarifying and reviewing titles if that makes sense). Write your specific concerns somewhere please.

I have lots of specific concerns but since this review is late I decided to do a PR instead (didn't push it yet) ⏳

Please see Sagemaker and
for some more concerns.

Please see Sagemaker and
for some more comments and follow-up.


move fourier to its own repo?

or use https://www.npmjs.com/package/fourier

excelent! that one wasn't there last time ;)


Fixed power range to start at 1

Fixed the power range in section Over vs Underfitting, in order to start at value 1. This avoids having a 0th expansion which introduces additional bias.
This issue was raised in the session 02 forum here

Closed the fix and merged with another one also regarding section-02.ipynb


add security access headers for ocdav requests

Adds necessary security headers for ocdav requests.
For owncloud/ocis-reva#66

Hi @karakayasemi ,
take a look at the following page for default security configurations:
https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.1.1d&guideline=5.4
If we are providing some defaults, let's make sure they are aligned with the propositions above.

Hi @karakayasemi ,
take a look at the following page for default security configurations:
https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.1.1d&guideline=5.4
If we are providing some defaults, let's make sure they are aligned with the propositions above.

The only conflicting part that I see is the age of Strict-Transport-Security. I aligned it according to the example config.


bug 1939227: make liveness hit livez

livez didn't exist when we started.  Now it does.  Update.
We may want a startup probe distinct from livez now.
/assign @sttts

/bugzilla refresh

/bugzilla refresh

/lgtm
/retest

/bugzilla refresh

/lgtm

/override ci/prow/e2e-aws-operator
this test it known to be broken and it's pointless to re-test it, this is being actively worked on


Make TextRange constructors more boring

Remove fn TextRange( as that's slightly unusual and surprising,
which will add up to a lot of confusion over the long run.
Instead add:

new as the biased, canonical way to create range from bounds
from_len as an alternative ctor from starting position and len
empty for empty ranges at a given offset
up_to for ranges at zero offset with given length
default for an empty range at zero

bors r+

bors r+


git town config - print perennial branch trees

resolves #1140

@charlierudolph sorry about that. It must have yanked you from all teams as part of off-boarding. I have added you back to the gittown-admins team, and also given you push access to the master branch. Please try again.


Create logical way of combining Configuration instances copying 'settings' / policies

With the introduction of a 'missing' policy, creating a new Configuration instance from an existing one leads to confusing results as __init__ doesn't magically copy or merge the settings from its arguments. Having a 'more logical' call for this that makes it very clear which settings are copied from where would ease this.
An instance method makes sense in order to be able to access the settings of the instance that is to be used for inspiration. An in-place update might get scary, returning a newly merge Configuration is 'safer', if that can be done without surprises.

An instance method would also 'reserve' any wording for that as an attribute, something like confidence.merge(a, b) could

default to making sure a and b use the same settings
allow overriding settings as keyword arguments

without reserving anything :thinking:


Doc (registry): Update to the image registry doc

While using the "Configure image registry" doc, I noticed some improvements which could help users. This PR adds these improvements.

Thanks for the review @mikebrow. Updated and ready for review again.


iOS navbar .center is not actually centered when the number of buttons on L/R side is not the same

When the number of buttons on the left/right side of the navbar is not the same, the navbar title shifts to the side which has less buttons, but as seen on the screenshot there is enough space to accomodate for all the buttons and the title.
Sure it can easily be fixed by forcing the width of the smaller .left/.right div, but it would be nice if it handles it somehow automatically.

And the same issue is true when left and right sides has 1 and 0 buttons, which is quite a lot more common.

It will be rendered correctly no matter of what is in the left or right elements. Just make sure it was added before page init, otherwise just call sizeNavbar method http://framework7.io/docs/navbar.html#related-app-and-view-methods

Hey,
I've got the same issue with the Material theme.
Below is my navbar. The title always shifts to the left near the back button. I also tried sizeNavbar, but it didn't change it.

                                  Back

Title

Am I doing anything wrong or is it just the Material theme?
Thanks!


Add Diff to gh-pages

Do you think this makes sense for difference report?

Closing to fix commit user


feat: convert main.tex into responsive web page with Engrafo

This PR adds the GitHub workflow that renders static web assets generated from main.tex with Engrafo^1 and deploys them to GitHub Pages.
If you want to know how this works, check out my folk repo.

great work, thank you!


[FEATURE-TRACKING]: ksctl k8s event driven architecture

Purpose
enable more management capabilitites for ksctl
Feature Name
ksctl k8s event driven architecture
Feature Description
purpose: to make controllers for each feature like:

scaleup/scaledown (cluster autoscaler)
cloudprovider based loadbalancer
application installer
health checks
etc.

Sub-Actions

[ ] #107
[ ] #179
[ ] #220
[ ] #251

Benefits
with a single consumer aka (ksctl-agent)
we can have multiple controllers and crds under ksctl.com domain
and ksctl-agent will have all the logic how to interact with different cloud providers, provided the controllers does the kubernetes specific logic what happsn and which endpoint of ksctlagent to call
Potential Drawbacks
It will require us to rewrite the logic of existing application install
Alternatives Considered
No response
Scope of changes

[X] Cli
[ ] UI
[X] Docs

Agreement

[X] I agree to engage in constructive discussion and follow the Contribution Guidelines.

@dipankardas011 add the diagram for the overall overview of the event driven archeticture


feat: add topic validators to pubsub

Clean up validation in pubsub, add topic validator functions

validate method now has additional peer arg and triggers topic-specific validation functions
topicValidator is Map<string, (topic, peer, message) => unknown>

topic validators can be added / removed here

topic validation results can have additional processing overridden with _processTopicValidatorResult - default to truthy results passing validation

cc @jacobheun

Codecov Report

Merging #75 into master will increase coverage by 0.20%.
The diff coverage is 94.11%.

@@            Coverage Diff             @@
##           master      #75      +/-   ##
==========================================
+ Coverage   84.41%   84.61%   +0.20%
==========================================
  Files           8        8
  Lines         494      507      +13
==========================================
+ Hits          417      429      +12
- Misses         77       78       +1

Impacted Files
Coverage Δ

src/pubsub.js
86.62% <94.11%> (+0.46%)
:arrow_up:

Continue to review full report at Codecov.

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

Is there any reason for not adding this to libp2p-pubsub?

I've been viewing these two open PRs (#75 and #74) as sort of clean up tasks so that this src/pubsub.js may be merged into libp2p-pubsub. (And so that this pubsub impl "has what we need" for the gossipsub v1.1 upgrade)
I think for this one, one of the bigger reasons I didnt' PR directly into libp2p-pubsub is bc this would be a breaking API change to the validate function. (from async (message: RPC.Message) => boolean to async (peer: Peer, message: RPC.Message) => boolean)
Somehow it seemed simpler to explore this with my pseudo libp2p-pubsub impl before having the broader discussion about merging breaking functionality back upstream.
Happy to make the PR to libp2p-pubsub if you think thats better tho.

@wemeetagain seems a good approach. We can start here and then iterate to js-libp2p-pubsub then! I will make sure to review this PR tomorrow


incorporate express changes for pricing-cards

Describe your specific features or fixes
Resolves: MWPW-143422
Test URLs:

Pre Migration Link: https://adobe.com/express/pricing
Before: https://main--express-milo--adobecom.hlx.page/express/pricing
After: https://MWPW-143422-sync--express-milo--adobecom.hlx.page/express/pricing

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 64.61%. Comparing base (47c9af1) to head (3669aa2).

Files with missing lines
Patch %
Lines

express/scripts/utils/pricing.js
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #75      +/-   ##
==========================================
+ Coverage   64.04%   64.61%   +0.56%
==========================================
  Files          41       41
  Lines        6445     6437       -8
==========================================
+ Hits         4128     4159      +31
+ Misses       2317     2278      -39

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Clarity the Licence of the code

Hello, I found this project, and I am a bit tempted to hack on it for a bit.
But I am unsure what is the licence of the code and exactly what can be done with it.
Could you clarify the licence that you had in mind for this code?
Thanks

Added MIT License to this repository, check it out here.


Add support for the @availability annotations

Closes https://github.com/elastic/elasticsearch-specification/issues/2107

Removed the individual @since, @stability, and @visibility annotations in favor of @availability with those annotations now being set via key-value pairs.
Always set availability.stack.* to the values from the rest-api-spec stubs for now, in the future once the Elasticsearch specification becomes the source of truth we can remove this.
Updates all existing request definitions to use the new annotation.

Thanks @swallez, I've applied your feedback!

Thanks all for the reviews!

It looks like this covers us for Requests (in effect APIs). Do we have any thoughts about how we'll handle stack/serverless differences for parameters and fields?

@tvernum I'm planning on using a similar approach with @availability to document parameters which are available on the Stack but not Serverless. I'll have to document in the modeling guide that if no @availability annotation is given then the property/request/value is available in all flavors of ES.


[Task]: Get all installed packages for an application

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
No response

We have decided not to have such a flow. The modules under published packages should be available by default.


Gruntfile to generate dist files

Does the following:

processes SCSS files
minifies CSS files
copies JS file
uglifies JS file

Just run npm install, then grunt.
I also removed the CSS files in src, since they are dist files.
Also added a .gitignore.
I checked that it was still working using the demos.

:+1:


Data down-sampling for visualization

for systems with too many grid points (> millions), we need to down sample the data
i.e. instead of visualizing every grid point, we can visualize every other one.
it would be nice that the down-sampler could be controlled on the fly

after improving the performance and memory management, this seem to be unnecessary for now


speech_to_text's example might have a typo

❓ Questions and Help
What is your question?
Am I misusing script or do we have a typo?
Code
python fairseq/examples/speech_to_text/prep_librispeech_data.py

creates an error:
Traceback (most recent call last):
  File "prep_librispeech_data.py", line 14, in <module>
    from examples.speech_to_text.data_utils import (
ModuleNotFoundError: No module named 'examples'

What have you tried?
changing source code to:
from data_utils import (
    create_zip,
    extract_fbank_features,
    gen_config_yaml,
    gen_vocab,
    get_zip_manifest,
    save_df_to_tsv,
)

seems to work then...
What's your environment?

fairseq Version 0.10.2
PyTorch Version 1.10.2+cu113
OS Debian GNU/Linux 11 (bullseye)
How you installed fairseq (pip, source): clone source, pip install path/to/fairseq
Python version: 3.7.11
CUDA/cuDNN version: cu113
GPU models and configuration: RTX 3050 TI

you may add the path of fairseq root to your PYTHONPATH, input this in shell script:
export PYTHONPYTH=$PYTHONPATH:/path/to/your/fairseq
so that python can find 'examples/speech_to_text/prep_librispeech_data.py' to execute.

Yep you are right, sorry didn't think of that.


Eleventh Community Call

Next call will be at Tue July 28th at 10am CEST (0800 UTC,1:30pm India, 5pm Korea). The time is selected to be accessible to European and Asian-based projects. We will alternate times, every 4 weeks at this time, and every 4 weeks (with 2 week offset), at a more US-friendly time - 6pm CET.
Agenda:

The road towards CosmWasm 1.0
Announcing 2 CosmWasm-powered testnets
CosmJS updates
Open Q&A

Zoom link: https://zoom.us/j/627731807?pwd=aHlGZzBKUUsxd0hrdURUY2wrR2poUT09
(This is same for all meetings at Asia-friendly times)

Video recording is available here:  https://vimeo.com/442300427


Refs 282: also deploy to stage-stable

lets see if this works

https://issues.redhat.com/browse/HMSCONTENT-282

⚠ This task currently requires qe-approval, but this PR does not fully resolve the task.  Please contact QE to determine appropriate testing required.


Intellisense doesn't work.

Describe the bug
I can see the icon inside the attribute, but the intellisense doesn't work. Any idea? I'm using a Nuxt 3 project with NuxtLab UI.
<UButton icon="i-heroicons-magnifying-glass" />
My file settings.json is empty during test.
Reproduction
local
System Info
System:
    OS: macOS 12.6.8
    CPU: (8) x64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
    Memory: 302.67 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.16.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.8.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 115.0.5790.114
    Safari: 16.6

Used Package Manager
yarn
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

We temporarily close this due to the lack of enough information.
Please provide a minimal reproduction to reopen the issue.
Thanks.

Why reproduction is required

I'm having the same issue... If I rollback to v0.5.4 then the intellisense typeahead works again.
To reproduce:

In a compatible file/attribute type a prefix and then : - this normally triggers the typeahead for that particular iconset.

In v0.6.0 and 0.6.1 nothing happens. However, if you happen to type a valid icon name it does render.

v0.6.0 & 0.6.1

v0.5.4

+1


[Improvement] Add reference to GitHub copilot documentation

Why:
Closes #21159

What's being changed (if available, include any code snippets, screenshots, or gifs):
This PR adds a reference to GitHub Copilot documentation in the Codespaces documentation, making it easier for Codespaces users interested in Copilot to move through the docs.

Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Vào Th 6, 7 thg 10, 2565 BE lúc 10:20 github-actions[bot] <
@.***> đã viết:

Automatically generated comment ℹ
This comment is automatically generated and will be overwritten every
time changes are committed to this branch.
The table contains an overview of files in the content directory that
have been changed in this pull request. It's provided to make it easy to
review your changes on the staging site. Please note that changes to the
data directory will not show up in this table.
Content directory changes
You may find it useful to copy this table into the pull request summary.
There you can edit it to share links to important articles or changes and
to give a high-level overview of how the changes in your pull request
support the overall goals of the pull request.
Source Preview Production What Changed
codespaces/codespaces-reference/using-github-copilot-in-github-codespaces.md
fpt
ghec
fpt
ghec
fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server
ghae: GitHub AE
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Triệu Nguyễn

@bpires Thanks for the contribution!
If you're interested in picking up a project as part of Hacktoberfest, check out the pumpkin-spice label 🎃


[swarm] load-balancing not working as expected

Output of docker version:
Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:04:48 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 23:54:00 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 2
 Running: 2
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 11
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host null bridge overlay
Swarm: active
 NodeID: 2jml8zh2ap8gnw3ghchc03g09
 Is Manager: true
 ClusterID: 1h8ug9o7h7ihgspy7wmgr7z68
 Managers: 2
 Nodes: 5
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot interval: 10000
  Heartbeat tick: 1
  Election tick: 3
 Dispatcher:
  Heartbeat period: 5 seconds
 CA configuration:
  Expiry duration: 3 months
 Node Address: <IP_ADDRESS>
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.16-boot2docker
Operating System: Boot2Docker 1.12.0 (TCL 7.2); HEAD : e030bab - Fri Jul 29 00:29:14 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.9 MiB
Name: master1
ID: XFBC:QIPK:ZJH5:MGSZ:D6IA:32XG:TUHL:6E43:HXOQ:FVLW:OY64:HWD4
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 55
 Goroutines: 212
 System Time: 2016-08-04T08:18:26.116262192Z
 EventsListeners: 2
Username: rogaha
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:

docker service create --name service1 --network whoami-net -p 8000 jwilder/whoami
docker service scale service1=3

Describe the results you received:
rogaha@Robertos-MacBook-Pro:~$ docker service inspect service1                                                                                1:37:42
[
    {
        "ID": "cojb16cncgj76z0sslxt015bc",
        "Version": {
            "Index": 112
        },
        "CreatedAt": "2016-08-03T15:15:33.784675129Z",
        "UpdatedAt": "2016-08-04T08:10:52.87831274Z",
        "Spec": {
            "Name": "service1",
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "jwilder/whoami"
                },
                "Resources": {
                    "Limits": {},
                    "Reservations": {}
                },
                "RestartPolicy": {
                    "Condition": "any",
                    "MaxAttempts": 0
                },
                "Placement": {}
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 3
                }
            },
            "UpdateConfig": {
                "Parallelism": 1,
                "FailureAction": "pause"
            },
            "Networks": [
                {
                    "Target": "cke02aohtbpspx5so5gc6a76x"
                }
            ],
            "EndpointSpec": {
                "Mode": "vip",
                "Ports": [
                    {
                        "Protocol": "tcp",
                        "TargetPort": 8000
                    }
                ]
            }
        },
        "Endpoint": {
            "Spec": {
                "Mode": "vip",
                "Ports": [
                    {
                        "Protocol": "tcp",
                        "TargetPort": 8000
                    }
                ]
            },
            "Ports": [
                {
                    "Protocol": "tcp",
                    "TargetPort": 8000,
                    "PublishedPort": 30000
                }
            ],
            "VirtualIPs": [
                {
                    "NetworkID": "5wgpghefhq0indqu50kbzee3v",
                    "Addr": "<IP_ADDRESS>/16"
                },
                {
                    "NetworkID": "cke02aohtbpspx5so5gc6a76x",
                    "Addr": "<IP_ADDRESS>/24"
                }
            ]
        },
        "UpdateStatus": {
            "StartedAt": "0001-01-01T00:00:00Z",
            "CompletedAt": "0001-01-01T00:00:00Z"
        }
    }
]

rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:18:26
I'm a2531712ae05
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:19:56
I'm a2531712ae05
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:09
I'm a2531712ae05
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:09
I'm a2531712ae05
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:10
I'm a2531712ae05
rogaha@Robertos-MacBook-Pro:~$

rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:10
I'm b0d6d239f694
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:45
I'm b0d6d239f694
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:46
I'm b0d6d239f694
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:47
I'm b0d6d239f694
rogaha@Robertos-MacBook-Pro:~$

rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:48
I'm af339bc5e1bf
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:21:00
I'm af339bc5e1bf
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:21:01
I'm af339bc5e1bf
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:21:01
I'm af339bc5e1bf
rogaha@Robertos-MacBook-Pro:~$

Describe the results you expected:
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:18:26
I'm a2531712ae05
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:19:56
I'm b0d6d239f694
rogaha@Robertos-MacBook-Pro:~$ curl http://<IP_ADDRESS>:30000/                                                                                1:20:09
I'm af339bc5e1bf

Additional information you deem important (e.g. issue happens only occasionally):

It might be related to networking as well, see below the details about the whoami-net overlay network:
rogaha@Robertos-MacBook-Pro:~$ docker network ls                                                                                2:47:32
NETWORK ID          NAME                DRIVER              SCOPE
0ea70f2651d7        bridge              bridge              local
ca341b9644c8        docker_gwbridge     bridge              local
34cd36e32e75        host                host                local
5wgpghefhq0i        ingress             overlay             swarm
4a514a524726        none                null                local
cke02aohtbps        whoami-net          overlay             swarm
rogaha@Robertos-MacBook-Pro:~$ docker network inspect whoami-net                                                                                2:54:59
[
    {
        "Name": "whoami-net",
        "Id": "cke02aohtbpspx5so5gc6a76x",
        "Scope": "swarm",
        "Driver": "overlay",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "<IP_ADDRESS>/24",
                    "Gateway": "<IP_ADDRESS>"
                }
            ]
        },
        "Internal": false,
        "Containers": {
            "61b9fb8d79a928641c2124fb893ba27b187236d55a513d68db152298a9e68643": {
                "Name": "service2.4.9gvvljb25qrm71c1jazvx4b7d",
                "EndpointID": "381e23fddbfb9bf05f39c9c07180030db65b9327d6c968c89df98be8ece6df1a",
                "MacAddress": "02:42:0a:00:00:0a",
                "IPv4Address": "<IP_ADDRESS>/24",
                "IPv6Address": ""
            },
            "a2531712ae053b426ab6957ab034ae476a26e7f6915d5a53705a91c654aaa66d": {
                "Name": "service1.1.c83vrhg87a0hxpfo0te4weat6",
                "EndpointID": "b61138779dd6247d743015fc559ae3c4dd544c03894bd4326f8d62dca275671b",
                "MacAddress": "02:42:0a:00:00:03",
                "IPv4Address": "<IP_ADDRESS>/24",
                "IPv6Address": ""
            },
            "c37dab81741fa972b6a9ade72367545f78ae0e454a9c784454d850a40da7f321": {
                "Name": "service3.2.8dkjkhz15ov94ktec6bcq1qa1",
                "EndpointID": "39daa00813add94d648a4bd1835644e83f685cb0efc8ae564e68b89afd143709",
                "MacAddress": "02:42:0a:00:00:10",
                "IPv4Address": "<IP_ADDRESS>/24",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.driver.overlay.vxlanid_list": "257"
        },
        "Labels": {}
    }
]
rogaha@Robertos-MacBook-Pro:~$

I saw similar issue and I think @mrjana suggested it had been fixed in libnetwork upstream

I am having the same issue as well. I don't think is related to the network, I am running the instavote/vote app, as it is demod on docker blog (https://youtu.be/F7hoq0KwHD4?t=155), and for some reason the load balancing across nodes is not working, when you access a node it only load balances to the containers that are running in that node and not in the others. I don't know yet if this issue appears only on the services with published ports or even in intra container communication.

@all do we need clarify the definition on  load balancing across nodes feature?  Does IPVS support random access the entrypoint?

any update?

It seems to be fixed on 1.12.2-rc1.

Closing


Enable db2 log rotatation

In the db2 tuning tasks there is a setting for db2 log rotation missing.
https://github.com/HCL-TECH-SOFTWARE/connections-automation/blob/9eb050fdad217266a0fed3e2e35ebaf9f0b20d62/roles/third_party/ibm/db2-install/tasks/apply_tunings.yml#L18-L25
It must be activated for better control of the log size.
https://www.ibm.com/support/pages/db2-how-rotate-db2-diagnostic-file-db2diaglog
Please add db2 update dbm cfg using DIAGSIZE {{ __db2_instance_diag_size }} in the tuning file.

Hi Martin, thank you for the feedback. Please submit a PR for this change and it will be merged into the Connections-Automation repository. Thanks again.


1.1.0.m2 script support

Description
Introduced new Event during param state initialization to be triggered when the model is instantiated new (Action: _new). This is different from model instantiation while resurrecting the state (Action: _get).
With this change, it would be possible to write Event Handlers which can take advantage of executing logic that should only be applied when the an entity is instantiated new for the first time. It can be viewed being analogous to providing arguments an Class constructor, which the constructor uses while instantiating the object.
Based on this foundational change to support the new event, the f/w now has a new extension called "@Script". Current support exists for inline SpEL, file based SpEL and file based groovy. Underlying implementation uses Java's ScriptEngine abstraction for Groovy and other supported scripting engines can be plugged-in in future.
Fixes # (issue)

Made change in Context Loader for f/w to now have the ability to make calls to QuadModel which is still in process of being initialized. For example, onStateLoad there could be a script which calls a _process on self via CommandGateway. Earlier, this would result in failure as the QuadModel was not yet registered in session

Overview of Changes

Added new Event: OnStateLoadNew
Made f/w changes to hookup corresponding Event Handler
Made f/w initState changes to trigger the new Event
Separated initSetup internally invoking initState from Root ExecutionModel
Responsibility to initialize state is now passed to the caller to decide when to initialize and not make it part of building of the param state itself
Corresponding change made in Action Executor Get to explicitly call initState

Type of change

[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] This change requires a documentation update

How Has This Been Tested?

[ ] EntityInitilizationTest

You did it @soham-anthem!
Thank you for signing the Anthem Opensource Software CLA.


BlockBuffer Constructor - Issue with Disk Full & Checking of Validity of args

Case when disk is full is not handled
Validity of Block types and Block number in Constructors
Constructor 2 doesn't check if the input block is actually occupied in the disk

DISK FULL ISSUE IS BEING MANAGED IN OTHER ISSUES


IS it possaible to connect to multiple LDAP authentication servers?

Hi all,
we need connect to Zulip extra LDAP authorization server. Our organization bought another one and we all want use Zulip as standard communication solution.
In programistic way I`m looking for option silimar to this:
AUTH_LDAP_SERVER_URI = "ldap://example.com,ldaps://example2.com/"

I seems to recall this just works: https://django-auth-ldap.readthedocs.io/en/latest/multiconfig.html.
Post in "production help" in chat.zulip.org if you find that doesn't work.

We can reopen the issue if the solution above doesn't work.


feat(preset-icons): add iconCustomizer option

Can I do this ? Maybe resolved #842

/cc @userquin you might have better idea on this

@chris-zhu
I think you did not understand me or I explained myself badly, what you have to do is add the unit and then add a custom iconCustomizer to add the w/h if it is not configured, but for this we first call the one provided by the user and then we configure the width and height if the user has not configured them before in their customizations:
             async iconCustomizer(collection, icon, props) {
               await providedIconCustomizer?.(collection, icon, props)
               if (unit) {
                 if (props.width !== undefined && props.width !== null) {
                   props.width = `${scale}${unit}`
                 }
                 if (props.height !== undefined && props.height !== null) {
                   props.height = `${scale}${unit}`
                 }
               }
             },

@userquin Thanks so much!


Fix #443

Change a let to var to work around a build failure on current Swift 6.0 toolchains

@swift-ci please test

@swift-ci please test


Documentation

There is a severe lack of documentation at the moment... Some should be written!

Does JS do docstrings?

No, JavaScript doesn't include any documentation thingies as a core part of the language. I use NaturalDocs, which I am not too happy with... Hmm...

What aren't you happy with?

....okay?


Reduction on a shifted set produces incorrectly bucketed QScript.

select count(loc[*]) from zips

This reduction should be bucketing on the row level ids of zips, but instead it's requesting a single bucket. The left shift should put the array indices onto the identities stack. Then we pop those off and bucket on the remaining stack. Instead, QScript is incorrectly requesting a single bucket Constant(Null()).
Reduce
├─ LeftShift
│  ├─ ShiftedRead(/home/apolune/spark_local_test/zips, ExcludeId)
│  ├─ Struct
│  │  ╰─ Guard
│  │     ├─ ○
│  │     ├─ Type(Obj(Map[], Some(Top)))
│  │     ├─ Guard
│  │     │  ├─ ProjectField
│  │     │  │  ├─ ○
│  │     │  │  ╰─ Constant(Str(loc))
│  │     │  ├─ Type(FlexArr(0, None, Top))
│  │     │  ├─ ProjectField
│  │     │  │  ├─ ○
│  │     │  │  ╰─ Constant(Str(loc))
│  │     │  ╰─ Undefined
│  │     ╰─ Undefined
│  ├─ IdStatus
│  │  ╰─ IdStatus(ExcludeId)
│  ╰─ Repair
│     ╰─ RightSide
├─ Bucket
│  ╰─ Constant(Null())
├─ Reducers
│  ╰─ Count
│     ╰─ ○
╰─ Repair
   ╰─ ReduceIndex(Some(0))

The above QScript produces an incorrect result of
 value  |
--------|
  58706 |

Instead we expect one result per row of the original dataset where each value is 2 (the size of each array zips.loc). Or phrased differently, the results are the counts of the number of rows per row level identity, after we flatten.
For a second example, if we consider
select sum(loc[*]) from zips

then we'd expect one result per row of the original dataset where that result is the sum of the values in each array.

The query select count(loc[*]) from zips will yield 2 * count(zips), assuming every loc contains two entries and every row contains a loc.
The query select count(loc[_]) from zips should yield count(zips) results, where every entry is a 2 (the length of each array), under the preceding assumptions.

Oh, looks like I confused [*] (flatten array) with [_] (shift array). In my original post, my intention was to flatten the arrays, putting the array indices at the head of the identity vector. But that is actually what loc[_] does, not loc[*]. I just verified the qscript for the loc[_] version of the query and it is correct (and is returning correct results in spark). Yay!
@jdegoes to make sure we're on the same page, in order to achieve the results you are expecting for the [*] version of the query, we'd need to be putting 2 pieces of information into the identity vector when we do the flatten, so that when we pop one off in order to do the reduction, each row has unique identities (i.e. each row will be its own bucket). Or alternatively we could be modifying the identities to achieve this some other way? If [*] flattens the array without affecting the provenance, then I'd argue that select count(loc[*]) from zips should instead return a single result because there would just be one piece of information in the identity vector after we perform the flatten, we'd pop that piece off, and then we'd reduce on a single bucket.

@alissapajer If you look at the specs, both track provenance, but only [_] adds a new dimension; the flattening operator merely tacks on more information to the end of the last dimension.
This is a difference between present QScript and the MRA spec. In MRA, foo[*].bar + foo[*].baz does a pairwise addition on array elements, and of course flattens the result, whereas I believe in QScript, it results in a cross—which is incorrect if true.

@jdegoes oh, yeah, I should have just looked at the spec :) we're all clear on that front, thanks! QScript is indeed handling [*] differently than what MRA prescribes.

Following up, QScript is actually returning the correct result for all the queries mentioned in this issue, including foo[*].bar + foo[*].baz and select count(loc[*]) from zips. I'm going to add some tests to make sure we maintain this behavior and will close the issue when those tests land.

@alissapajer So foo[*].bar + foo[*].baz returns an element-wise addition?

@jdegoes here is an example run on master against spark. Please confirm this is doing what you expect.
💪 $ select foo[*].bar * foo[*].baz from flattentest

 value |
-------|
    35 |
     6 |
   143 |
     6 |
   323 |
     6 |

And the data flattentest:
{"foo": [{"bar": 5,  "baz": 7},  {"bar": 3, "baz": 2}]}
{"foo": [{"bar": 11, "baz": 13}, {"bar": 3, "baz": 2}]}
{"foo": [{"bar": 17, "baz": 19}, {"bar": 3, "baz": 2}]}

An example identity vector for both foo[*].bar and foo[*].baz is ["flattentest", _id1 -> 0] with the two respectively corresponding values 5 and 7.

The result set looks correct to me. 👍

@jdegoes awesome. Glad you, me, and QScript are all on the same page :)

Keeping this issue open until we add integration tests for:
select count(loc[*]) from zips

select count(loc[_]) from zips

select foo[*].bar * foo[*].baz from flattentest

select foo[_].bar * foo[_].baz from flattentest

Hm, so what isn't working correctly is this query:
select foo[_].bar * foo[*].baz from flattentest

An example identity vector for the shift looks like ["flattentest", _id1, 0] and an identity vector for the flatten looks like ["flattentest", _id1 -> 0]. So the two sides should autojoin only as far as "flattentest", meaning we get a full cross across all rows after shifting/flattening. But alas the results in spark are the same as the version with foo[*].bar * foo[*].baz. This is a bug in QScript.

Actually, they will auto-join as far as _id (auto-join goes depth-wise, as well as length-wise).

Got it, so we'd expect a full cross within each row that shares an _id. So the results of select foo[_].bar * foo[*].baz from flattentest should have size 12.

Moving this to a later iteration since it no longer has the "initial production rollout" label, given the preceding commentary from August.


Update dracula theme

Make dracula theme work for 1.9x pterodactyl version.

https://github.com/Ferks-FK/Pterodactyl-AutoThemes/issues/15#issuecomment-1169916212


Error: node-canvas was built without SVG support

@charoitel Thank you for your great job. This saved lots of my time.
Although an error occurred in my lambda function, so I share the error log.
2021-06-10T03:56:35.901Z	4ca4fa3a-3b60-5c6b-98ad-a301b4c819ab	ERROR	Error: node-canvas was built without SVG support
    at setSource (/opt/nodejs/node_modules/canvas/lib/image.js:91:13)
    at Image.set (/opt/nodejs/node_modules/canvas/lib/image.js:62:9)
    at /var/task/socialImageDesigns/common.js:133:19
    at new Promise (<anonymous>)
    at Object.loadImage (/var/task/socialImageDesigns/common.js:125:12)
    at Object.create (/var/task/socialImageDesigns/textNote-type1-ver1.js:63:41)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async /var/task/socialImages.js:30:35
    at async Promise.all (index 0)
    at async Runtime.exports.main [as handler] (/var/task/socialImages.js:11:5)

Will you be planed to rebuild node-canvas with librsvg ?
The same error was reported in the node-canvas repo and the cause is building without librsvg
=> https://github.com/Automattic/node-canvas/issues/1484#issuecomment-640255501

@kozo002 Thanks for raising the issue here, I have updated the release on AWS Serverless Application Repository. Please try again with the latest release and let me know if there is still any issue? Thank you.


:nail_care: increment cache value

:rocket: deployed to http://profiles-pr-87.dev.c2s.nhschoices.net


Commands can be dispatched to handlers

Solution to issue #128

The code looks good, though the test code is getting messy. We may need to refactor is later to make things cleaner, remove duplication. This may be a sign that our unit tests are more integration tests, and we've coupled them together too strongly.


Redis for http caching

Hello. How can I implement Redis for http caching?

You need to create a new component for that. There is no support for client caching.

Thank you. How I understand I can't resolve this problem if I create plugin. Need use this repository and expand it

You don't need to fork the repository. You can write a plugin and make it work together with KrakenD. See: https://www.krakend.io/docs/extending/writing-plugins/


Keeping local time

Hi,
i have a problem with datetimepicker showing one thing on page and converting it to utc equivalent in the background.
i do select 6 pm but it is submitted as 3 pm.
is there a way to prevent it from happening?
thank you

Please create a fiddle or plunker that reproduces this problem.

Closed due to no response from OP


Add oobabooga text generation webui api completer

Connects to local models: LLaMa (including llama.cpp), local GPT-derivatives via oobabooga's text generation webui
Closes #11

Just opened this; will see what I can do in the meantime

Yes, thanks! @rizerphe . It was a real problem

Just opened this as well; currently working under the assumption that my changes get accepted

Overall this seems to be working for me; I hope the generation web UI gets CORS support; other than that the only real problem left seems to be model switching - I don't like the idea of it in general, and I don't like how clumsily I had to do it even more.
Oobabooga only allows you to have one model loaded at a time, and switching takes a lot of time, and this isn't too convenient. For now, what I do is before every generate call, I check which model is loaded (through another API call) and load the one I need if necessary. Doing it differently could be smarter but requires a bit of a rewrite.

Quickly wanted to mention that oobabooga merged my pull request, therefore you don't need to use my fork anymore.


EarlGrey Failure - “Keyboard did not disappear after resigning first responder status”

This error occurs when attempting to use the action to type text into a textfield.
If you chain responder status between textfields, EarlGrey will fail, reporting that "Keyboard did not disappear after resigning first responder status".  This is because when your client implementation immediately moves firstResponder to a new textfield, the keyboard will not disappear (nor should it).
This error occurs because EarlGrey checks for Auto Correction on the textfield, disables autocorrection on the textfield, and then calls "resignFirstResponder" followed by "becomeFirstResponder", in order to effect the change.  If your app chains firstResponder status, then the first call to "resignFirstResponder" will cause your app to pass responder status to the next text field.
Inspecting the EarlGrey source, it looks like the issue could be on line 182 in GREYActions.m.  Here, we aren't checking to see that auto correction status is actually on.  So even if your text field doesn't use auto correction, this will always invoke "resignFirstResponder" followed by "becomeFirstResponder".  We should actually check to make sure that the prior value was "on" before performing this dance.

Thanks a lot for bringing this to our attention. We currently have a fix in process for this. As a quick workaround, you could turn off Autocorrection Type from either the text field or the Settings?

hi @tirodkar  - Unfortunately turning off autocorrection doesn't work.  The reason is that regardless of the autocorrection type on the UITextField, it will be asked to resignFirstResponder, and then becomeFirstResponder.
I wasn't aware you guys had a fix in progress, so I created a PR.  You can see what I am talking about here:
https://github.com/google/EarlGrey/pull/57
Feel free of course to close the PR since you have something in the works :)

@janderson-primary, the Pull Request is in. Feel free to tell us if you still experience any more issues. Closing this for now.


wip-feature Support show partitions using storage policy

Proposed changes
Issue Number: close #xxx
Previously, there was no method to query which partitions were using a storage policy. This pull request adds the functionality of querying which partitions are using a storage policy by including the storage policy information in the tablet report task of the backend.
User can use such tvf like
mysql> select * from storage_policy("storage_policy" = '13006') ;
+-----------------+-------------+
| StoragePolicyId | PartitionID |
+-----------------+-------------+
| 13006           | 13008       |
| 13006           | 13009       |
| 13006           | 13010       |
+-----------------+-------------+
3 rows in set (0.89 sec)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Patch fix: add Manifest.toml to benchmarking

After some problems with the benchmarking CI, I came to the conclusion that the failure was due to swapping to Pkg.add in CI which was causing uncommitted changes to the branch in the CI run leading to a failure ("dirty commit").
To stabilise the changes on the checked out branch in CI I've add a Manifest.toml file for the benchmarking following https://github.com/tkf/BenchmarkCI.jl#setup-with-benchmarkmanifesttoml .

The fork of BenchmarkCI we are using is specified there.
EpiAware dep is specified there.

This reduces the CI command to just instantiate and stops an error occurring between running benchmarks for the target and the baseline commits.
Evidence that this works is the test draft PR #523 which is aimed at benchmarking the test branch trigger-bci-2 against the test branch trigger-bci: both of which have this approach to specifying the benchmark project deps.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.64%. Comparing base (67d5072) to head (4683a6f).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #524   +/-   ##
=======================================
  Coverage   89.64%   89.64%
=======================================
  Files          53       53
  Lines         753      753
=======================================
  Hits          675      675
  Misses         78       78

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Unable to install hydrogen with apm in Atom 1.40.1

Prerequisites

[X] Have you checked the solutions in our troubleshooting guide for common problems ?
[X] Have you checked that your issue isn't already filed ?

Description
Unable to install hydrogen with apm on atom version 1.40.1, as well as 1.40.1-beta1, while it works for 1.39.1.
Probably not related to #1738.
Problem also appears for other packages with a postinstall script, thus I originally filed an issue on Atom itself (https://github.com/atom/atom/issues/19866), but was asked to create downstream issues instead. Related issue for atom-ink (https://github.com/JunoLab/atom-ink/issues/212).
Steps to Reproduce

Atom 1.40.1
apm install hydrogen fails with

➜  ~ grep -E "[0-9]+ (warn|error)" /home/coroa/.atom/.apm/_logs/2019-09-03T09_31_49_440Z-debug.log
10982 warn enoent ENOENT: no such file or directory, open '/tmp/apm-install-dir-11983-9676-fv0chj.tnbh/package.json'
10984 warn<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^15.0.0 but none is installed. You must install peer dependencies yourself.
10985 warn apm-install-dir-11983-9676-fv0chj.tnbh No description
10986 warn apm-install-dir-11983-9676-fv0chj.tnbh No repository field.
10987 warn apm-install-dir-11983-9676-fv0chj.tnbh No README data
10988 warn apm-install-dir-11983-9676-fv0chj.tnbh No license field.
10996 error code ELIFECYCLE
10997 error errno 134
10998 error<EMAIL_ADDRESS>install: `node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)`
10998 error Exit status 134
10999 error Failed at the<EMAIL_ADDRESS>install script.
10999 error This is probably not a problem with npm. There is likely additional logging output above.

Versions
OS version:
Debian sid/unstable

atom --version

Atom    : 1.40.1
Electron: 3.1.10
Chrome  : 66.0.3359.181
Node    : 10.2.0

apm --version

apm  2.4.3
npm  6.2.0
node 10.2.1 x64
atom 1.40.1
python 2.7.16+
git 2.23.0

Hydrogen version:
2.12.0
Plugins
Have you installed and activated any of the Hydrogen plugins below ?

[ ] hydrogen-python
[ ] Hydrogen Launcher
[ ] Data Explorer

No plugins, yet.
Logs
Debug log by apm: 2019-09-03T09_31_49_440Z-debug.log
Expected behavior
Installation of hydrogen.

I have the same issue on Debian/buster. Same version of everything apart from Python (3.7.3) and git (2.20.1).

Hi, apologies for not responding sooner because I have little knowledge of this stuff. Most likely what is happening here is an issue hydrogen cannot fix. Thus I would suggest checking your apm version, and I would upgrade it if possible and retry. Also since you are experiencing this on multiple projects I am very confident that we are not responsible for this issue, even if I had the ability to diagnose it.
Closing, as we are most likely not responsible. Comment if you believe we should reopen this. Apologies for the late reply.


Review nn/hypergraph models

Review the model implementations and make sure they converge properly on real-world datasets.

[x] AllDeepSet
[x] AllSetTransformer
[x] DHGCN
[ ] HMPNN
[ ] HNHN
[ ] HyperGAT
[ ] HyperSage
[x] UniGCN
[ ] UniGCNII
[ ] UniGIN
[ ] UniSAGE

UniGCNIILayer, UniGINLayer, UniSAGELayer are not using topomodelx.base.conv primitives


Chocolatey package protonpass out of date - current protonpass version is 1.16.1

Please update this package to reflect the current protonpass version of 1.16.1
https://proton.me/download/PassDesktop/win32/x64/ProtonPass_Setup_1.16.1.exe

Thank you, I just pushed https://community.chocolatey.org/packages/protonpass/1.16.7


Possible memory leak?

@patrick-kidger as you are already aware of the Mistral port I have been working on. I have now put that code in a public repo. There are some TODOs remaining that I will complete anyway but I am dealing with a big issue. Here is the condensed code implementation for reference.
import gc
import jax
import numpy as np
import equinox as eqx
import jax.numpy as jnp
import jax.tree_util as jtu
from collections import namedtuple

# Utility to convert dtypes
def to_dtype(model, dtype):
     def _to_dtype(leaf):
        if isinstance(leaf, jax.Array):  # not eqx.is_array, which also detects NumPy arrays
            leaf_with_dtype = leaf.astype(dtype)
            del leaf
            gc.collect()  # just in case?
            return leaf_with_dtype
        else:
            return leaf
     return jtu.tree_map(_to_dtype, model)

def count_jax_parameters(model):
    return sum(x.size for x in jtu.tree_leaves(eqx.filter(model, eqx.is_array)))

# 1. RoPE
def precompute_frequencies(dim, max_pos, theta=10000.0):
    inv_freq = 1.0 / (
        theta ** (jnp.arange(0, dim, 2, dtype=jnp.float32)[: (dim // 2)] / dim)
    )
    t = jnp.arange(0, max_pos, dtype=jnp.float32)
    freqs = jnp.outer(t, inv_freq)
    return jnp.cos(freqs), jnp.sin(freqs)

def calculate_rope(x, cos_freq, sin_freq, offset=0):
    # x shape  is [seqlen, num_heads, head_dim]

    # Get the sequence length
    seqlen = x.shape[0]

    # Get the corresponding positional embeddings
    sin = sin_freq[offset : offset + seqlen, :]
    cos = cos_freq[offset : offset + seqlen, :]

    # Positional embeddings are 2D while our input is 3D
    # if `num_heads` dimension is present in the inputs.
    # We need to add another dimension to our positional embeddings
    sin = sin[:, jnp.newaxis, :]
    cos = cos[:, jnp.newaxis, :]

    # Get the even-odd positions from the inputs
    x1 = x[..., 0::2]
    x2 = x[..., 1::2]

    # Matmul with the rotation matrix
    # [cos_nθ, -sin_nθ] [x1]
    # [sin_nθ,  cos_nθ] [x2]
    # => [x1 * cos_nθ - x2 * sin_nθ, x1 * sin_nθ + x2 * cos_nθ]
    pos_embed = jnp.stack([x1 * cos - x2 * sin, x1 * sin + x2 * cos], axis=-1)
    pos_embed = jax.lax.collapse(pos_embed, -2)
    return pos_embed.astype(x.dtype)

# 2. Attention layer
class Attention(eqx.Module):
    n_heads: int
    n_kv_heads: int
    sliding_window: int
    scale: float
    kv_repeats: int
    head_dim: int
    wq: eqx.nn.Linear
    wk: eqx.nn.Linear
    wv: eqx.nn.Linear
    wo: eqx.nn.Linear

    def __init__(self, args:namedtuple, key:jax.Array):
        self.n_heads = args.n_heads
        self.n_kv_heads = args.n_kv_heads
        self.kv_repeats = self.n_heads // self.n_kv_heads
        self.sliding_window = args.sliding_window
        self.scale = args.head_dim **-0.5
        self.head_dim = args.head_dim

        key1, key2, key3, key4 = jax.random.split(key, 4)
        self.wq = eqx.nn.Linear(args.dim, args.n_heads * args.head_dim, use_bias=False, key=key1)
        self.wk = eqx.nn.Linear(args.dim, args.n_kv_heads * args.head_dim, use_bias=False, key=key2)
        self.wv = eqx.nn.Linear(args.dim, args.n_kv_heads * args.head_dim,use_bias=False, key=key3)
        self.wo = eqx.nn.Linear(args.n_heads * args.head_dim, args.dim, use_bias=False, key=key4)

    def __call__(self, x, cos_freq, sin_freq, positions, mask):
        seqlen = x.shape[0]

        xq = jax.vmap(self.wq)(x)
        xk = jax.vmap(self.wk)(x)
        xv = jax.vmap(self.wv)(x)

        xq = jnp.reshape(xq, (seqlen, self.n_heads, self.head_dim))
        xk = jnp.reshape(xk, (seqlen, self.n_kv_heads, self.head_dim))
        xv = jnp.reshape(xv, (seqlen, self.n_kv_heads, self.head_dim))

        xq = calculate_rope(xq, cos_freq, sin_freq, 0)
        xk = calculate_rope(xk, cos_freq, sin_freq, 0)

        if positions.shape[0] > 1:
            # prefill
            key = jnp.repeat(xk, self.kv_repeats, axis=1)
            value = jnp.repeat(xv, self.kv_repeats, axis=1)
        # TODO: else fill from cache

        query = jnp.transpose(xq, (1, 0, 2)) # [seqlen, num_heads, head_dim] -> [num_heads, seqlen, head_dim]
        key = jnp.transpose(key, (1, 0, 2)) # [seqlen, num_heads, head_dim] -> [num_heads, seqlen, head_dim]
        value = jnp.transpose(value, (1, 0, 2)) # [seqlen, num_heads, head_dim] -> [num_heads, seqlen, head_dim]

        # scores : [n_heads, seqlen | 1, seqlen]
        scores = jnp.matmul(query, jnp.transpose(key, (0, 2, 1))) * self.scale

        if mask is not None:
            # Mask will of shape [seqlen, seqlen] but our scores
            # have shape [num_heads, seqlen, seqlen], hence we need
            # to introduce another dimension in the mask
            mask = mask[jnp.newaxis, ...]
            scores = scores + mask

        scores = jax.nn.softmax(scores.astype(jnp.float32)).astype(query.dtype)
        output = jnp.matmul(scores, value)
        output = jnp.transpose(output, (0, 2, 1))
        output = jnp.reshape(output, (output.shape[-1], -1))
        output = jax.vmap(self.wo)(output)
        return output

# 3. FeedForward
class FeedForward(eqx.Module):
    w1: eqx.nn.Linear
    w2: eqx.nn.Linear
    w3: eqx.nn.Linear

    def __init__(self, args, key):
        super().__init__()
        key1, key2, key3 = jax.random.split(key, 3)

        self.w1 = eqx.nn.Linear(args.dim, args.hidden_dim, use_bias=False, key=key1)
        self.w2 = eqx.nn.Linear(args.hidden_dim, args.dim, use_bias=False, key=key2)
        self.w3 = eqx.nn.Linear(args.dim, args.hidden_dim, use_bias=False, key=key3)

    def __call__(self, x):
        return self.w2(jax.nn.silu(self.w1(x)) * self.w3(x))

# 4. TransformerBlock
class TransformerBlock(eqx.Module):
    dim: int
    n_heads: int
    attention: Attention
    attention_norm: eqx.nn.RMSNorm
    feed_forward: FeedForward
    ffn_norm: eqx.nn.RMSNorm

    def __init__(self, args, key):
        key1, key2 = jax.random.split(key, 2)
        self.n_heads = args.n_heads
        self.dim = args.dim

        self.attention = Attention(args, key=key1)
        self.attention_norm = eqx.nn.RMSNorm(args.dim, eps=args.norm_eps, use_bias=False, use_weight=True)

        self.feed_forward = FeedForward(args, key=key2)
        self.ffn_norm = eqx.nn.RMSNorm(args.dim, eps=args.norm_eps, use_bias=False, use_weight=True)

    def __call__(self, x, cos_freq, sin_freq, positions, mask):
        normed_x = jax.vmap(self.attention_norm)(x.astype(jnp.float32)).astype(jnp.float16)
        r = self.attention(normed_x, cos_freq, sin_freq, positions, mask)
        h1 = x + r
        h2 = jax.vmap(self.ffn_norm)(h1.astype(jnp.float32)).astype(jnp.float16)
        h2 = jax.vmap(self.feed_forward)(h2)
        out = h1 + h2
        return out

# 5. Transformer
class Transformer(eqx.Module):
    tok_embeddings: eqx.nn.Embedding
    layers: TransformerBlock
    norm: eqx.nn.RMSNorm
    output: eqx.nn.Linear
    vocab_size: int
    n_layers: int

    def __init__(self, args, key):
        self.vocab_size = args.vocab_size
        self.n_layers = args.n_layers
        keys = jax.random.split(key, args.n_layers + 2)
        embed_key, linear_key, tf_layers_keys = keys[0], keys[-1], keys[1:-1]

        self.tok_embeddings = eqx.nn.Embedding(args.vocab_size, args.dim, key=embed_key)
        self.norm = eqx.nn.RMSNorm(args.dim, eps=args.norm_eps, use_bias=False, use_weight=True)
        self.output = eqx.nn.Linear(args.dim, args.vocab_size, use_bias=False, key=linear_key)

        make_tf_layers = lambda k: TransformerBlock(args, key=k)
        self.layers = eqx.filter_vmap(make_tf_layers)(tf_layers_keys)

    def __call__(self, x, positions):
        # x is of shape (seqlen, ). We need to use vmap
        # as the embedding layer expects single token (scalar)
        # as input.
        h = jax.vmap(self.tok_embeddings)(x) # output shape: [seqlen, embed_size]
        sin_freq = precomputed_sin_freq[positions]
        cos_freq = precomputed_cos_freq[positions]

        if x.shape[-1] > 1:
            seq_len = x.shape[-1]
            t = jnp.full((seq_len, seq_len), dtype=h.dtype, fill_value=1)
            mask = jnp.tril(t, k=0)
            # make the mask banded to account for sliding window
            mask = jnp.triu(mask, k=-args.sliding_window)
        else:
            mask = None

        # We need to call all the transformer blocks in a loop. Better to use lax.scan
        # as it would reduce compilation overhead and will be much faster.
        dynamic_tf_layers, static_tf_layers = eqx.partition(self.layers, eqx.is_array)

        def f(_x, _dynamic_tf_layers):
            tf_layer = eqx.combine(_dynamic_tf_layers, static_tf_layers)
            return tf_layer(_x, cos_freq, sin_freq, positions, mask), None

        h, _ = jax.lax.scan(f, h, dynamic_tf_layers)
        h = jax.vmap(self.norm)(h)
        h = jax.vmap(self.output)(h)
        # TODO: Calculate logits in this block
        return h

ModelArgs = namedtuple(
    "ModelArgs",
    [
        "dim",
        "n_layers",
        "hidden_dim",
        "n_heads",
        "head_dim",
        "n_kv_heads",
        "sliding_window",
        "norm_eps",
        "vocab_size",
        "max_batch_size"
    ]
)

# Same hparams as used in the original code
args = ModelArgs(
    dim=4096,
    n_layers=32,
    n_heads=32,
    n_kv_heads=8,
    head_dim=128,
    hidden_dim=14336,
    vocab_size=32000,
    max_batch_size=1,
    sliding_window=4096,
    norm_eps=1e-5
)

# Initialize the model
transformer = to_dtype(Transformer(args, key=jax.random.PRNGKey(1)), jnp.float16)

Given that this model has 7B parameters, I should be able to load this model on a A100 40G GPU as well as on TPUv3-8. The problem is that no matter what device, it always errors out with OOM.
I suspected that it might be the case that I am initializing the transformer with full precision, and then converting it to float16, so I tried the other way round where in each block I convert each layer to float16 as soon as it is initialized. Even after that it errors out with OOM. I suspect there is a memory leak somewhere but I am not able to pinpoint it.
Any suggestions/pointers would be very helpful. Thanks in advance 🙏

From skimming the code, I suspect the issue might now lie with Equinox, since you're only using Embedding, Linear and RMSNorm from the Equinox namespace and none of those should be responsible for your problem.
Here's what I would do:

Disable the 75% default allocation of the GPU by JAX:
XLA_PYTHON_CLIENT_PREALLOCATE=false
Decrease some values in your ModelArgs
Check GPU usage
Slowly increase the values in ModelArgs
Repeat until you run out of memory
Investigate your parameters and the code again.

That would be my first naive experimentation.

Thanks @Artur-Galstyan  but I already performed all those analysis before opening the issue. For A100, it runs OOM after 4 transformer layers, and for TPUv3-8 it runs OOM after 16 layers. Both the devices have enough memory to handle a 7B model. In fact, I can load the entire torch model with no issues at all. There is definitely a memory leak, and I don't know if it's because of scan or something else

I'll try to investigate this too, later. Unfortunately, I don't have an A100, but if my math is correct, I should (theoretically) be able to load 7B models on a 3090 with 16-bit precision. I'll let you know if I find something.

Sure thing. Thanks. BTW you can test it on TPUs on Kaggle for free

Thanks @patrick-kidger  butleaf.delete() throws Concretization error

@patrick-kidger this throws ConcretizationError
---------------------------------------------------------------------------
ConcretizationTypeError                   Traceback (most recent call last)
Cell In[6], line 1
----> 1 transformer = Transformer(args, key=jax.random.PRNGKey(1))
      2 jitted_transformer = eqx.filter_jit(transformer)

File /usr/local/lib/python3.10/site-packages/equinox/_module.py:514, in _ModuleMeta.__call__(cls, *args, **kwargs)
    512 initable_cls = _make_initable(cls, cls.__init__, post_init, wraps=False)
    513 # [Step 2] Instantiate the class as normal.
--> 514 self = super(_ModuleMeta, initable_cls).__call__(*args, **kwargs)
    515 assert not _is_abstract(cls)
    516 # [Step 3] Check that all fields are occupied.

    [... skipping hidden 2 frame]

Cell In[4], line 203, in Transformer.__init__(self, args, key)
    200 self.output = to_dtype(eqx.nn.Linear(args.dim, args.vocab_size, use_bias=False, key=linear_key), jnp.float16)
    202 make_tf_layers = lambda k: to_dtype(TransformerBlock(args, key=k), jnp.float16)
--> 203 self.layers = eqx.filter_vmap(make_tf_layers)(tf_layers_keys)

File /usr/local/lib/python3.10/site-packages/equinox/_vmap_pmap.py:219, in _VmapWrapper.__call__(***failed resolving arguments***)
    214         raise ValueError(
    215             "Cannot resolve batch dimension. Non-`None` `out_axes` requires "
    216             "either `in_axes` or `axis_size` to be not `None`."
    217         )
    218 else:
--> 219     vmapd, static = jax.vmap(
    220         _fun_wrapper,
    221         in_axes=(in_axes,),
    222         out_axes=(0, None),
    223         axis_name=self._axis_name,
    224         axis_size=self._axis_size,
    225         **self._vmapkwargs,
    226     )(dynamic_args)
    227 nonvmapd, out_axes = static.value
    229 assert jtu.tree_structure(vmapd) == jtu.tree_structure(out_axes)

    [... skipping hidden 4 frame]

Cell In[4], line 202, in Transformer.__init__.<locals>.<lambda>(k)
    199 self.norm = to_dtype(eqx.nn.RMSNorm(args.dim, eps=args.norm_eps, use_bias=False, use_weight=True), jnp.float16)
    200 self.output = to_dtype(eqx.nn.Linear(args.dim, args.vocab_size, use_bias=False, key=linear_key), jnp.float16)
--> 202 make_tf_layers = lambda k: to_dtype(TransformerBlock(args, key=k), jnp.float16)
    203 self.layers = eqx.filter_vmap(make_tf_layers)(tf_layers_keys)

    [... skipping hidden 3 frame]

Cell In[4], line 166, in TransformerBlock.__init__(self, args, key)
    163 self.n_heads = args.n_heads
    164 self.dim = args.dim
--> 166 self.attention = Attention(args, key=key1)
    167 self.attention_norm = eqx.nn.RMSNorm(args.dim, eps=args.norm_eps, use_bias=False, use_weight=True)
    169 self.feed_forward = FeedForward(args, key=key2)

    [... skipping hidden 3 frame]

Cell In[4], line 80, in Attention.__init__(self, args, key)
     77 self.head_dim = args.head_dim
     79 key1, key2, key3, key4 = jax.random.split(key, 4)
---> 80 self.wq = to_dtype(eqx.nn.Linear(args.dim, args.n_heads * args.head_dim, use_bias=False, key=key1), jnp.float16)
     81 self.wk = to_dtype(eqx.nn.Linear(args.dim, args.n_kv_heads * args.head_dim, use_bias=False, key=key2), jnp.float16)
     82 self.wv = to_dtype(eqx.nn.Linear(args.dim, args.n_kv_heads * args.head_dim,use_bias=False, key=key3), jnp.float16)

Cell In[4], line 11, in to_dtype(model, dtype)
      9     else:
     10         return leaf
---> 11 return jtu.tree_map(_to_dtype, model)

    [... skipping hidden 2 frame]

Cell In[4], line 6, in to_dtype.<locals>._to_dtype(leaf)
      4 if isinstance(leaf, jax.Array):  # not eqx.is_array, which also detects NumPy arrays
      5     leaf_with_dtype = leaf.astype(dtype)
----> 6     leaf.delete()
      7     gc.collect()  # just in case?
      8     return leaf_with_dtype

File /usr/local/lib/python3.10/site-packages/jax/_src/core.py:870, in Tracer.delete(self)
    869 def delete(self):
--> 870   raise ConcretizationTypeError(self,
    871     f"The delete() method was called on {self._error_repr()}."
    872     f"{self._origin_msg()}")

ConcretizationTypeError: Abstract tracer value encountered where concrete value is expected: traced array with shape float32[4096,4096].
The delete() method was called on traced array with shape float32[4096,4096]..
This BatchTracer with object id<PHONE_NUMBER>18672 was created on line:
  /tmp/ipykernel_13/2973233627.py:80 (__init__)
This BatchTracer with object id<PHONE_NUMBER>18672 was created on line:
  /tmp/ipykernel_13/2973233627.py:80 (__init__)

See https://jax.readthedocs.io/en/latest/errors.html#jax.errors.ConcretizationTypeError

Do the dtype conversion after model creation, not inside of it. In this case you can't delete the old buffer whilst inside a vmap.

@patrick-kidger fair enough but the other one didn't make any difference. BTW, I figured out where the issue lies, and it is definitely with equinox.filter_vmap(...). If I use a for loop to create a list of n layers of TransformeBlocks, it works i.e. I am able to load it successfully at least on TPUv3-8.
In a nutshell, in the above code inside TransformerBlock
This fails, and leads to OOM
make_tf_layers = lambda k: TransformerBlock(args, key=k)
self.layers = eqx.filter_vmap(make_tf_layers)(tf_layers_keys)
self.layers = to_dtype(self.layers, jnp.float16)

This works though
self.layers = [to_dtype(TransformerBlock(args, key=k), jnp.float16) for k in tf_layers_keys]

Oh! That's super weird. What about when there is no to_dtype call inside the model at all, and only the one at the very outside (on the last line of your original example)?
(In all cases including the leaf.delete() call.)

What about when there is no to_dtype call inside the model at all, and only the one at the very outside (on the last line of your original example)? (In all cases including the leaf.delete() call.)

Still OOM. And I somewhat have an idea why it is happening. When we use eqx.filter_vmap(...) for n layers, it actually creates stacked arrays with shape [n_layers, d1, d2, ....]. Unless you convert each layer to half precision as soon as it is initialized, you can't load those arrays in memory especially with full precision.
Quick question: Any trivial reason for not supporting dtype for each layer explicitly?

Ah, maybe I misunderstood the memory constraints of your model. Indeed, filter_vmap will create all of the weights for all layers simultaneously, all in full precision.

Quick question: Any trivial reason for not supporting dtype for each layer explicitly?

You're asking about adding an e.g. MultiheadAttention(..., dtype=...) argument you mean? We've considered this (along with other kinds of custom initialisation strategies, e.g. sampling from other distributions), but have generally decided not to include this, as it fairly rapidly gets out of hand (perhaps wanting lots of arguments for how to initialise every sub-sub-sub-layer in a model). The recommended approach has been to create the layer and then manipulate it using tree_map or tree_at as appropriate.
That said, this does seem like a case where that turns out to be fairly complicated. Hmm, it might be that we should reconsider the above approach, or else find some other way to directly create the weights with the desired precision.

Indeed, filter_vmap will create all of the weights for all layers simultaneously, all in full precision.

Thanks for the confirmation. Now that the only solution is to create a  list of TransformerBlocks in a for loop, what's your recommended way of calling these layers? I want to jit the whole thing but I am not aware of any other method than what I tried above.

but have generally decided not to include this, as it fairly rapidly gets out of hand (perhaps wanting lots of arguments for how to initialise every sub-sub-sub-layer in a model).

Agreed but I think dtype is far more imp than any other parameter, else loading models/layers with different precisions will become a headache

How can I call self.layers efficiently?

One simple thing that will work at the moment would be to stack all the layers after creating them:
layers = [to_dtype(...) ...]
self.layers = jtu.tree_map(lambda *x: jnp.stack(x) if eqx.is_array(x) else x, layers)

On dtype: agreed that this seems like it could be thought of differently to the other initialisations. I'm not currently sure if we should (a) bite the bullet and add general initialiser, (b) add just a dtype argument, or (c) maybe there is a way to finesse this with the current API. Either way this seems like a problem worth solving.

Thanks for the suggestion. I will try that out.

On dtype: agreed that this seems like it could be thought of differently to the other initialisations. I'm not currently sure if we should (a) bite the bullet and add general initialiser, (b) add just a dtype argument, or (c) maybe there is a way to finesse this with the current API. Either way this seems like a problem worth solving.

I can help contribute to it. Do you want to open an issue to track this?

Sure, go ahead and open an issue to track this.
If there is some cunning way to do this without modifying the existing API then that would definitely be best.

self.layers = jtu.tree_map(lambda *x: jnp.stack(x) if eqx.is_array(x) else x, layers)

I don't know if this is the intended behavior here but this doesn't create stacked arrays. self.layers is still a list.

No worries. Thanks for the clarification. Also, once the weights are stacked, I guess it will be a simple vmapped call?

Probably a lax.scan to iterate through the layers one at a time, rather than evaluating them in parallel. See https://docs.kidger.site/equinox/tricks/#improve-compilation-speed-with-scan-over-layers

Couple of issues here:

If we stack the layers after creating a list of TransformerBlocks, then we need to comment out leaf.delete() statement in the to_dtype function otherwise it complains  that the array has been deleted. This is weird as it wasn't happening when I was using eqx.filter_vmap(...) to create the stacked layers
The scan example doesn't work in this case. Throws ValueError: scan got values with different leading axis sizes:. This is again weird as nothing has fundamentally changed in the input/output shapes of the layers

Not sure I completely understand what you're getting at, but I think this sounds like a bug in how you've implemented things. You probably want to delete each thing only once, after all.
You can check the sizes of each layer just by printing it out: print(self.layers); this will include the shape of every array.

I figured out what's wrong with the list-> stack approach. I have put a simple code example for your reference:
class FeedForward(eqx.Module):
    layer1: eqx.nn.Linear
    layer2: eqx.nn.Linear

    def __init__(self, in_features, out_features, key):
        key1, key2 = jax.random.split(key)
        self.layer1 = eqx.nn.Linear(in_features, out_features, key=key1)
        self.layer2 = eqx.nn.Linear(out_features, out_features, key=key2)

    def __call__(self, x):
        x = jax.vmap(self.layer1(x))
        x = jax.vmap(self.layer2(x))
        return x

class CustomModel(eqx.Module):
    layers: FeedForward

    def __init__(self, in_features, out_features, num_layers):
        keys = jax.random.split(jax.random.PRNGKey(1), num_layers)
        self.layers = [FeedForward(in_features, out_features, key=k) for k in keys]
        self.layers = jtu.tree_map(lambda *x: jnp.stack(x) if eqx.is_array(x) else x , *self.layers)

    def __call__(self, x):
           ...

If I print out CustomModel, it has this structure:
CustomModel(
  layers=FeedForward(
    layer1=Linear(
      weight=(f32[8,16], f32[8,16]),
      bias=(f32[8], f32[8]),
      in_features=16,
      out_features=8,
      use_bias=True
    ),
    layer2=Linear(
      weight=(f32[8,8], f32[8,8]),
      bias=(f32[8], f32[8]),
      in_features=8,
      out_features=8,
      use_bias=True
    )
  )
)

You can see that the FeedForward layer has weight and bias as tuples, and not a big stacked matrices of sizes [2, 8, 16] and [2, 8] respectively.
PS: If you just use jnp.stack(x), then it stacks properly but if there are many layers like in the original example where mistral has 32 TransformerBlocks, it OOMs out, and I have no idea why. TPUv3-8 has enough memory to hold two blocks each of which are ~15G max

Any suggestions? @patrick-kidger

Ah, the typo is that x is a tuple, so eqx.is_array(x) returns False. I suppose the robust way to do this would be something like this:
def _stack(*x):
    is_array = {eqx.is_array(xi) for xi in x}
    if len(is_array) == 1:
        if is_array.pop():
            return jnp.stack(x)
        else:
            return x
    else:
        raise ValueError

self.layers = jtu.tree_map(_stack, *layers)

not terribly pretty but it works.
(Hopefully with the new dtype PRs then we shouldn't need to do any of htis any more anyway.)

Thanks for the help but it OOMs out as soon as I try to stack layers, and I have no idea why! The simple for loop for creating layers work but stacking them doesn't. Though I can give it one more try, I would take a break here as I am exhausted debugging this.

Hopefully with the new dtype PRs then we shouldn't need to do any of htis any more anyway.

Yes, it will save a lot of time, and will make the code concise

Probably because both versions of the weights (pre-stack and post-stack) need to live in memory at the same time for a short while.
In any case you shouldn't need to worry about this any more anyway, we've merged your PR over on the dev branch?

I tried the dev branch on TPU v3-8. Given that everything is now in half-precision, I used eqx.filter_map(...) to create a big layer instead of creating them in a loop. It OOMs out again!

I tried it on TPUv3-8 with the changes on dev branch. Given everything is in half-precision, I used eqx.filter_vmap(...) to create one big stacked layer as opposed to creating in the loop. It OOMs out!

Hard to say what's going on from where I'm sitting I'm afraid. I hope this is something you can debug, and then let us know where the error came from!

Will pick this up again next week, and will update the findings

This is now solved but I figured out to solve it in a much better way.
@patrick-kidger Mistral-7B port is complete. Here is the source code for your reference. Thanks again for all the help.

Oh awesome!
I'd be happy to link to your GitHub page from the "advanced examples" in the Equinox documentation, if you'd like?
By the way, I see a comment in your code about RMSNorm being wrong -- what's going on there? :)

I'd be happy to link to your GitHub page from the "advanced examples" in the Equinox documentation, if you'd like?

That would be awesome! Thanks 🍺

By the way, I see a comment in your code about RMSNorm being wrong -- what's going on there? :)

Like RoPE, when you compute norm of the inputs, it should be calculated atleast with full precision. Right now now the source code looks like this:
inv_rms = jax.lax.rsqrt(jnp.mean(x**2) + self.eps)

If I initialize RMSNorm with flot16/bfloat16, the calculation for norm will take place with that precision resulting in wrong output (not mathematically wrong, but that it can lead to instability at certain places). This inputs should first be scaled up and then the resulting output should be casted to the desired precision:
upscaled_inp = x.astype(jnp.float32)
inv_rms = jax.lax.rsqrt(jnp.mean(upscaled_x**2) + self.eps)

I will send a PR for this