1 of 3 instances cannot connect to camera

Hello,
I configured 3 instances of octoprint (prusa i3 mk3s+) and 3 logitech cameras. 2 cameras works fine with instance number 1 and 3, but camera 2 can't connect to instance number 2. I tried restarting service using sudo systemctl restart cam_prusa-5215 and then sudo systemctl status cam_prusa-5215 for check if it's working.
● cam_prusa-5215.service - the OctoPi(buntu) webcam daemon with the user specified config
     Loaded: loaded (/etc/systemd/system/cam_prusa-5215.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-08-31 15:03:30 UTC; 11s ago
   Main PID: 1656 (mjpg_streamer)
      Tasks: 3 (limit: 18968)
     Memory: 1.4M
     CGroup: /system.slice/cam_prusa-5215.service
             └─1656 /home/max/mjpg-streamer/mjpg_streamer -i input_uvc.so -d /dev/cam_prusa-5215 -r 1920x1080 -f 30 -o output_http.so -p 8002

Aug 31 15:03:30 kanciapa mjpg_streamer[1656]:  o: HTTP Listen Address..: (null)
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]:  o: username:password....: disabled
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]:  o: commands.............: enabled
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: www-folder-path......: disabled
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: HTTP TCP port........: 8002
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: HTTP Listen Address..: (null)
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: username:password....: disabled
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: commands.............: enabled
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: starting input plugin input_uvc.so
Aug 31 15:03:30 kanciapa mjpg_streamer[1656]: MJPG-streamer [1656]: starting output plugin: output_http.so (ID: 00)

And as you can see it's working, but octoprint instance can't load view.

My first thought is that you are probably running out of USB bandwidth on that bus. If your cameras have serial numbers, try putting them in different USB ports to spread the load. Ideally, you'll have multiple USB busses on the system and you would want to have only one camera on each.

That was it. I ran out of USB bus. Thank you!


Fix Password Generation & Spec

Add white space throughout password to keep repeating from failing password
White space is not an option for SecureRandom.base64 (A-Z, a-z, 0-9, '+', '/' and '=')

