Is cardholder name functionality being worked on?

I've found some StackOverflow questions and some previous issues in regards to grabbing the cardholder's name but most of these are from 2013 or 2014.
I noticed that progress has been made on reading the expiration date, but would like to know if any progress has been made on reading the name as well.

Excellent question!
Unfortunately, reading the cardholder name represents a big challenge for us. There are various reasons for that, mostly technical, but also just the fact that we will probably need a large number of additional sample credit cards of a variety of designs before we have a sufficient dataset to use in training our Deep Learning models.
So at this moment we're not yet attacking the scanning of cardholder names.

When shall we expect reading "card Holder name" ?

When can we expect the library to support reading Card Holder Name?

Coley Brown has posted a fork in #231 that implements name recognition in addition to flat card scanning.
https://github.com/CTBConsulting/Card.io-for-Capital-One-vertical-Cards
Would it be feasible to merge his enhancements?

Is there any solution for this yet?
Thanks


$sort get lost on socket updates

Steps to reproduce
I created a service called entries with a date property. This property is used to sort the list.
My vue component fetch the entries when mounted and the client should automatically update the list through socket events.
Just created the feathers-client.js and the store/index.js according to the doc:
https://github.com/feathers-plus/feathers-vuex
// feathers-client.js
import feathers from '@feathersjs/feathers'
import socketio from '@feathersjs/socketio-client'
import auth from '@feathersjs/authentication-client'
import io from 'socket.io-client'

const socket = io('http://localhost:3030', {transports: ['websocket']})

const feathersClient = feathers()
  .configure(socketio(socket))
  .configure(auth({ storage: window.localStorage }))

export default feathersClient

// store/index.js
import Vue from 'vue'
import Vuex from 'vuex'
import feathersVuex from 'feathers-vuex'
import feathersClient from '../feathers-client'

const { service, auth } = feathersVuex(feathersClient, { idField: '_id' })

Vue.use(Vuex)

export default new Vuex.Store({
  plugins: [
    service('entries'),
    auth()
  ]
})

At my-component.vue
...
  mounted: function () {
    this.fetchEntries({query: {$limit: 1000, $sort: {date: 1, _id: 1}}})
  },
  methods: {
    ...mapActions('entries', {fetchEntries: 'find'})
  },
  computed: {
    ...mapGetters('entries', {findEntries: 'find'}),
    filteredEntries: function () {
      return this.findEntries({query: {$limit: 1000, $sort: {date: 1, _id: 1}}})
    }
  }

...
Expected behavior
After receiving a socket update for a service, the list should be sorted (the new item should not be added to the end of the list but according to the correct sort param)
Actual behavior
The 1st time data is loaded, it is perfectly sorted, but when the client receives socket updates the sort is lost and the new items are added at the end of the list
System configuration
"dependencies": {
"@ feathersjs/authentication-client": "^1.0.2",
"@ feathersjs/feathers": "^3.1.3",
"@ feathersjs/socketio-client": "^1.1.0",
"feathers-vuex": "^1.1.4",
"socket.io-client": "^2.0.4",
"vue": "^2.5.2",
"vue-router": "^3.0.1",
"vuex": "^3.0.1"
},
NodeJS version: 8.9.4
Operational System: ubuntu 17-10 64 bits
Browser Version: Chrome 64.0.3282.119 and Firefox 59.0.1

I have similar issues and made several experiments.
My TL;DR main finding is:
the find GETTER fails to sort by more than one field.  Limitation or bug?
My full findings so far are:
The find ACTION fails to sort when you try to sort by a fastJoint-ed field.  But is not a feathers-vuex issue, because when using a REST client (postman), result is the same.  So it may be a (normal?) limitation, at least when using the feathers-neDB adapter.
However, I successfully sorted by 3 fields that are "natural" (not fast-Joint-ed) fields, both with feathers-vuex's find action, and with postman (directly querying the server with no UI).
Nevertheless, once the data is in the store, it is just like local data, so there is no more distinction between natural and fastJoint-ed fields, since they all are just properties of objects in the store.
However, the find GETTER fails to sort by more than one field.
IMO, this is a concern because the UI (and the UX) is driven by the find getter, not by the find action.
I don't know if it is a limitation or a bug in feathers-vuex' find getter, but any hint on the better workaround will be greatly appreciated.   For my use case, I really need to sort by several fields.
feather-vuex is a geat tool anyway.

