[Bug]: ISR and next/link Prefetch Cause RSC Page Return Content in self.__next_f.push Function With App Dir on Next.js 14.0.3

Summary
When ISR is enabled and a next/link component with href of the current page (e.g. homepage) URL exists, ISR will be run twice when refreshing the page. The ISR log shows two ISR records of the page at about the same time. I guess it's because ISR will be triggered by the prefetch of the next/link component and the page load.
This sometimes/frequently causes the page content returned to be the code in self.__next_f.push functions in the script tag at the end of the body tag, rather than the actual page content.
Whenever the issue happens, I notice the ISR log shows the ISR record just once.

A link to a reproduction repository
https://github.com/AresTG2612/test
Expected Result
Whenever refreshing the page with ISR and next/link component, it returns the page content stably.
Actual Result
Refreshing the page, sometimes it returns the code in self.__next_f.push functions in the script tag at the end of the body tag.
Steps to reproduce

Install a fresh new copy of next.js with npx create-next-app@latest with app dir.
Add a next/link component with href of homepage on app/page.tsx, e.g. <Link href={'/'}>Test.
Add export const revalidate = 1; in app/layout.tsx to enable ISR.
Deploy to Netlify.
Try refresh the homepage every minute.

Next Runtime version
4.41.2
Is your issue related to the app directory?

[X] Yes, I am using the app directory

More information about your build

[ ] I am building using the CLI
[ ] I am building using file-based configuration (netlify.toml)

What OS are you using?
None
Your netlify.toml file
No response
Your public/_redirects file
No response
Your next.config.js file
No response
Builds logs (or link to your logs)

Build logs
11:30:15 AM: build-image version: 3ffff9df3d5419545acc1b673a54de348174406d (focal)
11:30:15 AM: buildbot version: 234adcfe967f1d318bfad465ff22f561d657197d
11:30:15 AM: Fetching cached dependencies
11:30:15 AM: Starting to download cache of 216.4MB
11:30:18 AM: Finished downloading cache in 2.61s
11:30:18 AM: Starting to extract cache
11:30:20 AM: Finished extracting cache in 1.886s
11:30:20 AM: Finished fetching cache in 4.556s
11:30:20 AM: Starting to prepare the repo for build
11:30:20 AM: Preparing Git Reference refs/heads/main
11:30:22 AM: Starting to install dependencies
11:30:22 AM: Python version set to 3.8
11:30:22 AM: Attempting Ruby version 2.7.2, read from environment
11:30:22 AM: Using Ruby version 2.7.2
11:30:23 AM: Started restoring cached go cache
11:30:23 AM: Finished restoring cached go cache
11:30:24 AM: go version go1.19.13 linux/amd64
11:30:25 AM: Using PHP version 8.0
11:30:26 AM: Started restoring cached Node.js version
11:30:27 AM: Finished restoring cached Node.js version
11:30:27 AM: v18.19.0 is already installed.
11:30:27 AM: Now using node v18.19.0 (npm v10.2.3)
11:30:27 AM: Enabling Node.js Corepack
11:30:27 AM: Started restoring cached build plugins
11:30:27 AM: Finished restoring cached build plugins
11:30:27 AM: Started restoring cached corepack dependencies
11:30:27 AM: Finished restoring cached corepack dependencies
11:30:27 AM: No pnpm workspaces detected
11:30:27 AM: Started restoring cached node modules
11:30:27 AM: Finished restoring cached node modules
11:30:28 AM: Installing npm packages using pnpm version 8.7.6
11:30:29 AM: Lockfile is up to date, resolution step is skipped
11:30:29 AM: Already up to date
11:30:29 AM: Done in 622ms
11:30:29 AM: npm packages installed using pnpm
11:30:30 AM: Successfully installed dependencies
11:30:30 AM: Starting build script
11:30:30 AM: Detected 1 framework(s)
11:30:30 AM: "next" at version "14.0.3"
11:30:30 AM: Section completed: initializing
11:30:32 AM:
11:30:32 AM: Netlify Build
11:30:32 AM: ────────────────────────────────────────────────────────────────
11:30:32 AM:
11:30:32 AM: ❯ Version
11:30:32 AM:   @netlify/build 29.29.4
11:30:32 AM:
11:30:32 AM: ❯ Flags
11:30:32 AM:   baseRelDir: true
11:30:32 AM:   buildId: 656d1d960f64400008c2abfe
11:30:32 AM:   deployId: 656d1d960f64400008c2ac00
11:30:32 AM:
11:30:32 AM: ❯ Current directory
11:30:32 AM:   /opt/build/repo
11:30:32 AM:
11:30:32 AM: ❯ Config file
11:30:32 AM:   No config file was defined: using default values.
11:30:32 AM:
11:30:32 AM: ❯ Context
11:30:32 AM:   production
11:30:32 AM:
11:30:32 AM: ❯ Using Next.js Runtime - v4.41.2
11:30:33 AM:
11:30:33 AM: @netlify/plugin-nextjs (onPreBuild event)
11:30:33 AM: ────────────────────────────────────────────────────────────────
11:30:33 AM:
11:30:33 AM: Next.js cache restored.
11:30:33 AM: Netlify configuration property "build.environment.NEXT_PRIVATE_TARGET" value changed.
11:30:34 AM:
11:30:34 AM: (@netlify/plugin-nextjs onPreBuild completed in 90ms)
11:30:34 AM:
11:30:34 AM: Build command from Netlify app
11:30:34 AM: ────────────────────────────────────────────────────────────────
11:30:34 AM:
11:30:34 AM: $ pnpm run build
11:30:34 AM: ><EMAIL_ADDRESS>build /opt/build/repo
11:30:34 AM: > next build
11:30:34 AM:    ▲ Next.js 14.0.3
11:30:34 AM:    Creating an optimized production build ...
11:30:37 AM:  ✓ Compiled successfully
11:30:37 AM:    Linting and checking validity of types ...
11:30:39 AM:    Collecting page data ...
11:30:40 AM:    Generating static pages (0/5) ...
11:30:40 AM:    Generating static pages (1/5)
11:30:40 AM:    Generating static pages (2/5)
11:30:40 AM:    Generating static pages (3/5)
11:30:41 AM:  ✓ Generating static pages (5/5)
11:30:41 AM:    Finalizing page optimization ...
11:30:41 AM:    Collecting build traces ...
11:30:46 AM: Route (app)                              Size     First Load JS
11:30:46 AM: ┌ ○ /                                    11.3 kB        95.2 kB
11:30:46 AM: └ ○ /_not-found                          872 B          84.8 kB
11:30:46 AM: + First Load JS shared by all            83.9 kB
11:30:46 AM:   ├ chunks/569-6961324a6798b7a2.js       28.8 kB
11:30:46 AM:   ├ chunks/c141e8ea-9e027de7199c3c94.js  53.3 kB
11:30:46 AM:   ├ chunks/main-app-88cfcfb950789b9a.js  219 B
11:30:46 AM:   └ chunks/webpack-031ca56bc5e2f967.js   1.65 kB
11:30:46 AM: ○  (Static)  prerendered as static content
11:30:46 AM:
11:30:46 AM: (build.command completed in 12.5s)
11:30:46 AM:
11:30:46 AM: @netlify/plugin-nextjs (onBuild event)
11:30:46 AM: ────────────────────────────────────────────────────────────────
11:30:46 AM:
11:30:46 AM: Moving static page files to serve from CDN...
11:30:46 AM: Moved 4 files to CDN
11:30:46 AM: The following routes use "revalidate" values of under 60 seconds, which is not supported.
11:30:46 AM: They will use a revalidate time of 60 seconds instead.
11:30:46 AM: ┌─────────┬───────┬────────────┐
11:30:46 AM: │ (index) │ Route │ Revalidate │
11:30:46 AM: ├─────────┼───────┼────────────┤
11:30:46 AM: │    0    │  "/"  │     1      │
11:30:46 AM: └─────────┴───────┴────────────┘
11:30:46 AM: You are not using Netlify Edge Functions for image format detection. Set env var "NEXT_FORCE_EDGE_IMAGES=true" to enable.
11:30:46 AM: Netlify configuration property "redirects" value changed to [
11:30:46 AM:   { from: "/next/static/", to: "/static/:splat", status: 200 },
11:30:46 AM:   {
11:30:46 AM:     from: "/_next/image",
11:30:46 AM:     query: { url: ":url", w: ":width", q: ":quality" },
11:30:46 AM:     to: "/ipx/w:width,q:quality/:url",
11:30:46 AM:     status: 301
11:30:46 AM:   },
11:30:46 AM:   { from: "/_ipx/", to: "/.netlify/builders/_ipx", status: 200 },
11:30:46 AM:   {
11:30:46 AM:     from: "/api/",
11:30:46 AM:     to: "/.netlify/functions/___netlify-handler",
11:30:46 AM:     status: 200
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/next.svg",
11:30:46 AM:     to: "/next.svg",
11:30:46 AM:     conditions: { Cookie: [Array] },
11:30:46 AM:     status: 200
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/vercel.svg",
11:30:46 AM:     to: "/vercel.svg",
11:30:46 AM:     conditions: { Cookie: [Array] },
11:30:46 AM:     status: 200
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/",
11:30:46 AM:     to: "/.netlify/functions/___netlify-handler",
11:30:46 AM:     status: 200,
11:30:46 AM:     conditions: { Cookie: [Array] },
11:30:46 AM:     force: true
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/index.rsc",
11:30:46 AM:     to: "/.netlify/builders/___netlify-odb-handler",
11:30:46 AM:     status: 200,
11:30:46 AM:     force: true
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/",
11:30:46 AM:     to: "/.netlify/builders/___netlify-odb-handler",
11:30:46 AM:     status: 200,
11:30:46 AM:     force: true
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/_next/data/_fuzAKWjN3of8LPdDJcwC/_not-found.json",
11:30:46 AM:     to: "/.netlify/functions/___netlify-handler",
11:30:46 AM:     status: 200,
11:30:46 AM:     force: false
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/_not-found",
11:30:46 AM:     to: "/.netlify/functions/___netlify-handler",
11:30:46 AM:     status: 200,
11:30:46 AM:     force: false
11:30:46 AM:   },
11:30:46 AM:   {
11:30:46 AM:     from: "/",
11:30:46 AM:     to: "/.netlify/functions/___netlify-handler",
11:30:46 AM:     status: 200
11:30:46 AM:   }
11:30:46 AM: ].
11:30:46 AM:
11:30:46 AM: (@netlify/plugin-nextjs onBuild completed in 126ms)
11:30:46 AM:
11:30:46 AM: Functions bundling
11:30:46 AM: ────────────────────────────────────────────────────────────────
11:30:46 AM:
11:30:46 AM: Packaging Functions from .netlify/functions-internal directory:
11:30:46 AM:  - ___netlify-handler/___netlify-handler.js
11:30:46 AM:  - ___netlify-odb-handler/___netlify-odb-handler.js
11:30:46 AM:  - _ipx/_ipx.js
11:30:46 AM:
11:31:20 AM:
11:31:20 AM: (Functions bundling completed in 33.7s)
11:31:20 AM:
11:31:20 AM: Edge Functions bundling
11:31:20 AM: ────────────────────────────────────────────────────────────────
11:31:20 AM:
11:31:20 AM: Packaging Edge Functions from .netlify/edge-functions directory:
11:31:20 AM:  - rsc-data
11:31:20 AM:
11:31:20 AM: (Edge Functions bundling completed in 370ms)
11:31:20 AM:
11:31:20 AM: @netlify/plugin-nextjs (onPostBuild event)
11:31:20 AM: ────────────────────────────────────────────────────────────────
11:31:20 AM:
11:31:20 AM: Next.js cache saved.
11:31:20 AM:
11:31:20 AM: (@netlify/plugin-nextjs onPostBuild completed in 92ms)
11:31:20 AM:
11:31:20 AM: Deploy site
11:31:20 AM: ────────────────────────────────────────────────────────────────
11:31:20 AM:
11:31:20 AM: Starting to deploy site from ".next"
11:31:20 AM: Calculating files to upload
11:31:21 AM: 6 new files to upload
11:31:21 AM: 2 new functions to upload
11:31:28 AM: Skipping form detection
11:31:28 AM: Post processing - header rules
11:31:28 AM: Post processing - redirect rules
11:31:28 AM: Starting post processing
11:31:28 AM: Post processing done
11:31:28 AM: Section completed: postprocessing
11:31:28 AM: Section completed: deploying
11:31:28 AM: Site deploy was successfully initiated
11:31:28 AM:
11:31:28 AM: (Deploy site completed in 7.5s)
11:31:28 AM:
11:31:28 AM: Netlify Build Complete
11:31:28 AM: ────────────────────────────────────────────────────────────────
11:31:28 AM:
11:31:28 AM: (Netlify Build completed in 55.9s)
11:31:29 AM: Site is live ✨
11:31:29 AM: Caching artifacts
11:31:29 AM: Started saving node modules
11:31:29 AM: Finished saving node modules
11:31:29 AM: Started saving build plugins
11:31:29 AM: Finished saving build plugins
11:31:29 AM: Started saving corepack cache
11:31:29 AM: Finished saving corepack cache
11:31:29 AM: Started saving pip cache
11:31:29 AM: Finished saving pip cache
11:31:29 AM: Started saving emacs cask dependencies
11:31:29 AM: Finished saving emacs cask dependencies
11:31:29 AM: Started saving maven dependencies
11:31:29 AM: Finished saving maven dependencies
11:31:29 AM: Started saving boot dependencies
11:31:29 AM: Finished saving boot dependencies
11:31:29 AM: Started saving rust rustup cache
11:31:29 AM: Finished saving rust rustup cache
11:31:29 AM: Started saving go dependencies
11:31:29 AM: Finished saving go dependencies
11:31:29 AM: Build script success
11:31:29 AM: Section completed: building
11:31:30 AM: Uploading Cache of size 216.4MB
11:31:32 AM: Section completed: cleanup
11:31:32 AM: Finished processing build request in 1m16.564s