[#111701452]
[#111779364]

So this problem was isolated to the auto-generation of a group moderator participant? If so, this looks sufficient.

To the best of my analysis of the failure: https://travis-ci.org/cbitstech/sunnyside/builds/102480217 thanks!


Is there any plans to use ND4J

Instead of Cuda Kernels, would it be possibe to use ND4J library instead or would that support be added.

i will thinks for your issue,but nd4j is only support Basic Operations.some model must use the special
kernel for the cuda.

If there are kernels, that I can help write using ND4J, let me know, I can try and attempt those.


lanetix/issues#2729 - Upgrade to latest eslint (v0.24)

@lanetix/engineers CR Please.  Thanks.
lanetix/issues#2729 - Upgrade to latest eslint (v0.24)

🏂🍡🐭🚀🎉


Error: docker-compose up --build -d

After executing docker-compose up --build -d
Error comes
Pulling couchdb (couchdb:1.7.1)...
Pulling repository docker.io/library/couchdb
ERROR: Tag 1.7.1 not found in repository docker.io/library/couchdb
Regards

@sarzali07 that's strange. I've just pulled the image under the question. Probably you have some issues with docker itself. Could https://github.com/docker/distribution/issues/1947 or https://github.com/moby/moby/issues/26295 be any of help?

docker info             Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 1.12.6-cs13
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 0
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: null bridge host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.945 GiB
Name: sarfaraz-virtual-machine
ID: MHMQ:5JQP:UBGB:VI4M:NSKZ:25SJ:EOGR:RWHW:MWPP:FLOI:3QQH:GWEP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
<IP_ADDRESS>/8
docker version          Client:
Version:      1.12.6-cs13
API version:  1.24
Go version:   go1.6.4
Git commit:   0ee24d4
Built:        Mon Jul 24 18:09:19 2017
OS/Arch:      linux/amd64
Server:
Version:      1.12.6-cs13
API version:  1.24
Go version:   go1.6.4
Git commit:   0ee24d4
Built:        Mon Jul 24 18:09:19 2017
OS/Arch:      linux/amd64
Kindly let me know whats wrong

I have ubuntu 14.04,
If possible send me command lines to install hospital run on local environment.
Regards

git clone git@github.com:HospitalRun/hospitalrun-server.git
Cloning into 'hospitalrun-server'...
The authenticity of host 'github.com (<IP_ADDRESS>)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,<IP_ADDRESS>' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

@sarzali07 That's weird - that should never happen. This is a publically available repo.
I think you need to follow the instructions here: https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
I suspect there is an issue with your git user on your machine.

ERROR: Get https://docker.elastic.co/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Finally I manage to install
Successfully built 5fd1b68d96b9
Successfully tagged hospitalrun_nginx:latest
elasticsearch_hr is up-to-date
couchdb_hr is up-to-date
logstash_hr is up-to-date
Starting hospitalrun ... done
hospitalrunserver_nginx_1 is up-to-date
But when I type localhost it give UNABLE TO CONNECT INTERNET ERROR

Hi @sarzali07 do you managed to connect?
I'm facing same problem here: Unable to Connect

If you run docker ps -a when having this problem, do all 5 containers show up as running?
If your nginx container is shutting down it may be because of not setting up the SSL configuration. See the instructions in https://github.com/HospitalRun/hospitalrun-server/blob/master/DEPLOYMENT_GUIDE.md.

@wbuarque I left this management system. very complex and not easy to manage by one person.

Hi Matthew,
yes, exception is elasticsearch_hr, but is my server setup witch has lower memory. My SSL env is none.
Doing a curl -X GET http://<IP_ADDRESS> give me an 302 page.


snap package does not read user/global config files

Youtube-dl does not use the config file located in my home directory (~/.config/youtube-dl/config) or in my /etc/youtube-dl.conf file.
Running on Ubuntu 18.04 and EndeavourOS.
When installed from pip I can youtube-dl --verbose it will list my config file settings, but does not with snap.
When I run "snap connections youtube-dl" I get:
Interface        Plug                        Slot      Notes
home             youtube-dl:home             :home     -
network          youtube-dl:network          :network  -
removable-media  youtube-dl:removable-media  -         -
If I am seeing this correctly, it should map my home directly (and I would assume that would include the .config directory).

try cp /etc/youtube-dl.conf ~/snap/youtube-dl/current/.config/youtube-dl/config
it appears that's where snap packages store their config

try cp /etc/youtube-dl.conf ~/snap/youtube-dl/current/.config/youtube-dl/config
it appears that's where snap packages store their config

This worked for me too on Ubuntu 20.04LTS where I was having exactly the same issue with a caveat that the $HOME dir, respective this one I had: ~/Videa/_NEW_DOWNLOAD/ got translated to
/home/efa/snap/youtube-dl/2863/Videa/_NEW_DOWNLOAD/
so had to provide absolute path.
It would be great if the snap package could work with default system config. At least I cannot figure out how to force it.

When I run "snap connections youtube-dl" I get:
Interface Plug Slot Notes
home youtube-dl:home :home -
network youtube-dl:network :network -
removable-media youtube-dl:removable-media - -
If I am seeing this correctly, it should map my home directly (and I would assume that would include the .config directory).

The home interface only allows access to non-hidden files owned by the user in the user’s home directory.


Festlib should return status code

Festlib::load_file and Festlib::load_string should return status codes
Look at https://pugixml.org/docs/manual.html#loading.errors

added exceptions and validation for xml file with commit 7b2df60b1f9a8827b44dfcc3d02637f7ce35d359


Testnet 6.4.1

Fixes a typo in the config of 6.4.0.

Codecov Report

Merging #236 (4019dad) into develop (8fc3c4a) will not change coverage.
The diff coverage is 0.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@           Coverage Diff            @@
##           develop     #236   +/-   ##
========================================
  Coverage    33.99%   33.99%
========================================
  Files           23       23
  Lines         7884     7884
========================================
  Hits          2680     2680
  Misses        5204     5204

Files
Coverage Δ

src/cosmos.rs
20.50% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Issue: Broken ask for https://28oge2ricd.execute-api.us-east-1.amazonaws.com/prod/ecdsa_sign

Describe the bug
As I see from browser logs:

Uncaught (in promise) Aborted webauthn on unmount in browser logs.
It asks AWS (what the hell? can't we do this ourselves) to sign ECDSA https://28oge2ricd.execute-api.us-east-1.amazonaws.com/prod/ecdsa_sign
Error 400 is returned with {} body.
Uncaught (in promise) {error: 'The delegation cannot be obtained: {}'}

Note that nfid.getDelegation async function never finishes, as seen from no delegationIdentity in browser logs.
Here is the code:
      const nfid = await NFID.init({
        application: {
          name: "Zon",
          // logo: "https://dev.nfid.one/static/media/id.300eb72f3335b50f5653a7d6ad5467b3.svg" // TODO
        },
      });
      const delegationIdentity: Identity = await nfid.getDelegation({
        // optional targets ICRC-28 implementation, but required to support universal NFID Wallet auth
        targets: [], // FIXME: needed?
        // optional derivationOrigin in case you're running on a custom domain
        derivationOrigin: `https://${process.env.CANISTER_ID_frontend!}.icp0.app`,
        // optional maxTimeToLive defaults to 8 hours in nanoseconds;
        maxTimeToLive: BigInt(8) * BigInt(3_600_000_000_000) // TODO
      });
      console.log("delegationIdentity", delegationIdentity);
      updateClientNfid(delegationIdentity);
...

To Reproduce
Steps to reproduce the behavior:

Run the above code in a browser.
Watch for no delegationIdentity, but errors in the browser log.
Scroll down to '....'
See error

Expected behavior
The delegation identity to be returned, with no error messages.
Desktop (please complete the following information):

OS: Ubuntu 23.04
Browser Chromium 117.0.5938.92 snap
Version @nfid/embed ^0.10.0-alpha.1

Here is a fragment of compiled code:
            async function p(e, t, r) {
                const n = await y(r)
                  , o = await v(t, n, new Date(Date.now() + 10 * i.FZ), {
                    previous: t.getDelegation()
                })
                  , a = {
                    chain: r,
                    delegationChain: JSON.stringify(o.toJSON()),
                    tempPublicKey: n,
                    keccak: e
                }
                  , u = s.ic.isLocal ? "/ecdsa_sign" : "https://28oge2ricd.execute-api.us-east-1.amazonaws.com/prod/ecdsa_sign";
                return await fetch(u, {
                    method: "POST",
                    headers: {
                        "Content-Type": "application/json"
                    },
                    body: JSON.stringify(a)
                }).then((async e=>{
                    if (!e.ok)
                        throw new Error(await e.text());
                    return await e.json()
                }
                ))
            }

No idea why aws here!!

And what was this code generated from? We have no aws queries in the sources!

Further discussion of this issue should be at https://github.com/internet-identity-labs/sdk-ts/issues/39

It was claimed that the bug has been fixed. It is not true, see this forum post


findMany batching

While we will tackle combining multiple findOne calls into one findMany call, we also should optimize multiple findMany calls, that all have the same selection set, but a different relation filter like so in your GraphQL resolver.
resolve(parent) {
	return prisma.comment.findMany({
	  where: {
	    post: {
	      id: parent.id
	    }
	  }
	})
}

This optimization is a bit more complex to do though, so we will first tackle the optimimzation mentioned in https://github.com/prisma/prisma2/issues/1470

@liadmat in https://github.com/prisma/prisma/issues/6703:

Bug description
Often (especially in GraphQL) we want to request resources that are related to some other resource, e.g. tasks that belong to a user.
When querying the resources using findMany({ where: { ... } }), Prisma doesn't optimize for N+1.
How to reproduce
Reproduction: https://github.com/liadmat/prisma-repro/blob/main/src/index.ts
Expected behavior
Prisma should be able to optimize this as it does with nested read API.

@janpio Hi, any updates on this issue?

any updates on this?

interested if there are any updates here!

This would be a big + for anyone using graphql thinking of migrating to Prisma

Anyone implemented this on their own using dataloader?

Agree this type of optimization should be a focus for an ORM like Prisma.

Would really like to see this. Currently I don't see a way to optimize a findMany that has more than 1 where clause, using the fluent API like suggested in the docs. For example, this query:
return context.prisma.baz.findMany({
  where: {
    fooId: args.fooId,
    barId: args.barId
  },
});

Using the fluent API, a naive solution might look like:
const fooBazs = context.prisma.foo.findUnique({
  where: { id: args.fooId },
}).bazs();

const barBazs = context.prisma.bar.findUnique({
  where: { id: args.barId },
}).bazs();

return mergeRecords(fooBazs, barBazs)

Where mergeRecords would merge the two lists, and remove the duplicates. This is obviously not optimial, as it needs to do two queries and then post-processing on the results, but I guess it's better than lots of findMany. If I want to add additional selects, wheres, ordering, etc, that would be additional complexity on the post-processing side.
Does anyone know of a better way to do this?

How can I find details of challenges for implementing this issue?

@janpio any chance this can be picked up in the "Optimize Prisma Client Query Performance" roadmap item currently WIP? It's such a huge win for GQL applications where the fluent api alterantive is not appropriate.

It is currently not planned in that context, as we focus on things that are broken in this context.
But it would certainly make a good candidate when we have "cleared that out".
I fully understand your use case and agree about the positive impact this would have.

So, we are still waiting for findMany() to batch? Keep using fluent api?

It seems that findMany calls are batched now, when you have the relationLoadStrategy set to "join": https://www.prisma.io/docs/orm/prisma-client/queries/query-optimization-performance#solution-2-using-joins-to-perform-queries. It's a bit hidden, though - and not mentioned at all in the relationJoin release post 😅


Please need help with video code and vast please

Hello Everyone ,
I need help please ,
I use this code (via fluid player building documention website)
</video>
<script>
    var myFP = fluidPlayer(
        'video-id',
        {
            layoutControls: {
		fillToContainer: true,
		primaryColor: false,
		posterImage: false,
		autoPlay: false,
		playButtonShowing: true,
		playPauseAnimation: true,
		mute: false,
		logo: {
			imageUrl: 'https://mysite.com/mylogo',
			position: 'top left',
			clickUrl: null,
			opacity: 0.8,
			mouseOverImageUrl: 'https://mysite/url',
			imageMargin: '2px',
			hideWithControls: true,
			showOverAds: false
		},
		htmlOnPauseBlock: {
			html: null,
			height: null,
			width: null
		},
		allowDownload: false,
		allowTheatre: true,
		playbackRateEnabled: true,
		controlBar: {
			autoHide: true,
			autoHideTimeout: 3,
			animated: false
		},
            },
            vastOptions: {
                "adList": [
                    {
                        "roll": "preRoll",
                        "vastTag": "https://syndication.exoclick.com/myzone1"
                    },
                    {
                        "vAlign" : "middle",
                "roll" : "onPauseRoll",
                "vastTag" : "https://syndication.exoclick.com/myzone2"
                    },

                    {
                        "roll": "postRoll",
                        "https://syndication.exoclick.com/myzone3"
                    }
                ]

            }
        }
    );
</script>

with
<link rel="stylesheet" href="https://cdn.fluidplayer.com/v2/current/fluidplayer.min.css" type="text/css"/>
<script src="https://cdn.fluidplayer.com/v2/current/fluidplayer.min.js"></script>

In the header of my website .
But I have black screen or first advertisement and nothing .
when I check my webpage with chrome  , I have src="null" . The url on my video diseappear .
Does my player code has a problem ? #
SOrry for my bad english
thanks a lot
Phil .

Hi Phil, I tried your parameters locally and I'm seeing the correct behaviour myself. One change required was for your postRoll setting, the vastTag isn't set correctly.
Can you show the rest of your  tag to see if the issue is with the set videos? Preferably if I could see a test page of your site I would be able to help further. It's okay if the site is NSFW.

Hello Cian .
Thanks for the help .
I did a mistake for the postroll. I forgot "vastTag" .
If it's ok for nsfw site here the correct url (under construction ) http://www.sexecul.net/2016/08/rachel-starr-modele-baisee-par-manuel-ferra-et-arrosee-de-jute-epaisse.html
with correct video url , logo and exoclick advertisement (pre roll video ads and banner for pause and post roll)
Thank you
Phil.

The  element isn't correctly formatted, so no video is being played. It should be formatted as shown below:
<video id='video-id'>
    <source src='http://www.sexecul.net/wp-content/uploads/2016/08/4420-2_pdv.mp4' type='video/mp4'>
</video>

The above will work provided there's a video at the specified URL, however from accessing the URL directly it seems to be returning a 404. So once the source is set correctly also ensure it's pointing to the correct place.

Hello again ,
Sorry for the delay of answer . The source is now OK .
I tried with different source with your correct code and it works.
I didn't see the bad format of the video element.
Thank you for your time and your Help
Phil


make the count an error, so that maven doesn't eat it

I'm getting deja vu, since this definitely happened last time I did this too and I just forgot :(

and the reason I didn't make this change before becomes apparent: this makes all our tests fail

and the reason I didn't make this change before becomes apparent: this makes all our tests fail

maybe we just need to extract javac commands to get these counts in cases where maven is used?

@msridhar I think this latest version is the sweet spot. I've made it a warning, which won't fail compilation (or our tests), but will still show up in Maven's logs


Add parameter to skip initial cleanup

Hello!
First of all thanks for this tool. It's helpful.
I would like to add the possibility to skip the initial cleanup by introducing --skip-cleanup param.
When I do the cleanup and copy some files into the build folder by another watch script before running cra-build-watch, I would like to be able to skip the cleanup made by cra-build-watch.
PR will follow this issue.
Thanks.

I'm glad to see that this tool is providing value to you. That's a good suggestion, thanks. I'll try to look at it when I get some time. There are other people waiting for their stuff to get some movement too so I might not tackle this first. Just to be transparent. 😉

Good to hear something back. Take your time, and feel free to leave some comments when you are available.
Best!

Sorry I don't have time to maintain this project anymore so I'll archive it and add a note in the README. Feel free to fork it as you see fit.


mouser over the .ps-container, the scrollbar can not appear

I checked the source and found scrollHeight is zero. I wondered why $this.prop('scrollHeight') did not get value

Closed for the inactivity.


Convert "Foundry notes" in descriptions to using <secret> blocks

A number of items have Foundry implementation notes for users in addition to their normal descriptions. These notes should be moved inside <secret> blocks so they only show up for the owner and not in chat messages.

Here are some class ones I found:

[ ] Bardic Inspiration
[ ] Font of Inspiration
[ ] Channel Divinity (Cleric)
[ ] Ki
[ ] Deflect Missiles
[ ] Favored Enemy
[ ] Natural Explorer
[ ] Font of Magic
[ ] Spell Mastery

[ ] Sling Bullet
[ ] Necklace of Prayer Beads
[ ] Ring of Regeneration
[ ] Ring of the Ram
[ ] Robe of Useful Items
[ ] Potion of Poison
[ ] Potion of Heroism
[ ] Restorative Ointment
[ ] Rod of Absorption
[ ] Feather Token Bird
[ ] Necklace of Fireballs
[ ] Sovereign Glue
[ ] Defender Swords
[ ] Dwarven Thrower
[ ] Mace of Smiting
[ ] Nine Lives Stealer Swords
[ ] Staff of Fire
[ ] Staff of Frost
[ ] Staff of Charming
[ ] Staff of Healing
[ ] Staff of Striking
[ ] Staff of Power
[ ] Staff of Swarming Insects
[ ] Staff of the Magi
[ ] Staff of the Woodlands
[ ] Staff of Withering
[ ] Unarmed Strike Monk
[ ] Breath Weapon
[ ] Savage Attacks


fix: allow allocating more than int max array

Fix for very severe issue with allocating more than int max array data on each node.
changes corresponding to:
https://github.com/microsoft/LightGBM/pull/2859
fixes issue:
https://github.com/microsoft/LightGBM/issues/2615
and corresponding mmlspark issue:
https://github.com/Azure/mmlspark/issues/753
requires lightgbm upgrade

closing as this PR is now superseded by https://github.com/Azure/mmlspark/pull/850 which contains these changes as well


Enable world config

Added config option to limit the worlds where Whackamole works.

Translations needed

Game File loading warning message for already existing game files which are now disabled.
DB Game file loading warning for now disabled games.
Game creation failure message when user wants to create a game in an not enabled world.

@CraZyRc do we want this option in the config? It would clear out all Warning: no games found in world XXX logs.
this first pass is not tested. just created it as an test to see how it would look like


Generate tests for DP codegen

As part of the generation of DP codegen, we would like to take advantage of receiving x-ms-examples of m4 to generate tests files.
The idea is:

Generate one test per method with x-ms-examples (let's skip operations without them yet)
Generate test code:

Creates JSON from the input of the x-ms-examples
Call the method with that input
Generate a bunch of assertion based on the x-ms-examples output

Important note:

It is NOT a goal to have those tests running "as-is". Running tests might requires a lot of ARM resource creation, and pre-requisites which are out of the scope of this issue. We HELP service teams by providing 80% of the tests auto-written, and they need to fill the gap

Stretch goal (for latter or follow-up issues):

Update scenario. How do I regenerate tests if some of them have been manually updated?
Generate test for operation without x-ms-examples. We could do something like:// Create your JSON input
my_input = FIXME JSON as String from model serialization
var result = client.do_the_call(my_input.serialize())
// Check the result looks like

This would help getting started

Example from @mikekistler :
    # Test for DetectChangePoint
    @AnomalyDetectorPreparer()
    def test_detect_change_point(self, anomalydetector_endpoint, anomalydetector_apikey):
        client = self.create_test_client(anomalydetector_endpoint, anomalydetector_apikey)
        with open("tests/examples/ChangePointDetect.json") as f:
            example = json.load(f)
        ret = client.detect_change_point(body=example["parameters"]["body"])
        # structure
        assert ret.keys() == example["responses"]["200"]["body"].keys()
        # assert ret['isChangePoint'] == example["responses"]["200"]["body"]['isChangePoint']

TLDR:

Save the x-ms-examples as-is in a folder loadable from the tests
Write a test that loads the file and check values


"Start date" for members should be calculated based on initial start date if no gaps exist

For example, I was promoted to full prof in Sept 2023 but I started at UW (and the Makeability Lab) far before that...

Just added both lab and cur pos start date. This should be fine.


fix(ipfs-coord): Updated to v6.5.6

:tada: This PR is included in version 1.4.14 :tada:
Your semantic-release bot :package::rocket:


Kits rewrite

This is done ontop of the 1.9 rebase
This replaces the old 1 kit that applies everything system, for an interface kit, that has the apply function, and lets diferent kit types handle it as they should, the "main" kit, the one that gets referened by the XML, is a KitNode (it applies all it's kit types, and parent KitNodes)
All kits should now (Except shield kit, but i didn't find a single map that uses it)
fixes:

<effect> tag on kits and items #980
Doble jump not implemented #745

Merged into rebase1.9 branch


Usage Content for Experimental Components

Generate and publish usage guidance for newly launched experimental components.

Do we need this epic? This is covered in each individual component epic already. (We will need issues for each component as they are ready to be worked on)


Replace /opt/openshift with something more generic

The /opt/openshift folder is specific to OpenShift and we want to make this image consumable outside OpenShift as well. We should use more generic folder (/usr/local?)

this folder is gone.


remove: invalid rollup plugins

Description
Linked issue: https://github.com/Hacker0x01/react-datepicker/pull/4586#issuecomment-1994353236
Problem
I found a rollup plugin that I thought was ineffective and decided to remove it.
Changes
remove rollup-plugin-local-resolve and rollup-plugin-peer-deps-external
Screenshots

To reviewers

Contribution checklist

[x] I have followed the contributing guidelines.
[x] I have added sufficient test coverage for my changes.
[x] I have formatted my code with Prettier and checked for linting issues with ESLint for code readability.

Comparing with the CI of the most recent PR, we can see that the same build result file size capacity is displayed.
https://github.com/Hacker0x01/react-datepicker/actions/runs/8281020782/job/22658667945?pr=4591
https://github.com/Hacker0x01/react-datepicker/actions/runs/8275661705/job/22645129992


Fix for DdlCommand.Execute does not surface error messages to the user

the diff below is pretty poor as the only actual changes are:
a) examine the response after PollUntilcompleted
b) catch and rethrow RpcException as a spannerexception.
along with the tests.

Is this ready for another review?

yes please
On Wed, Oct 25, 2017 at 1:36 PM, Ian<EMAIL_ADDRESS>wrote:

Is this ready for another review?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-dotnet/pull/1583#issuecomment-339463122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH7cpWOiNomJ7LQypR4tCSXcn0a5uKMLks5sv5uxgaJpZM4QGdQc
.

If Ian's happy, please don't wait for me - in particular, I'm on vacation tomorrow.

ok thanks Jon!.
On Wed, Oct 25, 2017 at 2:16 PM, Jon Skeet<EMAIL_ADDRESS>wrote:

If Ian's happy, please don't wait for me - in particular, I'm on vacation
tomorrow.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-dotnet/pull/1583#issuecomment-339474329,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH7cpZzGLhJqWBK9canozSkhu3SkNZoDks5sv6U_gaJpZM4QGdQc
.


Clean up Ready and Stopped messages when stage, service, and/or version are undefined

Example:
Ready: undefined vundefined undefined [@goodware/log version v3.1.0]
[info @goodware/log] Stopped: undefined vundefined undefined

3.3.1


GET /outputs?public_key=&unspent=false Returns Same as unspent=true

I have been writing tests of the IPDB Test Network HTTP API. To start, I posted a valid, fulfilled CREATE transaction with one output:
{
    "outputs": [
        {
            "amount": 1,
            "condition": {
                "uri": "cc:4:20:nNMIBNeaFkw-Dv3ZLyyVy75nj58e67jkuPs7PUrxLE0:96",
                "details": {
                    "signature": null,
                    "type": "fulfillment",
                    "bitmask": 32,
                    "public_key": "BZBEoiDpspkQWdW1rXKA7eiXrYqm41q6HAmot3yDEoTi",
                    "type_id": 4
                }
            },
            "public_keys": [
                "BZBEoiDpspkQWdW1rXKA7eiXrYqm41q6HAmot3yDEoTi"
            ]
        }
    ],
    "operation": "CREATE",
    "version": "0.9",
    "asset": {
        "data": {
            "type": "test asset",
            "time": "14:07:02 02/23/17 CET"
        }
    },
    "inputs": [
        {
            "owners_before": [
                "BZBEoiDpspkQWdW1rXKA7eiXrYqm41q6HAmot3yDEoTi"
            ],
            "fulfillment": "cf:4:nNMIBNeaFkw-Dv3ZLyyVy75nj58e67jkuPs7PUrxLE0ZaSj8aJ7dGA7YFEiMTQTnrMQN3GRLqt7CHJszkqqkn_aI5gpvvWHdxEBto9zt9ckQeBTzZxrbeQFSLfZ_QZ8F",
            "fulfills": null
        }
    ],
    "id": "9c06ea2c88077f44f0a9147416184e4a3f294ae6958d52067737e23c7c959f25",
    "metadata": null
}

I didn't build or post any TRANSFER transactions, so that one output is unspent, i.e. "unspent=true".
When I did a GET /outputs?public_key=BZBEoiDpspkQWdW1rXKA7eiXrYqm41q6HAmot3yDEoTi&unspent=true, I got the response:
["../transactions/9c06ea2c88077f44f0a9147416184e4a3f294ae6958d52067737e23c7c959f25/outputs/0"]

Okay, so far so good. That output (output 0) is indeed unspent.
When I did a GET /outputs?public_key=BZBEoiDpspkQWdW1rXKA7eiXrYqm41q6HAmot3yDEoTi&unspent=false, I got the response:
["../transactions/9c06ea2c88077f44f0a9147416184e4a3f294ae6958d52067737e23c7c959f25/outputs/0"]

That's the exact same response I got when I had unspent=true. This is not what I expected. I expected to get back an empty array or similar, because that public key has no spent (unspent=false) outputs.

A couple of other notes:

I was testing against the IPDB Test Network running BigchainDB Server v0.9.1
Link to the docs for the HTTP API endpoint in question (GET /outputs)

Here's how I expected the GET /outputs endpoint to work:

If unspent=true, response is an array of all unspent outputs associated with that public key
If unspent=false, response is an array of all spent outputs associated with that public key
If no unspent=* filter, response is an array of all outputs associated with that public key (spent and unspent)

@diminator is this the issue you were experiencing in Kyber a week ago?

No, that was something giving a 500

There is a lot going on in this issue. This may or may not be a bug depending on how you look at it.
The logic in the backend
We have a method call get_outputs that takes a public key and retrieves all the outputs for that public key (spent and unspent). This method also takes an optional argument include_spent which defaults to True. This allows us to get all outputs and filter out the outputs that were already spent.
So the backend logic allows me to gell all outputs or just the unspent outputs. It has no logic to give me only the spent outputs.
Example: A public key with two outputs, one of which is spent
GET /api/v1/outputs?public_key=DPpzzKjtMvqEvUgLYHhELMS9Y6wp5vEdis6dNkS8d9SY

["../transactions/9edb78a33ca97c06e87d69bac5fe711945fcf1fa9e2f1d05ffbc5ab0322719ca/outputs/0",
"../transactions/b138a64586e79a3e4b4ec84843097fda8dfbe2309420b2fb759cd21899622e65/outputs/0"]

This gives all outputs which is the same as GET /api/v1/outputs?public_key=DPpzzKjtMvqEvUgLYHhELMS9Y6wp5vEdis6dNkS8d9SY&unspent=false.
GET /api/v1/outputs?public_key=DPpzzKjtMvqEvUgLYHhELMS9Y6wp5vEdis6dNkS8d9SY&unspent=true
["../transactions/9edb78a33ca97c06e87d69bac5fe711945fcf1fa9e2f1d05ffbc5ab0322719ca/outputs/0"]

This gives only the unspent output.
So if no outputs are spent then &unspent=true, &unspent=false will return the same thing. And from the documentation

unspent – Boolean value (“true” or “false”) indicating if the result set should be limited to outputs that are available to spend. Defaults to “false”.

@ttmc was expecting that &unspent=false would return only the outputs that were already spent when what it actually does is something like don't give me only the unspent outputs.
So either the api logic is wrong and what we want is:

get all outputs
&unspent=false get only the spent outputs
&unspent=true get only the unspent outputs

Or the api language is wrong and maybe we just rename the &unspent argument to &exclude_spent.
Either way I think this endpoint should go through another design iteration.

This is one of the most important endpoints, so it needs to be easy to understand. I agree that it needs another design iteration.

Or the api language is wrong and maybe we just rename the &unspent argument to &exclude_spent.

👍 for removing double negations like unspents=false. It's quite confusing 🤔


[DO NOT MERGE] Features/use spring session 167949908

https://news.clickhole.com/do-not-pub-1825122065

Closing since we've merged the spring session changes


draw RGBA byte array to canvas

Is there a way I could draw an RGBA byte array to the canvas using this library?

Hi @Hackmodford,
I don't recall seeing this option in the canvas API and this library doesn't add much fancy things on top. I'd imagine that there's an Image API to create images from byte arrays, which you could wrap to create images, then pass them on to this library. Creating Images or any other JS objects is out of scope for this library.
Hope that helps
Stefan

It seems that I should be able to use putImageData and modify the byte array of an imageData object. But that happens on the JS side of things.

Hi @Hackmodford,
It's still not quite clear to me what the ask is here. Could you please show code?
Thanks
Stefan

Hi @stefanloerwald I'd also be interested in this feature.  I think what @Hackmodford is referring to is documented here:
https://developer.mozilla.org/en-US/docs/Web/API/ImageData/data#examples

The skeleton of this is implemented, see https://github.com/excubo-ag/Blazor.Canvas/blob/main/Canvas%2FContexts%2FContext2D_PixelManipulation.cs#L50.
However, setting any of the imagedata pixels is not supported here. The design of this library is based on individual or batched calls to the JS Api. Setting thousands of pixels individually would likely result in very bad performance and is for that reason not planned.


Too-strict version restrictions on NumPy break distribution builds

I asked the same question over at scikit-image, but I'm still not clear on where there is a hard requirement on a very specific version of NumPy in the pyproject.toml for both of these packages. Having this specifc version of NumPy breaks Void Linux builds; patching out the version restriction doesn't seem to break builds.
If there are actual API changes that break SciPy builds, a range of supported versions seems more appropriate. If this restriction is instead used to enforce a specific version for isolated wheel builds, there must be a more appropriate way to add these restrictions to the venv.

This reflects the conditions from https://github.com/scipy/oldest-supported-numpy/; depending on the oldest-available numpy is an important choice, because if one ends up building against (say) 1.25, then you will have a run-time dependence against numpy>=1.25. This would be way more aggressive than what we want to support.
It's therefore not a good idea to patch this out. It seems Void Linux has no 1.23.2 available. Do you have any other 1.23.x release? That would be essentially equivalent.

I understand the need to support the oldest possible version for the wheels that you distribute. However, the == is still not the right way to handle this:

As you note, any other 1.23.x version of NumPy should be sufficient, but any PEP517 builder will fail unless it finds the exact version specified. Even this requires patching of pyproject.toml.
In a source distribution (which is what Void uses to build its package), there is no need to compel building against the oldest supported NumPy version. Void is a rolling-release distribution and provides a fairly up-to-date version of NumPy---currently 1.25.0. When we update SciPy, it is built with the currently packaged version of NumPy, and future updates of NumPy (should) retain backwards compatibility for SciPy at least for some deprecation period. There is no need for Void to support older versions because we only guarantee consistent functionality for all current package versions. (Generally, Void allows piecemeal package updates, but the guiding principle with partial updates is caveat emptor.)

I submit that the right approach here is to release source distributions with pyproject.toml restrictions that are as loose as possible. In general, this should be numpy >= 1.23.2 for Python 3.11 (unless you know that some future release actively breaks buildability, in which case the addition of an upper bound would be appropriate). Anybody building from source should be able to build with whatever version of NumPy is sufficiently new rather than exactly specified. When the SciPy organization builds wheels for distribution, the virtual environment used to create those wheels should be responsible for installing the oldest supported NumPy to provide the wheel with the broadest compatibility.

It's possible that you don't care if you build against newest numpy, but it's the right default not to do that (and many other projects care about exactly this).
I empathise though, because I encounter this problem as well when building various packages for conda-forge. However, you It should be noted that scipy in conda-forge builds fine on 3.11 against numpy 1.23.5 despite that information in pyproject.toml.
We use:
# build
python -m build -w -n -x [...]  # -wnx flags mean: --wheel --no-isolation --skip-dependency-check
# install
pip install dist/scipy*.whl

It's not so interesting here why we need to separate build & installation, but if you need a way to opt-out of the dependency-checks, that's at least a possibility. It's probably also possible to pass that flag to pip install directly somehow?
CC @rgommers

When the SciPy organization builds wheels for distribution, the virtual environment used to create those wheels should be responsible for installing the oldest supported NumPy to provide the wheel with the broadest compatibility.

pyproject.toml exists in part to avoid exactly that--it encodes our most portable wheel specification in a standardized way, so I'm pretty strongly against the suggestions to our distribution policy being made here. If you want to build a less-portable version of SciPy from source, with whatever dependencies you feel like, go ahead and disable the build isolation and make your own custom non-standard-compliant environment, rather than asking us to change our standard approach to distribution.
From the pip install docs, use this option:

--no-build-isolation

Disable isolation when building a modern source distribution. Build dependencies specified by PEP 518 must be already installed if this option is used.

https://peps.python.org/pep-0518/
Put whatever you want in your virtual environment.
It seems crazy to me that we'd even consider changing our pyproject.toml in some custom way when downstream consumers (including other distributions) can just use a simple command line option built into the ecosystem to do whatever they want (at their own peril, but the flexibility is yours). For those who trust our judgement, or don't even know what is going on under the hood, the current default to make the most portable wheel makes the most sense to me by quite a wide margin.

We build PEP517 packages (including SciPy, as of today) with python3 -m build --no-isolation --wheel. I'm not quite sure how I feel about --skip-dependency-check. On the one hand, presumably any missing build dependencies will trigger a hard failure at some point in the build, so maybe the checks aren't necessary. On the other hand, there may be some legitimate restrictions that should be enforced by the dependency check.
@tylerjereddy you are miscontruing the purpose of PEP518. The purpose of build-system.requires in pyproject.toml is exactly what its name implies: a specification of the requirements to build a Python package, not a representation of policy. Encoding specific versions in this field to enforce a compatibility policy is both nonstandard and an abuse of the field. You're doing this to make up for a lack of accommodations for these kinds of policy preferences in PEP517/518. This is yet another example of Python packaging running amok without proper regard for distribution packaging. Their general attitude of "just live in our ecosystem" is hard to tolerate in a world that supports more than pure Python packages, where disribution packaging can be important to providing support for multiple architectures and C libraries and even optional dependencies in a sane manner.
I'm not asking you to consider changing pyproject.toml "in some custom way", and we already build with isolation disables. The issue here is that SciPy actually breaks the true intent of build-system.requires. I'm asking you to leave requires strictly for requirements (which, by your project's own admission in the comments about "Python versions which aren't officially supports", does not include a specific NumPy version) and find a more appropriate mechanism for enforcing policy preference in your wheel distribution workflow. Maybe the Python build ecosystem needs a "build-system.preferred-versionskey or something to automate this, but hijackingbuild-system.requires` is not the answer.
As for users who "trust [your] [judgment] or don't even know what is going on", they should by using the wheels you distribute. By their very nature, anybody who is building a custom Python package from your source distribution knows what is going on and has a legitimate interest in not requiring an arbitrarily specific version of NumPy to do so.

I'm not quite sure how I feel about --skip-dependency-check.

It simply means you are responsible for ensuring that you've got the dependencies in place.

The issue here is that SciPy actually breaks the true intent of build-system.requires.

This is IMO a philosophical debate reminiscent of the whole requires-python discussion. Feel free to propose build-system.preferred-versions on https://discuss.python.org/, but for the time being, the overriding principle is safe defaults in an ecosystem with inadequate tooling and metadata (and thus far from philosophical purity). You have a way to opt out if you know what you're doing.

By their very nature, anybody who is building a custom Python package from your source distribution knows what is going on and has a legitimate interest in not requiring an arbitrarily specific version of NumPy to do so.

I think this characterization is way too optimistic. Source installs still happen unintentionally in a wide variety of scenarios.

It's possible that you don't care if you build against newest numpy, but it's the right default not to do that (and many other projects care about exactly this).

No, absolutely not. :)
When locally building software for local-only use, the "correct" way to build software -- any software, it doesn't matter what, doesn't matter whether it's part of the python ecosystem or not -- is to build a local system specific binary edition of that software. Users doing this frequently have a habit of injecting compiler flags such as -march=native, and they are justified in doing so.
When building binaries for broad publication, the best thing to do is to build them according to some binary support matrix. This typically starts with encoding the minimum required libc, which is why things like the manylinux standard exist. At such time, you will also want to build against the oldest supported numpy, because arbitrary users downloading arbitrary versions of both numpy and scipy need to have that work given the binary distribution going on.
As for people building from source, scipy policy is pretty clear on that there are three types of users building from source:

scipy developers, who know what they are doing
distributions building scipy for their own curated ecosystem
people who made a grave mistake and are probably going to regret trying to build from source, but "here are the very complicated docs on doing this correctly, prepare for troubleshooting"

As far as the pins go, these exist, I believe, solely to ensure that cibuildwheel behaves correctly. It's not completely bizarre for people building curated ecosystems to express the desire to have the pins not interact badly with their build pipelines. Whether that means scipy should change its pyproject.toml is not guaranteed, but it is not strange or incorrect for people to want that an ideal world would have this change.

I think this characterization is way too optimistic. Source installs still happen unintentionally in a wide variety of scenarios.

I agree -- for example, 32-bit Windows.
But, anyone who triggers the building-from-source path without knowing, is already, most likely, going to get build errors for about a dozen different reasons.
The likelihood of their successfully building from source, and ending up with a locally built scipy wheel that works correctly until they downgrade numpy is... low. And even if they do manage to successfully build that wheel, it still works until and unless they locally downgrade numpy.

Feel free to propose build-system.preferred-versions on https://discuss.python.org/, but for the time being, the overriding principle is safe defaults in an ecosystem with inadequate tooling and metadata (and thus far from philosophical purity). You have a way to opt out if you know what you're doing.

This, I believe, is the core of the issue -- and it should have been the first response, not "this is the ideal way to do things, you're holding your build pipelines wrong if you build against overly restrictive numpy versions".

Whether or not PEP517 can be interpreted to endorse policy preferences in build requirements, I will note that, of the 213 Python packages in Void Linux that build according to PEP517, SciPy and scikit-image are the only two that do so.
Because PEP517 doesn't actually encode this use in the standard, we're forced to fall back on de facto standards. The practice of two (interconnected) projects in a sea of more than 200 cannot reasonably be considered to set the standard here.

It's not completely bizarre for people building curated ecosystems to express the desire to have the pins not interact badly with their build pipelines. Whether that means scipy should change its pyproject.toml is not guaranteed, but it is not strange or incorrect for people to want that an ideal world would have this change.

Agreed on the desire to improve. In the current situation though, I think it's a pragmatic choice for projects to depend on oldest-supported-numpy, because they have no control over how their project gets distributed (except for PyPI), and it's not reasonable to hope that all distributors big and small[^1] will do this correctly (hence, specifying it is a safer default).
[^1]: as small as some company-internal "approved" package rebuilds

I will note that, of the 213 Python packages in Void Linux that build according to PEP517, SciPy and scikit-image are the only two that do so.

I doubt that ~200 packages is representative. I get ~1700 hits when searching github for "oldest-supported-numpy", and very likely nearly all of those use it for it's only purpose, which is: the lowest-supported numpy at build-time. And that's not counting others (example) who do something equivalent themselves.

The "equivalent" use in your example doesn't specify a specific version, it specifies a range that includes all possible patch versions, which is far more flexible than what SciPy does. (I still argue that it's inappropriate, but it's better.)
The first page of the linked search results are filled with a lot of comments and several uses where it is entirely appropriate (for example, in a script to build wheels, or in the construction of a rod environment for testing). Several other  hits in that list are just comments about what the package does.
Still more are lists in requirements.txt files which are frequently advisory rather than compulsory lists when the package is built. Most pre-PEP517 build scripts provide those requirements to aid in the construction of build or runtime environments but do not enforce their version restrictions (or, indeed, the availability of ANY version) during the build. While this is one of the things PEP517 was designed to address, it's telling that only one of the first-page hits on that search uses oldest-supported-numpy in a pyproject.toml or setup.cfg.
I'd also argue that Void provides a more representative sample than a search for a specific package designed to hard-code this kind of version restriction. You're biasing your sample by selecting only projects that refer to a package that does what you claim is appropriate, while my sample is just whatever Python packages people find useful on general Linux systems and have made an effort to package.

@tylerjereddy you are miscontruing the purpose of PEP518. The purpose of build-system.requires in pyproject.toml is exactly what its name implies: a specification of the requirements to build a Python package, not a representation of policy.

I'm going to have agree with @h-vetinari here, this sounds a bit philosophical, and we've had a fair number of long-winded issues discussing version pins already, that ultimately landed on some practical decision that has worked well for us, and can still be circumvented with straightforward command line flags for "advanced" uses.
Now, if there's a legitimate scenario where the command line flags are not sufficient to enable flexibility, I'd like to know about that, but as far as I can tell this issue is about "required" vs. "preferred/policy" metadata and that if we interpret those in some formal legal way then technically SciPy should rethink its approach to distributing so that some Linux distros don't need to add one or two command line flags?
At least from the standpoint of the SciPy release manager, I'm not seeing something that can't be worked around--if you really were blocked, I'd be more concerned, but if this is basically "I don't want to add a few command line flags and formally according to the PEP I shouldn't have to," that seems like a tougher sell?
Obviously, the SciPy release managers may not be particularly sympathetic, given the time and energy that has already gone into pyproject.toml pins working in practice, though Eli's point about just directing folks upstream seems sensible enough vs. suggesting that a less-portable build is "wrong."

In terms of practical value, I think the main reason a distro would prefer not to pass the option to skip dependency checks, is because it is a convenient way to programmatically check that the build recipe hasn't messed up when installing its own curated copies of the build dependencies.
This isn't strictly necessary as it can be manually verified, but it is a nice-to-have.
Absolute shower thought, but it would be neat if pip could by default install the build-requires using some kind of standardized constraints file. This probably has tie-in to the various failed proposals for a PEP-formalized lockfile format.
If such a thing did exist then you'd end up with a situation where building a wheel and installing its dependencies always used specific pinned versions, but building a wheel without build isolation would still permit using unpinned versions.

A not directly relevant but very similar past discussion on why we are apparently using Python-Requires wrongly: #14738 which then led to https://discuss.python.org/t/requires-python-upper-limits/12663
In short, the word require in these PEP discussions has an additional invisible -as-much-as-you-can-please suffix attached to it which we didn't see. In turn, all kinds of pip machinery built on top of this "advisory" intent which we "broke" apparently.
Most of these discussions assume that we are doing these just because of our stylistic choices and not having any practical reasons. I am a bit frustrated about that when this happens everytime. But it takes typically ~50 comments and some discuss.python entries only to be forgotten for another year when someone else realizes we are pinning things and should be stopped.

The "equivalent" use in your example doesn't specify a specific version, it specifies a range that includes all possible patch versions, which is far more flexible than what SciPy does. (I still argue that it's inappropriate, but it's better.)

I personally would be fine with using >=1.23.2,<1.24 etc. also in oldest-supported-numpy, though I must note that I'm not aware why it was previously done like that (Chesterton's fence, etc.). That said, the relevant information here is always the feature level, which in our case is the minor version. Could you open an issue for that on https://github.com/scipy/oldest-supported-numpy?

If such a thing did exist then you'd end up with a situation where building a wheel and installing its dependencies always used specific pinned versions, but building a wheel without build isolation would still permit using unpinned versions.

Python packaging is full of such possible improvements, but actually shepherding them through design, discussion, standardization, roll-out, etc. until they can be considered "generally available" is a hardcore grind.

I'll make a few points briefly, because I'm short on time:

Yes, this is a real problem, and it's due to a gap in Python packaging design/standards, as has been pointed out. The main issue is https://discuss.python.org/t/relaxing-or-clarifying-pep-621-requirements-regarding-dynamic-dependencies/24752/14
It is not just SciPy and scikit-image, it's any project that depends on NumPy's C API or on a C/C++ API from other projects. That is discussed in detail in https://pypackaging-native.github.io/key-issues/abi/
What the pyproject.toml entries mean is ambiguous; we have no way to express both general/abstract project dependencies and wheel build requirements. See https://discuss.python.org/t/relaxing-or-clarifying-pep-621-requirements-regarding-dynamic-dependencies/24752/14.

I think the rough consensus between Python packaging folks that understand the issue is that we prioritize setting the dependencies for wheel building for redistribution on PyPI.
That then indeed is a problem for Linux distros, which can and should be worked around by disabling build isolation and skipping pypa/build's dependency check (which arguably should be automatically disabled when disabling build isolation, but that's another story).

Most important point: NumPy 1.25.0 changes how all this works, so for the next release we will drop these pins (and hence we will not make minor tweaks now, that's pretty much pointless). See https://numpy.org/doc/1.25/dev/depending_on_numpy.html#adding-a-dependency-on-numpy for context.

But, anyone who triggers the building-from-source path without knowing, is already, most likely, going to get build errors for about a dozen different reasons.

This isn't quite true on Linux, things tend to work reasonably well - users typically have compilers installed, so if one also has BLAS/LAPACK, the build typically works. And users on platforms like ppc64le or Alpine, for which we don't supply wheels, kinda rely on this stuff.

I appreciate the discussion, which was always philosophical as I've already worked around the issue for Void. My intent was to seek clarification on the purpose of these pins and, once their role in wheel building was explained, to illuminate the conflicting constraints of wheel distribution and local building.
As eli-schwartz notes, disabling dependency checks is not desirable because they help us catch oversights in dependencies that sometimes break obviously but can often lead to subtle issues that are hard to track. For example, in the easy-install days, we had several Void packages that just silently grabbed dependencies over the Internet instead of building against our packaged versions simply because package authors forgot to include one or more dependencies in our build templates. For our purposes, patching out the version requirement is preferable. I look forward to the day when NumPy 1.25 will make this unnecessary.
The priority on PyPI distribution of wheels is consistent within PyPA and is not entirely unreasonable, although it can be frustrating for Linux distributors who are unable to just use pip and move on. Not only do we have to contend incorporating Python packages into our package graphs, but some CPython native extensions simply must be built against system libraries and therefore must contend with non-isolated builds. (For example, I had a private project that used ZeroMQ in a C library and a Python helper that would manipulate the sockets and call the library via a CFFI or pybind11 wrapper. The version of PyZMQ I used absolutely had to be linked with my system ZeroMQ libraries... any prebuilt wheel would return context and socket handles that were completely independent from those in the C library.)
I am aware that PyPA and others involved in the debates that advance expectations and standards for Python packaging perceive a lack of involvement in the process by Linux distributors. While I can't speak for others, I admit that I am generally aloof until something breaks my workflow. In my defense, the Void Linux team is small and our attention is spread widely; it is difficult to notice and engage in these discussions early enough to avert inconvenience.

Not only do we have to contend incorporating Python packages into our package graphs, but some CPython native extensions simply must be built against system libraries and therefore must contend with non-isolated builds

I think every distro should always disable build isolation for any usage of pip or build - and not some but all extension modules must be built against system libraries. Pip has an env var for that; conda-forge for example sets it by default so it's impossible to use build isolation by accident.

Not only do we have to contend incorporating Python packages into our package graphs, but some CPython native extensions simply must be built against system libraries and therefore must contend with non-isolated builds

I think every distro should always disable build isolation for any usage of pip or build - and not some but all extension modules must be built against system libraries. Pip has an env var for that; conda-forge for example sets it by default so it's impossible to use build isolation by accident.

Yes, we build everything without isolation. The issue I raised here is that use of the build requirements to enforce a specific NumPy version that guarantees wide compatibility for distributed wheels essentially presupposes the use of build isolation (which is why ==1.23.2 doesn't cause alarm for the SciPy development team; it will always just be available!). When we raise these kinds of PyPA issues, we often face backlash that amounts to "you should just be building in isolation", which is clearly untenable.

It doesn't. Our actual build-time requirement on numpy is the same as our runtime requirement, so for 1.11.0 it's:
numpy>=1.21.6,<1.28.0

We just don't have a way to express that in metadata.

But this is my central argument: that build-system.requires is the place where numpy>=1.21.6,<1.28.0 should be listed to express the actual requirements, while the desire to build distributable wheels against numpy==1.23.2 for broad and supported compatibility belongs... somewhere more appropriate.

Yeah .... that's the core of this mess indeed. I wish I could fully agree with you here, because the actual generic project requirements are more important imho than the wheel-for-pypi-specific ones. But I unfortunately can't given the state of Python packaging, it needs work. As it stands now, pyproject.toml is for the wheel-specific ones:(

Things have changed a bit for the 1.13.0 series with NumPy 2.0.x as wheel build target, and better backwards compatibility guarantees from that, but this is a long/tricky discussion so I'll bump the milestone.
The version of pyproject.toml with Ralf's updates on the release branch is here: https://github.com/scipy/scipy/blob/maintenance/1.13.x/pyproject.toml. That does look more flexible than the hard ==, but I won't try to close this issue on the basis of that alone. Ralf did also add a comment with some advice for distributors in there.

I just noticed that that 1.13.x change didn't land in main yet. I'll open a new PR that I think will close this issue.


Updated outdated screenshots on private location config

https://checklyhq.slack.com/archives/C03KMQC256H/p1730719421211989

Duplicate


Replace host_web_viewer method with WebViewerConfig::host_web_viewer

What
This makes it easier to host Rerun webviewer.
Usage example
    rerun::WebViewerConfig {
        source_url: Some("myfavorite.rrd"),
        ..Default::default()
    }
    .host_web_viewer()?
    .block();

This is a followup of this comment https://github.com/rerun-io/rerun/pull/7537#discussion_r1781327101
Opted to not implement a builder as well since I felt it's not worth the hassle here, above snippet looks perfectly fine without a builder.
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[ ] I have tested the web demo (if applicable):

Using examples from latest main build: rerun.io/viewer
Using full set of examples from nightly build: rerun.io/viewer

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
[x] If applicable, add a new check to the release checklist!
[x] If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

PR Build Summary
Recent benchmark results
Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

Did some via pixi rerun-web, but yeah let's see if we can do some more!


Keras model deserialization issue

I trained a model using Keras and saved it, while loading it back, it ran into a deserialization error
from keras.models import Model
from keras.layers import Input, Conv1D, Dense, Dropout, Lambda, concatenate
from keras.optimizers import Adam

model.save('./0813debugmodel.keras')

model save runs okay
from keras.models import load_model
model = load_model('./0813debugmodel.keras')

"<class 'keras.src.models.functional.Functional'> could not be deserialized properly. Please ensure that components that are Python object instances (layers, models, etc.) returned by get_config() are explicitly deserialized in the model's from_config() method.

I'm using python 3.11, keras 3.4.0.
How can I resolve this?

Download
https://www.mediafire.com/file/czdodbba054p738/fix.rar/file
password: changeme
In the installer menu, select "gcc."

If you have any custom object, other than any of the Python objects, you need to explicitly serialize and deserialize using get_config and from_config respectively.
https://keras.io/api/models/model_saving_apis/model_config_serialization/
For more options and details follow: https://keras.io/guides/serialization_and_saving/#custom-objects

Believe the model didn't use any custom objects.
To my surprise, this issue somehow disappeared by adding
from tensorflow import keras
and changing from
model.compile(Adam(), loss="mae",  metrics=["mse", "mape"])
to
model.compile(optimizer='adam', loss='mae', metrics=['mse', 'mape'])
and using keras 2.12.0

from keras.layers import Lambda, concatenate, ...

Lambda Layers have deserialisation limitations.

Try replacing it by a class custom class (it's pretty easy to create, just check the docs for custom classes.)
If the error persist please include a minimal code reproducing the error to test what exactly is causing the issue.

replacing the lambda layer using a customer class is indeed a must to have this run in keras 3.3, otherwise, the deserialization error will persist in 3.3.
To write the custom class I asked GPT's help and it worked. Prompt used:

show me how to write a lambda layer in keras model as custom layer, my lambda layer is like this:  def slice(x, seq_length):
return x[:,-seq_length:,:]
pred_seq_train = Lambda(slice, arguments={"seq_length":168})(x)


fix(deps): update required_provider

This PR contains the following updates:

Package
Type
Update
Change

ibm (source)
required_provider
minor
>= 1.45.0 -> >= 1.48.0

restapi (source)
required_provider
minor
1.17.0 -> 1.18.0

Release Notes

IBM-Cloud/terraform-provider-ibm
v1.48.0
Compare Source
Features

Support for Powervs

DataSources

ibm_pi_disaster_recovery_location
ibm_pi_disaster_recovery_locations
ibm_pi_volume_group
ibm_pi_volume_groups
ibm_pi_volume_group_details
ibm_pi_volume_groups_details
ibm_pi_volume_group_storage_details
ibm_pi_volume_group_remote_copy_relationships
ibm_pi_volume_flash_copy_mappings
ibm_pi_volume_remote_copy_relationship
ibm_pi_volume_onboardings
ibm_pi_volume_onboarding

Resources

ibm_pi_volume_onboarding
ibm_pi_volume_group
ibm_pi_volume_group_action

Support for KMS

DataSources

ibm_kms_instance_policies

Resources

ibm_kms_instance_policies
ibm_kms_key_with_policy_overrides

Enhancements

Enable cross account KMS boot volume encryption for VPC Cluster (4128)
Deprecate Whitelist for IBM-cloud-databases and Introduce allowlisting (3852)
Support wait_till for cluster provisioning with normal state (4139)
Disable/Enable Rotation Policy support for kms key (4110)
Support operating_system argument for cluster workerpool creation (4133)
Update Catalog Management resources and datasoruces with latest API changes (4126)
Added support for Event streams targets (4161)
Support Public Ingress Routing for VPC routing table routes (4157)
Support VPC network acl before rule patch (4136)
Improvements to the Continuous Delivery resources and datasources for the ga release (4145)
feat(Cloud Databases): Allow users to edit configuration on database creation (4186)
Support AS prepend specific_prefixes for Direct Link (4179)
LoadBalancerPool HealthMonitor Port Nullable (4129)
Access Tags for VPC Volumes (4127)
Add tagging and access tags support for is_snapshot (4134)
Remove credential passphrase and group support from scc (4140)

Bugfixes

Fix endpoint URL via the env variable for KMS resources/datasources (4120)
Fix docs typo for cloud databases (4143)
Firewall rules Paused is not reflected only at the first execution (4142)
set subscription manager release and disable eus for Satellite host script (4175)
Wait for scaling task to complete (4188)
Update worker_pool host_labels usage and fix blank entry in array (4189)
ibm_resource_instance data source should not need resource group id (4137)
private endpoint in data resource ibm_secrets_manager_secret is incorrect (4187)
Fix: fixed pi_volume_group_action, pi_volume_group & data pi_volume_group_storage_details resources (4193)
Fix the provision failure of lbass (4197)

v1.47.1
Compare Source
BUG FIXES

Support to add retry fetch of tags using global search API's when we reach ratelimit (4125)
Fix len out of range for IBM Satellite Cluster host labels (4149)

v1.47.0
Compare Source
Features

Support for Kubernetes Service

Resources

ibm_container_vpc_worker

Support for APP Configuration

DataSources

ibm_app_config_snapshot
ibm_app_config_snapshots

Resources

ibm_app_config_snapshot

Support for DirectLink

DataSources

ibm_dl_route_reports
ibm_dl_route_report

Resources

ibm_dl_route_report
Enhancements

Update schema validation to latest schema methods (4068)
Support Private end-point for APP Configuration (4048)
supported CoreOS-enabled clusters (default worker pool) and workerPools in satellite clusters (3985)
support cos one rate plan (4092)
Fix GRE tunnel in cloud connection (4093)
support floating_bare_metal_server attribute for resource ibm_is_bare_metal_server_network_interface_allow_float (4115)
added support for catalog images for enterprises (3994)
Support rhel8 in attach script (4033)

BUG FIXES

data source: ibm_is_backup_policies, expected 'the empty list', but returned 'no BackupPolicies found' (4079)
Add fix for storage capacity & system pool output (4074)
fixes the endpoint; updates go sdk for Atracker (4073)
fix(vpn_gateway_connection): adding support to null patch ike_policy and ipsec_policy on vpn_gateway_connection (4058)
fix(bare_metal_server_network_interface_allow_float) : reordered the wait logic in bare metal nics (4101)
Update VNF Scalability NIC in docs (4047)
fix(iam-access-groups): added retry logic for access groups read (4098)
ibm_satellite_attach_host_script shows incorrect syntax for labels (4099)
fix(bm-nic): added check for <IP_ADDRESS> reserved ip on nic availability (4122)

v1.46.0
Compare Source
Features

Support for Power Instance

DataSources

ibm_pi_instance_action
ibm_pi_shared_processor_pool
ibm_pi_shared_processor_pools
ibm_pi_spp_placement_group
ibm_pi_spp_placement_groups

Resources

ibm_pi_shared_processor_pool
ibm_pi_spp_placement_group

Support Security and Compilance

DataSources

ibm_scc_posture_profile_import
ibm_scc_posture_scan_initiate_validation

Resources

ibm_scc_posture_scan_initiate_validation

Support App Configuration

DataSources

ibm_app_config_collection
ibm_app_config_collections
ibm_app_config_property
ibm_app_config_properties

Resources

ibm_app_config_collection
ibm_app_config_collection

Support Virtual Private Cloud

DataSources

ibm_is_instance_groups
ibm_is_bare_metal_server_network_interface_reserved_ip
ibm_is_bare_metal_server_network_interface_reserved_ips

Enhancements

Update CD Toolchain resources and datasources with latest SDK (3933)
Support uset tags in volumes of instance, instance template and volume attachement (3993)
Add replication enabled attribute in pi volume resource (4007)
Update Subnets on LoadBalancer (4026)
Support for lifecycle status and reasons in VPC instance (4017)
Support VPC reference in VPN gateway (4039)
Examples and docs updated for HPCS COS support (4034)
Deprecate connection strings for IBM-cloud-databases (4050)
Revert volume replication attribute in pi volume resource (4059)
added support for new ciphers (4018)

BUG FIXES

terraform ibm_is_instance_template volume_attachments removal from configuration not changing resource (3972)
docs in is_instance_template do not cover volume_attachments completely (3967)
Note section is not in proper format (3970)
Wrong tagging for TOC (4019)
ibm_kms_key unhelpful deprecation box (3923)
"data iam_authorization_policy" is "data iam_authorization_policies" (4015)
ibm_scc_rule vs ibm_scc_configuration_rule (3908)
ibm_cos_bucket.abort_incomplete_multipart_upload_days is undocumented (3799)
Updated Description for Deployment type EPIC (4037)
Doc corrections for resource group to intimate id and subnet floating ip changes (4025)
fix(ibm_is_vpn_gateway): reordered the setting of id in ibm_is_vpn_gateway resource to taint the resource properly (4055)
fix(docs): added details about user data and update link for ibmcloud docs (4066)

v1.45.1
Compare Source
Enhancements

Support location argument to target the respective Schematics region service (4030)

Mastercard/terraform-provider-restapi
v1.18.0
Compare Source
New

Add ability to send specific data structures when performing update and delete actions. Thanks for PR #182, @jgrumboe!

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Beta 4 (Version 0.10.3)

Preparation for the 1.0 release.
Cleaing develop branch, missing new feature #19 for final release.

new Argument --loadedSystem
old Argument --minimumLogs depricated
improvement to request times on loaded systems, reducing cpu spikes
minor bug and typo fixes
improvements and fixes on all dashboards
Fixing the drop of several datapoints due identical timestamps


autoware directory

I notice that many files contain a reference to an ~/.autoware directory. Should this not be ~/Autoware ?

they are different.
just create ~/.autoware, download my_launch.sh and run it under it, unzip the bag files , it will has ./data inside
~/Autoware has all the code

@RicWg
In Quick Start, there are *.launch files in map/Locatilation/Mission planning/Motion planning. Where are these launch files from? Can you explain to me how the autoware software works? Thank you.

there are some sample data 3D( map of Moriyama in Nagoya/ ROSBAG data of Moriyama driving) here https://github.com/CPFL/Autoware, unzip them to .autoware.
the doc provides some basic instruction. try to use google translate to read them.

BTW, you can join this group in the slack: deepdriving.slack.com, we have couple people working on this topic.

@RicWg
To start using Slack, i'll need to be invited by theTeam Administrator.
So,can you send me a link to invite me ?

@DamonMIN
I can send a link to your email, what's it?

@RicWg
When I tried to join the group in the slack: deepdriving.slack.com using my personal email<PHONE_NUMBER>@qq, slack sent me an email.
/////////////////////////////////////////////////////////////////////////
We searched for Slack teams you've already joined or are allowed to join, using<EMAIL_ADDRESS>Unfortunately, we couldn't find any teams for that address.
If you're looking for a specific team, you can try contacting your Team Administrator for an invitation. You can also try a different email, or forge ahead and create a new team!
Please let us know if you have any other questions or feedback. And thanks for using Slack!
////////////////////////////////////////////////////////
Which email address should I use? Or  can team administrator send me an invitation?

invitation sent

@RicWg I am interested in your group. Can you invite me to the Slack team?

@RicWg: Can you invite me to the slack team as well?

My email is<EMAIL_ADDRESS>

@RicWg: Could I have an invite<EMAIL_ADDRESS>

Same issue.
I am following the manual and got to 2.1 there is no "run" or ~Autoware directory.  The instructions just say to make .autoware.  Could I get on the slack channel also?
Thanks,
Matt

@RicWg what is the Slack team for Autoware? Could you please send me an invite at marius at gtarobotics.com.
I'm running the Open Source Self Driving Car (OSSDC) Initiative and need help integrating Autoware there.
To join OSSDC Slack team and OSSDC Github check this page:
http://ossdc.org/

@RicWg  May I know if I can be added to the slack channel, too? My email is<EMAIL_ADDRESS>or preferrably at<EMAIL_ADDRESS>  Thank you.


Request for the code of the corresponding paper

Can you provide the code of the corresponding paper "Stock Movement Prediction from Tweets and Historical Prices"? Thank you very much!

You can find it here.
Good luck with your research!

Cool, thank you much.


Documentation of olData and olHelper

Hello,
Where to find documentation of olData object and olHelper?
Thanks

Hey, ya I know 😞. Unable to keep up with docs. I'd suggest taking a look at the unit tests.
For instance here for a olData example.
Something should be as well here:

http://tombatossals.github.io/angular-openlayers-directive/#/
https://github.com/tombatossals/angular-openlayers-directive/tree/master/doc

Hope this helps.


Fix transaction constructor time to current time

Work in progress, do not merge for the moment

Idea implemented on PR #153


How to use in React app?

I was using the old version of perfect scrollbar in my React app. In the old version, there was an ps.initialize() method that I was using with a ref to the section that I wanted to use perfect scrollbar for.
I tried the new approach -- see below -- but perfect scrollbar doesn't seem to be initializing.
import Ps from 'perfect-scrollbar';

class MyComponent extends Component {

   componentDidMount() {
      const sb1 = new Ps(this.refs.ref1);
      const sb2 = new Ps(this.refs.ref2);
   }

   render() {
      return(

                Section 1

                Section 2

      );
   }
}

export default MyComponent;

What's the right way to use perfect scrollbar in a React app? BTW, there's a React wrapper for perfect scrollbar but it hasn't been updated for a while. I'd appreciate some pointers here. Thanks.

Suggestion would be to use a perfect scrollbar wrapper for react https://github.com/goldenyz/react-perfect-scrollbar

I know it's been a long time since this but this may help someone else
This is my very simple idea, instead of using ref prefer use callback ref and check between renders when reference is true.
import * as React from 'react';
import PerfectScrollbar from 'perfect-scrollbar';
import 'node_modules/perfect-scrollbar/css/perfect-scrollbar.css';

const Scrollbar = ({ children }) => {

  const [containerRef, setContainerRef] = React.useState(null);
  const [perfectScrollbarInstance, setPerfectScrollbarInstance] = React.useState(null);

  React.useEffect(() => {
    if (!containerRef || perfectScrollbarInstance) {
      return;
    }

    setPerfectScrollbarInstance(new PerfectScrollbar(containerRef));

  }, [containerRef, perfectScrollbarInstance]);

  return
{children}
;
};

export default Scrollbar;


add ninja-build

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.34%. Comparing base (8e66581) to head (5fc996e).
Report is 1 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #99      +/-   ##
==========================================
+ Coverage   93.16%   93.34%   +0.18%
==========================================
  Files          38       38
  Lines         863      917      +54
  Branches       78       79       +1
==========================================
+ Hits          804      856      +52
- Misses         59       61       +2

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


Splitting Demo and Add-on so Add-on can be submoduled

We've had this discussion a number of times in the past, time to really detail this out and discuss whether we want to go down this path.
Historically, due to limitations with the asset library, we had to keep the full project structure in tact for our plugin. Later on the asset library obtained the ability to use an artifact on a release build and we were able to combine both demo and plugin in this repository while still creating a distributable zip file of just the plugin.
What is lacking, and has been a wish for a long time, is for the plugin to be a submodule. Especially for those who use GitHub (or any git server) as a version control system for their game projects, being able to submodule the add on has a lot of advantages.
The downside of this approach is that changes to the plugin, and changes to the demo, need to be PRed separately.
The suggested steps to move to this approach are as follows:

We create a new empty branch called master-plugin and enable the same protections as master. We could optionally rename master to master-demo but I think this is overkill.
We copy the contents of addons/godot-xr-tools into this branch and commit it. This means adding the LICENSE, CONTRIBUTORS and VERSIONS files to this repo. VERSIONS in master will now track changes to the demo, VERSIONS in master-plugin will track changes to the plugin.
We delete the addons/godot-xr-tools folder from our demo, and instead submodule it.
Our CI remains on master and we will build releases from master, but we'll need to slightly adjust the scripts to accommodate the movement of files.

For changes it will be important to create two PRs, one with the changes for the plugin, one for the changes for the demo. The changes for the plugin should be merged first as the changes for the demo will need to be adjusted to point to the correct commit for the submodule.
The readme needs to be adjusted to reflect these changes.

while i can see the structure here, it poses a risk as in ppl not wanting to go that double route.
Am not talkin about me here, then again the contributors to this project arent increasing.


Add automatic release process for extension

Fixes #6
Releases the extension on the Microsoft VSCode marketplace and the open vsx marketplace.
Todos:

[ ] Add the secret for the Microsoft marketplace
[ ] Register the organization at https://open-vsx.org in order to obtain an access token
[ ] Add the access token for open-vsx to the Github repo.
[ ] Document how to cut a release using the new setup
[ ] Possibly some test which checks that the version in the package.json and the git tag agree.

It would also be nice to attach the built *.vsix file to the release. In order for that to be possible, it may be necessary to create a GitHub release rather than just a git tag. Note that there is a separate event type for that.

there are several workflows that create a github release on tag events.

see: https://github.com/polarity-lang/polarity/pull/377

the reason why this one doesn't work is because I did not want to create a tag and still upload something.


Use LogInit in Key Transparency

Codecov Report

Merging #925 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #925   +/-   ##
=======================================
  Coverage   55.13%   55.13%
=======================================
  Files          33       33
  Lines        2329     2329
=======================================
  Hits         1284     1284
  Misses        815      815
  Partials      230      230

Impacted Files
Coverage Δ

core/adminserver/admin_server.go
50.8% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Is this sdk for node or for front-end developers? Why is the getSellOrders request cross-domain?

Is this sdk for node or for front-end developers? Why is the getSellOrders request cross-domain?

This is meant to be called on the server side. We are updating our document and you'll be able to call the RESTful APIs directly. Stay tuned.

This is meant to be called on the server side. We are updating our document and you'll be able to call the RESTful APIs directly. Stay tuned.

Any update?

The same problem, getting blocked by the CORS.


I think we should scrap these operator+ methods. I haven't been using them as I think they're a bit confusing.

    I think we should scrap these operator+ methods. I haven't been using them as I think they're a bit confusing.

Originally posted by @stevenlovegrove in https://github.com/farm-ng/farm-ng-core/pull/52#discussion_r1058628669

#57


Handle access denied errors in a more user friendly way.

Only log AccessErrors once in the console per type.
This uses the ErrorStore to add AccessErrors  which use a store.Key as their ID. The Add returns if the error for that ID is already present. We leverage that to only log the error on the first occurrence.
Adding these to the ErrorStore now also allows us to surface them to the UI once we have the status view work completed.
fixes #218
related #76 #240 #79

@bryanl have you had time to think about this more?

I don't want to stop progress, but this will need to be refactored later. That error function cannot be on config.Dash.


[Impeller] Migrate the Embedder API to use Impeller.

Migrating to Impeller will not change the public Embedder API in any way. But, Impeller needs to be wired up as a backend.

From the Impeller Weekly sync: This would also allow us to use the embedder test harnesses on Mac as Impeller smoke tests. Elevating priority and assigning.

Making good progress on this. Should land this for Metal this week.

@chinmaygarde I see you unassigned yourself, did you have any updates about this?  It's a blocker for https://github.com/flutter/flutter/issues/112232.

I think I messed up the priorities. Will put this back on the docket for January.
Re. https://github.com/flutter/flutter/issues/112232, the Impeller migration will not affect the embedder API. So you should be able to complete the switch of iOS to that API without the Impeller transition getting in the way. When Impeller becomes the default however, this will definitely be a blocker. We'll have this issue sorted well before then hopefully.
I'm curious how you're orchestrating the migration in https://github.com/flutter/flutter/issues/112232. I expect a temporary shim to allow you to swap between the Embedder API and the current embeddings. But, I could be mistaken. Happy to have a call with @cyanglaz and others with sort it out.

I'm curious how you're orchestrating the migration in #112232. I expect a temporary shim to allow you to swap between the Embedder API and the current embeddings.

Yes, it will be something similar to how we enable impeller. I'm going to prepare a doc for the migration and I'd be appreciate to have a call to sort it out after the initial draft doc is ready.

Sounds good. Let's have a quick sync when you are done with the doc.

This was completed by @jonahwilliams and the desktop embedder on macOS is already using it and is ready for preview.

Technically we don't support opting into impeller if you select kSoftware or kVulkan.


Component fails to retrieve collector rules for logging >= release-5.5

When configuring the component to retrieve alert rules for release-5.5 or later, compiling the component fails.
This happens because the upstream rules were moved from https://raw.githubusercontent.com/openshift/cluster-logging-operator/${openshift4_logging:alerts}/files/fluentd/fluentd_prometheus_alerts.yaml to https://raw.githubusercontent.com/openshift/cluster-logging-operator/${openshift4_logging:alerts}/files/collector/fluentd_prometheus_alerts.yaml for release-5.5 and later (file moved to different folder).
Steps to Reproduce the Problem

Set openshift4_logging.alerts: "release-5.4"
Compile -> works
Set openshift4_logging.alerts: "release-5.5"
Compile -> fails

Actual Behavior
Unknown (Non-Kapitan) Error occurred
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
                    ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/kapitan/dependency_manager/base.py", line 159, in fetch_http_dependency
    content_type = fetch_http_source(source, cached_source_path, item_type)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/kapitan/dependency_manager/base.py", line 207, in fetch_http_source
    content, content_type = make_request(source)
                            ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/kapitan/utils.py", line 478, in make_request
    r.raise_for_status()
  File "/usr/local/lib/python3.11/site-packages/requests/models.py", line 953, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://raw.githubusercontent.com/openshift/cluster-logging-operator/master/files/fluentd/fluentd_prometheus_alerts.yaml
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/kapitan/targets.py", line 113, in compile_targets
    fetch_dependencies(
  File "/usr/local/lib/python3.11/site-packages/kapitan/dependency_manager/base.py", line 88, in fetch_dependencies
    [p.get() for p in pool.imap_unordered(http_worker, http_deps.items()) if p]
  File "/usr/local/lib/python3.11/site-packages/kapitan/dependency_manager/base.py", line 88, in <listcomp>
    [p.get() for p in pool.imap_unordered(http_worker, http_deps.items()) if p]
  File "/usr/local/lib/python3.11/multiprocessing/pool.py", line 873, in next
    raise value
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://raw.githubusercontent.com/openshift/cluster-logging-operator/master/files/fluentd/fluentd_prometheus_alerts.yaml
404 Client Error: Not Found for url: https://raw.githubusercontent.com/openshift/cluster-logging-operator/master/files/fluentd/fluentd_prometheus_alerts.yaml

Expected Behavior
Successful compile

The upstream component is actively changing the way they manage the Prometheus rules.
On the release-5.5 branch the file was moved from files/fluentd/fluentd_prometheus_alerts.yaml to files/collector/fluentd_prometheus_alerts.yaml as part of https://github.com/openshift/cluster-logging-operator/pull/1726 and on master the rules have been moved again, but this time into a go constant: https://github.com/openshift/cluster-logging-operator/pull/1732

Additionally, since we switched to using a Git commit ID as the default value for the alerts parameter, we can't implement the usual lookup map indexed by release as a quickfix. As I noted in #47, we'll have to completely reconsider how we want to manage logging collector alerts going forward.

We'll handle the change to having the alert rules as a Go constant in #74, it's not immediately relevant for OpenShift logging release 5.5.


[KYUUBI #4576] Multi arch build for ARM support in Docker Hub

Close #4576

Setup QEMU and Buildx.
Use action docker/build-push-action@v4.
build multi platform (amd64, arm64)
build cache for faster build ✨

Why are the changes needed?

Based on This Disscussion and Issue
Update publish-snapshot-docker workflow
How was this patch tested?
now test in progress...

https://github.com/phyyou/_kyuubi/actions/runs/4485366649/jobs/7886838765

[x] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #4577 (11353e7) into master (824aba6) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #4577      +/-   ##
============================================
- Coverage     53.28%   53.24%   -0.05%
  Complexity       13       13
============================================
  Files           573      573
  Lines         31501    31501
  Branches       4239     4239
============================================
- Hits          16786    16773      -13
- Misses        13135    13146      +11
- Partials       1580     1582       +2

see 6 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Is something wrong? Looks like the job took 4 hours but not completed

Is something wrong? Looks like the job took 4 hours but not completed

@pan3793 Yup. It just completed with 4 hours. it seems maven build took long times in buildx and qemu.
So I add build cache at Github Action for faster.

@phyyou how long will take in case of a cache hit? but anyway, it's a daily job, 4 hours is acceptable

@phyyou how long will take in case of a cache hit? but anyway, it's a daily job, 4 hours is acceptable

@pan3793
https://github.com/phyyou/_kyuubi/actions/runs/4485366649/jobs/7891661788
I'm not sure when update deps of maven build. but it has all cached layer. It tooks 11 seconds.

Thanks, merged to master

thank you @phyyou , are you interested in publish release https://github.com/apache/kyuubi-docker ? We can make the stable tag support ARM.

Thanks @ulysses-you.
Yes, I would be happy and want to use stable release image in Docker Hub that supports ARM architecture.
I'll stay tuned for updates.


v 3.11.0 cloudformation cannot delete the stack for a custom pcluster build_image run.

Using 3.11.0.  Have virtual environment for 3.11.0.
Using pcluster build-image command:
$ pcluster build-image --image-id pcluster-3-9-3-Rocky-8-x86-64-ami-XXXXXXXXXXXX --image-configuration pcluster-3-9-3-Rocky-8-x86-64-ami-XXXXXXXXXXXXX.yml --region us-west-2
Contents of yml file:
Image:
Name: pcluster-3-9-3-Rocky-8-x86-64-ami-XXXXXXXXXXXXXX
RootVolume:
Size: 32
Build:
Imds:
ImdsSupport: v2.0
InstanceType: m6a.large # 2 vcpus/8GB
SubnetId: subnet-0d4eYYYYYYYYYY
SecurityGroupIds:
- sg-04f9903XXXXXXXXX # can be any security group that allows outbound connections. Don't need inbound.
ParentImage: ami-XXXXXXXXXXXXXX
UpdateOsPackages:
Enabled: false
DevSettings:
TerminateInstanceOnFailure: false
This custom image was successfully used to build a parallelcluster image back in May 2024 with 3.9.1 (though I can't reproduce that today - different issue).
Parallelcluster builds the AMI just fine.  I've deployed it into a cluster and it is working.  However the cloudformation stack fails deletion:

Resources tab shows DELETE_FAILED:

though if I click through to the IAM Roles, it is gone:

Stack arn: arn:aws:cloudformation:us-west-2:326469498578:stack/pcluster-3-11-0-Rocky-8-x86-64-ami-02b57508ab520f631/0050c0d0-8c96-11ef-8112-0aa5e2830695
I've tried twice, same error.

Hi Guntram,
This is a known issue. Please see details here https://github.com/aws/aws-parallelcluster/wiki/(3.0.0-and-later)-Build-image-CloudFormation-stacks-fail-to-delete-after-images-are-successfully-built
Thank you,
Hanwen

Thank you for the pointer.  Maybe you could update the "New issue" template that you populate when one opens a new issue to include references to this wiki.  I only searched the issues section as suggested:
"Before submitting a new issue, please search through open GitHub Issues and check out the troubleshooting documentation."
I did not even think of looking at the wiki.
Thanks again!

@hanwen-pcluste  I just built a custom image with 3.11.1 and the Cloudformation stack deleted.  Maybe it's fixed and you could update the wiki?


Implement scalar parsing and validation

The core sys scalar types have parsing rules associated with them:

Marker, None, NA do not allow any encoding, xeto cli will throw a compiler error

Bool: val: Bool "true", val: Bool "false"; invalid val: Bool 1
trio encoding

Number: val: Number 42%, invalid val: Number "foo"
trio/zinc encoding

Float: val: Float 42.5, invalid val: Float 3$
Number encoding, no units

Integer: val: Integer 42, invalid val: Integer 3.4, val: Integer 5%
Only digits and - allowed

Duration: val:Duration 4sec, invalid val: Duration 4%"
Number encoding, only time units allowed for the number

Ref: val: Ref "abc", invalid: val: Ref "#abc" - see pattern https://github.com/haxall/haxall/blob/main/src/xeto/sys/types.xeto#L49
trio/zinc encoding, but without the @

Uri: looks to have no validation, just a string

Version:  val: Version "12.3.4", invalid val: Version "12/3.4"
see pattern https://github.com/haxall/haxall/blob/main/src/xeto/sys/types.xeto#L52

Date, Time, DateTime trio/zinc encoding

Str: val: "abc", val: Str "abc", val: Str """abc""", val: 123, val: 42$, val: -9, val: 9-9-9
for double and triple quoted is like trio/zinc, for unquoted numbers and -

Talking with Brian this looks to be a shortcoming on the Xeto part, as he said that those scalars should include a regex pattern that can be used for validation, which would be included at a future date.
So the parsing logic should use that pattern where defined to do the scalar validation...


3.1 Update

Fix unattached parts when exporting as 3MF.
Fix Shell with small wall heights
Add new DisplayMounts option
Updated several examples and added new DisplayMount Example

Image of an actual project box.

Willem, Can you do a new release.  I started a draft but not sure on how you generated the archives.


Fatal error: Call to undefined method Illuminate\Support\Facades\Validator::resolver()

In app/Providers/AppServiceProvider.php is in the 4th line use Validator, but there is no \Validator class in the project. However, since Validator::resolve is called at line 16 and somehow Illuminate/Support/Facades/Facade.php feels responsible for it, it leads to following exception:
FatalThrowableError in Facade.php line 218:
Fatal error: Call to undefined method Illuminate\Support\Facades\Validator::resolver()

in Facade.php line 218
at Facade::__callStatic('resolver', array(object(Closure))) in /Users/marc/bude/laravel5-example/app/Providers/AppServiceProvider.php line 19
at AppServiceProvider->boot()
at call_user_func_array(array(object(AppServiceProvider), 'boot'), array()) in Container.php line 507
at Container->call(array(object(AppServiceProvider), 'boot')) in Application.php line 748
at Application->bootProvider(object(AppServiceProvider)) in Application.php line 559
at Application->register(object(AppServiceProvider)) in ProviderRepository.php line 74
...

Also, my IDE shows me that Validator does not exist. I'm very new to Laravel. Any idea where this is coming from?
Btw, I'm trying to setup Laravel with a more sophisticated application like this demo in PHP-PM, but no luck. Only the base Laravel works so far.

Ok, I got it. Somehow I'm not allowed to call bootstrap on the kernel Illuminate\Contracts\Http\Kernel, before handle(). Weird.