Dang.  This is probably an issue with the underlying sift package (https://www.npmjs.com/package/sift) which we're using to support more MongoDB query syntax.  Can you try downgrading one version below v1.1.4 and see if there's still an issue?  (I imagine there will be even more issues, honestly, but I don't know)

Hi,
How (and where) should I downgrade it? (ps. I couldn´t find it on any package.json)?
I tried npm i -s<EMAIL_ADDRESS>on the vue project root but it didn´t change anything
Anyway, i figure it out that this only happens having multiple sort properties, removing _id from $sort works fine
filteredEntries: function () {
    return this.findEntries({query: {$limit: 1000, $sort: {date: 1}}}).data
}

@barata0 Did you close the issue because you found a solution?  If so, please share.

@barata0 I was referring to downgrading feathers-vuex.

I'm going to leave this open, unless you found a solution @barata0

Sorry,
I didn´t wanted to close.
I´ll try downgrading feathers-vuex and let u know

This is fixed in<EMAIL_ADDRESS>


Warning of invalid param for catch all route with named route redirect

Version
4.1.6
Reproduction link
jsfiddle.net/z0kytrqj/16/
Steps to reproduce
Navigate to a catch all route with a named route redirect
  {
    path: '/:pathMatch(.*)*',
    redirect: { name: 'HOME' }
  }

What is expected?
No warnings
What is actually happening?
Warning displayed: Discarded invalid param(s) "pathMatch" when navigating. See https://github.com/vuejs/router/blob/main/packages/router/CHANGELOG.md#414-2022-08-22 for more details.

This is due to the implicit parameter being passed during a redirection. You can workaround it by passing an empty object of Params alongside the name of the route.
I’m unsure if this warning can be avoided without removing it. Worst case scenario we can also mention the workaround in the warning

Hi @posva can I work on to try to fix it ?

Sure

@posva I would like to work on this

Is there a workaround for this issue?

It's the very first comment, I added some extra examples: https://github.com/vuejs/router/issues/1617#issuecomment-1320941431


Radial Line of Sight and Range tool still has a reference to the computer it was posted from

the Output Workspace parameter still has a default of
D:\Users\matt2542\Documents\GitHub\solutions-geoprocessing-toolbox\visibility\data\Results.gdb.
this does not affect how the tool runs, but we could clean this up.

Try it now... cleaned up with https://github.com/Esri/solutions-geoprocessing-toolbox/pull/246

No response in 3 weeks ... closing.


Consider migration to preservim

Besides the long term lack of activity, I noticed you have marked this as being unmaintained. First of all thanks for the contribution to the VIM plugin space, I have used this for years myself still appreciate it.
I would like to ask if you would be interested in migrating this to the @preservim org namespace. I and a couple other folks have managed this for a few years now as a neutral place to house aging but still useful plugins that still get some community traction but the maintainers have moved on and want to let them go a little bit. We started with nerdcommentor and also now manage nerdtere, tagbar, vim-markdown, and quite a few others.
The idea is that I and a few others (to include yourself) would just keep an eye out on community contributions and find contributors who have a good track record and give them a little bit more permissions to help with maintenance. My usual modus is to setup a team form anyone ⓐ interested and ⓑ with a previous positive track record of contributions such that the team can manage issues and merge PRs pending at least one other approval and passing CI checks.
If agreeable I would keep you on as owner of the repo but also myself be able to invite people to the team for this plugin. GitHub handles redirects from the old repository location, so most users of the plugin would hardly notice the change. My first order of business would be to setup some basic CI checks to make sure PRs don't outright break basic functionality and then look through the issue tracker and past PRs looking for existing contributions that should be included and with a weather eye out on if there is anybody to invite to help with maintenance.
I can't promise anybody will step up run with it, but at least the friction will be lowered on contributions so that there is a chance any needed fixes or improvements can get through.
If your are interested in this let me know and I'll invite you to the org and we can get started.

This sounds like a great idea!

We kind of need some buy-in from @nathanaelkane to proceed. As an org our goal is not to just fork plugins but to become the canonical source for existing users. Doing this without friction and requiring existing users to find the fork and switch requires the original owner's blessing.
It isn't hard to setup and won't take any time going forward (if he doesn't want to participate although he would continue to have owner access if he did feel so inclined) but we would need him to get started by transferring the repo.

Hi @alerque, sounds like a great idea, I'd be happy to migrate this across. 👍

Ownership has been transferred to PreserVIM, thanks @alerque.

@nathanaelkane You should have an invite to the org. When you accept that you should have enough mojo to use GitHub's Transfer repository option in settings and move this repository to the org namespace. That will also setup Git + HTTP redirects so nobody with this is their plugin managers get disconnected. My only major suggestion after that is for you to not fork a copy of the repo back to your personal GitHub namespace because that will clear the redirects. I'll still be the owner of the repo in the PreserVIM namespace and can work on it there if you like.
After it's migrated over I can setup a team for it if other people want to join as maintainers and setup some CI to keep everybody out of trouble.

Jinx ... I got distracted and that sat as a draft too long.
The not about not making a new fork in your personal namespace is still relevant so we don't kill off the nice redirect stuff.

Yep all sounds good, thanks.

If anybody wants to contribute going forward the best place to start is sending a PR or commenting on existing issues with anything that helps moving them toward resolution. I'll be keeping an eye out and offering elevated privileges on this repo (based on interest and contributions) to help facilitate issue triage and code contributions.


importing modin result in latest arrow 6.0 hang

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Ubuntu 18.04 LTS
Windows 10

Modin version (modin.__version__):
0.12.1

Python version:
Python 3.9.1

Code we can use to reproduce:

Install latest modin and arrow with:
conda create -n test -c conda-forge modin-all pyarrow=6.0.1

Then use the code to reproduce.
# importing modin result in hang for arrow iterator
import modin.pandas as pd
import pyarrow.dataset as ds

dfile = 'veterans_lung_cancer.csv'
data = ds.dataset(dfile, format='csv')
rb_iter = iter(data.to_batches())
next(rb_iter)

Also attach the code:
modin_arrow_hang.tar.gz
Describe the problem
The code hang with arrow 6.0, but for arrow 4.0 it's ok. If modin is removed, everything is fine.

Hi @xwu99, thanks for the report! I was able to reproduce the issue on Windows, but not on Linux. We will take a look at this more closely.
Also, the following issues were observed on Linux when digging into the problem.

When performing conda create -n test -c conda-forge modin-all pyarrow=6.0.1 Modin 0.11.1 is installed and when performing conda create -n test -c conda-forge modin-all Modin 0.11.3 is installed.
When updating pyarrow 3.0.0 to pyarrow 6.0.0 in environment-dev.yml I got deps conflict.

cc @devin-petersohn

You can also try to mix using conda-forge and pip install to reproduce on Linux. Such as using conda to install pyarrow and pip to install modin or the other way.

Yes, @prutskov, did this way and reproduced the issue. However, a common practice is not to mix conda and pip.

Yes, @prutskov, did this way and reproduced the issue. However, a common practice is not to mix conda and pip.

Not intended to mix, but somethings there are some packages not released in both channels.

@xwu99 is there a companion issue in arrow? Probably worth opening there since this fix will probably need to be there.
While it is not recommended to mix conda and pip, it sometimes must happen if certain packages are only supported in one or the other as @xwu99 mentions.
Looking into what is causing this. We don't run anything super complicated in the init, so it is unexpected.

Ok, I was able to reproduce this without Modin:
import os
import pyarrow.dataset as ds

os.environ["OMP_NUM_THREADS"] = "1"  # offending line

dfile = 'veterans_lung_cancer.csv'
data = ds.dataset(dfile, format='csv')
rb_iter = iter(data.to_batches())
next(rb_iter)  # hangs

This probably needs to be raised in pyarrow because it is not something we could fix in Modin. Thanks @xwu99 for finding/reporting this!

I did not submit issue for arrow right now. It looks importing Modin impacts arrow's normal behavior. But we can submit PR if arrow needs to be fixed.

Ok, I was able to reproduce this without Modin:

import os

import pyarrow.dataset as ds

os.environ["OMP_NUM_THREADS"] = "1"  # offending line

dfile = 'veterans_lung_cancer.csv'

data = ds.dataset(dfile, format='csv')

rb_iter = iter(data.to_batches())

next(rb_iter)  # hangs

This probably needs to be raised in pyarrow because it is not something we could fix in Modin. Thanks @xwu99 for finding/reporting this!

Did you change openmp env when importing Modin? It seems to work for earlier versions of pyarrow (4.0)?
I can submit another issue for pyarrow.

Yes, we set os.environ["OMP_NUM_THREADS"] = "1" on import to avoid running out of threads on the OS. Users can override it if they wish by manually setting OMP_NUM_THREADS after import.
Even if we move this setting, it will not solve the problem for pyarrow.

I have opened an issue here: https://issues.apache.org/jira/browse/ARROW-15362

Ok looks like the issue has been resolved and the fix will be in the next release.
Closing this, but please re-open if there is something we should do/change to help with this.

Probably mention this in Troubleshooting?

@Garra1980 yes, we can add a note there.


RedisSubscriptionStore?

Now that we have the CacheClientSubscriptionStore we can simply create a Redis version of it, for storing subscriptions, and offer that to people as an alternative store.
We could create a 'ServiceStack.Webhooks.Redis' nuget from a 'Webhooks.Redis' project in the solution ,and ship that nuget separately.

I just went through this entire process and made the discovery that there really is no need to create a nuget package called "ServiceStack.Webhooks.Redis".
We already have the CacheClientSubscriptionStore so, all we have to do for Redis, is register the RedisClientManager and we have a redis store!
(see: Caching Stores for more examples.
public override void Configure(Container container)
{
    Plugins.Add(new ValidationFeature());
    Plugins.Add(new AuthFeature(...));

    // Register a Redis ICacheClient
    container.Register<IRedisClientsManager>(c => new PooledRedisClientManager("localhost:6379"));
    container.Register(c => c.Resolve<IRedisClientsManager>().GetCacheClient());
    container.RegisterAutoWiredAs<CacheClientSubscriptionStore, ISubscriptionStore>();

    Plugins.Add(new WebhookFeature
    {
        .. any customization for your environment
    });
}


if TLF has not been identified, and we are in AlwaysRunIdentify mode

@strib @songgao r?
It seems like the following can happen in the KBFS client when calling GetTLFCryptKeys.
1.) We runGetTLFCryptKeys on a TLF with TLFIdentifyBehavior_CHAT_GUI on a TLF with a user with a failing tracker statement. In this case, KBFS will seemingly store the folder_branch_ops thing withidentifyDone set to false.
2.) When we call GetTLFCryptKeys again, but this time with TLFIdentifyBehavior_CHAT_CLI on the same TLF, then even with the failing tracker statement, we are able to get crypt keys since it will skip the identify after hitting this folder_branch_ops cache.
My change makes it so that if you hit this cache, but identifyDone is false we run an identify.
Let me know if this works, I don't know this code very well so I it could be this is the wrong approach.
cc @maxtaco

The AlwaysRunIdentify function actually lives in the keybase1 package, and that gets used in KBFS, and uses the new flag.

@mmaxim right, but we already have that flag in our vendored copy of client, as far as I can tell.  So I don't see how the re-vendor solves any problem related to this PR.

Ah ok! I guess someone probably vendored that in sometime when I landed it in client and now. I'll drop the vendor stuff from this PR then. Thanks!

Ok thanks!  git blame vendor/github.com/keybase/client/go/protocol/keybase1/extras.go shows that the flag has been in there since a commit on 10/11.

Ah I see, just to be clear the thing I added is this TLFIdentifyBehavior_CHAT_GUI_STRICT, not the function itself.

And I see in master it actually doesn't seem to have my latest change there, this is what I see:
func (b TLFIdentifyBehavior) AlwaysRunIdentify() bool {
	return b == TLFIdentifyBehavior_CHAT_GUI || b == TLFIdentifyBehavior_CHAT_CLI
}

which is missing the new flag I was talking about.

Ok got it, I thought you were just talking about the AlwaysRunIdentify function itself.  Feel free to open up a new PR to re-vendor client to get the new behavior (or I'm happy to do it if you like).

Like I said this new flag doesn't add any new functionality, but the desktop team didn't feel comfortable using the CLI flag if they wanted identifies to be failures.

Ok will do!


password length limit is too high

validatePassphrase enforces that passphrases must be shorter than 600 bytes. At this point, the de facto limit is lower (because passphrases are set through NS REGISTER or NS PASSWD, which is limited to 512 bytes now that maxline is gone).
You can use extremely long passwords with SASL (because we support line continuations), but passwords around 400 bytes are problematic because it could be difficult to change them with NS PASSWD. I think 256 bytes is a more sensible limit.

Makes sense. We also need to keep in mine that bcrypt caps out at a certain length, which I thiiink is an issue we used to run into back when I was doing salts manually (the long salt prefixes were cutting off the actual password the user entered).

Ah, that's not an issue anymore because we apply an initial pass of SHA3-512 before bcrypting (512 bits is 64 bytes, which is below the bcrypt length limit).

I'm raising this to 300 bytes, to accommodate the irctests that test SASL continuations (the blob needs to be 400 bytes or higher --- with base64 and the auth[cz]id, 300 bytes of passphrase is enough).


If I rotate the screen when playing the slideshow, a black screen will appear,and then it will normal

If I rotate the screen when playing the slideshow, a black screen will appear,and then it will normal

When I rotate screen slider shows only white and it does not play until I click the next icon.


Not working on os11 ?

Just copied the source into my project, dropped a textview onto my viewcontroller, changed the class to GrowingTextView and when I run, the keyboard overlays the textview?
So in my case I have a tableview and want to add this at the bottom. I created a view, dropped a textview in it (just as in the example 2).  What I don't understand is how this resizes the tableview while the keyboard is open?

So I "got this working" in the example adding a tableview to Example 2.  However in the example it ties the constraint to the BottomLayout which is now deprecated and we are told to use safe area.  How does this get updated to use save area of xCode 9.2 vs the BottomLayout ?

I have update all 3 examples with new auto layout implementation. You may take a look.

AWESOME!  thanks.. looking it over now.. Constraints are "great" but boy in IB they are so confusing.

That appears to work.. Can you add and example 2b which would put a table view above the control.  I'm attempting to do that and not sure if it all needs to be in a view and where the bottom contraint would be such that the tableview would resize and textview move up when keyboard is shown

Add a constraint that make your tableview's bottom equals to toolbar's top, then it should works.

Wow that "appears" to work however.  I took Example2 and simply added a tableview before the inputtoolbar and it appears to work just fine without messing with the constraint?   1 final  thing;   how can I scroll to the bottom of the list when the growingtext appears?  Is there a delegate method that gets called by growing text?

Are you sure it is working? I think you have to add constraint for that. Anyway, regarding your question, what do u mean "when the growingtext appears"? I guess you are talking about "keyboard appears", right? You need to implement keyboard observer in your ViewController (like Example2), then you may call tableView.scrollToRow(at: indexPath, at: .bottom, animated: true) when keyboard appears.


KeyError: 'logPath' while running remote experiment

While trying to run remote training and then get some info about the status, I get an error from nnicli:
root# nnictl log trial
Traceback (most recent call last):
  File "/root/.pyenv/versions/3.6.8/bin/nnictl", line 11, in <module>
    sys.exit(parse_args())
  File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/nni_cmd/nnictl.py", line 217, in parse_args
    args.func(args)
  File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/nni_cmd/nnictl_utils.py", line 366, in log_trial
    trial_id_path_dict[trial['id']] = trial['logPath']
KeyError: 'logPath'

Brief what process you are following:
Running an experiment as described in MNIST remote example. It got stuck in a "waiting" status, so I'm trying to request a log - nnictl log trial
How to reproduce it:

nni Environment:

nni version: 1.0
nni mode(local|pai|remote): remote
OS: Ubuntu 16.04.6 LTS
python version: 3.6.8
is conda or virtualenv used?:  no
is running in docker?: yes

need to update document(yes/no): no
Anything else we need to know:
This happens when I try to run experiment using remote mode, but from the same machine (trial and ctl are on the same machine). I see it starts to pack scripts dir with tar and then nothing happens. /tmp contains empty tar files (zero size). In Web UI status of trial keeps being waiting.

Thanks to @apatsekin for raising the issue, this is a bug of NNI. We will fix this issue in https://github.com/microsoft/nni/pull/1550, please feel free to give feedback if you have any questions.


Sometimes you just want to

fswatch . 'go build && ./app'
god I miss that command

feel free to add a pr


Topic form should send the data somewhere

should be an email, then we need a captcha maybe

Just remove thet form nd make it:
For questions & inquiries<EMAIL_ADDRESS>On Thursday, February 4, 2016, Clément Renaud<EMAIL_ADDRESS>wrote:

should be an email, then we need a captcha maybe
—
Reply to this email directly or view it on GitHub
https://github.com/duangish/duangish.github.io/issues/19.

removed the form. added the button, email works!


TypeError: node_1.Headers is not a constructor

Hi,
I'm seeing the following error when trying the quick start on remix v2:
TypeError: node_1.Headers is not a constructor
    at new EventStream (/example-ui/node_modules/src/server/EventStream.ts:31:21)
    at loader4 (/example-ui/app/routes/emitter.tsx:6:12)
    at Object.callRouteLoaderRR ((/example-ui/node_modules/@remix-run/server-runtime/dist/data.js:52:22)
    at handler ((/example-ui/node_modules/@remix-run/server-runtime/dist/routes.js:54:20)
    at runHandler ((/example-ui/node_modules/@remix-run/router/router.ts:3782:7)
    at callLoaderOrAction ((/example-ui/node_modules/@remix-run/router/router.ts:3842:22)
    at map (/(/example-ui/node_modules/@remix-run/router/router.ts:3155:9)
    at Array.map (<anonymous>)
    at loadRouteData ((/example-ui/node_modules/@remix-run/router/router.ts:3154:24)
    at queryImpl ((/example-ui/node_modules/@remix-run/router/router.ts:2932:26)

import { EventStream } from 'remix-sse'
import {LoaderFunction} from "@remix-run/router";
export const loader: LoaderFunction = ({ request }) => {

    // Return the EventStream from your route loader
    return new EventStream(request, (send) => {
        // In the init function, setup your SSE Event source
        // This can be any asynchronous data source, that will send
        // events to the client periodically

        // Here we will just use a `setInterval`

        const interval = setInterval(() => {
            // You can send events to the client via the `send` function
            send('greeting', JSON.stringify({ hello: 'world'}))
        }, 1000)

        return () => {
            // Return a cleanup function
            clearInterval(interval)
        };
    });
};

@jseparovic sorry for the late reply, this lib has not been tested yet on RemixV2 - I am in the process of updating it

@jseparovic sorry for the delay, everything is working for V2 now

:tada: This issue has been resolved in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

@dan-cooke Awesome! Thanks heaps for this. Perfect timing, I’m just getting back to UI dev today

@jseparovic no problem! Let me know if the integration goes smoothly, I’m still ironing out some ES module issues but check the examples to see how to import in the meantime!

@dan-cooke Sounds good! Yeh I need to integrate with our existing inventory REST API. We have a Socket.IO server which is sending basic CRUD events for changes to inventory objects. This is my first remix project so still trying to figure out the events architecture and how to keep the UI updated as objects are updated in the API. I'm thinking the remix server will open a connection to the socket.io server and then use remix-sse to trigger the client UI to refresh as CRUD events come in.

@dan-cooke looks good now on 4.0.0 with remix v2.
Only issue I saw was the RemixSseProvider path changed from:
import {RemixSseProvider} from "remix-sse/client";
to
import {RemixSseProvider} from "remix-sse/dist/client";

Great! That’s right about the paths - in v4 I changed the build structure slightly in an attempt to use workspaces with the example projects
There is an open PR #13 where I am investigating the issue
i will also open an issue to track this as it’s not ideal


Onchain Runner sets have Wine instead of Water Jug

This was fixed on the wiki and on app.aavegotchi.com (https://github.com/aavegotchi/aavegotchi-contracts/commit/f81369f031d5c69c5779764d8bd1b432b6e229fa#diff-960e4a0be23f3be297efc0ff8a0adda4786e72d7ab9d83d2a1fd986d7e674435L287), but the onchain sets haven't been updated.
ItemsFacet.getWearableSets still has Wine (121) instead of Water Jug (118) in the "Runner" and "Long Distance Runner" sets.

Updated and pushed onchain in https://github.com/aavegotchi/aavegotchi-contracts/commit/6aef490cead8bd4cd934cf7f3ab73fb00b42e5b4. Thanks!


Add DaduDev

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Hey 👋 I'm closing this for now, as the package-lock version in this PR is outdated again.
Feel free to pick another issue from the other open ones.
Tipp for the future: To prevent closed PRs in the future, feel free to jump into a discussion on an open issue, so we can clarify the requirements before the PR gets opened 👍


Enhance AdRequestOptions Extension Functions

This PR introduces enhancements to the extension functions for configuring AdRequestOptions related to ad content ratings and compliance with various app categories.
Changes Made
Refinement of Existing Extension Functions
The existing extension functions for configuring AdRequestOptions have been refined and extended to include additional scenarios. The following extension functions are now available:

setForChildrenApp(): Configures options for apps designed specifically for children.
setForFamilies(): Configures options for apps targeting families, with support for primarily child-directed and mixed-audience apps.
setForEveryoneApp(): Configures options for apps targeting everyone, including children and families.
setForTeens(): Configures options for apps targeting teens.
setForAdults(): Configures options for apps targeting adults.

These extension functions provide a streamlined way to set the appropriate content rating and treatment options for ads, ensuring compliance with policies and regulations across different app categories.
How to Use
You can utilize the extension functions to configure AdRequestOptions for various app categories as needed. The method for configuring AdRequestOptions depends on your context:

If you are within a Composable context, you can access the AdRequestOptions via LocalAdsControl.current:
val adsControl = LocalAdsControl.current
adsControl.adRequestOptions.apply {
  maxAdContentRating = AdContentRating.UNSPECIFIED
  tagForChildDirectedTreatment = TagForChildDirectedTreatment.UNSPECIFIED
  tagForUnderAgeOfConsent = TagForUnderAgeOfConsent.UNSPECIFIED
}

If you are outside of a Composable context, you can use AdMob.configureAdRequest:
AdMob.configureAdRequest {
  maxAdContentRating = AdContentRating.UNSPECIFIED
  tagForChildDirectedTreatment = TagForChildDirectedTreatment.UNSPECIFIED
  tagForUnderAgeOfConsent = TagForUnderAgeOfConsent.UNSPECIFIED

  setForFamilies()         // Configure for apps targeting families
  setForChildrenApp()      // Configure for apps designed for children
  setForEveryoneApp()      // Configure for apps targeting everyone, including children and families
}

Choose the appropriate method based on your context to configure AdRequestOptions for your application's specific requirements.
This allows you to easily set the appropriate ad content rating and treatment options for ads within your application.

New Features Added:

Extension functions for AdRequestOptions to configure settings for different audience age groups.
Updated documentation for the new functions.

Compliance with Google Play Service and AdMob Policies:
These extension functions have been designed to ensure compliance with Google Play Service and AdMob policies, especially with regard to the ad content rating and child-directed treatment settings. When using these functions, developers can be confident that their apps meet the required criteria for the specified audience age groups and adhere to both platform's policies.


fix: remove exports

I'm sort of confused at the new export maps so I'm just removing it.
Related to #36

Related https://github.com/developit/microbundle/issues/795


Add Sharding v1.0 Spec & Storage Transformers to Zarr v3.0

This PR adds a specification for the sharding protocol, as discussed in issue #127 and explored in Python implementations previously[^PRs]. From those discussions the presented sharding design emerged as a reasonable candidate we hope to include with zarr v3. We, this is scalable minds, will also provide a PR based on this spec for sharding support in zarr-python v3 after those changes are incorporated into the zarr-spec. This work is funded by the CZI through the EOSS program.
This PR adds the sharding & storage transformer concepts to the zarr v3 specs.
The following parts are copied from the spec in this PR:
Sharding

This specification defines an implementation of the Zarr
storage transformer protocol for sharding.
Sharding co-locates multiple chunks within a storage object, bundling them in shards.

Motivation

In many cases it becomes inefficient or impractical to store a large number of chunks in
single files or objects due to the design constraints of the underlying storage,
for example as restricted by the file block size and maximum inode number for typical file systems.
Increasing the chunk size works only up to a certain point, as chunk sizes need to be small for
read efficiency requirements, for example to stream data in browser-based visualization software.
Therefore, chunks may need to be smaller than the minimum size of one storage key.
In those cases it is required to store objects at a more coarse granularity than reading chunks.
Sharding solves this by allowing to store multiple chunks in one storage key, which is called a shard:

Storage transformer

A Zarr storage transformer allows to change the zarr-compatible data before storing it.
The stored transformed data is restored to its original state whenever data is requested
by the Array. Storage transformers can be configured per array via the
storage_transformers name in the array metadata.
A storage transformer serves the same Abstract store interface as the store.
However, it should not persistently store any information necessary to restore the original data,
but instead propagates this to the next storage transformer or the final store.
From the perspective of an Array or a previous stage transformer both store and storage transformer follow the same
protocol and can be interchanged regarding the protocol. The behaviour can still be different,
e.g. requests may be cached or the form of the underlying data can change.
Storage Transformers may be stacked to combine different functionalities:

    graph LR
      Array --> t1
      subgraph stack [Storage transformers]
        t1[Transformer 1] --> t2[...] --> t3[Transformer N]
      end
      t3 --> Store

Sequence diagram with storage transformer
  Please click the arrows on the right to see the diagram
  sequenceDiagram
    actor User
    participant Codec as Codec (& Filters)
    participant Array
    participant ST as Storage Transformers
    participant Store

    User->>Array: a[10:20]
    Array->>Array: index_to_chunks
    Array->>ST: get(…)
    loop for all transformers
      ST->>ST: get(…)
    end
    ST->>Store: get(…)
    Store-->>ST: bytes
    loop for all transformers
      ST-->>ST: return bytes
    end
    ST-->>Array: bytes
    Array->>Codec: decode(bytes)
    Codec-->>Array: decoded_bytes
    loop for all filters
      Array->>Codec: decode(bytes)
      Codec-->>Array: decoded_bytes
    end
    Array->>Array: interpret_as_array
    Array-->>User: data

The spec contains many more details, please see the diff of this PR for a full overview.
To see the rendered spec in an auto-reloading server, I ran
## optionally setup an venv
# python3 -m venv .venv
# . .venv/bin/activate
pip install -r docs/requirements
pip install sphinx-autobuild
sphinx-autobuild docs docs/_build/html

We'd be very happy to get feedback on this PR, high-level as well as concrete suggestions and questions.
Two high-level questions that came up directly during the design:

Should we introduce the concept of Storage Transformers here? This concept seems to be a great point to plug in other future extensions, and quite the right abstraction for sharding. An alternative would be to incorporate sharding as one specific mechanism without adding the whole transformer concept. Implementation wise this would behave just like one specific transformer, but the logic could also be implemented closer to the Array or Store instead.[^transformer-thoughts]
Should storage transformers be formulated as extensions? Then the storage_transformer key for each transformer would rather be called extension and the extension would need to be listed in the array metadata extensions key I guess. This would be helpful if optional storage transformers might be added. One such example might be a caching storage transformer (not actually transforming things, just caching).

@alimanfoo In the community call two weeks ago there was the suggestion that you might be a great candidate for the first main review, since there's quite some overlap with issue #82. What do you think?
Thanks everyone for the helpful discussions so far! We hope to get the design finalized via this spec and look forward to getting this into zarr production :tada:
cc @joshmoore @d-v-b @jbms @jakirkham @MSanKeys963 @rabernat @shoyer @d70-t @chris-allen @mkitti @FrancescAlted @martindurant @DennisHeimbigner @constantinpape
[^PRs]: Previous explorations regarding Sharding with the Python implementations:
https://github.com/zarr-developers/zarr-python/issues/877: original issue for the Python implementation, containing many discussions around the sharding protocol design
https://github.com/zarr-developers/zarr-python/issues/876: initial prototype PR
https://github.com/zarr-developers/zarr-python/issues/947: another prototype where the translation logic happens purely in the Array class
https://github.com/alimanfoo/zarrita/pull/40: PR in the clean room implementation zarrita in the spirit of the Prototype I, but simplified as much as possible
[^transformer-thoughts]: Sidenote: I think the storage transformer serves a similar purpose on the store side as filters do on the encoding side. They provide a clear interface to add store-agnostic functionality, similar as filters do that for encodings. See also the collapsed Sequence diagram with storage transformer above.

Should we introduce the concept of Storage Transformers here? This concept seems to be a great point to plug in other future extensions, and quite the right abstraction for sharding. An alternative would be to incorporate sharding as one specific mechanism without adding the whole transformer concept. Implementation wise this would behave just like one specific transformer, but the logic could also be implemented closer to the Array or Store instead.

One thing that I think would really help address this question is if we consider what other storage transformers might be useful, and how they would stack before and after sharding.
Two ideas I've heard mentioned are:

content-addressable storage (CAS): the store adds an additional level of indirection and deduplicates based on content hash.
independent of CAS, something that adds chunksums in order to detect data corruption

It seems to me that 1 (content-addressable storage) could be stacked after sharding, though since it would deduplicate entire shards it would not be particularly useful (and to actually verify the checksum of partial reads would require a more complicated tree-of-checksums approach).  It is less clear how it would work to stack it before sharding; probably the sharding tranformer would need to be modified to just pass through the hash keys (so the shards would just store the keys of each chunk, not the chunk itself), but then it would fail to accomplish the original objective of sharding, which is to reduce the number of keys in the underlying store.
It seems that (2) could be stacked before or after sharding, though if stacked after sharding it would need a more elaborate tree-of-checksums approach in order to allow verifying the checksums of partial reads.  If stacked before sharding, it could also be implemented as a codec.
The other point, not directly relevant to the spec, is that it would be useful to expose in a convenient way on the array class itself something that indicates the optimal chunk shape for writing (i.e. the shape of each shard); previously users would just use the chunk shape for this purpose, but with sharding a separate attribute is needed.

One thing that I think would really help address this question is if we consider what other storage transformers might be useful, and how they would stack before and after sharding.

Agreed! That's very important to assess if storage transformers are a helpful concept here. We might not need to "fix" compatibility of sharding with possible future storage transformers yet, but it's very useful to explore.
My understanding for the CAS proposal is that the hash keys are stored at the original data location, and that the value entries are stored under a different prefix, e.g. content/…. Having 1 (CAS) stacked after sharding, my understanding also is that the keys are then grouped per shard, which does solve half the problem in this case, and content keys are still per chunk. Deduplicating the chunks and combining chunks into regular grid sized shards seem to be contrary concepts at first glance to me, but the content keys could be combined with a different strategy (e.g. some tree).
Besides the two possible future proposals you mentioned, I found two storage transformers already in the current v2 zarr-python implementation, which are implemented as stores wrapping another store (basically the same thing as a storage transformer, without the formalizations):

`ConsolidatedMetadataStore](https://zarr.readthedocs.io/en/stable/api/storage.html#zarr.storage.ConsolidatedMetadataStore)

A layer over other storage, where the metadata has been consolidated into
a single key.
The purpose of this class, is to be able to get all of the metadata for
a given array in a single read operation from the underlying storage.
See zarr.convenience.consolidate_metadata for how to create this
single metadata key.
This class loads from the one key, and stores the data in a dict, so that
accessing the keys no longer requires operations on the backend store.
This class is read-only, and attempts to change the array metadata will
fail, but changing the data is possible. If the backend storage is changed
directly, then the metadata stored here could become obsolete, and
zarr.convenience.consolidate_metadata should be called again and the class
re-invoked. The use case is for write once, read many times.

LRUStoreCache:

Storage class that implements a least-recently-used (LRU) cache layer over
some other store. Intended primarily for use with stores that can be slow to
access, e.g., remote stores that require network communication to store and
retrieve data.

Also, compatibility layers might be implemented at the storage transformer level, to be able to transform metadata directly.
What I quite like about the storage transformer stack concept already, it makes it easy to wrap your head around and communicate the exact behavior (e.g. what does X before Y or Y before X in the stack), since it brings a clear interface and abstraction. However, I think it's also perfectly fine to "just" introduce sharding as a core mechanism, without the additional transformer concept.

Hi @jstriebel, great to see this and very happy to review.
One small thought, in approaching this it might be useful to distinguish between storage transformers, which do actually make some change to how the data is organised within the base store, and other types of storage layer such as caching, which are not changing how data are organised but offer some other advantage such as performance.
The obvious reason for this distinction is that if a true storage transformer has been used, then a zarr implementation that's trying to read the data needs to know about it, and so it needs to be included in the zarr metadata so the implementation can discover it. That is equally true regardless of which zarr implementation is being used, and what type of base storage is being used.
Other storage layers such as caches are configured at runtime depending on the application and/or the zarr implementation and/or the base store type, and so should not be included in zarr metadata.

I wonder about the efficiency of the indexed shard format. Depending on shard/chunk size, reading the index could potentially be moderately expensive. In the worst case (without caching), there would be twice the number of IO operations required to read a chunk.
The alternative would be some form of higher level index, e.g., at the level of an entire array. For moderate numbers of chunks (e.g., <1e7) this might be desirable.
Do we have a sense of what shard/chunk sizes would be desired in practice? That might help inform these design decisions.

The desired shard size probably depends on a lot of factors, such as relative cost/overhead per key/value pair on the underlying store, the throughput of the underlying store, and the desired write pattern.  But I think for GCS or similar cloud storage I would probably target 1GB shards normally, perhaps containing several thousand chunks.  Possibly for a very large array and a fast network could go larger, ~10GB, but then the shard index starts to be rather large.
A single shard index for the entire array means it is challenging to write the array in parallel without additional coordination, which I think is a major drawback.
Additionally, it seems like in the uncached case it is actually worse than a separate index per shard -- you would still be reading the entire shard index.  However it is true that if you first read a complete index of all chunks and cache it, then it would be more efficient to be able to read that index with a single read rather than one read per shard.

But I think for GCS or similar cloud storage I would probably target 1GB shards normally, perhaps containing several thousand chunks.

This sounds about right to me.

A single shard index for the entire array means it is challenging to write the array in parallel without additional coordination, which I think is a major drawback.

I agree, I was imagining this as more similar to consolidated metadata -- something that is written after the fact.
In any case, I guess this is something that could be layered on later, if desired.

Interesting connection here in what happens in kerchunk? You can already create a virtual dataset over many zarr datasets, where each of those may live in different buckets or even different backing stores. This would correspond to the idea earlier in this thread of moving sharding into the storage layer, but also comes with the benefit of consolidating the metadata. I'm not saying it's a replacement, but perhaps a complementary way to achieving something similar, one that already works in V2.

One small thought, in approaching this it might be useful to distinguish between storage transformers, which do actually make some change to how the data is organised within the base store, and other types of storage layer such as caching, which are not changing how data are organised but offer some other advantage such as performance.

@alimanfoo Good point, absolutely agree! I think runtime-configured storage-transformers could mostly be appended or prepended to the stack. Do you already have further feedback regarding the specs? I'm on vacation for a week, but happy to apply any feedback afterwards.

Interesting connection here in what happens in kerchunk? You can already create a virtual dataset over many zarr datasets, where each of those may live in different buckets or even different backing stores. This would correspond to the idea earlier in this thread of moving sharding into the storage layer, but also comes with the benefit of consolidating the metadata. I'm not saying it's a replacement, but perhaps a complementary way to achieving something similar, one that already works in V2.

@martindurant  Agreed! I think there's value in having this in the zarr standard, but interesting to see how this would be done in kerchunk. This would require configuring each shard in kerchunk, right?

Interesting connection here in what happens in kerchunk? You can already create a virtual dataset over many zarr datasets, where each of those may live in different buckets or even different backing stores. This would correspond to the idea earlier in this thread of moving sharding into the storage layer, but also comes with the benefit of consolidating the metadata. I'm not saying it's a replacement, but perhaps a complementary way to achieving something similar, one that already works in V2.

@martindurant Agreed! I think there's value in having this in the zarr standard, but interesting to see how this would be done in kerchunk. This would require configuring each shard in kerchunk, right?

Each chunk of each shard is referenced by the collected reference set. So kerchunk scans the inputs just once and collates this information. "configuring" sounds more heavy, I'm not sure what you mean - it's pretty simple.

@alimanfoo It would be great to get your review on this proposal, could you maybe give an estimate when you have time for it?

@jstriebel - thanks a lot for all of your hard work and patience. 🙏
This PR has revealed that our governance is still lacking in terms of ability to make major decisions in a timely way. I recognize that this must be frustrating for a contributor such as yourself who has put a lot of work into Zarr. The situation reflects the fact that we are still in transition away from a BDFL governance model towards a more community-based one.
I am very optimistic that the ZEP process (currently being refined in https://github.com/zarr-developers/governance/pull/16) will give us a good framework to decide on this PR. I hope we will conclude the ZEP discussion and accept it by the end of next week. After that, we can reframe this PR as a ZEP, with your top-level comment basically serving as the text of the ZEP. If my suggestion in https://github.com/zarr-developers/governance/pull/16#pullrequestreview-936576560 is accepted, approval would require

Unanimous approval of the Zarr Steering Committee
Majority approval of the Zarr Implementations Committee. Approval indicates that that implementation plans to implement the new spec features. Not all implementations must implement all features, but a majority is required.
No vetos from the Zarr Implementations Committee. Each implementation has the right to veto a ZEP if it would cause severe problems for that implementation.

I will personally commit to doing whatever I can over the next weeks to ensure that this process evolves in a timely way. Because this work touches the spec so deeply, you have inadvertently become a 🐹  (guinea pig, not hamster!) in our nascent spec governance process. I know that was probably not what you signed up for. But I am very optimistic that this effort will bootstrap a much more efficient and sustainable framework for evolving the Zarr spec. So thank you again!

A brief update from the rousing community call yesterday evening (my time): it seems that the tendency is towards simplifying the V3 spec and getting it out and then layering this proposal on top in the least breaking way possible.

As discussed during recent community meetings and steering council, merged this proposal into the dev branch as a common basis for discussions. The final list of features to be included in v3.0 is to be decided.


feat(kernels): implement the DVR algorithm

TODO
ref: https://epubs.siam.org/doi/abs/10.1137/16M1089101

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

Project coverage is 81.78%. Comparing base (d79671f) to head (b5d98f8).
Report is 2 commits behind head on master.

Files with missing lines
Patch %
Lines

honeycomb-kernels/src/dvr/mod.rs
0.00%
60 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #212      +/-   ##
==========================================
- Coverage   82.04%   81.78%   -0.26%
==========================================
  Files          41       42       +1
  Lines        5681     5930     +249
==========================================
+ Hits         4661     4850     +189
- Misses       1020     1080      +60

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


WKEnsure & WKDSG review of update Best practices Handbook

To be performed after #13

Followup workshop from WKENSURE october 2023 WKAFPA

The following recommendations were listed as 'related to the Best practices document' (hereafter BPD), see https://community.ices.dk/Committees/DIG/Master documents/Best practices document/Recommendations_WKEnsure_WKDSG.xlsx?web=1:
WKEnsure 2023-35: not incorporated as the BPD focusses on the data contributors and not on the users
WKDGS 2021-30: version 2 of the BPD provides more information on standards, and communication channels.


Add UpdateInputOutput parameter

Added UpdateInputObject parameter which will allow user to update the input and output for their existing markdown files.  Also updated the parser to correctly parse input and output from the get-help call.  Previously it would treat all types as a single string, now it will treat each type on a new line as a separate type.
Previously, parsed as:
"
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultKey
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultSecret
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultCertificate
"
Now parsed as:
"Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultKey"
"Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultSecret"
"Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultCertificate"
This means that the output looks like:
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultKey
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultSecret
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultCertificate
Instead of:
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultKey
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultSecret
Microsoft.Azure.Commands.KeyVault.Models.PSKeyVaultCertificate

Alright, I defintely learned from this what is considered INPUT in PowerShell :) Thank you!
Let's adress the minor comments (avoid copy-pasting as much as possible) and we should be good for a merge.

@vors Done! Let me know if there's anything else I need to address.

@vors Ping :)


created make commands for implementing poetry

Changes

"implement-poetry" command will install poetry and add dependencies from "requirements.txt" and also modify Dockerfile accordingly.
"add" and "remove" command can be used to add or remove dependencies going forward.

Fixes #281

Hey @chynh! Since this whole COVID-19 pandemic I've been preoccupied with other things and totally missed this. Thanks for picking this up, I'll review it soon!

@chynh Hey, I took a look just now. I think there was a misunderstanding in what we wanted. We want to get a poetry.lock file actually locking down the required versions of the required packages and change the Dockerfile to install those when the image is built. Once we do that, we won't need the requirements.txt file anymore so you can delete that in favor of the poetry.lock file.
I like the idea of being able to add and remove packages using make. Can you give an example of how to use that?

@chynh Hey, I took a look just now. I think there was a misunderstanding in what we wanted. We want to get a poetry.lock file actually locking down the required versions of the required packages and change the Dockerfile to install those when the image is built. Once we do that, we won't need the requirements.txt file anymore so you can delete that in favor of the poetry.lock file.

@aaron-suarez Got it. So I believe running make implement-poetry would basically initialize poetry and install all required packages from requirements.txt. After that, you would have poetry.lock and pyproject.toml in both the container and your local machine. Finally, the script will modify Dockerfile to reflect the changes, like to copy pyproject.toml and poetry.lock instead of requirement.txt, install the packages on poetry.lock file when the image is built, etc.
I didn't yet make is so that requirement.txt would get deleted but that's something that I can include in the script.
Does this sound similar to what you had in mind?

I like the idea of being able to add and remove packages using make. Can you give an example of how to use that?

Yeah, this is definitely not included in the original scope of the issue but while working on it, I just thought it would be useful and decided to throw it in. You could use this command to add or remove package from poetry like so:
make add <some package>
make remove <some package>

I guess I just don't understand the use case for why we need to run make implement-poetry more than once.

I guess I just don't understand the use case for why we need to run make implement-poetry more than once.

Ah okay. Yeah, that's a fair point. I guess this should really be a one-time thing rather than having a command for it.
I can remove the make implement-poetry command. So just to double-check, would you be okay with me just running this and committing the changes? I think that would roughly include modifying the Dockerfile, removing requirement.txt and adding poetry.lock file.

Yes, go ahead and run it, remove the command from the makefile and then commit the changes. And the dockerfile changes if that doesn't happen automatically. I'll do another round of review after that to make sure it all looks good

Oh and you can leave in the add/remove commands, that looks handy. Thanks for thinking of that

I guess we have a conflict in requirement.txt that we'll need to fix, but it seems to run fine locally. @mc962 @irvingpop Would you guys mind taking a look at these changes as well and making sure it looks right?

You'll need to git rebase your branch before this is green to merge

I did update poetry packages as I realized I wasn't using the latest requirements.txt. Let me know if there is anything else that needs to be addressed

Ok, took another look at it and we're pretty close. Please remove the requirements.txt file, as we won't be needing it anymore. If we do need one for some reason, we can always generate it from the poetry.lock file using poetry export -f requirements.txt > requirements.txt
Once you make that change, I'll be happy to merge!


How to handle optionalDependencies

Using this plugin results in issues when libraries have optional dependencies. Moving over from https://github.com/rollup/rollup-plugin-node-resolve/issues/24 Originally opened by @leeyeh. Quoting them:
var memcpy = null; try { memcpy = require("memcpy"); } catch (e) {}
if (memcpy) // ...

will be rolled to
var require$$0$2 = _interopDefault(require('memcpy')); // throw
// .....
var memcpy = null; try { memcpy = require$$0$2; } catch (e) {}
if (memcpy) // ...

@calvinmetcalf Do you have ideas about it?

if _interopDefault(require('memcpy')); was moved down to the actual point it was retired that would probably do the trick

@Rich-Harris What was the reason to split assignment and requiring?

@TrySound because imports have to be at the top level – there's no way to turn a require inside a try-catch into an equivalent import. I think this is just a fundamental difference between CJS and ES. Even if there were some way to keep the final require call in the same place as the original in the case of CJS bundles, it doesn't work for AMD, UMD etc.
I don't really have any good ideas for this off the top of my head.

Just saw this in React-Virtualized. One way to handle this would be introduce some level of support for runtime require() calls, where the contents would be pre-hoisted (i.e. calling require would simple execute whatever code would have otherwise been imported).

I have exactly this issue with try-thread-sleep. What's the recommended workaround?

Related: https://github.com/rollup/rollup/issues/1385
Is this still an issue?


Fix infinite thread leaks while flushing queues in state store

If https://github.com/airbnb/MvRx/pull/277 is working then you should be able to get this in a 1.2.0-SNAPSHOT soon

No problem ;)


Latest page search bar is broken

It's been 2 days since I made a release of fs-tree that introduced a method called read_at.
However, when I go to the /latest/ documentation page, and search it, I get nothing:
https://docs.rs/fs-tree/latest/fs_tree/?search=fstree%3A%3Aread_at

In contrast, the /0.5.5/ page search bar works as expected:
https://docs.rs/fs-tree/0.5.5/fs_tree/index.html?search=read_at

This is specifically a problem with the search bar, since the method page can be seen in both versions:
https://docs.rs/fs-tree/latest/fs_tree/enum.FsTree.html#method.read_at
https://docs.rs/fs-tree/0.5.5/fs_tree/enum.FsTree.html#method.read_at

To be clear, the latest page shows that the version is indeed 0.5.5.

Problem is not found in local rustdoc pages.

It works for me which makes it likely to be a local caching issue. I think it might be because 0.5.4 and 0.5.5 were built with the same rustdoc version, and that's the only part of the search-index-....js filename that varies between builds.

@Nemo157 IMO this is the last remaining case of #1593 , and only can happen when two releases are build with the same nightly version.
I created an CDN invalidation for the crate.
If the search is fine now for @marcospb19 I would close this issue in favor of #1593

I cannot re-test it, because I had to refresh the cache to confirm @Nemo157's point.
But I'm ok with closing it :) .


Added Color to the buttons to make calculator more colorfull

Decimal numbers already submitted pull request,
this is the 2nd pull request for making it more colorful.

!bounty 10


Disable Checkbox not working

When I do disable_checkbox on a node, it doesn't work. Doing disable_node with same node disables the node but then it becomes grayed out which I do not want.
Here is how I initialized jstree:
                treeCheckbox.jstree({
                    'checkbox': {
                        'three_state':false,
                        'tie_selection': false
                    },
                    "plugins": ["checkbox", "themes"],
                });

jstree version: 3.3.8

Please provide an example so that I can see which  part is not working. If the only problem is the graying out - you can override it in your own CSS.


screen returns non-zero exit status 1

Executing
./asciinario.py demo.asciinario my.cast 2> errors.txt

I get in errors.txt the following:
Traceback (most recent call last):
  File "/home/arialdo/tmp/asciinario/./asciinario.py", line 129, in <module>
    play_inscript(instructions, screen_id)
  File "/home/arialdo/tmp/asciinario/./asciinario.py", line 111, in play_inscript
    player.do(line)
  File "/home/arialdo/tmp/asciinario/./asciinario.py", line 23, in do
    return method(self, match)
  File "/home/arialdo/tmp/asciinario/./asciinario.py", line 32, in do_status_change
    self.send_screen("hardstatus", "alwaysfirstline")
  File "/home/arialdo/tmp/asciinario/./asciinario.py", line 89, in send_screen
    subprocess.check_output(["screen", "-S", self.screen_id, "-X", *args])
  File "/usr/lib/python3.10/subprocess.py", line 421, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.10/subprocess.py", line 526, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['screen', '-S', '792e45e6-6928-4f0d-84ea-a673a29094cd', '-X', 'hardstatus', 'alwaysfirstline']' returned non-zero exit status 1.
asciinema: recording asciicast to my.cast
asciinema: exit opened program when you're done

Here's my setup:
❯ python --version
Python 3.10.9
❯ screen --version
Screen version 4.09.00 (GNU) 30-Jan-22
❯ asciinema --version
asciinema 2.2.0

Any idea? Thank you very much!

I think the issue was that not enough time was given to screen to start properly. I now poll screen for a few seconds, that should hopefully be enough. Can you git-pull and test again?

Sure! In 9f7574a25ff6318be9004a489c0e8bf9ae6c3f08 it works perfectly! Thank you!


Update golang example

The golang example is broken, this patch make it work again.

Can you please revert the space -> tab changes? They make reviewing harder and are inconsistent with the rest of the file.

@bjorn3 done

Thanks for this @kamyuentse!


add docs to clip_from_view

more docs

Users can also use a custom projection

im aware, i think if a user is advanced enough to do custom projections then they know what they're doing. i cant possibly document what they are doing anyways

Mhm. Just thinking we should maybe leave a comment reminding people about it. Up to you, I don't feel strongly either way.

The other nice thing to add would be how you check for ortho vs perspective in a shader.

addressed both

Docs always good. Is there anything we can do to avoid having 3 sets of the same docs from getting out of sync? Newtyping? Including a text document or linking to it?

You can include_str various bits of text in docs. In this case though module docs feel more correct.


Converting Krnl to affine or std

It seems that even after converting the Krnl dialect to the Affine dialect by using onnx-mlir-opt --convert-krnl-to-affine --lower-affine input.mlir > out.mlir, some operations of Krnl are not converted to Affine. How to get rid of the Krnl dialect ?
When I try to add the C wrappers using mlir-opt --convert-std-to-llvm='emit-c-wrappers=1' --allow-unregistered-dialect out.mlir -o c.mlir I am getting the following error:
out.mlir:2939:24: error: custom op 'krnl.vector_type_cast' is unknown                 %198 = krnl.vector_type_cast %95 : memref<256x64xf32> to memref<256x4xvector<16xf32>>
Thanks!

To get a good feel, either read the code that plan the optimizations, and/or run onnx-mlir with the -print-ir-after-all options. There are indeed more opts to lower krnl just before LLVM. Others are needed if there are simd instructions.

closed due to lack of activity


Meteor Update And MutationObserver fix

Update Package declaration for latest meteor version
Fix MutationObserver missing method takeRecords

Any updates?


Add a new GRPC port for frontend for authentication.

Fixes #1568

Closed as the commit has been merged to #1579


Problem with emotion widgets (standard theme) and profiler comments

In themes/Frontend/Bare/widgets/emotion/index.tpl there's this code:
<section class="emotion--container emotion--column-{$emotionCols} emotion--mode-{$emotionMode} emotion--{$emotion@index}"
                         data-emotion="true"
                         data-gridMode="{$emotionGridMode}"
                         data-fullscreen="{if $emotionFullscreen}true{else}false{/if}"
                         data-columns="{$emotionCols}"
                         data-cellSpacing="{$cellSpacing}"
                         data-cellHeight="{$cellHeight}"
                         data-baseWidth="{$baseWidth}"
                         {block name="widgets/emotion/index/attributes"}{/block}>`

When using comments for block reference, the profiler breaks the html while surrounding the block in the code above with html comments.

It results in broken code:

![shyim_bug](https://cloud.githubusercontent.com/assets/3703637/24154799/76cabe48-0e52-11e7-939d-4765f3f826da.jpg)

Fixed with latest version


operator [O] flux (2.0.1)

Thanks for submitting your Operator. Please check the below list before you create your Pull Request.
Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description of the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.

/retest

/retest

/retest

I don't understand the failures here. Is it related to the minimum k8s version?

@souleb yes. Basically in the CSV you are declaring that the operator requires k8s >= 1.24.0 but you are not declaring that it does not support openshift 4.10 (which corresponds to k8s 1.23).
You should probably set annotations.com.redhat.openshift.versions to v4.11 in metadata/annotations.yaml.

/hold cancel

@souleb I think for this to work we need to first need to remove 2.0.1 from the index and then re-submit it.
Can you please close this one and submit a PR to remove 2.0.1?

@souleb works for me. Closing.


Is this plugin still active

See no much activity

I'm just here to verify the plugin works for android.


On Pypi

I want pip install snipergw. The name is free on pypi. We need to build this into the CI, after #4

Follow-up: this seems to be basically impossible right now. If gwemopt is treated as a submodule, pypi won't take the wheel. If gwemopt is a regular dependency, all the argparsing stuff won't work because gwemopt has a non-standard directory structure, with much of the magic happening in bin/, and you need to import the file.

Now possible after #73


docs: ADR-009 liquidity mining

Description
ADR proposing a new module

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[x] added appropriate labels to the PR
[x] added ! to the type prefix if API or client breaking change
[x] targeted the correct branch (see PR Targeting)
[x] provided a link to the relevant issue or specification
[x] added a changelog entry to CHANGELOG.md
[x] included comments for documenting Go code
[x] updated the relevant documentation or specification
[x] reviewed "Files changed" and left comments if necessary
[x] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

The lockup periods (1 | 7 | 14 days), would have different percentages of rewards?
Like if I have locked up for 1 day I would receive the same amount of rewards as another one which locked up for 14 days?

The lockup periods (1 | 7 | 14 days), would have different percentages of rewards?
Like if I have locked up for 1 day I would receive the same amount of rewards as another one which locked up for 14 days?

They'll need different rewards so we can incentivize longer lock periods.

Marked R4R now. Here are a couple notes in advance:

The isolated (from each other) design of incentive programs right now seems to prevent a variety of edge cases. I favor this approach over one that would allow for combinations, extensions, and alterations of ongoing programs.
"Three lock tiers across the board" was a frontend decision during our original design meetings - it's what users can understand. For that reason, having custom tiers per incentive program isn't something we should explore unless we really need to.


Improper commits used when a pipeline is crossed with its ancestor

What happened?:
We have a pipeline ("Imputed SNP Chip Datasets") that has a Cross input of two pipelines. One of these inputs is also an ancestor of the other pipeline. This one input (see below) is called "SNP Chip Reference Set." This repo follows the deferred processing concept and every time we want to persist one of the results we assign it to a branch (e.g., freeze-1). Once one of the results is persisted it is added as input for the Cross. The idea is that for every saved "SNP Chip Reference Set' we want to perform this "imputation" operation on each Dataset from "SNP Chip Datasets" and organize them into folders based upon the reference set used.

The issue we're facing now is that not all datasets from "SNP Chip Datasets" are being processed. It appears to be randomly determining the input commit that is used to be either "Commit 1" or "Commit 2" (these are the ancestor commits that were used for setting the branches of freeze-1 or freeze-2). It will never use the latest commit for this operation. Similarly, I cannot manually run pipeline and specify the commits.
 If we pick another execution of the job it might have used the provenance of the other freeze branch.
What you expected to happen?:
We expect it to use the latest commit on master branch when pulling from "SNP Chip Datasets."
How to reproduce it (as minimally and precisely as possible)?:
I believe what is in the diagram is the most minimal way to reproduce it. I am going to test this out more and I will let you know if I can simplify it further.
Anything else we need to know?:
Environment?:

Kubernetes version (use kubectl version): v1.14.10-gke.42
Pachyderm CLI and pachd server version (use pachctl version): 1.10.3 for both
Cloud provider (e.g. aws, azure, gke) or local deployment (e.g. minikube vs dockerized k8s): GKE
OS (e.g. from /etc/os-release): Arch Linux -- Linux 5.6.13
Others:

We believe this may be a new issue that started after upgrading to pachyderm 1.10.3 from 1.9.6 (I believe).

This is a corner case that our provenance system doesn't currently handle. The provenance system is designed with the assumption that each job only processes one commit from each branch, this generally makes sense as a constraint because it gives a consistent view of the world. Different commits on the same branch represent different versions of the same data, and a lot of confusing things can happen if you're using different versions of the same data set. I realize though that it's intentional in this case.  I'm wondering if there's maybe a different way to accomplish the same thing that doesn't require crossing different versions of the same dataset. The data that's in the earlier commits, is it still present in the more recent commit? Or does it get deleted? If it's still present then it seems like you can just cross the commit with itself (or maybe use a join to filter pieces you don't want) to get the data you need. And if it is getting deleted you might want to re-architect things so it doesn't get deleted.
This is definitely a more complicated use case so it might make sense to go over this in slack or a call so we can help you figure out how to get it working.

Hey @jdoliner, I can message you on slack and we can setup a call after that if necessary. I will send the message later today. Anyone else you want me to include on it?

We were able to reproduce the issue, and determined that it's due to a subtle bug with job inputs. When a new job is started, and the provenance for it has multiple commits on the same branch and repo, it uses the last one it sees in the provenance slice. However, the ordering of the provenance slice is non-deterministic, so it essentially will randomly choose one of the commits it sees. Our intended fix is to do a topological sort on the slice before creating a new job, so that it always chooses the latest such commit.

Thanks for looking into this @adelelopez. Joe has given us a solution that we will implement in the meantime.


Multiple Carousel and HttpClient

Great work on the mobile blazor bindings!
I seem to have a strange issue when using multiple carousels in a page.
In my example I have 2 carousels and they work as expected, but when I do a HttpRequest in the page the second carousel breaks, so it cant swipe left or right. This is for IOS and gives the same behaviour in the simulator and on my iphone.
The http request does not update anything in the example, but I would like to pull data using a get request and then populate multiple carousels in the same page.
Any ideas as to what may be going wrong?
https://github.com/cornelhuman/newtest
If I comment out await GetData(); in the MainPage.razor it works as expected.

Thanks for kind words!
I've tried to reproduce the issue from your repro, but failed to do so. Could you provide a screen recording?
Also, could you check whether it's iOS specific? Does it reproduce on Android emulator?

I have made a recording. It is for IOS and happens on my iphone simulators, also on my personal Iphone SE and 14 Pro phones.
https://youtu.be/EP_8W28uxPE
If I comment the call to GetData() it works ;)
I will do an Android test and let you know.
Thank you

I have played around with using a CollectionView to host the CarouselViews, and that works as expected on my IOS simulator. The above is still a strange issue.... But for the moment I can experiment with the CarouselView.


fix: update UI

bot port and enum issues

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

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cost change DAE

Hello! I have a question.
I'd like to change the costs for an individual player using DAE. Are there any flags or something else to implement this?

you can probably use a macro for that and activate it with dae.
I don't know what you want to do exactly, but for example this is a macro to decrease the item uses by 2:


[Bug]: Investigate differences in plots produced with zppy test using Xarray/xCDAT codebase

What happened?
Related to https://github.com/E3SM-Project/zppy/pull/651#issuecomment-2532741917
Image check failures
There's a large number of image check diffs in subdirectories of:

https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v3_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_comprehensive_v3
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v2_www/test-346-20241210/v2.LR.historical_0201/image_check_failures_comprehensive_v2/
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_bundles_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_bundles/

But as far as I can tell, the errors are mostly benign. Example errors:

Many involve actual having "RMSE" and "CORR" further to the left than in expected.
Slight differences in text shape/size -- e.g., actual and expected
Slight differences in contours like actual and expected
Differences in lat/lon labels -- actual and expected

Some errors seem more concerning:

Completely different stats and colors: actual and expected

What did you expect to happen? Are there are possible answers you came across?
No response
Minimal Complete Verifiable Example (MVCE)
No response
Relevant log output
No response
Anything else we need to know?
No response
Environment
Latest main with Xarray/xCDAT codebase

@forsyth2 and @tomvothecoder thank you for reporting this issue. Some results are definitely off. example https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v3_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_comprehensive_v3/e3sm_diags/atm_monthly_180x360_aave/model_vs_obs_1987-1988/lat_lon/ERA5/ERA5-TREFHT-ANN-global.png_actual.png and its corresponding box plot:

@chengzhuzhang @tomvothecoder If you want to test using zppy (rather than purely e3sm_diags), you can use the following workflow:
Workflow
# Set up branch
cd <zppy directory>
git status
# Check that there are no file changes that will persist when we switch branches.
git fetch origin main
# Check out local version of my branch
# You need to do this because zppy can't run post-CDAT E3SM Diags with its code as of `main`.
git checkout -b issue-346-diags-post-refactor origin/issue-346-diags-post-refactor

# Set up E3SM Diags environment
cd <e3sm_diags directory>
git status
# Check that there are no file changes that will persist when we switch branches.
git fetch upstream
git checkout main
git reset --hard upstream/main
conda clean --all --y
conda env create -f conda-env/dev.yml -n e3sm_diags_main_<date>
conda activate e3sm_diags_main_<date>
pip install .

# Set up zppy environment
cd <zppy directory>
conda clean --all --y
conda env create -f conda/dev.yml -n zppy_dev_pr651
conda activate zppy_dev_pr651
pip install .

If you want quick debugging method:
For a sample test cfg, you could modify the paths in tests/integration/generated/test_min_case_e3sm_diags_comprehensive_v3_chrysalis.cfg, available at https://github.com/E3SM-Project/zppy/pull/651/files
# Run zppy
zppy -c test.cfg

If you want to produce my test results:

 Full test reproduction steps
# Set up a zppy-interfaces environment too
# We need to do this because the full test suite is expecting we have all tasks operating.
cd <zppy-interfaces>
git status
# Check that there are no file changes that will persist when we switch branches.
git fetch upstream
git checkout main
git reset --hard upstream/main
conda clean --all --y
conda env create -f conda-env/dev.yml -n zi_main_<date>
conda activate zi_main_<date>
pip install .

# Modify tests/integration/utils.py:
# UNIQUE_ID = "my-test-id"
# For get_chyrsalis_expansions: (Switch out the paths so they point to your conda install location)
#        "diags_environment_commands": "source /gpfs/fs1/home/ac.forsyth2/miniforge3/etc/profile.d/conda.sh; conda activate e3sm_diags_main_<date>",
#        "global_time_series_environment_commands": "source /gpfs/fs1/home/ac.forsyth2/miniforge3/etc/profile.d/conda.sh; conda activate zi_main_<date>",

python tests/integration/utils.py
zppy -c tests/integration/generated/test_weekly_comprehensive_v3_chrysalis.cfg
zppy -c tests/integration/generated/test_weekly_comprehensive_v2_chrysalis.cfg
zppy -c tests/integration/generated/test_weekly_bundles_chrysalis.cfg # Runs 1st part of bundles cfg

# Once those all finish:
zppy -c tests/integration/generated/test_weekly_bundles_chrysalis.cfg # Runs 2nd part of bundles cfg

# Once that finishes:
# Check output, grep lines should print nothing
cd /lcrc/group/e3sm/${USER}/zppy_weekly_comprehensive_v3_output/my-test-id/v3.LR.historical_0051/post/scripts/
grep -v "OK" *status
cd /lcrc/group/e3sm/${USER}/zppy_weekly_comprehensive_v2_output/my-test-id/v2.LR.historical_0201/post/scripts
grep -v "OK" *status
cd /lcrc/group/e3sm/${USER}/zppy_weekly_bundles_output/my-test-id/v3.LR.historical_0051/post/scripts
grep -v "OK" *status

# Run integration tests
cd <zppy directory>
pytest tests/integration/test_*.py

Now look for the image_check_failures subdirectories on the web server:
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/<username>/zppy_<test_name>_www/my-test-id/v3.LR.historical_0051/

Those have actual, expected, and diff images.

thanks @forsyth2 !
It does look like cdscan is now successfully removed as a zppy dependency, with the updates in e3sm_diags new code base and zppy?

I manually went through the diffs and noted some outstanding issues we need to address:

Any sets with variable TREFHT, SST and TREFMNAV
2. GPCP v3.2 diff plot
MISRCOSP-CLDLOW_TAU1.3_9.4_MISR
Metrics diffs in zonal mean 2d plots.
I think we should be able to confirm these diffs with v3 complete run regression tests.

It does look like cdscan is now successfully removed as a zppy dependency, with the updates in e3sm_diags new code base and zppy?

Yes, https://github.com/E3SM-Project/zppy/pull/651 removes cdscan from zppy code. It was never actually a zppy dependency -- it was used in e3sm_diags.bash which runs in whatever environment that environment_commands is set to.
The only other issue with CDAT was with global-time-series, which was resolved in https://github.com/E3SM-Project/zppy/pull/519 + https://github.com/E3SM-Project/zppy/pull/611 (same situation -- the environment that global_time_series.bash is run in is actually what used it, not the zppy environment itself.)
In summary, the zppy environment never used CDAT/cdscan, but there were two instances where it was used in templated code run in other environments. Once https://github.com/E3SM-Project/zppy/pull/651 merges, not even these will remain.

@tomvothecoder I can reproduce first issue (TREFHT) with a dev environment created from main . However, when debugging in a new PR (#907) in vscode. I ran into a problem regarding ESMF:
chengzhu@login12:~/e3sm_diags>  cd /global/homes/c/chengzhu/e3sm_diags ; /usr/bin/env /global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/bin/python /global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher 54913 -- /global/homes/c/chengzhu/e3sm_diags/auxiliary_tools/cdat_regression_testing/906-v3_complete_run/12_11_24_lat-lon_diffs.py
Traceback (most recent call last):
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/runpy.py", line 198, in _run_module_as_main
    return _run_code(code, main_globals, None,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/runpy.py", line 88, in _run_code
    exec(code, run_globals)
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py", line 71, in <module>
    cli.main()
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py", line 501, in main
    run()
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py", line 351, in run_file
    runpy.run_path(target, run_name="__main__")
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 310, in run_path
    return _run_module_code(code, init_globals, run_name, pkg_name=pkg_name, script_name=fname)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 127, in _run_module_code
    _run_code(code, mod_globals, init_globals, mod_name, mod_spec, pkg_name, script_name)
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 118, in _run_code
    exec(code, run_globals)
  File "/global/homes/c/chengzhu/e3sm_diags/auxiliary_tools/cdat_regression_testing/906-v3_complete_run/12_11_24_lat-lon_diffs.py", line 9, in <module>
    from e3sm_diags.parameter.core_parameter import CoreParameter
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/parameter/__init__.py", line 1, in <module>
    from .annual_cycle_zonal_mean_parameter import ACzonalmeanParameter
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/parameter/annual_cycle_zonal_mean_parameter.py", line 1, in <module>
    from .core_parameter import CoreParameter
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/parameter/core_parameter.py", line 11, in <module>
    from e3sm_diags.driver.utils.climo_xr import ClimoFreq
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/driver/utils/climo_xr.py", line 11, in <module>
    import xcdat as xc
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/__init__.py", line 11, in <module>
    from xcdat.regridder.accessor import RegridderAccessor  # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/regridder/__init__.py", line 1, in <module>
    from xcdat.regridder.accessor import RegridderAccessor  # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/regridder/accessor.py", line 8, in <module>
    from xcdat.regridder import regrid2, xesmf, xgcm
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/regridder/xesmf.py", line 4, in <module>
    import xesmf as xe
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xesmf/__init__.py", line 3, in <module>
    from . import data, util
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xesmf/util.py", line 8, in <module>
    import esmpy as ESMF
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/__init__.py", line 108, in <module>
    from esmpy.api.esmpymanager import *
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/api/esmpymanager.py", line 9, in <module>
    from esmpy.interface.cbindings import *
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/interface/cbindings.py", line 13, in <module>
    from esmpy.interface.loadESMF import _ESMF
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/interface/loadESMF.py", line 89, in <module>
    raise VersionMismatch("ESMF installation version {}, ESMPy version {}".format(
esmpy.util.exceptions.VersionMismatch: ESMF installation version 8.4.2, ESMPy version 8.7.0

I'm wondering have you encountered similar problems before?

I manually went through the diffs and noted some outstanding issues we need to address:
1. Any sets with variable TREFHT, [SST](https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v3_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_comprehensive_v3/e3sm_diags/atm_monthly_180x360_aave/model_vs_obs_1987-1988/lat_lon/SST_CL_HadISST/HadISST_CL-SST-ANN-global.png_diff.png) and [TREFMNAV](https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v3_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_comprehensive_v3/e3sm_diags/atm_monthly_180x360_aave/model_vs_obs_1987-1988/lat_lon/MERRA2/MERRA2-TREFMNAV-ANN-global.png_diff.png)
   2.[ GPCP v3.2 diff plot](https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v3_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_comprehensive_v3/e3sm_diags/atm_monthly_180x360_aave/model_vs_obs_1987-1988/lat_lon/GPCP_v3.2/GPCP_v3.2-PRECT-ANN-global.png_diff.png)

2. [MISRCOSP-CLDLOW_TAU1.3_9.4_MISR](https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.forsyth2/zppy_weekly_comprehensive_v3_www/test-346-20241210/v3.LR.historical_0051/image_check_failures_comprehensive_v3/e3sm_diags/atm_monthly_180x360_aave/model_vs_obs_1987-1988/lat_lon/Cloud%20MISR/MISRCOSP-CLDLOW_TAU1.3_9.4_MISR-ANN-global.png_diff.png)

3. Metrics diffs in zonal mean 2d plots.
   I think we should be able to confirm these diffs with v3 complete run regression tests.

Here is my comment in PR #903 with the regression testing notebook.
The variables that you pointed out here with issues are also appearing in the list of mismatching variables.

@tomvothecoder I can reproduce first issue (TREFHT) with a dev environment created from main . However, when debugging in a new PR (#907) in vscode. I ran into a problem regarding ESMF:
chengzhu@login12:~/e3sm_diags>  cd /global/homes/c/chengzhu/e3sm_diags ; /usr/bin/env /global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/bin/python /global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher 54913 -- /global/homes/c/chengzhu/e3sm_diags/auxiliary_tools/cdat_regression_testing/906-v3_complete_run/12_11_24_lat-lon_diffs.py
Traceback (most recent call last):
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/runpy.py", line 198, in _run_module_as_main
    return _run_code(code, main_globals, None,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/runpy.py", line 88, in _run_code
    exec(code, run_globals)
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py", line 71, in <module>
    cli.main()
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py", line 501, in main
    run()
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py", line 351, in run_file
    runpy.run_path(target, run_name="__main__")
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 310, in run_path
    return _run_module_code(code, init_globals, run_name, pkg_name=pkg_name, script_name=fname)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 127, in _run_module_code
    _run_code(code, mod_globals, init_globals, mod_name, mod_spec, pkg_name, script_name)
  File "/global/u2/c/chengzhu/.vscode-server/extensions/ms-python.debugpy-2024.12.0/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 118, in _run_code
    exec(code, run_globals)
  File "/global/homes/c/chengzhu/e3sm_diags/auxiliary_tools/cdat_regression_testing/906-v3_complete_run/12_11_24_lat-lon_diffs.py", line 9, in <module>
    from e3sm_diags.parameter.core_parameter import CoreParameter
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/parameter/__init__.py", line 1, in <module>
    from .annual_cycle_zonal_mean_parameter import ACzonalmeanParameter
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/parameter/annual_cycle_zonal_mean_parameter.py", line 1, in <module>
    from .core_parameter import CoreParameter
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/parameter/core_parameter.py", line 11, in <module>
    from e3sm_diags.driver.utils.climo_xr import ClimoFreq
  File "/global/homes/c/chengzhu/e3sm_diags/e3sm_diags/driver/utils/climo_xr.py", line 11, in <module>
    import xcdat as xc
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/__init__.py", line 11, in <module>
    from xcdat.regridder.accessor import RegridderAccessor  # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/regridder/__init__.py", line 1, in <module>
    from xcdat.regridder.accessor import RegridderAccessor  # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/regridder/accessor.py", line 8, in <module>
    from xcdat.regridder import regrid2, xesmf, xgcm
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xcdat/regridder/xesmf.py", line 4, in <module>
    import xesmf as xe
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xesmf/__init__.py", line 3, in <module>
    from . import data, util
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/xesmf/util.py", line 8, in <module>
    import esmpy as ESMF
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/__init__.py", line 108, in <module>
    from esmpy.api.esmpymanager import *
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/api/esmpymanager.py", line 9, in <module>
    from esmpy.interface.cbindings import *
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/interface/cbindings.py", line 13, in <module>
    from esmpy.interface.loadESMF import _ESMF
  File "/global/cfs/cdirs/e3sm/zhang40/conda_envs/edv3/lib/python3.12/site-packages/esmpy/interface/loadESMF.py", line 89, in <module>
    raise VersionMismatch("ESMF installation version {}, ESMPy version {}".format(
esmpy.util.exceptions.VersionMismatch: ESMF installation version 8.4.2, ESMPy version 8.7.0

I'm wondering have you encountered similar problems before?

Hey @chengzhuzhang, I think I ran into this with e3sm_diags before and I recreated the dev env to get around it.
I just created the dev environment and was able to import xcdat without issue. All of the correct dependency versions are installed.
$ mamba env create -f conda-env/dev.yml -n e3sm_diags_dev_894_2
$ mamba activate e3sm_diags_dev_894_2

(e3sm_diags_dev_894_2) vo13@login17:.../E3SM-Project/e3sm_diags$ python
Python 3.12.8 | packaged by conda-forge | (main, Dec  5 2024, 14:24:40) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xcdat
>>>
KeyboardInterrupt
>>>
[1]+  Stopped                 python
(e3sm_diags_dev_894_2) vo13@login17:.../E3SM-Project/e3sm_diags$ conda list
# packages in environment at /global/homes/v/vo13/mambaforge/envs/e3sm_diags_dev_894_2:
#
# Name                    Version                   Build  Channel
...
esmf                      8.7.0           nompi_h6063b07_1    conda-forge
esmpy                     8.7.0              pyhecae5ae_0    conda-forge
...
xarray                    2024.11.0          pyhd8ed1ab_0    conda-forge
xcdat                     0.7.3              pyhd8ed1ab_1    conda-forge
xesmf                     0.8.8              pyhd8ed1ab_1    conda-forge