Function logs

ISR Function logs
Dec 4, 11:32:35 AM: fa5f950b INFO   [GET] / (ODB TTL=60)
Dec 4, 11:32:35 AM: fa5f950b Duration: 173.76 ms	Memory Usage: 97 MB
Dec 4, 11:33:40 AM: 81a63f74 INFO   [GET] / (ODB TTL=60)
Dec 4, 11:33:40 AM: 81a63f74 Duration: 99.08 ms	Memory Usage: 97 MB
Dec 4, 11:33:41 AM: a8e9b947 INFO   [GET] / (ODB TTL=60)
Dec 4, 11:33:41 AM: a8e9b947 Duration: 43.42 ms	Memory Usage: 97 MB
Dec 4, 11:34:44 AM: 6053f657 INFO   [GET] / (ODB TTL=60)
Dec 4, 11:34:44 AM: 6053f657 Duration: 103.31 ms	Memory Usage: 97 MB

.next JSON files
No response

To add more details, I’ve tested this on Next.js 13.5 versions and the latest 13.4 versions, and the problem is still there.

I've upgraded Next.js to 14.0.4 to test and it's not working either.

I've tested with Next.js 14.1.0 and the issue still exists.

I've tested this with the latest Next.js 14.1.0 and it seems the issue is fixed with this version. I will keep testing and monitoring.


Document gulp.tree API

We have a new method exposed (gulp.tree()) that allows users or outside tools to get the registered tasks.  We need to document this in API.md

I think you want this in two parts:

For the cli (in gulp-cli repo)
The api tree for other people to get

For part 1:
Do you want this in the gulp-cli repo or in the gulp repo?
It looks like there is a line or two in there. Is this sufficient? It could certainly be beefed up with pictures and examples if you think its worth the time. Disclosure: I'd like to get gulp 4 released as soon as possible.

References:

https://github.com/gulpjs/gulp-cli/blob/4.0/lib/versioned/^4.0.0-alpha.1/index.js#L28
https://github.com/gulpjs/gulp-cli/blob/4.0/docs/CLI.md
https://github.com/gulpjs/gulp/blob/4.0/docs/CLI.md

For part 2:
I'm planning adding a blurb in API.md. Showing an example with deep and an example without- then referencing to the undertaker
If that sounds good, I'll submit a pull request soon.
References:

https://github.com/phated/undertaker#treeoptions--object
https://github.com/gulpjs/gulp/blob/4.0/docs/API.md

Thanks for tackling this issue. All docs can be PRed here, as we are also building out the gulp website with all the docs (cli, gulp, etc). All of your outline sounds good.

@phated I think we let the docs finalize here then prior to 4.0 release we can auto-import them into the new website

@contra I agree.  Hence the issues

PR, linked and ready for review. Thanks!

@SyntaxRules thanks, merged.


Fix setup.py to work with buildbot.

This is also a test to ensure the status reporter is working...

Done.  The buildbot code for this was implemented over in https://github.com/opalmer/build.opalmer.com.  This closes #1 too.


Offline vector DB support

Please add support for offline vector DBs (e.g. Qdrant).

Hi @nicholaskoerfer, I understand the need for local vector DB support as the original BabyAGI has switched from Pinecone to Chroma/Weaviate.
However, in the case of BabyAGI-UI, we've added mod versions (BabyDeerAGI, BabyElfAGI) in addition to the original BabyAGI, and these mods no longer require a vector DB.
Do you often use the original (BabyAGI) rather than the mod version?


DeviantArt downloader downloads just the previews, not the actual files.

Found this extension from Chrome-Strats, but it's not updated since it's deletion last year, so it may not work properly.
https://www.4shared.com/folder/IhZnDOdu/DeviantArt_Downloader_OUTDATED.html

Please help your program limited download only 10 000 photo please help how to up limit to the 40 000


Incorrect parsing of an address with both user and header parameters

Parsing the address:
"Bob" <sips:bob:password@<IP_ADDRESS>:5060;user=phone>;tag=1234"
places
user=phone>;tag=1234
in the header tags.
This causes issues when responding to an INVITE, which expects the same From header back.
Pull request #67 has been submitted

Hi @InnovativeUS thanx for reporting. Will check it out. This could be broken due to some refactoring.

Thanks for contributing!

also now refactored to have less this control vars
@InnovativeUS


[Feature Request] updateOrCreate

I guess it'll look like this:
  updateOrCreate: function (criteria, data, cb) {
    var that = this;
    var resolver = Promise.pending();
    cb = cb || function () {};

    that.findOne(criteria).then(function (model) {
      if (model) {
        // Model exists. Update.
        model = _.deepExtend(model, data);
        model.save(function () {
          resolver.resolve(model);
          cb(null, model);
        });
      } else {
        // Model does not exist. Create.
        that.create(data).done(function () {
          resolver.resolve(model);
          cb(null, model);
        });
      }
    })
    .catch(function (err) {
      resolver.reject(err);
      cb(err);
    });

    return resolver.promise;
  }

Hi @ksaitor, would you mind submitting a PR? Some useful links below:

findOrCreate code: https://github.com/balderdashy/waterline/blob/master/lib/waterline/query/composite.js#L24
findOrCreate test: https://github.com/balderdashy/waterline/blob/master/test/unit/query/query.findOrCreate.js

PR #940 adds this, relevant comment: https://github.com/balderdashy/waterline/pull/940#issuecomment-93937764.

This should be reopened, mysql (INSERT ON DUPLICATE) and postgresql (UPSERT) with fallbacks should be implemented

Anything happening with this?
BTW: dmarcelino link is broken, new link -https://github.com/balderdashy/waterline/blob/master/lib/waterline/methods/find-or-create.js


A replacement for #473

A replacement for https://github.com/intridea/hashie/pull/473. The only users affected by this change would be those that have rolled a custom parser, vs. #473 that affects everyone who calls Mash#load.

Preserves backwards compatibility and doesn't change the behavior of Mash#load.
Allows passing options through, so one can Mash.load(file, whitelist_classes: [Symbol]) which was the desired effect of #473, and can specify other options such as aliases.
Documents the feature and the interface change for custom parsers.

@michaelherold Care to CR/squash/merge? Thanks.


[Bug] the behavior of moving items using hotkey are not consistent

for prompt list,  if you use hotkey to move the items up, when the selected item comes to the first or the last, if you continue to hit the key to move onwards, it stops to move, I think this is more natural.
but the for UI of changing chat session, when it comes to the first chat session, if you hit the key to continue, it goes to the last item. while it's in the last item, if you want to continue to move, it goes to the very beginning.
I think the behavior should be consistent as in the Prompt List.
I am going to create a PR to this issue.

This is by design, prompt list is different from chat list, prompt list shows dynamic options, and chat list is always considered to be static.


'ResNetCustom' object has no attribute '_norm_layer'

Thank you for your excellent job about the dropblock. However, there are some errors when I run the code.  It occured in the 34 line of resnet-cifar10.py,    self.layer1 = self._make_layer(block, 64, layers[0]). I am puzzled about it.

It could be a pytorch version incompatibility. Which version are you using?

It could be a pytorch version incompatibility. Which version are you using?

same here. Which version did you use on this example?


Make container mandatory for widget factory

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
✔

Fixed issues
-

👍


await is a reserved word

Version
Tell us which versions you are using:

react-native-router-flux 4.0.0-beta.24
react-native v0.50.3

Expected behaviour
It should load?
Actual behaviour

Steps to reproduce
For non-obvious bugs, please fork this component, modify Example project to reproduce your issue and include link here.
Upgraded from v3, and immediately hit this error on initial load...

No details. It is not related to RNRF


[High Urgency] Update Research and products

We want to update this part: https://universetbd.org/products and the research part

Pathfinder: https://pfrd.app
the description: Pathfinder is an AI tool designed to enable literature review and knowledge discovery in astronomy, utilising state-of-the-art large language models and a corpus of 350,000 peer-reviewed papers from the Astrophysics Data System. It focuses on semantic searching with natural language instead of syntactic searches with keywords, offering an innovative approach to scientific enquiry and literature exploration in the face of exponentially growing astronomical literature.

AstroPT is an autoregressive pretrained transformer developed for astronomical use-cases, trained on 8.6 million galaxy postage stamp observations from the DESI Legacy Survey DR8. The project aims to create an open-source "Large Observation Model" for observational sciences, with models ranging from 1 million to 2.1 billion parameters showing improved performance on downstream tasks as model size increases. @Smith42 can you check, also can you provide a logo :d?

we can keep the steering of charlie there

we can also keep Hypothesis Generation there

For the Research we need to put astrollama-chat and astropt papers

Maybe this blurb for astroPT?
AstroPT is an autoregressive pretrained transformer developed for astronomical use-cases. V1.0 has been trained on 8.6 million galaxy postage stamp observations from the DESI Legacy Survey DR8 with models ranging from 1 million to 2.1 billion parameters. Just like for LLMs, we see improved performance on downstream tasks as model size increases. The project's north star is integrating many astronomical modalities from imagery to stellar time series to spectra to hyperspectral cubes, with the end goal of creating an open-source "Large Observation Model" for observational sciences.
There's a mascot here: https://github.com/Smith42/astroPT/blob/main/assets/emoji.png

AstroPT paper is here https://arxiv.org/abs/2405.14930v1

I've added the astrollama-chat and astropt papers to the Research page, and astropt to the products page, but I think the summary needs to be much shorter for the products page - one sentence. I propose something like:
"AstroPT is an autoregressive pretrained transformer developed for astronomical use-cases, and V1.0 has been trained on 8.6 million galaxy postage stamp observations from the DESI Legacy Survey DR8."

Hmm maybe this as a one sentencer?
AstroPT is an AI model designed for astronomical applications, trained on millions of galaxy images, with plans to incorporate diverse astronomical data types to create a comprehensive "Large Observation Model" for astronomy.

I'll merge what has been fixed so far, but I haven't done anything about https://pfdr.app
If someone can provide a square logo and a one-sentencer, then I'll add it to the products page.

For Pathfinder [a temp one while Kartheik makes the final version, but in time for the release]:

The blurb: Pathfinder is an AI framework designed for astronomical literature review and knowledge discovery, using more than 300,000 peer-reviewed papers from the Astrophysics Data System. It incorporates advanced retrieval techniques and large language models to enable semantic searching of astronomy literature.
@kartheikiyer , hope this all good!

For the Highlights, we probs want to keep Pathfinder, AstroPT and Hypothesis Gen in order of release :-)

@Smith42 you also made some really nice squares, maybe we can choose between all of these and let jesse decide haha?

entry from Michele too

think the owl one is the winner :D

Yeah I quite like the owl one

I think it's back, so we can merge <3. Thanks Jesse!


Project still maintained?

I got to this project following the Google documentation about Binary Authorization:
https://cloud.google.com/binary-authorization/docs/creating-attestations-voucher
They mention two options for security vulnerability attestations, Kritis and Voucher.
I noticed that Kritis might not be maintained anymore (https://github.com/grafeas/kritis/issues/632)
Is Voucher is still maintained?
The README of this project mentions: "Binary authorization uses an admission controller such as Kritis",  does Voucher use Kritis?, or are these totally separate?

Per https://github.com/shopify/voucher being archived, Shopify is no longer using voucher or involved in this repository.
Most, but not all, contributors have been from Shopify: https://github.com/grafeas/voucher/graphs/contributors
We defer a decision about official deprecation to our partners in Google Cloud (e.g. @ooq, _rhdesmond et al).
Shopify replaced Voucher with a system that wraps https://github.com/kyverno/kyverno/ policies to produce binary authorization attestations. We like how other admission controllers provide a general "policy" abstraction for us, so we shifted to wrapping an admission controller to produce our binauthz attestations.
We like how this prevents coupling to GKE - we could run the same policies using Kyverno directly as an admission controller.
Our new system is not open source, sorry.


managed K8s with Pluscloud open?

This is done, right?

@lfrancke Is this still a thing?

Not right now, no


Virtual machines or virtual machine scale sets are running on images that will be deprecated soon on Azure

@karianna Is there any information on this - is it being actively worked on by your team and/or likely to cause us a problem?

@johnoliver and @gdams will need to look at this.


Link against the C++ standard library when C++ interop is enabled

This doesn't yet allow including C++ headers on platforms where libc++ isn't the default; see comments in UnixToolChains.cpp for details.
However, it does, for example, allow throwing and catching exceptions in C++ code used through interop, unblocking https://github.com/apple/swift/pull/30674.
Part of SR-12469

@compnerd I'd like your opinion on this in particular as you switched from clang++ (even without C++ interop enabled) to clang in https://github.com/apple/swift/pull/26110.
I think this addresses all of the issues you raise in the code comments. I've rewritten the comment to reflect what the reality is now, but let me know if you think there's more I should add.

@swift-ci Please smoke test

I've added a commit that adds experimental driver flags for C++ interop. I think this addresses some of the issues raised -- I'll respond to specific comments in a moment.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 46274318c3d3d273070be4d8b313216f0ab9afc7

Build failed
Swift Test Linux Platform
Git Sha - 46274318c3d3d273070be4d8b313216f0ab9afc7

@compnerd Your rewiew state is showing as "Changes requested", but I can't get github to show me those changes. Maybe those requested changes were for an outdated part of the PR?
Anything else that should be changed before this PR is ready to be merged?

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 332506f257fa3678b7fefa0464618e152cf33a01

Build failed
Swift Test OS X Platform
Git Sha - 332506f257fa3678b7fefa0464618e152cf33a01

@swift-ci Please test Windows

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test Windows

@swift-ci Please test

@swift-ci Please test Windows

@swift-ci Please test macOS

@swift-ci Please test Windows

@swift-ci Please test

Please add a test case to ensure that msvcprt demonstrating can be used by default on Windows.

I've filed SR-13164 for this:

Build failed
Swift Test OS X Platform
Git Sha - 541b2efded7f7307cf5f1c4e56ec577da15c1e1d

@swift-ci Please test OS X Platform

Build failed
Swift Test OS X Platform
Git Sha - 541b2efded7f7307cf5f1c4e56ec577da15c1e1d

@swift-ci Please test OS X Platform

Build failed
Swift Test OS X Platform
Git Sha - 541b2efded7f7307cf5f1c4e56ec577da15c1e1d

@swift-ci Please test

@swift-ci Please test


HDFS left with a single name node after rebooting a worker node

mantl 1.1.0 on AWS. cluster with 10 workers.
I deployed HDFS via mantl-api.
After deploying HDFS I had 2 namenodes (namenode1 and namenode2)
After rebooting the mavhine running namenode1, namenode1 doesn't come up again and HDFS is left with namenode2 only, which makes HDFS not highly available.
Ansible version 1.9.4
Python version 2.7.11
Git commit hash or branch: mantl 1.1.0
Cloud Environment: AWS
Terraform Terraform v0.6.16

Hey, @aitzkowi, thanks for reporting this. We have issues with reboot stability in general. Could you tell me how to reproduce this bug? Thanks

Hi @sehqlr
reproduce as follows:
mantl cluster with 10 workers. deploy hdfs via mantl api (default installation).
reboot the machine running namenode1.


Read in respiratory data

Read in respiratory data using chunks for PHQ/GAD.
Adapt the COVID algorithm accordingly.

the respiratory data is read in and the algorithm is adapted


python311Packages.correctionlib: fix build

Description of changes
The build was broken: https://hydra.nixos.org/build/249200317/nixlog/1

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Remove wheel from nativeBuildInputs
https://github.com/cms-nanoAOD/correctionlib/blob/v2.5.0/pyproject.toml#L2-L8
Move numpy into propagatedBuildInputs
Add packaging to `propagatedBuildInputs
https://github.com/cms-nanoAOD/correctionlib/blob/v2.5.0/setup.cfg#L27-L33

Result of nixpkgs-review pr 288112 run on x86_64-linux 1

2 packages failed to build:

python311Packages.coffea
python311Packages.coffea.dist

2 packages built:

python311Packages.correctionlib
python311Packages.correctionlib.dist


Service registry allowedToProxy check applies incorrectly to proxied service

I believe we've run into a bug introduced by [CAS-1019] (https://issues.jasig.org/browse/CAS-1019):
final List<Authentication> authns = ticketGrantingTicket.getChainedAuthentications();
if(authns.size() > 1) {
    if (!registeredService.getProxyPolicy().isAllowedToProxy()) {
        final String message = String.
                format("ServiceManagement: Proxy attempt by service [%s] (registered service [%s]) is not allowed.",
                service.getId(), registeredService.toString());
        logger.warn(message);
        throw new UnauthorizedProxyingException(message);
    }
}

This check appears to be enforcing proxy authorization on the proxied service, which afaict is wrong. I believe the intent is to prevent the proxying service from distributing proxy tickets when the allowedToProxy flag is disabled in the service manager, but this check as written effectively requires the proxied service to have proxy authorization as well. I would think that the correct implementation would walk the proxy chain and look up the parent registered service (i.e. the proxying service) and check its allowedToProxy field. Thoughts?
Here's a log entry from a failed proxy ticket request:
2015-04-03 09:36:13,304 WARN [org.jasig.cas.CentralAuthenticationServiceImpl] - ServiceManagement: Service Attempted to Proxy, but is not allowed. Service: [https://foo.cc.vt.edu/jbpm-console] | Registered Service: [id=6754887993499616,name=VT Catchall,description=<null>,serviceId=^https://([A-Za-z0-9_-]+\.)+vt\.edu(:\d+)?/.*,usernameAttribute=<null>,attributes={A,B,C},<null>]

That's a failed proxy ticket request because foo.cc.vt.edu is not allowed to proxy, but it shouldn't need that authorization because it's not proxying. In other words the parent proxying service is set allowedToProxy=true, but the check is being enforced on the child. That is incorrect by my understanding.

Dev list discussion thread: https://groups.google.com/forum/#!topic/jasig-cas-dev/hwY3pd3tgNk

Pull request with fix against 3.5.x branch: https://github.com/Jasig/cas/pull/933. Note the fix requires a minor API change, thus the version bump and target version of 3.6.0.

#933 merged. I will leave this open until a pull for 4.x branch is accepted.

merged https://github.com/Jasig/cas/pull/974 for master


The field CallbackType in MINIDUMP_CALLBACK_INPUT does not correspond to index values in MINIDUMP_CALLBACK_TYPE

I am writing a callback routine for a MinidumpWritedump implementation, and wish to match on the CallbackType field. This field is currently a u32 and I'm unsure how to compare it to the various MINIDUMP_CALLBACK_TYPE constants that exists in windows-rs.
If you were to compare the callback type in C++ you would do it against either the name of the type in the enum or refer by index. For example, IsProcessSnapshotCallback or 16.
It looks like the constants are defined in the latter way, printing IsProcessSnapshotCallback shows that it's indeed MINIDUMP_CALLBACK_TYPE(16).
So I expected the field to return u32 in the range 0-20, so that I could then compare against the inner values of the constants. The values vary greatly however, far exceeding that range. A sample of values: 0, 476, 285216287, 720, 736, 8072.
I'm not sure that there is actually a bug here, I could very well be misunderstanding something here. I would however like to suggest that this field become a MINIDUMP_CALLBACK_TYPE in the future to make it easier to match against it.
Thanks!

This looks like a duplicate of #1744. The issue is still there in the latest metadata (24.0.1-preview).

Thanks Tim, then I'll close this as a duplicate.

I'd still suggest keeping either this issue or #1744 open, possibly with a "blocked" tag. Much as I understand that maintainers would like to move issues that aren't (immediately) actionable out of sight, clients still need to be aware the issue.
@riverar Did you make any progress on this?


chore(main): release 0.3.2

:robot: I have created a release beep boop
0.3.2 (2023-04-02)
Bug Fixes

force bump version (c99e40b)
release.yml syntax (d396d98)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/guilhermeprokisch/timetoc/releases/tag/v0.3.2 :sunflower:


Cluster Autoscaler: Support other scale down poilcies

Seems like cluster autoscaler terminates the first valid candidate which works for most cases. There are situations where we might want to terminate the oldest nodes (like gradually upgrading cluster to new kubernetes version) or the least utilized node (to reduce rescheduling overhead).
I wrote some preliminary code to get some initial feedback. After approval I will attempt to add some unit/integration/e2e tests for the different scaling policies (possibly in another PR).

This change is

@mwielgus is this a desirable feature? If so I can up with a better implementation.

@andrewsykim We can have some strategies there. Picking the least-utilized node for deletion sounds quite reasonable. Oldest node for upgrades - at least for me - not necessarily but you can try to convince me with a more detailed example. Plus I would add a random strategy.

I agree that the oldest node strategy won't be used often, but if the implementation is not too difficult I don't see why it would hurt to keep that option available. I'll use a similar implementation to what we used for the expander strategies.

This needs to go to kubernetes/autoscaler if you want to get it in.


Add support for setting stylesheets per-view

At the moment, the only way to add a stylesheet is by loading it manually from the view. Maybe add an attribute to handle that automatically?

Fixed in #21


Azure, issue with mounting vhd

Hi,
I tried having a look at the multiple tickets regardind using mounting vhd volumes, but was unable to understand if the issue is fixed.
I can't see to replicate this demo:
I'm using the following yml replication controller:
apiVersion: v1
kind: Service
metadata:
  name: sayt
  labels:
    run: sayt
spec:
  type: NodePort
  ports:
  - port: 8081
    targetPort: 8081
    protocol: TCP
    name: http
  selector:
    run: sayt

---
apiVersion: v1
kind: ReplicationController
metadata:
  name: sayt
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: sayt
        uses: elas
    spec:
      containers:
      - name: sayt
        imagePullPolicy: Always
        image: essearch/sayt:dev1
        env:
        - name: SPIFFY_ENV
          value: "azuredev1"
        - name: ES_CLIENT
          value: "<IP_ADDRESS>:9200"
        ports:
        - containerPort: 8081
        volumeMounts:
          - name: disk0
            mountPath: "/mnt/disk0"
          - name: disk1
            mountPath: "/mnt/disk1"
          - name: disk2
            mountPath: "/mnt/disk2"
      volumes:
        - name: disk0
          azureDisk:
            diskName: sayt-dev1-node0-osdisk.vhd
            diskURI: https://saytdev1.blob.core.windows.net/strgsayt-dev1/sayt-dev1-node0-osdisk.vhd
        - name: disk1
          azureDisk:
            diskName: sayt-dev1-node1-osdisk.vhd
            diskURI: https://saytdev1.blob.core.windows.net/strgsayt-dev1/sayt-dev1-node1-osdisk.vhd
        - name: disk2
          azureDisk:
            diskName: sayt-dev1-node2-osdisk.vhd
            diskURI: https://saytdev1.blob.core.windows.net/strgsayt-dev1/sayt-dev1-node2-osdisk.vhd
      imagePullSecrets:
      - name: a_key

My pods stop in ContainerCreating status, with the following message:
FailedSync	Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "sayt-j8uwl"/"default". list of unattached/unmounted volumes=[disk0 disk1 disk2]
Here are the logs for kubernetes-controller pod:
E1102 00:48:45.810937       1 nestedpendingoperations.go:253] Operation for "\"kubernetes.io/azure-disk/sayt-dev1-node2-osdisk.vhd\"" failed. No retries permitted until 2016-11-02 00:49:01.810922747 +0000 UTC (durationBeforeRetry 16s). Error: AttachVolume.Attach failed for volume "kubernetes.io/azure-disk/sayt-dev1-node2-osdisk.vhd" (spec.Name: "disk2") from node "sayt-dev1-node-2" with: Attach volume "sayt-dev1-node2-osdisk.vhd" to instance "sayt-dev1-node-2" failed with compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=200 -- Original Error: Long running operation terminated with status 'Failed': Code="AcquireDiskLeaseFailed" Message="Failed to acquire lease while creating disk 'sayt-dev1-node2-osdisk.vhd' using blob with URI https://saytdev1.blob.core.windows.net/strgsayt-dev1/sayt-dev1-node2-osdisk.vhd. Blob is already in use."
I1102 00:49:01.847372       1 reconciler.go:170] Started AttachVolume for volume "kubernetes.io/azure-disk/sayt-dev1-node2-osdisk.vhd" to node "sayt-dev1-node-1"

I'm not sure I understand the error as I'm not attaching the volume anywhere else.
By the way I'm using a recent version of kubernetes-anywhere, and kubectl version shows:
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.4", GitCommit:"dd6b458ef8dbf24aff55795baa68f83383c9b3a9", GitTreeState:"clean", BuildDate:"2016-08-01T16:45:16Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3", GitCommit:"b44b716965db2d54c8c7dfcdbcb1d54792ab8559", GitTreeState:"clean", BuildDate:"2016-08-25T18:31:09Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

It says that the lease is already taken. Please look in the Portal and see where that disk is already attached.

I think I was configuration this incorrectly, please ignore the ticket


Update requests.rst

import logging was missing in the example. So I'm adding it to this pull request.

Thanks @khushhalm but could you instead open this PR upstream at https://github.com/johnwheeler/flask-ask? I don't maintain a fork and use this project only for when I'm working on contributions. (I believe my prevous are already merged.)


Y24-114	As SSRs we would like to not have to perform fake cherry picks on stock plates to make submissions so that we are not recording fake data.

As SSRs we would like to not have to perform fake cherry picks on stock plates to make submissions so that we are not recording fake data.
Description
We support a number of pipelines whose first step requires a submission on the stock plates received in SciOps from faculty. A restriction within SequenceScape prevents users making submissions on stock plates  - forcing SSRS to create fake transfers and plates, on which they can then create the desired submission.
This undesirable because:

This creates a false data record of what actually happens in the lab. (I suspect problematic for human material)
It is an unnecessary operation that the SSR's have to know about and perform.

Desired Outcome

[ ] Identify possible solutions to the problem (e.g. faculty perform cherry picks and only submit picked plates, enable submissions on stock plates, something else.....)
[ ] Check for any consequences for canceling and failing wells/plate that link back to submissions on stock plates.
[ ] Propose a solution such that fake cherry picks no longer need to be made.
[ ] Generate user story/ies required to implement change.

Who the primary contacts are for this work
SSR team
PSD
Knowledge or Stake holders
Liz C

Maybe also fold in why they do purpose changes.
Maybe fake cherrypick is for partials, purpose changes for full plates.

See Confluence page "Fake Cherry Picking (CP) Investigation"
Seems like we need to do 3 things (?):
Allow submissions from stock plates.
Allow users to change a plate purpose and/or allow plates to proceed to any purpose on a specified pipeline.
Allow plates to be submitted to SciOps with samples on for multiple studies.

Retention instructions on stock plates needs to be considered - if plates are used as stock plates but not called stock plates, will this cause confusion? (From conversation with Liz C)

Initially we could try adding Stock Plate to the list of acceptable purposes for limber PCR bespoke request type and also to the relationships for bespoke pcr as a starter for 10.
This should work for 10x - CITEseq and EMSeq.

Hi-C - Doesn't actually exist as a pipeline in Sequencescape or Limber so only has a library type. Not sure what we could even do in this case and it is only used for when TopUp sequencing is needed for some samples - rare occurence. This is a long read pipeline.

Outstanding issues:

custom RNA - Not even sure which pipeline this is? If we can work out where we need to make changes we can allow a submission on an RNA stock plate
Library quant submissions - again not sure of the pipeline it is referring to.
Bespoke/R&D requests - again not entirely sure how we would approach this. Do we want to be able to chnage the plate purpose on all pipelines for restricted users.
GbS - I think we need more information on how we could solve this one.


[Feature]: Support for puppeteer-web

Feature description
As part of this PR, you have removed support for puppeteer web and want to look at that feature soon. Could you please implement this feature? Or if there is an alternative, could you please redirect me to one.
I want to use puppeteer-web to execute puppeteer script inside my chrome extension. I see there is a way to start chrome with remote debugging enabled and use puppeteer.connect to connect via ws,  but I don't feel that is a cleaner way of doing it.

It should be possible to execute puppeteer-core inside the extension. Is anything missing for that?

@shivamothkuri yeah you need to perhaps exclude them when you bundle

Do you have a test repo for this? Are you using webpack or rollup? I'd recommend using the rollup as webpack might be doing too many things.

Also, what version do you use? BrowserFetcher does not exist anymore.

I don't have a test repo, yet. I'm trying it on my local setup.
I got an archived repo which kind of solves my issue. But, this repo is using very old version of puppeteer-core v4.0. The author has used browserify and aliasify, which don't have good updates recently and failing to modularise ES2022 code from latest puppeteer-core, like using #(hashes) for private methods/variables.
So, I tried to use a older version of puppeteer-core v18.0.0. Even for this, the node dependencies are an issue.
I tried to use rollup, but the number of things to exclude are never ending. And, I would face same problem when I will try to update to a newer puppeteer-core version.

Also, what version do you use? BrowserFetcher does not exist anymore.

Its puppeteer-core v18.0.0

Please try using the latest version, there should not be many things to exclude in the latest version: all Node dependencies would be only loaded in the node runtime and there should be not much to do. In fact, puppeteer-core is used by Chrome DevTools in the browser so that should mostly working.

Ok. Let me try with latest version and get back. Thanks

You need to run a browser like this: "/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary" --remote-debugging-port=9222 --remote-allow-origins='*' and the URL to connect will be something like ws://<IP_ADDRESS>:9222/devtools/browser/7c4e3772-fcf9-41a2-8dc0-6c1d0920638b. Rollup still prints some warnings in ElementHandle but at least opening the page works, I think the warnings need to be solved with rollup.

yes, I'm aware of this solution to use remote-debugging-port. But, I don't want my users to change the way they are opening the chrome.
If we use record/replay from chrome devtools recorder, it just works. I want to build an experience like that.
Do you have the source code/docs on how chrome devtools is able to replay without debugging port enabled?

@shivamothkuri that is not possible for security reasons.

You can use https://developer.chrome.com/docs/extensions/reference/api/debugger but it is a bit more work to write a custom transport and ". That is not directly related to running Puppeteer in the browser though.

Can you expand on "that API does not support modern CDP sessions that Puppeteer requires", please?

@OrKoN I tried with latest puppeteer-core(22.3.0) and I'm using a custom transport for protocol from puppeteer-extension-transport .
This works for puppeteer-core v13.x, but having trouble for later releases.
When I tried with latest puppeteer-core version, I ger below error in the console
FYI - puppeteer-extension-transport is using CDP v1.3
CallbackRegistry.ts:117 Uncaught (in promise) s: Protocol error (Browser.getVersion): {"code":-32601,"message":"'Browser.getVersion' wasn't found"}
    at <instance_members_initializer> (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:13:890)
    at new c (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:13:954)
    at l.create (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:13:116)
    at C._rawSend (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:188:1873)
    at C.send (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:188:1813)
    at tn (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:240:47294)
    at to (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:240:47838)
    at async Object.executePuppeteerCode (chrome-extension://flpoboeigldifdddkkmfnikkmpmbpjob/background.js:240:52911)

You can use https://developer.chrome.com/docs/extensions/reference/api/debugger but it is a bit more work to write a custom transport and ". That is not directly related to running Puppeteer in the browser though.

@OrKoN, can you expand on "that API does not support modern CDP sessions that Puppeteer requires", please?

Puppeteer relies on the flat session mode https://chromedevtools.github.io/devtools-protocol/tot/Target/#method-attachToTarget (i.e., multiple sessions in one connection with sessionId used to match commands to sessions) but AFAIK chrome.debugger only supports non-flat mode meaning a different chrome.debugger API needs to be invoked to attached to each of the targets manually (that might not work well if you want to configure the target before it starts running).

This is now documented in https://pptr.dev/guides/running-puppeteer-in-extensions and https://pptr.dev/guides/running-puppeteer-in-the-browser


docs: Add github action to documentation

I'm wondering whether we should symlink index.md and README.md...

Yeah if symlinking is possible, that would be nice :)


Column name for hour changed

When parsing hourly data to a DataFrame, the following exception is raised:
ValueError: Missing column provided to 'parse_dates': 'H'.
Looking at the raw data, the column name for 'hour' is changed from 'H' to 'HH'.

This change was also proposed in #18


Add arduino-core rosdep for Debian.

Thanks. Since the PR is only adding the missing Debian entry I will merge it without an additional +1.


Token price human error issue

Hi, I read the paper ReWOO very impressive.
I think I found some human error when counting the token cost on the PWS.py
https://github.com/billxbf/ReWOO/blob/9cd0283043ff4be0c9d614fda2789d143ca6ffd1/algos/PWS.py#L66-L68
OpenAI count the input token and output token because they have different pricing policy, but these codes just count the input and output token as same.
Maybe I can make a mistake, but I want you to know the issue.
Thanks a lot for the nice research!!

Thanks for your kind words! You are right, this function doesn't treat in/out token prices separately.
If I remember correctly, openai's API didn't split the in/out token prices at the time of this work. So I'd rather treat it as an estimation for experiments at the time.
Now they include token counts in the API's completion object, accessed by completion["usage"]

I totally understand about the history of the works.
Thank you for your response!

Closing this thread as solved.


Testing new apply interface for Flux.Chain

New Feature:
Implemented new apply functionality which returns a newly constructed chain as well as the output of applying the input to the current chain. This is in relation to the recent conversation for updating the recurrent network interface. The apply was described by @ToucheSir.
Most of the code is a modification of the _applychain functionality from Flux.jl. The general direction is to likely interface with Accessors.jl. Some minor tests were added, but we will want to include many of the layer types as we expand the feature.
PR Checklist

[x] Tests are added
[ ] Documentation, if applicable

I added the pullback for the vector chain. It likely doesn't work on GPUs yet, and may not be implemented in the most efficient way possible. But it passes the simple test comparing to the other interface.

I also decided to unify _apply with _apply_to_layer because I initially forgot about chains which can be composed of other chains through the parallel and other interfaces.

The non-mutating recur is relatively straightforward. One snag is we can no longer us the simple forward pass for time series data of the old mutating version (i.e. [chain(x) for x in xs]). Instead we need another scan like function. In Equinox, I believe they use jax.vmap to handle this (which maps over the time access of their inputs). I could see two options.

Implement a very simple map function ontop of chain which sends an input through the entire model before moving to the next timestep. Likely could use accumulate as a simple starting point.
Send the vector of time inputs through the chain layer by layer (kinda similar to how we handle blocked time right now in Flux.Recur). Only the stateful layers would have to be treated specially in this case.

I'm not as in on the overarching plans for Flux, but I could see 2 offering more options for optimization.

Also, implementing the non-mutating recur for this interface requires us to make a decision about how to handle time-series inputs for a chain. This is because [chain(x) for x in xs] will no longer work (for hopefully clear reasons). Instead, we will need a custom map function (which maybe _apply can dispatch on?). I could see this kind of function going two ways:

We handle this at the model level, and run the forward pass for the entire model on each time-step of the input.
We handle this at the layer level, and run the forward pass for the entire input for each layer sequentially.

I could see 2 offering more optimization options. But I'm not sure how well it will interact with the rest of Flux (especially future planned stuff).

@ToucheSir For sure. And yes it is, but the 3d api was never meant to be fully featured from what I remember when we were working on it. I'll put up another PR for the non-mutating recur when I make some more progress.


Latest (0.2.10) Bundled installer does not work

Description
Outline the issue here:

0.2.9 bundle installs fine
0.2.10 bundle fails to install due to error(s)

Environment summary
Install Method: How did you install the CLI? (e.g. pip, interactive script, apt-get, Docker, MSI, nightly)
Answer here: bundled installer
CLI Version: What version of the CLI and modules are installed? (Use az --version)
Answer here: 0.2.10 bundle
OS Version: What OS and version are you using?
Answer here: Linux (docker container with FROM buildpack-deps:xenial.
Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
Answer here: bash

Result from trying to install the 0.2.10 bundle:
...
Collecting isodate>=0.5.4 (from msrest>=0.4.4->azure-cli-core->azure-cli)
Collecting keyring>=5.6 (from msrestazure>=0.4.7->azure-cli-core->azure-cli)
Collecting monotonic; python_version == "2.6" or python_version == "2.7" or python_version == "3.0" or python_version == "3.1" or python_version == "3.2" (from humanfriendly->azure-cli-core->azure-cli)
Collecting pycparser (from cffi->azure-datalake-store==0.0.9->azure-cli-dls->azure-cli)
Collecting scandir; python_version < "3.5" (from pathlib2->azure-datalake-store==0.0.9->azure-cli-dls->azure-cli)
Collecting asn1crypto>=0.21.0 (from cryptography>=1.1.0->adal>=0.4.3->azure-cli-sf->azure-cli)
Collecting packaging (from cryptography>=1.1.0->adal>=0.4.3->azure-cli-sf->azure-cli)
   Could not find a version that satisfies the requirement packaging (from cryptography>=1.1.0->adal>=0.4.3->azure-cli-sf->azure-cli) (from versions: )
No matching distribution found for packaging (from cryptography>=1.1.0->adal>=0.4.3->azure-cli-sf->azure-cli)
Traceback (most recent call last):
  File "azure-cli_bundle_0.2.10/installer", line 210, in <module>
    args.override_native_check)
  File "azure-cli_bundle_0.2.10/installer", line 175, in main
    install_cli(tmp_dir, install_dir)
  File "azure-cli_bundle_0.2.10/installer", line 97, in install_cli
    _exec_command(cmd)
  File "azure-cli_bundle_0.2.10/installer", line 50, in _exec_command
    subprocess.check_call(command_list, cwd=cwd)
  File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)

@derekbekoe to take a look

@colemickens PR has been created.
I have also published https://azurecliprod.blob.core.windows.net/bundled/azure-cli_bundle_0.2.10-1.tar.gz.


Investigation: Inconsistent unsubscribed property in Customer.io

I was looking at some profiles in Customer.io and I noticed some weirdness with the unsubscribed attribute:

This member has the unsubscribed attribute
This member doesn't have the unsubscribed attribute

What's strange too, is that both came from Phoenix, were created ~30 minutes apart from one another, have a subscribed status at the top in green.
Here are some others without it:

https://fly.customer.io/env/63704/people/5b6dd12660faa2009b02d37a
https://fly.customer.io/env/63704/people/5b6dd09860faa2009f5ffa86
https://fly.customer.io/env/63704/people/5b6dd07960faa200b52cefbb

Then it's also weird if you go into the "People" overview and search by displayed attributes, unsubscribed isn't one, but unsubscribed_at is one. Maybe the interface doesn't let you pick all of the attributes?

If you go to the last page, you'll see Sergii's there with a timestamp for unsubscribed_at and then if you click into his profile, it says status = subscribed, unsubscribed = false. Which isn't the same scenario as this person who I flagged earlier as having the unsubscribed attribute.
If you go to this profile, it does seem like you can search for the unsubscribed attribute, but it's blank? Is that the default...?
Here's C.io documentation on unsubscribes. It says they'll set it to true if someone unsubscribes, which doesn't seem to be the case for Sergii (unless he resubscribed?) and it doesn't say anything about what the default value is...one would assume false but herm herm.
Context
We were trying to look for easy ways to globally unsubscribe batches of members and I assumed that every single person in C.io would have the unsubscribed attribute (maybe they do and it's just blank for most people so it doesn't show up in their attributes?).
As I mentioned at O'Doyle sprint groom, we're launching a voter reg initiative come Sept 1 where employers are getting their employees to register through us, we don't want to subscribe them to our emails (we've nixed the SMS feature of it). Full write up here. When we create the account on the fly for new members via the Importer, it adds them to our list as subscribed (once NS has this functionality to set it, we'd do it there). The thinking was we would import a CSV w/ updates via the C.io interface or if that didn't work, with a Zapier integration.
Before confirming that we could go through with one of these two workarounds, I wanted to see what their profiles looked like and was promptly confused!

That first user has unsubscribed but not email_frequency, which it would have if it came from Northstar. Could unsubscribed come from anywhere but Northstar? Northstar only sends unsubscribed if it also has email_frequency, so I'd expect that you'd only see an unsubscribed field set from Northstar if you also see email_frequency. Let's talk this through more on Monday, it's confusing!

This is a strange one! We currently rely on this sorta hacky logic in Blink to set the unsubscribed attribute (until we finish all the work to start handling that in Northstar). As a way of determining if the user account is "new" and should be subscribed (versus a backfill where they shouldn't), we compare their created and updated timestamps (since for a new user, they should be the same).
It looks like for the second person with no unsubscribed value, our hacky logic was a little off –– they have a created_at of<PHONE_NUMBER> but an updated_at of<PHONE_NUMBER>… a second later!

This was separately flagged by Anthony when he was doing some digging and wrote up some more detailed information here: https://docs.google.com/document/d/1U4B_pSrNlwzu8Wt7grLtoC4xmZjrbeax4PcSg7HhNPo/edit?ts=5b72f4df&pli=1


Created web browser hooks

Feel free to modify this however you see fit.

Looks lit af 🔥  thanks!


Add time conversion

+time should show the current time in the Adalia system. Actual conversion formula TBA

The official start of the calendar for us would be
00:00:00 Arrival Day, Terran Year Aion, Chronos Year 0 == 10:00 AM 17h of April, 2021, Earth UTC

https://influenceth.fandom.com/wiki/Adalia_System_Calendar <- docs

This should be added to the influence-utils and then imported here. (PR is a work in progress)


Function create_pointcloud not found

Required Info

Camera Model
n/a

Firmware Version
n/a

Operating System & Version
Linux (Ubuntu 16.04)

Kernel Version (Linux Only)
4.15.0-45-generic

Platform
n/a

SDK Version
2.33.1

Language
C++ 11

Segment
(does not matter, fails in simple standalone app)

Issue Description
Hi. I'm trying to use this code
#include <librealsense2/rs.hpp>
...
rs2::pointcloud pc = rs2::context().create_pointcloud();

from this tutorial https://github.com/IntelRealSense/librealsense/tree/master/examples/pointcloud.
But it gives me next error:
class rs2::context’ has no member named ‘create_pointcloud’
What is wrong here?

This sample is designed to call upon OpenGL graphics, so it may not be the best example to adapt if you are trying to reduce the program's complexity down to a simpler point cloud application.  For example, your script omits the #include "example.hpp" line, and example.hpp contains instructions for rendering a point cloud with OpenGL.
The simplest form of a C++ point cloud script, which may be a better place to begin experimentation at, is this:
rs2::pointcloud pc; rs2::points points = pc.calculate(depth_frame); pc.map_to(color_frame);
A slightly more complicated version of this that can export the point cloud to a .ply format file is in the link below.
https://github.com/IntelRealSense/librealsense/issues/2488#issuecomment-427814215

This sample is designed to call upon OpenGL graphics, so it may not be the best example to adapt if you are trying to reduce the program's complexity down to a simpler point cloud application. For example, your script omits the #include "example.hpp" line, and example.hpp contains instructions for rendering a point cloud with OpenGL.
The simplest form of a C++ point cloud script, which may be a better place to begin experimentation at, is this:
rs2::pointcloud pc;
rs2::points points = pc.calculate(depth_frame);
pc.map_to(color_frame);
A slightly more complicated version of this that can export the point cloud to a .ply format file is in the link below.
#2488 (comment)

Thank you. But I have additional question then. I will describe in more details.
I need to take depth data from .bag file and convert it to point cloud. It should work under ROS.
It should emulate real camera which produce pointcloud messages in topic camera/depth_registered/points. But .bag record does not contain this data. So I have to convert depth to point cloud pcl::PointCloudpcl::PointXYZRGB type.
I found this tutorial in thread https://github.com/IntelRealSense/librealsense/issues/2090
Seems it use sensor_msgs/Image message in devise_0/sensor_0/Depth_0/image/data topic. And your code use frame type.
How to convert message to frame?
P.S. I dont't use rendering part from tutorial, I need only conversion.

If you need to convert ROS data to PCL data, this link may be helpful:
https://answers.ros.org/question/316701/ros-intel-realsense-how-to-process-data-with-pcl/
Alternatively, if you are able to make use of the Python language then there is an Intel tutorial for loading in a bag file, retrieving the data from it and generating a point cloud.
https://github.com/dorodnic/binder_test/blob/master/pointcloud.ipynb

There's an error in documentation of pointcloud, I'll update it for the next release.

dorodnic, ok, thanks.
Thanks for links, MartyG-RealSense,  I will try to use them.

Hi @ViacheslavRud   I reviewed the pointcloud documentation, and an edit for create_pointcloud() was made on March 29 2020.
https://github.com/IntelRealSense/librealsense/commit/45f86e523d224b8b995e42a78bd3619fa7bdb7b2
I will therefore close this case as completed.  Thanks!


INSERT to empty table panics

Create a database with an empty table with SQLite:
$ sqlite3 users.db
SQLite version 3.45.2 2024-03-12 11:06:23
Enter ".help" for usage hints.
sqlite> CREATE TABLE users (id INT, username TEXT);

and then attempt to insert a row with Limbo:
limbo> INSERT INTO users VALUES (1, 'penberg');
thread 'main' panicked at core/storage/sqlite3_ondisk.rs:503:25:
already borrowed: BorrowMutError
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

limbo> insert into users values (1, 'foo');
limbo> select * from users;
1|foo


Optional (auto-generated) test case names

Description
To lower the barrier to writing test cases even further, especially for the initial stages of (or small) projects -- which is exactly, where writing tests is often "postponed", while simple, quick early smoke testing could save a lot of wasted effort), coming up with nice, unique case names (especially when they are already thematically grouped in some test runner file), could be a hindrance.
It would be nice to start with no name, and then add one later, as things (like terminology) take shape (and if the test case actually turns out to be kept at all, which is often not what happens).
E.g. for compilers, which support __COUNTER__ (i.e. all?), this is what I've done:
#define STRINGIFY_2(a) #a
#define STRINGIFY(a) STRINGIFY_2(a)
#define CONCAT_2(a, b) a##b
#define CONCAT(a, b) CONCAT_2(a, b)
#define FIRST(x, ...) x

#ifndef STD_CONFORMANT_PREPROCESSOR
#error Conformant C++ preprocessor is required for optional test case names!
#endif
#define CASE(...) DOCTEST_TEST_CASE( FIRST(__VA_ARGS__ __VA_OPT__(,) STRINGIFY(CONCAT(test_case_,__COUNTER__))) )

(Failure reports still include line numbers, so identifying nameless cases is not really a problem, especially if you have IDE support for locating the offending lines. And if you land there, you might then actually add a name, if you feel like. The point is you are not forced to.)
(BTW, that "conformant checking" placeholder in the code is not for __COUNTER__ -- that's still not standardized, unfortunately, but for __VA_OPT__, which is standardized, but the default (i.e. legacy) MSVC preprocessor merrily ignores even with -std:c++infinity. (-Zc:preprocessor enables their conformant version, in case anyone was wondering.))

Unfortunately __VA_OPT__ forces you to C20 / C++20, so that would likely be a no-go. One option would be to add a macro that introduces a unique name into scope for you, like...
#define DOCTEST_TO_STRING0(x) #x
#define DOCTEST_TO_STRING(x) DOCTEST_TO_STRING0(x)

#ifdef __COUNTER__
  #define DOCTEST_UNIQUE_NAME() DOCTEST_TO_STRING(__COUNTER__)
#else
  #define DOCTEST_UNIQUE_NAME() DOCTEST_TO_STRING(__LINE__)
#endif /* __COUNTER__ */
#define UNIQUE_NAME DOCTEST_UNIQUE_NAME

...with its usage being along the lines of...
SCENARIO(UNIQUE_NAME()) { /* Hacking... */ }
SCENARIO(UNIQUE_NAME() * doctest::may_fail) /* Hacking, but it might be a bit flaky for now... */ }

Test case names does not have to be unique. This piece of code works just fine
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include <doctest/doctest.h>

TEST_CASE("") {
    CHECK(false);
}

TEST_CASE("") {
    CHECK(true);
}

TEST_CASE("") {
    CHECK(false);
}

Output of test exe:
[doctest] doctest version is "2.4.8"
[doctest] run with "--help" for options
===============================================================================
main.cpp:4:
TEST CASE:

main.cpp:5: ERROR: CHECK( false ) is NOT correct!
  values: CHECK( false )

===============================================================================
main.cpp:12:
TEST CASE:

main.cpp:13: ERROR: CHECK( false ) is NOT correct!
  values: CHECK( false )

===============================================================================
[doctest] test cases: 3 | 1 passed | 2 failed | 0 skipped
[doctest] assertions: 3 | 1 passed | 2 failed |
[doctest] Status: FAILURE!

I suggest we close this.


Istio-base helm chart does not apply CRDs with correct app, chart, and release labels

Bug Description
Hi,
Deploying istio/base chart via Helm (with base.enableCRDTemplates set to "true") make CRDs be applied by following manifests :
https://github.com/istio/istio/blob/master/manifests/charts/base/crds/
Issue is that when you want to redeploy those CRDs (when some of them have new features, in my case EnvoyFilter getting "priority" spec, included in istiod since 1.14) via Helm, I got an error saying that they don't belong to my release, because not having correct keys:
Error: rendered manifests contain a resource that already exists. Unable to continue with update: CustomResourceDefinition "wasmplugins.extensions.istio.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "istio-base"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "istio-system"
The only one solution I found was to delete each CRD by hand, in order to be able to redeploy them and get the latest versions.
Please change/add missing and wrong keys in order to be able to manage them with the istio/base chart as expected.
Version
$ kubectl version --short
Client Version: v1.21.2
Server Version: v1.23.14-gke.401

$ helm version --short
v3.5.4

Additional Information
No response

Seems to be linked to previous installation of istio-pilot that modified annotations.

Removing CRDs by hand is the documented flow ATM: https://istio.io/latest/docs/setup/install/helm/#optional-deleting-crds-installed-by-istio
This is because we explicitly add a "helm.sh/resource-policy": keep tag to every CRD, so they will not be removed, because removing CRDs is potentially risky/tricky.
There is no support for upgrading CRDs automatically via Helm, at this time.
So for now, manual CRD deletion is documented approach.

Note: Helm doesn't officially support CRD update: :-(
https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#some-caveats-and-explanations

If we want to manually do our own CRD upgrades (because we are manintaining local conventions for Istio that make it safe for us to do so specifically, when it is not generically safe for Helm to do so) we need to properly do "Method 2" here: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-2-separate-charts

Template all Istio CRDs as regular Helm resources (effectively always do enableCRDTemplates) in base
Drop helm.sh/resource-policy: keep (it's pointless if we have a separate CRD chart and are self-managing)
Properly apply the same labels/annotations to the CRD resources that we do to other Helm resources already.

For most users, the base.enableCRDTemplates is not a well known settings. So when they deploy Istio through helm for the first them, they do so following the official document. The official document doesn't set that flag. Without the flag the CRD is still deployed, but without the annotations that mark the CRDs with corresponding helm release name, namespace, and managed-by label.
Contrarily, if the user install the Istio through helm with this base.enableCRDTemplates set to true from the very beginning, this is not going to be a problem. That is because helm will manage the resources rendered in template. The future upgrade will succeed.

For most users, the base.enableCRDTemplates is not a well known settings. So when they deploy Istio through helm for the first time, they do so following the official document. The official document doesn't set that flag. Without the flag the CRD is still deployed, but without the annotations that mark the CRDs with corresponding helm release name, namespace, and managed-by label.

Yes, that's why we should always template and drop helm.sh/resource-policy: keep - it's what prevents CRDs from being properly annotated here.

If we want to manually do our own CRD upgrades/"self-manage" CRD upgrades (because we are manintaining local conventions for Istio that make it safe for us to do so specifically, when it is not generically safe for Helm to do so) we need to properly do "Method 2" here: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-2-separate-charts
1. Template all Istio CRDs as regular Helm resources (effectively always do `enableCRDTemplates` and remove it as an option) in `base`

2. Drop `helm.sh/resource-policy: keep` (it's pointless if we have a separate CRD chart and are self-managing)

3. Properly apply the same labels/annotations to the CRD resources [that we do to other Helm-managed resources already](https://github.com/istio/istio/pull/52463).

Update from today's meeting where @bleggett brought up the topic. The team is good with 1 and 3. For 2, we prefer to keep it so that CRDs don't get accidentally removed during uninstall of the base.
cc @cb-troydai

Hi @bleggett assign to you since you mentioned earlier you'd be interested... let me know if not :) Thanks!

If you get this error while upgrading Istio like me (with terraform helm_release)
#!/bin/bash

# Variables
RELEASE_NAME="istio-base"
RELEASE_NAMESPACE="istio-system"

# List of CRDs
CRDS=(
  "authorizationpolicies.security.istio.io"
  "destinationrules.networking.istio.io"
  "envoyfilters.networking.istio.io"
  "gateways.networking.istio.io"
  "istiooperators.install.istio.io"
  "peerauthentications.security.istio.io"
  "proxyconfigs.networking.istio.io"
  "requestauthentications.security.istio.io"
  "serviceentries.networking.istio.io"
  "sidecars.networking.istio.io"
  "telemetries.telemetry.istio.io"
  "virtualservices.networking.istio.io"
  "wasmplugins.extensions.istio.io"
  "workloadentries.networking.istio.io"
  "workloadgroups.networking.istio.io"
)

# Patch each CRD
for CRD in "${CRDS[@]}"; do
  echo "Patching $CRD..."
  kubectl patch crd "$CRD" -p "{\"metadata\":{\"labels\":{\"app.kubernetes.io/managed-by\":\"Helm\"},\"annotations\":{\"meta.helm.sh/release-name\":\"$RELEASE_NAME\",\"meta.helm.sh/release-namespace\":\"$RELEASE_NAMESPACE\"}}}"
done

echo "All CRDs patched successfully!"

Then re-plan-apply.

If you get this error while upgrading Istio like me (with terraform helm_release)
#!/bin/bash

# Variables
RELEASE_NAME="istio-base"
RELEASE_NAMESPACE="istio-system"

# List of CRDs
CRDS=(
  "authorizationpolicies.security.istio.io"
  "destinationrules.networking.istio.io"
  "envoyfilters.networking.istio.io"
  "gateways.networking.istio.io"
  "istiooperators.install.istio.io"
  "peerauthentications.security.istio.io"
  "proxyconfigs.networking.istio.io"
  "requestauthentications.security.istio.io"
  "serviceentries.networking.istio.io"
  "sidecars.networking.istio.io"
  "telemetries.telemetry.istio.io"
  "virtualservices.networking.istio.io"
  "wasmplugins.extensions.istio.io"
  "workloadentries.networking.istio.io"
  "workloadgroups.networking.istio.io"
)

# Patch each CRD
for CRD in "${CRDS[@]}"; do
  echo "Patching $CRD..."
  kubectl patch crd "$CRD" -p "{\"metadata\":{\"labels\":{\"app.kubernetes.io/managed-by\":\"Helm\"},\"annotations\":{\"meta.helm.sh/release-name\":\"$RELEASE_NAME\",\"meta.helm.sh/release-namespace\":\"$RELEASE_NAMESPACE\"}}}"
done

echo "All CRDs patched successfully!"

Then re-plan-apply.

We have a similar snippet in our Helm upgrade docs now.


Update measuring-experiments.mdx

documented every autocapture event and their payloads

🚀 Deployed on https://667b383e7bb2cc7d26999825--cozy-fox-0defec.netlify.app


#210 A change so it can analyse Azure function apps.

For Issue #210
I don't fully understand how csc works, so this change is based on my observations of what is happening for the test project supplied in the defect, i.e. that the changed method is called twice both with coreCompile set to true, the first one contains the file paths for the source files. So the solution that appears to work is to aggregate the the results of the two calls together, attempted in a way to not interfere with other kinds of project, or what the app was doing before.
I have no idea which of the two commands should be retained as the command, so the last one wins.
I have run the tests and run the example project supplied on the defect with this fix and it produces an output which includes all the source files.
On my box I still get that running a design time build of the function app throws an error, which occurs for me on the integration test that does a design time build of the test Function app, however as you don't seem to have that problem it will be interesting to see if the tests pass for you

After working on this and trying to get a custom version of stryker to works discovered that for function apps I only want the first call to csc.

After working on this and trying to get a custom version of stryker to work. I discovered that for function apps I only want the first call to csc.

Yeah, looks like you hit the same wall I did in #210 - there's just too much going on in the Function App extensions to MSBuild that I think it's outside the ability of Buildalyzer to analyze.
Thanks for the effort though! At least now we know.


PeerSwap creates unblinded addresses with Elements v23

During a swap, PeerSwap will try to create what it expects to be a CT address using Elements. But in the next Elements release (v23) the generatenewaddress RPC is changed to create non-CT bech32 addresses. Because PeerSwap (or go-elements?) is expecting a CT address, an error occurs during a swap:
"cancel_message": "failed to generate surjection proof, please retry"

It seems we need to modify PeerSwap (or go-elements?) to create blech32 addresses explicitly now?

https://github.com/ElementsProject/glightning/blob/master/gelements/elementsd.go#L354
looks like you’ll need to add Blech32 to this enum, and then update the call site to use the correct int here
https://github.com/ElementsProject/peerswap/blob/c22211a9ea6aad15af32266901d620afd1ad2c5f/wallet/elementsrpcwallet.go#L127

this string impl will also need “blech32”
https://github.com/ElementsProject/glightning/blob/master/gelements/elementsd.go#L359

@sat-hoarder We have a patch you can use. https://github.com/ElementsProject/peerswap/pull/257


Remove distributionSha256Sum from gradle-wrapper.properties

Description

We get the below error after cloning and syncing the project, this happens because we had distributionSha256Sum present, since the sha256 can be different for different os versions like Window, Darwin or Linux then Android Studio throws an error.
We also got a query on slack for the same. The slack thread can be viewed here.
Android Studio itself suggests to remove distributionSha256Sum and sync the project.
Related issue https://github.com/gradle/gradle/issues/9361

Screenshot

Thanks! 👍


RUMM-1425 Add nightly tests for RUM feature config options

What does this PR do?
Adding the nightly test cases for the RUM Feature Configuration options :

RUM feature enabled
RUM feature disabled
RUM feature with sampled RUM sessions
LongTaskEvent mapper
ViewEvent mapper
ErrorEvent mapper
ResourceEvent mapper
ActionEvent mapper

Additional Notes
Please note that for all the test cases added in this PR we are re-using the performance monitor dedicated for the SDK initialisation execution time. This is already computing the average duration / day so it will work as expected.
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #630 (4c0572c) into master (0e9ac14) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #630      +/-   ##
============================================
- Coverage     88.41%   88.32%   -0.09%
- Complexity     1622     1625       +3
============================================
  Files           181      181
  Lines          5486     5486
  Branches        673      673
============================================
- Hits           4850     4845       -5
- Misses          394      400       +6
+ Partials        242      241       -1

Impacted Files
Coverage Δ

...android/rum/internal/ndk/DatadogNdkCrashHandler.kt
75.32% <0.00%> (-6.49%)
:arrow_down:

...id/log/internal/domain/event/LogEventSerializer.kt
95.24% <0.00%> (-4.76%)
:arrow_down:

...droid/rum/tracking/FragmentViewTrackingStrategy.kt
81.82% <0.00%> (-4.55%)
:arrow_down:

.../android/error/internal/DatadogExceptionHandler.kt
88.00% <0.00%> (-4.00%)
:arrow_down:

...ernal/instrumentation/gestures/GesturesListener.kt
89.74% <0.00%> (-1.71%)
:arrow_down:

...droid/rum/internal/domain/scope/RumSessionScope.kt
96.34% <0.00%> (-1.22%)
:arrow_down:

...g/android/rum/internal/domain/scope/RumEventExt.kt
80.91% <0.00%> (-0.91%)
:arrow_down:

...ore/internal/constraints/DatadogDataConstraints.kt
92.31% <0.00%> (ø)

...m/internal/domain/scope/ExternalResourceTimings.kt
73.53% <0.00%> (ø)

...l/net/info/BroadcastReceiverNetworkInfoProvider.kt
79.17% <0.00%> (ø)

... and 6 more


a11y: Add token to support disabled text

Is your feature request related to a problem? Please describe.
In reviewing Flight Search for accessibility issues, I came across the UI attached to this issue.

The CSS is written as
.valuetile.svelte-1unl1vz .valuetile-container .price-callout-container .disabled-text.svelte-1unl1vz {
    color: var(--ds-color-border-disabled-default);
    font-size: var(--ds-text-body-size-sm);
}

The code color: var(--ds-color-border-disabled-default); is the focus of this issue.

--ds-color-border-disabled-default is not the right token to be used for text
--ds-color-border-disabled-default is a deprecated token
There is no relative semantically correct token to request for replacement and is suspect to failed theming UI

Describe the solution you'd like
New tokens specifically for disabled text is requested.
var(--ds-color-text-disabled-default),
var(--ds-color-text-disabled-inverse),

According to WCAG 2.1 - Success Criterion 1.4.11: Non-Text Contrast, this requires a minimum 3:1 contrast ratio for graphical elements and states that it applies to "inactive user interface components," such as disabled text.
The closeted existing Auro token would be var(--ds-color-base-gray-500) with a hex value of #959595 which barely meets the 3:1 contrast requirement (2.99:1) but can be considered an acceptable option for disabled text.
For the inverse, var(--ds-color-base-gray-600) with a hex value of #7e7e7e would meet the 3.1 color contrast ratio 3.1 requirements (3.5:1) using the var(--ds-color-background-primary-100-inverse) token with hex value of #0e2b4f as an inverse background.
I'd also recommend that the token var(--ds-color-text-ui-disabled-default) be updated to alias color.base.gray.500.value to support the #959595 hex value that meets the 3:1 contrast requirement.
Describe alternatives you've considered
The cost of doing nothing is the following; endangerment of not providing a semantic token for disabled text which will result in inconsistent theme updates going forward and the possibility of disengaging users with low-vision impairments and/or color blindness issues.
Additional context
Related issue for flight search team

https://github.com/Alaska-ECommerce/flightsearch-lem-svelte/issues/2271

Exit criteria
This issue can be closed once the requested tokens have been made available for consumption by UI development teams.

@blackfalcon we currently already have these two tokens for this purpose defined:
--ds-color-text-ui-disabled-default: #adadad;
--ds-color-text-ui-disabled-inverse: #7e7e7e;

@nklansford We need to make sure we consider this as part of the semantic token conversations that are ongoing.

Hey @jason-capsule42
I did see those tokens in there, but I am unsure as to the rules for using ui tokens. These were initially intended to be used for 'interactive' elements and this use case is for non-interactive text that is to appear as disabled within the search experience.
Also, there is a suggested change to a token to use "value": "{color.base.gray.500.value}", as the disabled-default versus the "value": "{color.base.gray.400.value}", in order to meet a 3:1 contrast ratio that is documented in this issue.
If the decision is to retain only the --ds-color-text-ui-disabled-default/inverse tokens, I am ok with that, but I would strongly recommend changing the token alias reference.

Totally agree with where your head is at on this @blackfalcon.
There is a conversation being headed up by @nklansford assessing our semantic naming convention. As more teams are being required to use the tokens to support dual brand theming the complexity of the naming solution in place and the confusion arising from that is showing itself. There is movement to simplify the semantic token names, make them much more obvious about which to use and where and hopefully prevent issues exactly like this in the future.

I am going to move this to BLOCKED until the new naming convention is resolved and then I'll come back to this ticket.


Repo sync for protected CLA branch

The pull request is created from main637770243148274672 to main to fix git push error for protected CLA branch

@huypub : Thanks for your contribution! The author(s) have been notified to review your proposed change.


remove global_store instructions for dynamic igemm wrw pass

Remove globla_store_dword instruction in dynamic igemm wrw pass, because the instruction does not use 64 bits vaddr any more.

@shaojiewang @carlushuang Please make sure all of the other kernels are checked for this issue.

@shaojiewang @carlushuang Please make sure all of the other kernels are checked for this issue.

I did not see any other usage of global_store_dword instruction.

@shaojiewang  please remove instruction for debug purpose

compile error in rocm3.9 is eliminated.

@shaojiewang please remove instruction for debug purpose

removed

@carlushuang Please re-review.


feat: Auto generate the list data from the json files

public/data/*.json to be combined and generated to public/list.json

Great thank you 👍 This has now be completed here https://github.com/EddieHubCommunity/LinkFree/pull/168


Possible to version bump and release?

I only ask because I'm getting a bunch of compiler warnings about the zero arity functions.
I was planning on fixing them and sending a pull request before I noticed that they were already fixed.
If you were waiting on adding some features before releasing a new version, I understand. Just thought I'd ask. Thanks!

For sure it's possible to pull in the pr and release 👍 no worries, just send the pr my way and I'll do it.


Added CloudWatch writer

Added CloudWatch writer and fixed OS X specific problem with maven assembly.

This pull request is now managed with CodeReviewHub. Refresh.

This PR is replaced by #244


chore: bump candid to 0.9

Description
Bump Candid to 0.9. No user visible change is expected.
A backlog item to refactor ic-utils is added in #449
Checklist:

[ ] The title of this PR complies with Conventional Commits.
[ ] I have edited the CHANGELOG accordingly.
[ ] I have made corresponding changes to the documentation.

candid major version upgrade should result in major version bump of agent-rs crates.


Placement of inout

The placement of inout has changed because of SE-30. Can this be adopted in the code?
Currently, my error messages get lost in a long list of deprecation warnings because of this.

We should absolutely update to fix this.
That said, I would like to formalize a guideline/timeline around when we update for breaking changes.  Despite the warnings, everything compiles on the 03-01 snapshot where as any snapshot before 03-01 will result in a error error.
@qutheory/vapor:

What timeframe is sufficient to expect/force everyone to have upgraded all of their environments? Currently we're at 10 days, is that enough?
Would a snapshot+1 policy make sense, where if you don't upgrade by the snapshot following the breaking change, it's on you?
Given the early stages of Vapor, should we just make these changes immediately upon release?

If we make that change were also incompatible with iOS and Swift 2.2 until the fall. We should probably do Swift version compiler checks.

Our goal is compatibility with Swift 2.2. So, if we want to get rid of those warnings then we should unfortunately do version checking.

@shnhrrsn Given the scope and early stage of Vapor, I think we are fine to be compatible with only the latest snapshots, and to require that everyone is running the latest ones.
I'd make our support requirements the following:

Latest Swift 2.2 Release Snapshot
Latest Development Snapshot

We should upgrade Travis CI to test these both.

I might be missing something, but what's the point of supporting 2.2 when only 3.0 contains SwiftPM, which is the only supported way to build Vapor? Even if you make it compatible with 2.2, nobody will use it with it.

@czechboy0 I was actually hoping we'd make it cocoapod/carthage compatible after Xcode 7.3 is released.

If Vapor doesn't work with Swift 2.2 when it's released that would be ridiculous. We will find a way.

I'm not saying there isn't a way, all I'm saying is that Swift 3 as a platform, not as a language, is the first milestone where Vapor even makes sense.
Maybe my misunderstanding comes from the expectations of where Vapor will run. My guess is that absolute majority will be on Linux servers, where SwiftPM is the only way to build/run Vapor. There really aren't that many Mac servers, where you'd have the luxury of having Xcode installed, so I don't see how CocoaPods/Carthage even makes sense for a serverside project.
Feel free to introduce a bunch of compile-time checks for 2.2, but for a project which won't be able to run on 2.2 (unless you introduce a bunch of converters from Package.swift to the aforementioned package managers for the sake of being able to run on a few Mac servers), and which is still in active development, already introducing legacy feels like a very bad idea to me, mostly because I don't understand who you're trying to enable to use Vapor who already can't use Swift 3.0-dev.
The way I understood it was that Vapor is a Swift 3.0/SwiftPM targetting project, meaning you can already run it on servers with Swift 3.0-dev (whichever platform). But I didn't know backwards compatibility to language versions which don't support SwiftPM was a goal.

Vapor shouldn't require SwiftPM if NSJSON gets fixed.

Even if we have to bundle things manually to work with Swift 2.2, even if we have to make a branch, we should do that. I think it would be a major disadvantage for Vapor to not work with the release version of Swift on Linux.

IMO Swift 2.2 on Linux won't be very useful without SwiftPM.  But nothing we can do about that. :\

@czechboy0 It certainly won't be good to develop on, but I feel like we could build a package for apt-get or similar that runs in the swift2.2 runtime and wouldn't need SPM.

Exactly. I don't know what the schedule is like for Swift 2.2 release and Swift 3.0 release...I assume they would be at least 6 months apart. That's a lot of time to delay a 1.0.0 release.

I guess my question is: who are the people who will not be able to use 3.0-dev that we're optimizing here for? It's so easy to switch swift versions that I seriously doubt the effort to run on 2.2 forever is justified.

Vapor can't be production ready until it runs on a released compiler.


Font is not clearly visible on the Blog page.

On the Blog page , the font size is too small. It is not clearly visible and the font color is similar to the background image which makes it difficult for the user to read.

I would like to work on the blog page and make it look more attractive and readable for the users.
Can you assign this issue to me under GSSOC21.

/gssoc/

/level2/

I want to work on this.

Please assign me this task

Please assign me this task

/assign

@ishikalohia @kanchi-22 @mohdjameel2412 @ambivert-sam The website has gone through major frontend changes and I think this issue has been by and large fixed. Hence I'm closing this issue.


bug: enforce error when check login permission with multiple models

https://github.com/casdoor/casdoor/blob/7e0bce2d0f3c1e70071614932cda3b4e43d09d2c/object/check.go#L375-L381
As the line 375 shows, It get the enforcer from permission:
https://github.com/casdoor/casdoor/blob/7e0bce2d0f3c1e70071614932cda3b4e43d09d2c/object/check.go#L375
Then perform the function Enforce(),  It is a hard-code 3 size request, but the enfocers maybe have different models that define different size of request. For example, the RBAC with domian model. It needs 4 sizes of request. So it can throw an error belows:

https://github.com/casdoor/casdoor/blob/7e0bce2d0f3c1e70071614932cda3b4e43d09d2c/object/check.go#L378

@leo220yuyaodog can you make a PR to fix it?


DevContainer for Holohub

This PR includes the following changes:

Updates devcontainer script with a new command vscode to launch DevContainer with VS Code

The script accepts an optional application_name parameter to search for application-specific Dockerfile and DevContainer template

A top-leve .devcontainer template
VS Code launch.json and tasks.json to build, launch and debug for the following applications:

asr_to_llm
basic_networking_ping
colonoscopy_segmentation
cuda_quantum
cvcuda_basic
endoscopy_depth_estimation
endoscopy_tool_tracking
endoscopy_tool_tracking_distributed
florence-2-vision
h264_endoscopy_tool_tracking
h264_video_decode
volume_rendering

Some application includes compound launch profiles, for example:

basic_network_ping application includes a RX and a TX profile and a compound profile to launch both
endoscopy_tool_tracking includes a launch profile to launch all three fragments. It also includes three launch profile each for each of the fragments and a compound profile to launch all three in distributed mode

@mocsharp confirmed this is ready, thank you!