eosd can't launch with default genesis.json

Hello,
I compile eos project and try to launch eosd with the default eos/genesis.json. The output list below:
✔ ~/Code/eos/build/programs/eosd [master ↓·4|✔]
15:41 $ ./eosd --genesis-json=../../../../eos/genesis.json
2543884ms            chain_plugin.cpp:126          plugin_initialize    ] initializing chain plugin
2543885ms            wasm_interface.cpp:757        get                  ] Runtime::init
2543885ms            http_plugin.cpp:138           plugin_initialize    ] host: <IP_ADDRESS> port: 8888
2543886ms            http_plugin.cpp:141           plugin_initialize    ] configured http to listen on <IP_ADDRESS>:8888
2543886ms            net_plugin.cpp:2442           plugin_initialize    ] Initialize net plugin
2543886ms            net_plugin.cpp:2462           plugin_initialize    ] Setting net_plugin logging level to info
2543886ms            net_plugin.cpp:2487           plugin_initialize    ] host: <IP_ADDRESS> port: 9876
2543887ms            net_plugin.cpp:2566           plugin_initialize    ] my node_id is 56f6c35ff8abb99ccbf1166a68ed4c5155641f1ec884b6a9fed1fbbdf5513e7c
2543887ms            main.cpp:59                   main                 ] eosd version 93d05a9e
2543919ms            block_log.cpp:92              open                 ] Opening block log at /Users/jacktang/Code/eos/build/programs/eosd/data-dir/blocks/blocks.log
2544927ms            main.cpp:63                   main                 ] 3030010 checktime_exceeded: allotted processing time was exceeded
Transaction message exceeded maximum total transaction time of 10000ms
    {"limit":10000}
      chain_controller.cpp:906 process_message

    {"apply_ctx.notified[i]":"inita"}
      chain_controller.cpp:921 process_message

    {}
      chain_controller.cpp:1208 initialize_chain

    {"my->genesis_file.generic_string()":"../../../../eos/genesis.json"}
      chain_plugin.cpp:257 plugin_startup

What should I do to fix such error? My OS is MacOS High Sierra 10.13.2

Pls close the issue, I run it again and eosd is up now :)


react/destructuring-assignment ignoreClassFields not working correctly

Using the following config:
"rules": {
  "react/destructuring-assignment": [2, "always", { "ignoreClassFields": true }]
}

This still throws an error:
class Input extends React.Component {
  id = `${this.props.name}-${generateUUID()}`;
 ...

This looks like it was introduced in https://github.com/yannickcr/eslint-plugin-react/pull/1909 but I'm not seeing this actually working.

cc @alexzherdev


assign correct environment keys

Description
This pull request updates the Contentful environment keys that are used in the pipeline to match the same environment as the CONTENTFUL_ENVIRONMENT variable. These were not consistently updated when the CONTENTFUL_ENVIRONMENT variables were updated previously, leading to 404 errors i.e. 'environment not found' since each key is only able to access its assigned environment.
Code has not been commented and documentation has not been updated since it is not necessary for this pull request.
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Technical Enhancements

Checklist:
If any of these are not completed, please explain why in the notes.
Definition of Done
Code and merges

[ ] Code to be commented on where applicable
[ ] Documentation updated where required
[x] Have considered non-functional requirements such as Security, Performance, Scalability, and Fault Tolerance
[x] I have linted the code

Testing

[x] All levels of acceptance test are passing (automated, integration, manual, accessibility, etc.)
[x] I have run the behave command to check the selenium behaviour tests pass locally
[x] Acceptance criteria met

Other Checks

[x] I have performed a self-review of my own code
[x] I have checked for spelling errors
[ ] I have commented on my code, particularly in hard-to-understand areas
[x] My changes don't break anything unexpected
[x] I have checked and updated the security.txt file where required
[x] Up to date with the main branch
[] For a change that needs to be deployed in a release I have a commit with the fix:, feat: or BREAKING CHANGE:
tags and will copy this commit message to the squash
[ ] For a change that does not affect the deployed code I have added a commit with ci:, docs: or test:
depending upon which area of the solution was affected

Note when merging, squash commit must begin with one of the following tags:
"BREAKING CHANGE", "feat", "fix", "ci", "docs", "test"
Usage
BREAKING CHANGE: any change that breaks current functionality and may cause compatibility errors to users upgrading
E.G BREAKING CHANGE: refactored method x to take variable y as input (changed from variable z)
feat: A new feature
E.G feat: adding method x to future methods table
fix: A bug fix
E.G fix: amending page for method x to show correct release version
ci: Changes to our CI configuration files and scripts (Concourse)
docs: Documentation only changes
test: Adding missing tests or correcting existing tests

DEPLOY_URL=https://dvreaps3vwjm4.cloudfront.net/
cloudfront_id=E2B9IJFBSTQU79


Add methods for managing children of multibody descriptions

Adds methods to view the current children of  a multibody description as well as adding a child link from a full multibody description.

I was originally a little skeptical on how useful add_child_desc would be, but it turns out that it made my code much cleaner so I've included it in this pull request.

Thanks!


Blocking deps

[x] babel-eslint 10, https://github.com/babel/babel-eslint/issues/691
[ ] graphql 14, graphql-shield
[ ] Flow 0.82, Ramda and something from RN have problems with it
[ ] RNW blocks RN

great https://github.com/flow-typed/flow-typed/pull/2791


DDS loader crash fix

Fix for crash when loading a dds file of 3136x3104 with full mip-chain. The calculation to calculate the mip size was different from what two separate dds compressors seem to be using.
Repro case: create a DDS texture of the given resolution, and create a full mip chain for it. Try to load it, and during loading the application will crash because it is reading memory it shouldn't. I used
both TheCompressonator and Paint.NET to export the DDS, both failed to load.

What about KTX code path?

Good questions, I found a few more issues with my pull request because of them. I'm going to look into it a bit more.

I haven't tested ktx, as I don't regularly use this codepath. I will need to test this a bit more.
When a texture is compressed with texturec, it seems to work, though I am not able to load the dds with directxtex, nor Paint.NET. Could be because it saves in DX10 format, need to test more.
This was using BC3, and the texture has a DXT5 pixel format.

The texture I am trying to load is here: https://www.dropbox.com/s/l3xwi5msfo5ahfp/sizetest.dds?dl=0
I'll need to look into the issues above a bit more, so I'm fine if you want to reject this pull request for now. Or you can leave it open, up to you. :)

Yeah, I want more testing... But good you attached texture so I can take look at it.

Btw, this sizetest is just black texture? Or should I expect to see something?

Do some programmer art so that when I fix it I can see that it's not skewed or messed up in some other way.

Here's a folder with a bunch of images:
https://www.dropbox.com/sh/hv7ws4fgoi15r1n/AADg6_4sjZFub6R3KJNBaSh3a?dl=0
To test I copied the files into examples/runtime/textures and run example-06-bump, and replace the filename on line 156: m_textureColor = loadTexture("textures/sizetest.png");

sizetest.png --> input image. Now has some lines and text. Loads OK
sizetest_compressonator.dds --> dds file generated by the compressonator. Crash on load.
sizetest_paintnet.dds --> dds file generated by paint.net (possibly through a dds plugin). Crash on load.
sizetest_texturec.dds --> dds file generated by texturec. Loads OK. Though I can't seem to open this file in directxtex, nor paint.net (possibly because of DX10 pixel format and additional header struct?)
sizetest_texturec.ktx --> ktx file generated by texturec.  Loads OK.

Could it be that the non DX10 format has a different formula for storing mipmaps? My original fix was to not round the width/height to a multiple of 4 at every halving-step, but just do the rounding for each mipmap width/height only. That seems to load the DXT5 format dds's correctly.

Also, just to give some more contexts on that last remark about making it a multiple of 4, here are each mip size exported by the compressonator, versus the mipsize exported by texturec. Note that starting at mip 6, the resolutions and data size of the mipdata start to diverge because texturec rounds the width and height to a multiple of 4 for each step, and continues with that rounded number, and the compressonator doesn't:
`
Compressonator:
Mip 0, Texture size = 9734144 Bytes, 	width = 3136 px  	height = 3104 px
Mip 1, Texture size = 2433536 Bytes, 	width = 1568 px  	height = 1552 px
Mip 2, Texture size = 608384 Bytes, 	width = 784 px  	height = 776 px
Mip 3, Texture size = 152096 Bytes, 	width = 392 px 	height = 388 px
Mip 4, Texture size = 38416 Bytes, 		width = 196 px  	height = 194 px
Mip 5, Texture size = 10000 Bytes, 		width = 98 px  	height = 97 px
Mip 6, Texture size = 2496 Bytes, 		width = 49 px  	height = 48 px
Mip 7, Texture size = 576 Bytes, 		width = 24 px  		height = 24 px
Mip 8, Texture size = 144 Bytes, 		width = 12 px  	height = 12 px
Mip 9, Texture size = 64 Bytes, 		width = 6 px  		height = 6 px
Mip 10, Texture size = 16 Bytes, 		width = 3 px  		height = 3 px
Mip 11, Texture size = 16 Bytes, 		width = 1 px  		height = 1 px
texturec:
Mip 0, Texture size = 9734144 Bytes, 	width = 3136 px, 	height = 3104 px
Mip 1, Texture size = 2433536 Bytes, 	width = 1568 px, 	height = 1552 px
Mip 2, Texture size = 608384 Bytes, 	width = 784 px, 	height = 776 px
Mip 3, Texture size = 152096 Bytes, 	width = 392 px, 	height = 388 px
Mip 4, Texture size = 38416 Bytes, 		width = 196 px, 	height = 196 px
Mip 5, Texture size = 10000 Bytes, 		width = 100 px, 	height = 100 px
Mip 6, Texture size = 2704 Bytes, 		width = 52 px, 	height = 52 px
Mip 7, Texture size = 784 Bytes, 		width = 28 px, 	height = 28 px
Mip 8, Texture size = 256 Bytes, 		width = 16 px, 	height = 16 px
Mip 9, Texture size = 64 Bytes, 		width = 8 px, 		height = 8 px
Mip 10, Texture size = 16 Bytes, 		width = 4 px, 		height = 4 px
Mip 11, Texture size = 16 Bytes, 		width = 4 px, 		height = 4 px
`


Specification for: Page

Related issues or relevant information?
No response
Design tasks

[ ] Design is fully specified in Figma

[ ] Design component with all relevant states
[ ] Do a accessibility test of the sketches
[ ] Functionality/animation is described and prototyped if relevant
[ ] If there are used any svgs in this component is it available for the developer? [Link]
[ ] Link to Figma design: [Link]
[ ] Pasted screenshot from Figma below :point_down::skin-tone-2:

Development Tasks

[ ] Implement in Storybook
[ ] Make sure all variants/properties is possible to turn on/off
[ ] Make sure the component is usable across different breakpoints/screen sizes

Accessibility tasks

[ ] WCAG-review

Utgår, blir ikke en komponent i felles designsystem.


not operator (anything but)

tl;dr:
(param: Any) => not String
// shorthand
(param: Any) => !String

// union case
(param: Any) => not(String | Array)
// short hand
(param: Any) => !(String | Array)

Sometimes it's way easier and convenient to define the type by discarding one or several.
There's also the possibility to define it as a substraction—e.g. Any - String—but that would not be very conventional.
TypeScript approaches

substraction: https://github.com/Microsoft/TypeScript/issues/4183
exclude: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#predefined-conditional-types
negation: https://github.com/Microsoft/TypeScript/issues/18280

I like it.

After thinking about it I think that introducing a new keyword is not a good idea: we should be as JS compatible as possible. It's not ruby after all.
Ill do a PR if I find an acceptable title for the chapter.

After thinking about it I think that introducing a new keyword is not a good idea: we should be as JS compatible as possible. It's not ruby after all.
Ill do a PR if I find an acceptable title for the chapter.
But Iv got a problem:
// if & is introduced
!(A | B)
// could be expanded to
!A | !B
// which is not
!A & !B

So Ill keep it simple until #132 is resolved.

After thinking about it I think that introducing a new keyword is not a good idea: we should be as JS compatible as possible. It's not ruby after all.

I'm not sure what you mean by this. JavaScript has a logical ! operator which behaves similarly.
// if & is introduced
!(A | B)
// could be expanded to
!A | !B
// which is not
!A & !B

I don't see this as a problem, as long as it is well documented.

My biggest problem with this proposal is that ! type declarations can't be future-compatible. Because they blacklist instead of whitelist types, newly introduced types may be considered acceptable by the type system, even if they're not acceptable types in practice.

I'm not sure what you mean by this.

I was talking about not.

I don't see this as a problem, as long as it is well documented.

Do you have an example in mind? I thought require would be a good candidate but I think you can export undefined.

newly introduced types may be considered acceptable by the type system, even if they're not acceptable types in practice

That's expected. Let's say you had !Array before typed array were introduced and it doesn't cover Int16Array, I wouldn't blame rtype. He will have to update to !Array & !TypedArray; it's such a rare occurence that I don't mind.

@ericelliott #140


remove dependency on SwiftyJSON and use duckduckgo carthage dependencies

Reviewer: Caine or Mia
Asana:

https://app.asana.com/0/392891325557410/534186388081450
https://app.asana.com/0/392891325557410/534415163341060

CC:
Description:
Low hanging fruit:

Remove dependency on SwiftyJSON and use provided JSON serialisation API.
Update dependencies to use the ones forked on DDG (instead of hosted on Mia's Github account).

Steps to test this PR:

Clean launch the app
Visit cnn.com - open the privacy grade and check the trackers are grouped by network as normal
Exploratory testing as usual

thanks for the review @nilnilnil


Hotkey for copying the most recent hash stub

Provide a hotkey for copying the most recent commit hash stub from a pull request. In my use case it's for accessing resources with names identical to the current hash stub related to their commit.
It'd also allow me to avoid the horror that is trying to copy it from the page
Even if you do copy it from that part of the page, it comes suffixed with a space.
Example URL:

Any pull request URL
https://github.com/$USERNAME/$REPONAME/pull/$NUM I suppose

Can you explain your use case a little more? I don’t understand

Sure! As a normal part of my day to day development I'll need to grab the stub from the SHA hash of the latest commit in a pull request, these stubs are then used in the URL to the deployed version of that commit.
It's really fiddly to copy that hash stub, especially with a trackpad. If there were a copy icon (like so, shown underneath) that would also work.

Anything to escape the frustration of accidentally copying the entire bottom half of the pull request page!

In Chrome, you can just right-click the SHA link and click "Copy" to copy the text (not link).

I'm using firefox, where that feature isn't available sadly 😭

This seems very specific, we can’t add a button
You can probably improve the selection by adding some padding to that element instead (via Stylus or our own CSS field in the Options page)


Add canned responses as related project

Not turn turn this into an awesome-* but I love this extension so much.

Oh yeah definitely. Thanks for the suggestion :)

And in case you didn't know: https://github.com/stefanbuck/awesome-browser-extensions-for-github


Help user to install Udev rules

~Allow Linux users to install / verify Udev rules automatically (via a subcommand), which would be downloaded from the libnitrokey's repository.~
Provide a guide and diagnostic logic to help user find the cause of connection issues.

If by this you mean downloading files from the internet and putting those into a system location where they will be used for udev based detection and actions on system devices, executed as root... then no, please don't. That sounds not only dangerous but also error prone.

mmh, ok then maybe packaging the udev-rule file as a part of pynitrokey and provide something like nitropy udev-rules, which will output the rules file providing some more convenience and control to the user (because he'd have to copy it by himself)

If by this you mean downloading files from the internet and putting those into a system location where they will be used for udev based detection and actions on system devices, executed as root... then no, please don't. That sounds not only dangerous but also error prone.

Can you elaborate why do you feel it's dangerous or error prone?

Can you elaborate why do you feel it's dangerous or error prone?

It would require the user to elevate privileges to root for the installation of the files.
When looking at post-installation actions that would be required (e.g. run udevadm control --reload as root) and the necessary steps to ensure that e.g. the administrator location for these files exists and that the files do not conflict with other files and/or are being cleaned up properly on update or removal, this opens a whole other can of worms.
What would also need to be considered is the transfer safety of these files.
Overall, this adds a lot of complexity to your tooling for a few text files, which are usually integrated on a packaging level in a Linux distribution, which comes at no cost for you.
IMHO this time is much better spent with creating documentation on that these files exists and are required for running the tooling and that they need to be packaged with the tooling. This makes it easy for downstream distributions to pick up on this and do the right thing.

@dvzrv I see your point. We will change accordingly.

You might also want to look into https://man.archlinux.org/man/hwdb.7 depending on device support.

When looking at the required dependencies for spsdk, I also had a look at pyocd, which documents its udev requirements as such: https://github.com/pyocd/pyOCD/tree/main/udev


Migrate app to MVI pattern

The diff is big here but it's mostly because of package changes.

Self-ACK.


Data grid replacement investigations

I think we should close this one and open actual work item when time comes.


chore(e2e): expands Zone creation test

chore(e2e): renames zone test file
chore(e2e): expands Zone creation test
Adds assertions around the entity scanner content.
Signed-off-by: Philipp Rudloff<EMAIL_ADDRESS>

Am I right in thinking some of this stuff might be useful here:

We should really avoid using this in tests as much as possible because it will make the tests actually go through the added latency (as it uses setTimeout). In the case of the additions in this PR, just switching the response to return the right thing works and is fast so as far as I understand, introducing latency here would just make the test slower than it needs to be.

We should really avoid using this in tests as much as possible because it will make the tests actually go through

Hmm yeah, I think the loading one linked requires the latency to be able to test the loading state reliably (we want to make sure it doesn't immediately load).
Let me look at this a little more, theres something about it that doesn't sit well with me, its around that fact that the state changes from:
Then the "$zone-connected-scanner" element contains "Waiting for Zone to be connected"

to:
Then the "$zone-connected-scanner" element contains "The Zone “test” is now connected"

without you actually interacting with anything.
If possible could we still look at not asserting on human text in the meantime? I also left a couple of little nits seeing as we tweaking a little bit anyway.

Yeah exactly I'm not sure if that sits with me well because that isn't clear from the test, wondering if there is an improvement.
It looks like its a 1 second poll, so this only works as a test as we have a default wait of 4 seconds for something to pass/fail an assertion, is that right? Otherwise you would have to add the 1 - 2 second wait into the test?
Hmm yeah I just added a KUMA_LATENCY of 5000 and it failed, I know we aren't adding a latency here, but could we use the wait for step just before your last assertion? That means we are Arranging, Acting (waiting) and then Asserting.
If you are super strong you don't want to do this then fine, but I think it would make the test read better and would have prevented me from going "what!? this doesn't make sense!", and I don't think it has any consequences seeing as we secretly wait for 4000 in Cypress anyway.


When is the electrical boost of the hybrid heat pump activated?

Situation
Say I have 100 households, 90 of which have space heater combined network gas, 10 have hybrid heat pump space heating. In my technology profile I assign:

90 units Households space heater combined network gas, buffering
10 units Hybrid heat pump space heating (electricity), buffering
10 units Hybrid heat pump space heating (gas), boosting

Question
Are the 10 units belonging to the hybrid heat pump space heating gas and electricity coupled?
What I would like to happen is this:
When my electrical heat pump cannot fulfil the demand for that 10 units the gas heat pump should be activated for the demand of that 10 units.
Is this indeed how ETMoses handles this situation?
Or, are all the buffers on the same end node coupled? So my gas heat pump is only active when both the electrical heat pump and the combined network gas heater cannot supply the current demand of all 100 units.
@dennisschoenmakers FYI

Or, are all the buffers on the same end node coupled? So my gas heat pump is only active when both the electrical heat pump and the combined network gas heater cannot supply the current demand of all 100 units.

This is correct. If you have a space heating buffer with annual demand of 1000kWh and volume of 3kWh and 10 units, then we model that as a single buffer with demand of 10000kWh and volume of 30kWh.
It's the same with technologies: if you have a combined gas heater with capacity of 20kW and 10 units, we model that as a single heating technology with 200kW of capacity.
In your example above, I expect the 90 combined heaters to be used first, followed by the 10 electrical hybrid heat pump components. If there is still unsatisfied demand, the gas components of the HHPs would be used.
--
If you want to model a scenario where you have 90 households with combined heaters, and 10 with hybrid heat pumps, you'd need to use separate endpoints for each case.

Thanks for you answer!

If you want to model a scenario where you have 90 households with combined heaters, and 10 with hybrid heat pumps, you'd need to use separate endpoints for each case.

As a user this strategy feels a bit complicated. I think, for example, that looking at my load vs capacity is much more difficult if I have two end nodes in my topology that are one end node in reality.
I think my problem can also be solved by creating a separate buffer for the hybrid heat pumps (within the same end node). @antw, do you agree?
@jorisberkhout, I think the documentation of hybrid heat pumps should at least include the above described problem and preferably also a strategy for a solution.

I think my problem can also be solved by creating a separate buffer for the hybrid heat pumps (within the same end node). @antw, do you agree?

Indeed, that's a better idea than mine. :grinning:

Can we close this @DorinevanderVlies?

Yes, I shall open another issue about the documentation


Show loading indicator

I am using the huge apps example code with react-router-relay.
What should I do to show loading indicator when the route is changed?
Using render or renderLoading does not work.
renderLoading has no effect.
module.exports = {
  path: 'home',
  queries: queries,
  renderLoading: () =>
Loading...
,
  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('./components/App'))
    })
  }
}

using render gives " Uncaught Invariant Violation: onlyChild must be passed a children with exactly one child" error
module.exports = {
  path: 'home',
  queries: queries,
  render: ({ props }) => props ? require('./components/App') :
Loading...
,
  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('./components/App'))
    })
  }
}

Thanks to NevilleS, I found my mistake. Need to spread props.
the code below works perfectly
module.exports = {
  path: 'home',
  queries: queries,
  render: ({ props }) => props ? <App {...props} /> :
Loading...
,
  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('./components/App'))
    })
  }
}

We diagnosed this issue a bit - everything works fine with render, but you aren't passing along the props correctly to the App component. See https://github.com/relay-tools/react-router-relay/blob/master/README.md for usage details on how you need to spread the props into your component, e.g.:
        <Route
          path=":widgetId" component={Widget}
          queries={WidgetQueries}
          render={({ props }) => props ? <Widget {...props} /> : <Loading />}
        />

@NevilleS :+1:  Yes. Thank you so much for your help :)

Separately, tracking loading state for async components/routes is more of a React Router concern than a react-router-relay concern – right now the router doesn't explicitly surface a way to notify you that async routes are resolving, but you can e.g. attach a listener to the history.


Command - refactor to use typed interfaces to implement commands for tcp connections

Following the refactoring of RPC calls, we can now implement all commands using typed interfaces and implemented with a specific RPC client.
For example the Projects trait provides an access to projects, to create/list/delete them. That trait is implemented by the Controller client by making requests to the controller.
The use of the Projects interface can be seen in the following command to create projects.
Desired behavior
Provide similar interfaces for all other commands and remove all the "api helpers" from the ockam_command crate for the following:

tcp connections

All the interfaces and implementations must be part of the ockam_api crate so that the purpose of the ockam_command is only to:

get and validate arguments from the command line
call the ockam_api crate
display progress / reports / outputs / errors

[!NOTE]
Related epic: https://github.com/build-trust/ockam/issues/6310

We love helping new contributors! ❤
If you have questions or need help as you explore, please join us on Discord. If you're looking for other issues to contribute to, please checkout our good first issues.

hello, let me on this one

@0xkelvin That's awesome, this is all yours. Please let us know if you have any questions as you explore. You can also ask questions on the contributors discord https://discord.gg/RAbjRr3kds


Export to Figma feature doesn't export all the variables associated to the Theme

Describe the bug
Export to Figma feature doesn't export all the variables associated to the Theme.
The theme:

The exported variables:

Since the prim/mtl/color/value doesn't get exported into variables, all the variables in sem/color/mtl-light are all referenced to empty variable, thus, cannot be used.
To Reproduce
Steps to reproduce the behavior:

Create a token set that refer the color of another token set
Create a theme with those 2 sets, make sure to Enabled ( NOT Reference Only)
Export Variables to Figma using Style & Variables > Export styles & Variables
See error

Expected behavior

It should export both token sets as variables, when I pick Enabled Theme configuration
It should NOT export the token, if I pick Reference Only in Theme configuration

Screenshots or Screencasts
(See above)

hey @marach-t-mtl, it looks like you've only created a collection for the sem/color, but you're variables are missing hte core/primitives collection.

It is advised to always create a separate variable collection of your core/primitive tokens. These core/primitive sets need to always be enabled and then subsequent sets that are referencing these tokens need to be enabled BUT have the core set to reference only.

Closing, this should work with the above steps


Issue 129 - Use RangeFactory over Range constructor

Note that this PR is stacked on top of https://github.com/gchq/sleeper/pull/119, please merge that one first
Uses RangeFactory.createRange(...) instead of new Range(...). Resolves #129

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: patchwork01:x: kr565370You have signed the CLA already but the status is still pending? Let us recheck it.


Implement graceful node shutdown mechanism

This PR does two things:

Unify worker and processor logic in the router
Implement a more robust and verifiable shutdown mechanism

Things left to do documented in #2088

Regarding multi-hop reliability.
I don't really see how is that achievable in general. Every forwarding worker in the route may delay, drop, duplicate or modify the messages. Unless we know exactly how the worker behaves there is no way to tell if the message ever to be routed.
For some workers we can assume they are sources or sinks of other workers, but can we really tell? Am I missing something?
Although I agree that starting/stopping workers in groups (stages, clusters) can be generally useful
In some cases I can imagine you want to shutdown TCP first if connections are a source of messages in the node and not the sink.

I think the focus is not so much on providing actual messaging reliability on layer 1, especially because that always pulls in a bunch of resend/ control logic with it. I guess the title of the section in my first comment is a bit misleading in that regard.
The changes I was talking about yesterday are in regards to a very simple race condition that we are observing in our examples.
In actuality yes, the runtime can't really guarantee what a worker will do with a message. So this is by no means a replacement for higher level protocols.
Instead I would consider it some additional state the router has to take into account when shutting down a set of workers or the whole node.

Is there an API for worker implementations when they get the shutdown signal, or it's supposed to be all internal?

@hairyhum  Is there an API for worker implementations when they get the shutdown signal, or it's supposed to be all internal?

Yes and no. The Worker trait has a shutdown() function which can be used to handle any de-allocation tasks and can also send messages to other workers (that have not started shutting down yet!).
When a worker gets interrupted there's no way for workers to run user-code.

@spacekookie when trying example 9, did you replace these two lines with 1.node.ockam.network:4000?
https://github.com/ockam-network/ockam/blob/c3409f5971d588d7742a73656a51b42e33b4fb00/examples/rust/get_started/examples/09-streams-responder.rs#L9
https://github.com/ockam-network/ockam/blob/c3409f5971d588d7742a73656a51b42e33b4fb00/examples/rust/get_started/examples/09-streams-initiator.rs#L8

@mrinalwadhwa I had changed those but to the IP address of a custom node I created on hub.ockam.network which just hung both programs. Putting in 1.node.ockam.network:4000 works.
Updates

43e0bfe changes spawn logging from info to debug
c5a4cd8 was needed to make the stream consumer gracefully handle node shutdown (fetch_interval will be rejected when the node is stopping because it's a spawn action)


Vertical layout debug console (terminal) file path taking too much space

VSCode Version: 1.50.0
OS Version: Linux Mint 20

Steps to Reproduce:

Launch debug mode with a script and put the layout vertical

Hi,
it's a bit frustrating that almost half of the vertical space in debug console is used to display the file name where the log originated. In addition, those informations are 100% inaccurate to me because it always point to the logger file and not the file where the error originated...
I'm working with a 1080p monitor, tried different zoom level and panel size but it's always the same problem as source location adapt to panel size.
See screen capture below:

So you would like that there is a max width for the source location in the debug console.
I think this is a fair request which we might tackle in the future.

This should be better now, thus closing


feat: store user ui preferences

Description
This PR is a result of October 27th "flash hackathon" involving @Milouu and @acellard. The goal was to figure out how to properly manage user ui preferences in the backend, and provide api to get, retrieve and update them.
For now, such preferences involve columns display list and favorites compute plans. With likely more preferences in the future.
To keep it flexible and leave the responsibility to the frontend, the preferences are stored in a json field.
This PR also does some refactoring to use serializer to validate data.

Thank you for your contribution! Unfortunately, due to organisational and roadmap changes, this item has been deprioritised. We currently have no bandwidth to cope with the code drift between the current code state in the last release and this PR, therefore we are closing it.


Fix opam pin version .dev

It seems like having the directory with a .dev doesn't guarantee that opam will pin all packages to the dev version! The setting --with-version=dev does the job.

Also, can we get rid of the .dev in the bench-dir folder that I added😂 thank you!

Whoops I'm sorry, I was trying to push a commit but it got closed 😨


Windows bindings defaults

Taking a cue from hyper-apps-defaults.lua, make windows.lua key bindings user customizable. The WindowsLayout Mode's functionality should be the same, with the exception of the "quick help" status message described below. EDIT: added a showHelp option, defaulting to false.
I did this pretty much as an exercise to learn Hammerspoon/lua scripting, so feel free to close/discard this PR, as desired.
Summary of changes

Move all the hard-coded bindings from windows.lua into windows-bindings-defaults.lua
Update windows.lua to look for windows-bindings.lua, falling back to windows-bindings-defaults.lua and assign windowLayoutMode:bindWithAutomaticExit() bindings from those files
Update windowLayoutMode.statusMessage to display a quick help if showHelp option is true, based on the windows bindings file:

Add hammerspoon/windows-bindings.lua to .gitignore

@jeebak: This is sooooo cool! Thanks for this contribution.


[Tests] Tests should not rely on write order

Currently, some tests assume that the reading order of records is the same as they are written. This is not the case for all drivers.
See https://github.com/Toblerity/Fiona/pull/924

@rbuffat historically, the tests were all based on shapefiles, which was at the time the most used and most tested driver. And we did assume preservation of order.
I would like us to be conservative about changing tests to be more specific to particular drivers. It's not Fiona's job, in my view, to find and document bugs and quirks in GDAL/OGR drivers. And let's be clear: many of the GDAL vector drivers are of historical interest at best and are fine to ignore. I'd like for us to focus on implementing properly our feature access API without thinking too much about individual GDAL drivers. Concretely, let's firm up the semantics for Fiona opening modes and make sure that they map to the set of OGR driver capabilities, but let's not write tests that are specific to a particular driver or add code to Fiona that works around limitations of drivers.
I'm sorry that this comment is a little vague and hand-waving.

@sgillies I was thinking about refactoring the test_equal method of the testdata_generator to work with a collection of records instead of individual records and only refactoring the tests using it. https://github.com/Toblerity/Fiona/blob/7559619bef3e2e3a2d712b674c3c7c358551ccae/tests/conftest.py#L398-L409
I see the benefit of testing all enabled drivers in having more confidence if a new driver is enabled. But I also see that the complexity of the tests increases. There needs to be a balance between benefits and complexity.


Self-hosted nadeko not responding

Ever since Discord released channel categories Nadeko hasn't been responding to commands. The version of Nadeko that I am running is 1.3b and I was told that 4 other people have reported this bug

Please update your bot. You can do so by simply getting the new installer link from the linux guide.

Run it and install prerequisites
Download the bot (option 1)
Run the bot

All of your old data and setting should be preserved. Make sure to backup first just incase.

I updated to the latest Nadekobot and my self hosted from source bot is also not responding in a server that tested categories in disord canary but decided not to use them until stable discord had them. It works on the another server just fine that hasn't tested categories.

I just created categories on my server. Works fine.

One user reported that it didn't work since they restarted the bot

My bot had been offline through the duration and was started after testing categories, The bot hasn't responded to anything since.

Ah, there's the issue
https://github.com/RogueException/Discord.Net/issues/810
I'll try to push the update tonight


lints: add check for non-utf-8 filesystem content

As mentioned in #975, we should add a lint to ensure that all filenames are UTF-8, giving nice errors (with full pathnames) in the event that we encounter invalid filenames.
We also check symlink targets.
Add a unit test that tries various valid and invalid scenarios.

From what I can see of how we get our root Dir reference in cli.rs, and the recommended instructions for running this in a RUN command in the Containerfile, I think this might end up walking into /dev, /sys, /proc and so on as well...
On the other hand, any bind mounts that are present might prevent us from scanning the underlying content.  Imagine some scenario where /etc/resolv.conf in the image was a symlink that contained non-utf8 character, but we wouldn't be able to access that because it gets bind-mounted-over for the duration of the RUN command.
Maybe we should do a temporary bind mount of (only) the rootfs for purposes of linting?
Thoughts?

From what I can see of how we get our root Dir reference in cli.rs, and the recommended instructions for running this in a RUN command in the Containerfile, I think this might end up walking into /dev, /sys, /proc and so on as well...

Yeah we should avoid that for sure. There's relevant similar code in e.g. remove_all_on_mount_recurse

I don't really trust checking dev vs. rootdev anymore: we've had some reports of that that show that overlayfs with composefs can produce strange effects in this case... like in https://github.com/containers/composefs-rs/issues/41#issuecomment-2514883271
The overlayfs docs themselves warn about this:

While directories will report an st_dev from the overlay-filesystem, non-directory objects may report an st_dev from the lower filesystem or upper filesystem that is providing the object. Similarly st_ino will only be unique when combined with st_dev, and both of these can change over the lifetime of a non-directory object. Many applications and tools ignore these values and will not be affected.

https://docs.kernel.org/filesystems/overlayfs.html
The openat2 NO_XDEV flag approach seems kinda okay-ish I guess... does cap-std have support for this?
I think the best thing we could do here is some trickery with cloning the root mount to an fd using the new mount API and then iterating through that fd...

I don't really trust checking dev vs. rootdev anymore: we've had some reports of that that show that overlayfs with composefs can produce strange effects in this case... like in https://github.com/containers/composefs-rs/issues/41#issuecomment-2514883271

Yeah, fair.
OK so another approach which is also used in the referenced code is this: https://github.com/containers/bootc/pull/984

The openat2 NO_XDEV flag approach seems kinda okay-ish I guess... does cap-std have support for this?

Not directly but we can also just use rustix for stuff like this too.

Okay, "some trickery" isn't very tricky at all. It mostly looks like just using open_tree() without the AT_RECURSIVE flag. rustix binds this, so I'll take a look.

That is awesome! I didn't know that was usable unprivileged. Indeed it's by far the best approach. I noticed this wasn't doc'd so :arrow_right: https://github.com/brauner/man-pages-md/pull/15

Ah CI needs some #[cfg(feature = "install")] massaging...I am quite tempted again to drop that feature or just scope it to to-disk

After a live chat we decided to just rely on openat2(.. NO_XDEV), updated for that.

Also noting here just so it doesn't get lost:
We also discussed having container lint --root /path/to/root which would be usable in a multi-stage build like this:
FROM someimage as rootfs
...

FROM otherimage as linter
RUN --mount=from=rootfs,target=/rootfs bootc container lint --rootfs=/rootfs

An advantage of this approach is that we'd be able to scan the filesystem tree without having container runtime state (/proc, /dev) overmounted at all...which would actually allow us to e.g. also lint against device nodes.
But...the ergonomics would be obviously less good.
And ultimately the most powerful way to do this is to have a container scanner that runs outside of the running image, which would allow us to lint the actual image structure itself (e.g. tiny layers that should be coalesced). Or of course, a container -> container optimizer.


h30ga and r35gb on 0.3.0 version do not find 0.3.2 online update

When trying to upgrade h30ga and r35gb, they say:

But you click on upgrade firmware and:

I had a simmilar issue and upgraded to 0.3.2 manually - now it seems to work again.

Upload File via FTP and follow the instructions to install the update manually:
https://github.com/roleoroleo/yi-hack-Allwinner-v2/wiki/Manual-firmware-upgrade

Same here... I have many cameras, if I can didn't have to set a FTP on each , that can be a good thing. Hope to update to 3.3 from 3.0. Thanks

There was a bug in the previous version of busybox.
https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/779
You have to update with the manual procedure.

ok.
I try turn on the FTP Serve, but I got:
421 Can't change directory to /home/ftp/ [/]
I miss something?

Upgrade completed using the manual procedure, thanks!!


apiv2(ticdc): implmenet the list processors

What problem does this PR solve?

Issue Number: ref #8019
What is changed and how it works?
Implement the list processors for API v2
Check List
Tests

Unit test
Integration test

Questions
Will it cause performance regression or break compatibility?
No
Do you need to update user documentation, design documentation or monitoring documentation?
No
Release note
None

/run-all-tests

/run-all-tests

/merge


Polyglot Notebook: [DevExE2E][Regression]Fail to create Polyglot Notebook: Create new blank notebook (.dib ).

Describe the bug
Fail to create Polyglot Notebook: Create new blank notebook (.dib ), throw error "Cannot read properties of undefined (reading 'kernelInfo')"
Detailed Repro Build info:
Detailed Repro Build info: VSCodeSetup-arm64-1.94.2 + dotnet-interactive-vscode-1.0.5511031.vsix
VSCode Link: https://code.visualstudio.com/download
Version: 1.94.2 (system setup)
Commit: 384ff7382de624fb94dbaf6da11977bba1ecd427
Date: 2024-10-09T16:08:44.566Z
Electron: 30.5.1
ElectronBuildId: 10262041
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT arm64 10.0.22631
dotnet-interactive-vscode-1.0.5511031.vsix
https://artprodcus3.artifacts.visualstudio.com/Ab55de4ed-4b5a-4215-a8e4-0a0a5f71e7d8/7ea9116e-9fac-403d-b258-b31fcf1bb293/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL2RuY2VuZy9wcm9qZWN0SWQvN2VhOTExNmUtOWZhYy00MDNkLWIyNTgtYjMxZmNmMWJiMjkzL2J1aWxkSWQvMjU1ODU1Mi9hcnRpZmFjdE5hbWUvdnNjb2Rl0/content?format=file&subPath=%2Finsiders%2Fdotnet-interactive-vscode-1.0.5511031.vsix
sdk info: dotnet-sdk-8.0.403-win-arm64
Note:

It's a regression issue. It doesn't repro on VSCodeUserSetup-x64-1.93.1 + dotnet-interactive-vscode-1.0.5468011.vsix.
Not repro on create as .ipynb project.

Steps:

Ctrl+Shift+P => "Polyglot Notebook: Create new blank notebook"
Select "Create as .dib" ->Select "C#" or "F#"

Expected Results:
Creating .dib Polyglot Notebook should be done normally, with no error.

Actual Results:
Fail to create Polyglot Notebook: Create new blank notebook (.dib ).

[Window Title]
Visual Studio Code
[Main Instruction]
Command 'Polyglot Notebook: Create new blank notebook' resulted in an error
[Content]
Cannot read properties of undefined (reading 'kernelInfo')
[OK]

OS

[√] Windows 11
[ ] Windows 10
[ ] macOS
[ ] Linux (Please specify distro)
[ ] iOS
[ ] Android

Browser

[ ] Chrome
[ ] Edge
[ ] Firefox
[ ] Safari

Frontend

[ ] Jupyter Notebook
[ ] Jupyter Lab
[ ] nteract
[√] Visual Studio Code
[ ] Visual Studio Code Insiders
[ ] Visual Studio
[ ] Other (please specify)

Screenshots

This issue also repros on windows x64 platform with build- VSCodeUserSetup-x64-1.94.2 + dotnet-interactive-vscode-1.0.5515021.vsix + dotnet-sdk-8.0.403-win-x64, not the specific issue on ARM machine.

This issue doesn't repro on VSCodeSetup-x64-1.95.2 + dotnet-interactive-vscode-1.0.5562021.vsix.


Some fixes and improvements for ES6+

Hi Alexey.
Thx for you contribution. Can you add an example into the all-examples model regardin the commit "Allow default-exporting AbstractAssignmentExpression".
Let me know.

Never mind my precedent request, I've figured out the reason for your commit.

Hi Alexye, I'm very happy about your contributions nevertheless if you want/can contribute it's probably better if we coordinate:

all-examples, that I try to keep sane, has errors in your branch
super should be added using SuperCall and SuperProperty, see https://tc39.es/ecma262/#sec-left-hand-side-expressions
I always modify all-example model when I add new features
and so on.
Let me know.

Sure. I'll fix these now.
A question about tests. I see there is tests model, but some tests fail for me on the development branch. Is that ok?

Mmmm no, tests show errors in the editor due to missing properties (old properties) but all of them should be successful. I'll check tests. Thx

JSImportSpecifier in all-examples now throws Property constraint violation for property "name" because JSIdentifierUtils now (properly) reject empty identifiers.
I removed JSIdentifierName usage and implemented constraint on JSImportSpecifier directly.

Hi Alexey, lots of improvements. Thanks
For any additional contribution feel free to open another PR.
In general I've documented the implemented parts in all-examples, and keep it consistent while the language evolves.
And I try to adhere to the TC39 standard for the structure part also because the machanism for Yield, Return In etc checking rely on that structure.

Thank you!
What is the best place to look for information on how TC39 production parametricity is implemented? And how do I ensure it works properly when I add code?

For examplanation about production parameters [Yield] see https://tc39.es/ecma262/#sec-grammar-notation, I will write a small doc today. In short, I've used the HasYield, HasIn etc interfaces.
A leaf production can ask parents how it is actually called with respect to parameter navigating upwards in the hierarchy.

Take a look here   https://github.com/mar9000/ecmascript4mps/blob/development/implementation.md
At the moment nobody review this implementation choise so I'm very interested in what do you think about it.

Yeah, it seems reasonable. Though, I am not yet sure it will handle special cases well.
https://www.ecma-international.org/ecma-262/7.0/index.html#prod-GeneratorMethod
GeneratorMethod[Yield]:
  * PropertyName[?Yield] ( StrictFormalParameters[Yield] ) { GeneratorBody }

Note how PropertyName is ?Yield but StrictFormalParameters is always +Yield.

For this reason the all interface methods has a node as parameter, so the same resolver can return different values for different nodes.
With respect to your example  GeneratorMethod should implement HasYield so it is found as a resolver and should return true when node is StrictFormalParameters. Instead it should ask to its parent to decide about Yield when node is PropertyName.

That's good :+1:

Are there any cases when production may belong to two different parent productions? (We won't be able to inherit from two different parents in MPS.)

e.g., BindingPattern belongs to both ForBinding and CatchParameter
ForBinding[Yield, Await]:
  BindingIdentifier[?Yield, ?Await]
  BindingPattern[?Yield, ?Await]

CatchParameter[Yield, Await]:
  BindingIdentifier[?Yield, ?Await]
  BindingPattern[?Yield, ?Await]

A pattern that has been successful, until now, is to use interfaces or hiercarchy. The rules above state more or less:

in every place there is a ForBinding you can have BindingIdentifier or BindingPattern.
Same for CatchParameter.

To implement the points above an interface is sufficent.
CatchParameter is already  implemented has an inteface, see JSICatchParameter, so JSBindingIdentifier that is a concrete concept just needs to implement it.
I'm not sure this paradigm will be successful for the whole implementation, it was successful until now.
This means: to just "group" together some productions use interfaces.


Xcode 6.3: RealObject getting called on OCMClassMock and OCMStrictMock

My tests were passing before I updated and now they fail because the real object method is getting called instead of the mock.

@Spilly Are you using Cocoapods 0.36 by any chance?

I'm using 0.36.3 right now but I updated after i entered this issue. Should
I try again?
On Fri, May 1, 2015 at 1:51 PM Jamie Forrest<EMAIL_ADDRESS>wrote:

@Spilly https://github.com/Spilly Are you using Cocoapods 0.36 by any
chance?
—
Reply to this email directly or view it on GitHub
https://github.com/erikdoe/ocmock/issues/190#issuecomment-98233943.

I was seeing something similar after upgrading to 0.36 and I had to delete all the xcconfig files from my project and re-run pod install. If you were seeing this before 0.36 though, it could be something else.

Is this an OCMock issue or a Cocoapods issue? Should this issue be closed?

Closed due to inactivity.


add option to disable logs for routine metric collection

As there's already metrics being exposed for this, the logs don't add much for our use case. It would be really helpful if there was an option exposed to disable generating logs for routine metrics (i.e. the "Collected metrics for github-rate-limit-exporter" logs), both in the application and in Helm.

New chart was uploaded. Thanks again for the contribution :)


Cipher List Setting

Problem
can not connect some site. e.g. https://echo.websocket.org
https://www.ssllabs.com/ssltest/analyze.html?d=echo.websocket.org
Safari can respond 404 but HTTPSClient reset connection by peer
Reason
default cipher list "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4" is strict
so some server does not reach its requirement.
Fix
Able to set cipherList from HTTPSClient it can pass to TCPSSL and then
OpenSSL
it does not break current program because it uses cipherList: String? = nil so exsist code runs exactly it was before.

related:
https://github.com/Zewo/OpenSSL/pull/13
https://github.com/VeniceX/TCPSSL/pull/8
those need to be merged and tagged to for this.

fixed with openSSL for now not specify cipher at all


clang16Stdenv: init

Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

FYI: 82082e931fd

Oh, my! clang*Stdenv were aliases, while darwin.apple_sdk_11_0.clang*Stdenv were not. Should this be fixed?

Ah, I put the comment on different PR than I intended 🤦🏽 but it's yours again anyway.
The approach
# these are for convenience, not for backward compat and shouldn't expire

really feels unusual here to me, but I don't feel strongly either way.


Support jakarta EE 9

Hello
Are you planning to add support for Jakarte EE 9? Currently validation-api:1.1.0 is being imported.
Thank you

You might want to consider using a shading plugin to get the existing jar to work with Jakarta dependencies instead of javax. My understanding is that this module is deprecated - it is not planned to be part of Jackson 3.

Correct: this module is essentially unsupported. To support Jakarta would probably require change to multi-Maven build, doable of course but someone would need to do that.
And no plans for Jackson 3.x version: there are better tools available.


Add ci cd scripts

part of: https://issues.redhat.com/browse/RHCLOUD-16636
cc @BlakeHolifield can you take a peek at the scripts? I am wondering if we should use podman instead of docker.

With regards to podman v docker, it depends on what jenkins node these jobs run on. I'd say leave it as docker for now and we'll move to podman when we get this rolling.

@BlakeHolifield Thanks for the comments.


Howto : default settings for adding cards?

Hi,
Sorry, this is not a bug report or a feature request but I didn't know elsewhere post this.
I am trying to create a game and I need to create like 400+ different cards, which all have the same back image and need the same actions (make visible for me only, make visible for all, engage, stack and mix).
I found two ways to do so but which are not optimal :

Create one card with all the needed properties and then duplicate it and change the image at each time to create all the other cards
Drag and drop all the images of the cards and then change the settings and back image of each card

Is there another easy way to do so?
Thanks in advance for your answer!

Hey @El-Gavy
You can ask your question here without problem or you can go on the discussions section of this github project if you prefer.
I think the faster way to create your deck (I assume about 3 minutes) is to drag and drop all your images, then select them all and modify the back image and the actions for all cards at the same time. You can see an example in this quick video https://www.youtube.com/watch?v=E2lULjNFRl4
Does it help you ?

Thanks a lot @jrmi I tried it on a few cards and it seems to be working as expected!


[WIP] recent-edit page

About

Added '/user/:username([^/]+)/recent-edit'page

We'll implement this again in future.


Update ou.txt

removed outdated sets+bad UU mons

You're removing the additional empty line before new Pokemon. I don't know if the script requires two lines, but either way, it's the standard formatting here.


Build: Suppress IL2075 trimming warning

Description

Suppress trimming warning.
IL2075: 'this' argument does not satisfy 'DynamicallyAccessedMembersAttribute' in call to target method. The return value of the source method does not have matching annotations.
Currently we don't have a solution for this and we want to turn TreatWarningsAsErrors back on so we have to #pragma
How Has This Been Tested?

Build to check warnings gone.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[ ] I've added relevant tests.

@ScarletKuro I'm going to merge as the changes in this PR are as discussed and it builds and tests.


blueprint: abstract on-disk json/toml keys from struct data

This is a draft to show how we could move to a more unified/consistent "blueprint" package where we deprecate some keys and move to a single and consistent view of blueprints.
The end-goal of this is that this code will be part of a new "gitub.com/osbuild/bueprints" but that repo is not quite ready and patches would apply equally well. Here the concept can be discussed more easily.
The basic idea is that:

blueprint.Blueprint itself does not contain any json/toml keys
The parsing is done via blueprint.Load() and the json/toml structs are not expose
We will use "plural" for all arrays, e.g. "user" -> "users" and "group" -> "groups"
We will use underscore ("_") instead of dash ("-") consitently, this means "destination-path" -> "destination_path" etc

Unfortunately this is a lot of busywork, I'm not sure if there is an easier way, we could look into reflection to see if we can make this more elegant.
[draft because this needs at least toml loading and we need to adjust the rest of the code to not use the struct directly for unmarshal]
P.S. Naming ideas welcome too - fooOnDisk, fooJsonToml, fooJT, fooForParser, fooPF all feel cumbersome so far

I very much like the idea of this and I would like to push it even further. What bothers me that we have several blueprints:

image-builder
composer
images (JSON/TOML)

This is a great chance to not only find the good common blueprint format, but also to prepare ground for required transformations that will open doors for major OpenAPI changes later. Since I will have some spare time in the next quarter, I would like to take this idea and build on top of this draft. Let me know how you feel about the following plan.
First off, a terminology. I think since we will be dealing with many blueprint words I suggest the following naming conventions. Let’s discuss them, at least for the rest of this github comment I will use these:

common blueprint - the ultimate common type with extensions (more about them later)
distributed blueprint - on-disk blueprint format (I feel like on-disk is not a good choice for APIs)

First off, I would like to think about versioning and also prepare for transition in composer and image-builder by building an initial version of the common blueprint. Let’s call it common blueprint v0, it would have zero changes, just extracted type from the images library.
Now, versioning is an important one. I am thinking not leveraging Go native modules versioning but instead keep the module on the v1 forever (or maybe even never creating any git tag leaving it on sha-date v0 versioning scheme) and simply putting the common blueprint into properly named package. For example: github.com/osbuild/blueprint/cb0 would be a package for common blueprint v0 and db0 would be distributed blueprint v0.
The API would provide two interfaces: BlueprintReader and BlueprintWriter providing Load/Save capabilities as proposed in this draft PR. Instead of direct filenames, it would use Reader and Writer interfaces so it can be used easily in composer/image-builder. But the idea remains the same: distributed blueprint is separated from the common blueprint. And other project can build their own readers and writers into their native types or formats.
Now, I assume that the native blueprint in the images library has 1:1 mapping, but that is not the case for composer and image-builder I was told. But I would like to design the common blueprint to be bi-directional. Meaning, a distributed blueprint from image-builder could be converted to a common blueprint and back without loosing any data. This consistency will ensure the solution is future-proof and also will allow some nice test scenarios.
For that, I propose to create an "extension" field in the common blueprint, likely a slice or a map. Readers and writers could use the extension field to add own arbitrary data. For example, image-builder writer could put openscap tailoring information (insights uuid) there and reader could extract it from there if needed. This extension data would be only recognized by image-builder and ignored by other implementations.
Once v0 common blueprint and respective reader/writer are implemented, it can be relatively easily plugged into composer and image-builder while keeping their current APIs. Once that is done, only then I would suggest to do a common blueprint "cleanup" as proposed here and bump the version to v1. New readers/writers will need to be created for each version but this will allow us to start messing around with composer or image-builder APIs at its own pace. A huge benefit is what @ondrejbudai mentioned on our Prague meetup - have an API transformation for deprecated v1 API to v2 API.
The ultimate goal would be to use the "native" common blueprint readers and writers everywhere leading to one common format (JSON/TOML). But thanks to the separated types, we can gradually rollout major format upgrades.
I think that the new library should only provide the common blueprint, extensions, testing support, JSONSpec schema and interfaces with a default (reference) readers and writers. Individual readers and writers should be part of images, composer and image-builder repositories together with tests. Tho we could also explore the idea of hosting also all readers and writers in the new repository - having everything in one place is indeed a tempting idea.
Now, there is so much I do not know. Maybe this plan is too crazy, wrong or just too optimistic. Please let me know how you feel about this @mvo5 @supakeen @ondrejbudai @croissanne

I very much like the idea of this and I would like to push it even further. What bothers me that we have several blueprints:

image-builder
composer
images (JSON/TOML)

This is a great chance to not only find the good common blueprint format, but also to prepare ground for required transformations that will open doors for major OpenAPI changes later. Since I will have some spare time in the next quarter, I would like to take this idea and build on top of this draft. Let me know how you feel about the following plan.

Just ftr, in my mind, the one in osbuild-composer is the canonical blueprint format.
The one in images should have branched off and been renamed to something else when the split happened.  It would have avoided a lot of confusion about what "blueprint" means and where it's defined.

First off, a terminology. I think since we will be dealing with many blueprint words I suggest the following naming conventions. Let’s discuss them, at least for the rest of this github comment I will use these:

common blueprint - the ultimate common type with extensions (more about them later)
distributed blueprint - on-disk blueprint format (I feel like on-disk is not a good choice for APIs)

I would reserve the name "blueprint" for the schema we end up defining that will be used in osbuild-composer and eventually image builder.  The one that gets documented and we expect users to write and use to interact with all frontends of image builder.
Any other build configuration should be named something else to avoid confusion.  A "build config" for example that either adds extra bits of options or simplifies the schema because it has less requirements for backwards compatibility.
Let me illustrate both these extra bits and simplifications with examples:

In osbuild-composer, the blueprint needs to support two customizations that overlap: ssh keys and users.  When a user starts a build with a blueprint that contains both customizations, the ssh keys get converted to user customizations.  The ssh keys customization does not exist in the internal representation of the build configuration, but it exists in the user-facing blueprint for backwards compatibility.  So, here in osbuild/images, the sshkey customization does not exist and instead osbuild-composer merges the two customizations before passing the config on to osbuild/images.
Some options are defined on the command line when using osbuild-composer, like ostree stuff or the desired size of the image.  An internal build config should include these (if they will still exist), because osbuild/images or any other image generator shouldn't care about the distinction between options and blueprint.

If we had a BuildConfig (the name is not final, just an example) in osbuild/images that did both of the above, the interface to osbuild/images would be simpler and we would only need to do the conversion from Blueprint to BuildConfig internally.  It would also avoid confusion about the nature of this thing in osbuild/images called Blueprint and its relation to the osbuild-composer Blueprint.
The problem with this approach is that projects importing osbuild/images and wanting to support Blueprint would have to implement the conversion.

First off, I would like to think about versioning and also prepare for transition in composer and image-builder by building an initial version of the common blueprint. Let’s call it common blueprint v0, it would have zero changes, just extracted type from the images library.

I would extract it from osbuild-composer because that's really the canonical version right now.

Now, versioning is an important one. I am thinking not leveraging Go native modules versioning but instead keep the module on the v1 forever (or maybe even never creating any git tag leaving it on sha-date v0 versioning scheme) and simply putting the common blueprint into properly named package. For example: github.com/osbuild/blueprint/cb0 would be a package for common blueprint v0 and db0 would be distributed blueprint v0.

I think it would be nicer for adoption if we defined it as a schema.  Either OpenAPI or jsonschema or something like that.  Then structs for languages can be generated automatically.

The API would provide two interfaces: BlueprintReader and BlueprintWriter providing Load/Save capabilities as proposed in this draft PR. Instead of direct filenames, it would use Reader and Writer interfaces so it can be used easily in composer/image-builder. But the idea remains the same: distributed blueprint is separated from the common blueprint. And other project can build their own readers and writers into their native types or formats.
Now, I assume that the native blueprint in the images library has 1:1 mapping, but that is not the case for composer and image-builder I was told. But I would like to design the common blueprint to be bi-directional. Meaning, a distributed blueprint from image-builder could be converted to a common blueprint and back without loosing any data. This consistency will ensure the solution is future-proof and also will allow some nice test scenarios.

Yes, we should definitely do this for the service blueprints.

For that, I propose to create an "extension" field in the common blueprint, likely a slice or a map. Readers and writers could use the extension field to add own arbitrary data. For example, image-builder writer could put openscap tailoring information (insights uuid) there and reader could extract it from there if needed. This extension data would be only recognized by image-builder and ignored by other implementations.
Once v0 common blueprint and respective reader/writer are implemented, it can be relatively easily plugged into composer and image-builder while keeping their current APIs. Once that is done, only then I would suggest to do a common blueprint "cleanup" as proposed here and bump the version to v1. New readers/writers will need to be created for each version but this will allow us to start messing around with composer or image-builder APIs at its own pace. A huge benefit is what @ondrejbudai mentioned on our Prague meetup - have an API transformation for deprecated v1 API to v2 API.
The ultimate goal would be to use the "native" common blueprint readers and writers everywhere leading to one common format (JSON/TOML). But thanks to the separated types, we can gradually rollout major format upgrades.
I think that the new library should only provide the common blueprint, extensions, testing support, JSONSpec schema and interfaces with a default (reference) readers and writers. Individual readers and writers should be part of images, composer and image-builder repositories together with tests. Tho we could also explore the idea of hosting also all readers and writers in the new repository - having everything in one place is indeed a tempting idea.
Now, there is so much I do not know. Maybe this plan is too crazy, wrong or just too optimistic. Please let me know how you feel about this @mvo5 @supakeen @ondrejbudai @croissanne

I had the opposite idea, kind of.  I think the "official" schema should contain everything, the union of all Blueprints everywhere.  Sub-schemas of the common Blueprint would then be defined for different implementations, of even for different parts of projects.  For example, bootc-image-builder doesn't support the whole Blueprint, only a subset.  That would be up to bootc-image-builder to define.  Also, in osbuild/images, different image types support different parts of the Blueprint already.  The [customizations.installer] section only works for Anaconda installers.  [customizations.filesystem] doesn't make sense for a lot of image types (containers, ostree commits, installers).  Right now these restrictions are handles poorly by large, hard to follow functions in each distribution implementation.  A way to import or define a subschema to support would be a great way to unify this behaviour.

I very much like the idea of this and I would like to push it even further. What bothers me that we have several blueprints:

image-builder
composer
images (JSON/TOML)

Images should theoretically be the one in osbuild-composer (which is leading), we didn't split it out when images got split out and got a bunch of duplication. Hence I'd say we have two current incompatible blueprints: service (image-builder here), and local (composer here).

common blueprint - the ultimate common type with extensions (more about them later)
distributed blueprint - on-disk blueprint format (I feel like on-disk is not a good choice for APIs)

Just "blueprint" should be enough, I'd really dislike to split it out further than that.

First off, I would like to think about versioning and also prepare for transition in composer and image-builder by building an initial version of the common blueprint. Let’s call it common blueprint v0, it would have zero changes, just extracted type from the images library.

I don't understand this distinction is it what you want to have in the future?

Now, versioning is an important one. I am thinking not leveraging Go native modules versioning but instead keep the module on the v1 forever (or maybe even never creating any git tag leaving it on sha-date v0 versioning scheme) and simply putting the common blueprint into properly named package. For example: github.com/osbuild/blueprint/cb0 would be a package for common blueprint v0 and db0 would be distributed blueprint v0.

I'm not particularly well versed on Go module versioning but if that's what's commonly done then it sounds good.

For that, I propose to create an "extension" field in the common blueprint, likely a slice or a map. Readers and writers could use the extension field to add own arbitrary data. For example, image-builder writer could put openscap tailoring information (insights uuid) there and reader could extract it from there if needed. This extension data would be only recognized by image-builder and ignored by other implementations.

We can have implementations using osbuild/blueprints pass a slice of supported sections. What is the difference between sections (top-level keys) and having them under extensions?

Once v0 common blueprint and respective reader/writer are implemented, it can be relatively easily plugged into composer and image-builder while keeping their current APIs. Once that is done, only then I would suggest to do a common blueprint "cleanup" as proposed here and bump the version to v1. New readers/writers will need to be created for each version but this will allow us to start messing around with composer or image-builder APIs at its own pace. A huge benefit is what @ondrejbudai mentioned on our Prague meetup - have an API transformation for deprecated v1 API to v2 API.

Yes, a new version of blueprints (with a required version field) would be a nice idea.

The ultimate goal would be to use the "native" common blueprint readers and writers everywhere leading to one common format (JSON/TOML). But thanks to the separated types, we can gradually rollout major format upgrades.

I'd say that we should only support a single serialization format if at all possible (it might be difficult with the API).

Thanks for your comments.
I see that both of you do not like the newly proposed terms, I just could not dare to suggest two separate terms. I agree that "blueprint" term should be only used for the "main schema", and we should probably find better suited names for sub-formats.
The only thing that complicates this is that a new struct name will require a big patch in each and every project. Maybe the renaming can happen as a separate commit once the extraction is done. But that is just a technical detail.
So you are both saying that osbuild-composer should be the "main" schema source, not here. I see, I had no idea.

Either OpenAPI or jsonschema or something like that. Then structs for languages can be generated automatically.

I was planning schema, but I thought it is something that is not important now. I was planning to suggest "bottom-to-top" approach we utilized in launch service - we actually generate OpenAPI components (schema) from Go structs. This ensures that the schema is 100% Go "friendly" and there are no features which are difficult to work with. For example, enums. Other language bindings can be generated too as a follow-up step.
Then it looks like you both do not like the extensions idea. I am all for making the "main" blueprint a "catch-all" structure and then there is no need for an extension. The only drawback is that if we ever convert an API or "on-disk" format to the "main" blueprint in the future, there will always be some irrelevant fields that will appear in documentation (if we take advantage of schemas). That was my only concern and that is why I went down this idea. If you think exposing everything is better then I am all for it.

I don't understand this distinction is it what you want to have in the future?

I am not sure if I get your concern, but the only idea around extracting a v0 with zero changes first is just technical thing - I want to make sure that extraction goes smooth and everything works before I would start renaming or cleaning up the data structures. But this problem can be covered with tests nicely, so maybe doing it in one go is better option.

Called for a meeting next Monday about common blueprint format.


CTRL + CMD +  = strange behavior

I noticed something strange was going on when trying to map CTRL+CMD+LEFT/RIGHT in IntelliJ IDEA. For some reason IDEA registered CTRL+CMD+RIGHT=OPTION+TAB and CTRL+CMD+LEFT=OPTION+SHIFT+TAB.
Trying the same with AppCode registers the correct keystrokes, which is beyond me, baring in mind it's from the same company and essentially the same core as IDEA.
The same happens when I quit Karabiner and BTT.
Finally trying the same in EventViewer registers nothing. This is what I see in EventViewer when I CTRL+CMD+RIGHT:
eventType:keyMod          code:0x37       name:Command_L       flags:Cmd                                misc:KeyCode::COMMAND_L	characters:
eventType:keyMod          code:0x3b       name:Control_L       flags:Ctrl Cmd                           misc:KeyCode::CONTROL_L	characters:
eventType:keyMod          code:0x37       name:Command_L       flags:Ctrl                               misc:KeyCode::COMMAND_L	characters:
eventType:keyMod          code:0x3b       name:Control_L       flags:                                   misc:KeyCode::CONTROL_L	characters:

When I activate Karabiner.debug I can still see this when I press RIGHT while holding down CTRL+CMD:
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- UpdateEventFlagsCallback [ caught]: flags 0x00340009
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [ caught]: eventType 10, flags 0x80340009, key 0x007c, kbdType  44, repeat = 0
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- UpdateEventFlagsCallback [sending]: flags 0x00340009
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [sending]: eventType 10, flags 0x00340009, key 0x007c, kbdType  44, repeat = 0
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [ caught]: eventType 11, flags 0x80340009, key 0x007c, kbdType  44, repeat = 0
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- UpdateEventFlagsCallback [ caught]: flags 0x00140009
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [sending]: eventType 11, flags 0x00340009, key 0x007c, kbdType  44, repeat = 0
9/14/15 1:01:50.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- UpdateEventFlagsCallback [sending]: flags 0x00140009
9/14/15 1:01:51.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [ caught]: eventType 12, flags 0x80040001, key 0x0037, kbdType  44, repeat = 0
9/14/15 1:01:51.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [ caught]: eventType 12, flags 0x80000000, key 0x003b, kbdType  44, repeat = 0
9/14/15 1:01:51.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [sending]: eventType 12, flags 0x00040001, key 0x0037, kbdType  44, repeat = 0
9/14/15 1:01:51.000 AM kernel[0]: org.pqrs.Karabiner --Debug-- KeyboardEventCallback [sending]: eventType 12, flags 0x00000000, key 0x003b, kbdType  44, repeat = 0

Also tried with empty private.xml but same result.
What am I missing?

The command-control-arrow keys do not call [NSResponder  keyDown].
So, EventViewer cannot show these events.
It's an OS X limitation.

Ok so I understand this is not a Karabiner bug.
But how does AppCode detect these correctly? Should I avoid them altogether, or is there a workaround?

It depends input event handling in each apps.
If AppCode does not recognize command-control-arrow keys, you should change these key combinations to other combinations by Karabiner.

AppCode is the only program that recognizes them correctly like I said in my original question. IntelliJ IDEA recognizes CTRL+CMD+RIGHT as OPTION+TAB which I thought was very weird.  Anyway I respect your time so I'll research this on my own. I was wondering if you could point me to any further information with regards to the following:

The command-control-arrow keys do not call [NSResponder keyDown].
So, EventViewer cannot show these events.

I got it.
To receive these events, we should override [NSApplication sendEvent].
https://github.com/tekezo/Karabiner/blob/master/src/util/EventViewer/Classes/EventViewerApplication.m#L8-L12
I changed EventViewer at v10.9.9.
EventViewer also shows command-control-arrow keys.

Great work as usual. Thanks!


Received data points from Kiosk Override HA History

Describe the bug
Now that #178 is fixed, my HA is receiving kiosk data again, but every received data point overrides the previous, which means no history is being build.
So eg the real time power sensor only every shows the latest data point of max 30 mins old and nothing before that.
** Debug information **
Answer the questions below before submitting a new issue.

Are you using the latest version of Home Assistant? 2024.6.4
Are you using the latest version of this integration? Yes
Have you looked into the closed issues and did not find a similar issue. Kind of related to 178
Are you using Kiosk or Northbound / OpenAPI mode? Kiosk
If you are using Kiosk mode. Have you checked that the url is still valid? See I am using the kiosk mode, but the data is not updating yes, I updated the kiosk url in relation to 178
If you ar using Northbound / OpenAPI mode. Check if your credentials are still valid. See How can I verify my Northbound API / OpenAPI credentials?
Have you checked the logs for any info? No as I don't know where to find them

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
With every data point received from the kiosk, HA builds a history of the points, instead of only recording the latest one.
The below screenshots look the same, but they're at different kWh and they show that no history is recorded.

Screenshots
If applicable, add screenshots to help explain your problem.

You can switch on debug logging on the integration page.

Thank you. It comes up with this:
2024-07-05 12:39:11.133 DEBUG (MainThread) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk] calculated API base url for ABCDE: https://uni004eu5.fusionsolar.huawei.com 2024-07-05 12:39:11.134 DEBUG (MainThread) [custom_components.fusion_solar.sensor] fusion_solar 2024-07-05 12:39:11.134 DEBUG (MainThread) [custom_components.fusion_solar.sensor] ABCDE 2024-07-05 12:39:11.675 DEBUG (SyncWorker_9) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk_api] Received data for ABCDE: 2024-07-05 12:39:11.676 DEBUG (SyncWorker_9) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk_api] {'realTimePower': 1.343, 'cumulativeEnergy': 11742.800000000001, 'monthEnergy': 86.11, 'dailyEnergy': 11.120000000000001, 'yearEnergy': 2720.17} 2024-07-05 12:39:11.679 DEBUG (MainThread) [custom_components.fusion_solar.sensor] Finished fetching FusionSolarKiosk data in 0.545 seconds (success: True)
And this gets repeated every 10 mins.

I also tried removing the integration completely and adding it again which hasn't worked. Still HA only ever shows 1 data point and the previously reported point is no longer available.

I'm closing this as I'm a complete noob and this is totally a me issue and not anything to do with the integration. Sorry! (When re-adding the integration I renamed the sensors differently by accident and seeing I have several things excluded from the recorder, these were now also excluded...)


Refactor proxy authentication mechanism

simplified way howto authenticate to proxy hub and other registries in following changes
this is here to split PR  from https://github.com/ContainerSolutions/trow/pull/250 to multiple steps
please check it and I will fix  what I can fort  this part
Refactoring reflects what server is sending in www-authenticate header on first request, which  should  contain realm and additional variables necessary for further authentication. It was tested  registry-1.docker.io with and without user account. It was also tested against Azure registry.

This looks good. The major thing that's missing is some tests. Do you have tests working at the minute if you run cargo test? If not, I'll help you set it up.

@sopak could you e-mail me at<EMAIL_ADDRESS>I'm keen to help get this merged and I'd like to understand your use case.
BTW I realised fmt wasn't running on the server code when looking at this, so I've just enabled it. Unfortunately that means there is a bunch of conflicting formatting changes on the main branch which will be a pain. It's probably worth rebasing and/or running cargo fmt yourself. Sorry for the hassle, but it will make merges easier in the long term.


Fix appveyor

this should fix the sed command in appveyor.yml - leaving in draft mode until confirmed

sorry, i made a mess with this attempt at a merge request, please ignore it


Set avro schema configuration in format bundle

Rather than managing the avro reader schema configuration in the input
format, it needs to be managed in the format bundle. Otherwise a crunch
pipeline that has multiple inputs (kite views) with different schemas
will not see the correct reader schemas.
Note that the test only demonstrates the problem when also upgrading to
crunch 0.13.0 (which is not part of this commit). This is due to
CRUNCH-551 which is a fix for a problem in crunch that hides the current
issue (at least in the scenario of the test) in versions before crunch-0.13.0.

Closing in favour of an updated pull request.


Replace react-otp-input with shadcn otp-input

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR introduces a new OTP input component using the input-otp library, along with related animations and configuration updates. It replaces the existing react-otp-input dependency and enhances the onboarding email confirmation process.
Detailed summary

Added input-otp dependency to package.json.
Removed react-otp-input from package.json.
Updated tailwind.config.js to include caret-blink animation.
Created new components: InputOTP, InputOTPGroup, InputOTPSlot, InputOTPSeparator.
Refactored ConfirmEmail.tsx to utilize the new OTP input components.
Improved styling and functionality for OTP input slots.

The following files were skipped due to too many changes: pnpm-lock.yaml

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#4889  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @MananTank and the rest of your teammates on  Graphite


Update LYRX file for Pro 2.2 labeling

Updated LYRX file to support labeling numbered structures in Pro 2.2

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.

@topowright - new commit solves the problem. Note that there is a new featureset added in featuresetWebMerc.gdb to support the LYRX file.

Explanation:
To apply symbology from a LYRX file to a new layer in Pro, the source data from that original LYRX file has to be visible.
I have copied a feature class in to the featuresetWebMerc.gdb to supply this.
The tool is now working correctly for me.
I am also seeing it add a Number field correctly when none is present or specified on the input feature class.


Add locale for vietnamese version

Please review and merge it for multiple languages purpose, thanks

Devise doesn't include translations and neither do I, you can add them to wiki:
https://github.com/scambra/devise_invitable/wiki/I18n


Development, scss and config.assets.debug = false

When using application.css.scss and @import everything works fine, when asset.debug is set to false.
But when it is set to true, the file extension should be removed.
i.e.
sth. like this works when assets.debug is set to false:
*@import "plugins/jquery.mCustomScrollbar.css"; *
but when its set to true css is not included (because it has got extension). It will be ok:
*@import "plugins/jquery.mCustomScrollbar"; *

I'm not sure what you mean. What is the issue with rails-assets? What do you want us to change?

Closing due to lack of feedback for nearly one year.


Prevent concurrent relocations on same pair of servers

I don't have a very precise description of the problem but basically it was as follows. A colleague and I were talking about adjusting the topology of some servers in a replication chain and both used the UI at the same time to relocate servers with the end result being that we generated 2 co-masters replicating from each other, each co-master having slaves under it.  These co-masters had originally been intermediate masters below the primary master.
That should not happen. It looks like I decided to relocate one IM under another one and my colleague at the same time did the opposite action.
Configuration of servers were using MySQL 5.7 with Pseudo-GTID.
I discussed with Shlomi and he states that there is a maintenance lock to try to prevent this but it doesn't lock both the server being moved and the destination server.
His suggestion was to add an additional check to see if a lock already exists and not proceed if it's found to avoid this simultaneous relocation happening.

Oh as a comment on how we fixed this setup of a primary master and some slaves, and 2 independent co-masters replicating from each other and each having their own slaves too.
$ orchestrator -c relocate -i <server to move> -d <primary_master>

fixed the problem. Nice and +1.

When relocation A below B, A is placed under maintenance, but B isn't, and the intention was to be able to relocate further servers, like C below B. B isn't being changed, so why lock it.
However, this introduces the possibility to concurrently relocate A below B as well as B below A.
I still don't want to add a lock on the would-be parent (B in our story). However, it should be simple enough to avoid relocating A under B in the event B is itself locked, without placing a lock on B.

To add: IsUnderMaintenance(instanceKey * InstanceKey) ; to check in matchBelow().

Fixed by #420


Saved image size depends on 'image-preview' size

Hello guys! First time writing in github.
I am playing a little bit with this cool tool around, and it works really nice! The only thing that bothers me at the moment is, that the image I export as an image file is as large as I set the image preview file size, for example: .cropit-preview { width: 360px; height: 360px; } - my image file will also have the pixel size.
Since I want the preview window to be relatively small (360x360px), I get a low quality image (just 360x360px). Is there a way to set up a smaller window size while keeping a good quality image file at exportation?
Thanks in advance!

I've got it by using 'exportzoom':
$('.export1').click(function() {
var imageData1 = $('#image-cropper').cropit('exportZoom', 2.5);
imageData1 = $('#image-cropper').cropit('export');


SSE Mode: Error when connecting

Hi everyone,
thanks a lot for this library!
I was just trying out the Echo demo with sse transport and there seems to be an error in the ASGI exception wrapper. The inspector can list the tools and resources, but on every request an error occurs inside starlet (TypeError: 'NoneType' object is not callable)
# demo.py
from fastmcp import FastMCP

mcp = FastMCP("Echo 🚀")

@mcp.resource("echo://{message}")
def echo_resource(message: str) -> str:
    """Echo a message as a resource"""
    return f"Resource echo: {message}"

@mcp.tool()
def echo_tool(message: str) -> str:
    """Echo a message as a tool"""
    return f"Tool echo: {message}"

@mcp.prompt()
def echo_prompt(message: str) -> str:
    """Create an echo prompt"""
    return f"Please process this message: {message}"

if __name__ == "__main__":
    mcp.run(transport="sse")

Then executing python demo.py and fastmcp dev demo.py and connect via localhost:8000/sse.
I included a minimal reproduction repo here: https://github.com/eiseleMichael/fastmcp-sse-test
This might be related: https://github.com/modelcontextprotocol/python-sdk/pull/83
Let me know if you need more info or if I'm just using it wrong :-)

Unfortunately, I’m encountering the same problem while trying to use SSE transport. I was wondering if anyone has made progress on identifying the root cause or has any leads on how to resolve this? Any pointers would be greatly appreciated!
Thanks in advance to anyone who can help shed some light on this! 🙏


Bug: Mixed/wrong language translations in context menu

Description
Opening the context menu on a system with multiple languages installed causes some of the commands to appear in a different language. See attached image for example

My case could be even more specific as I am currently an English system and UI language, Italian locale for dates and numbers, and English and Traditional Chinese keyboards layouts installed. The "Notepad", "File Locksmith" and "PowerRenamer" entries are localized in Traditional Chinese instead of the expected English. Default context menu to show that they are actually properly shown in Windows

Steps To Reproduce

Have a system with multiple languages installed and possibly PowerToys or Notepad++ installed
Open the context menu for any file

Requirements
Show the correct language for all menu entries
Files Version
<IP_ADDRESS>
Windows Version
10.0.19045.4894
User ID
524eb47d-c4cf-4bc8-962b-178c05e044d3
Log File
debug.log

Well, I can work on this issue maybe

I think this is an issue with Windows.

@Lamparter I think that there should be modification on code like system is using multiple languages, the app should fetch the display language from the user's settings and apply it consistently

The extension label is pulled from Windows but in theory, it should match File Explorer. It's worth looking into this to see if we can pull a different value.

https://github.com/notepad-plus-plus/nppShell/blob/7b715ada2749321f0bf8fc08a5587ea2d10ab9cf/NppShell.rc#L108
I wonder what the result of GetThreadUILanguage.
Looks like SetThreadUILanguage changes .rc file's resource system switch.


Update chart versions

@bryantbiggs hello 👀

@kahirokunn Thanks for making the changes. I think merging these changes will unblock a lot work.

I hope this PR will be merged.


Program exits after "Game bindings path"

When I run the program, I see:
PS C:\Program Files\Hogwarts Legacy - SpellCaster> .\Whisper-Spell.exe
    *********************************************
    ***                                       ***
    ***    Program created by Cornebidouil    ***
    ***    https://github.com/cornebidouil    ***
    ***                                       ***
    *********************************************

NVIDIA card: 1
Game bindings path : C:\Users\phil\AppData\Local\Hogwarts Legacy\Saved\Config\WindowsNoEditor\Input.ini
And then the program exist. I am never asked to select a microphone or such. Ideas ?

Hello Philmosby,
Well it could be related to the configuration of the keybindings. I can propose you to join the project's discord to have a more interactive discussion: https://discord.gg/gzCbh2SM
And make it easier to find a solution!


Added sort to @role_list.each.

Adding sort to the role list display, makes it easier to read the list when you have 60+ roles.

Thank you for supporting Chef! Our process has a couple prerequisites before we can merge your contribution. We need to ensure you've completed a Contributor License Agreement (CLA) and a ticket on our ticket tracker for the release workflow. Pull requests are optional, but should always include the ticket number that they're related to for cross-referencing. Please take a moment to review the below wiki page for the appropriate steps:
http://wiki.opscode.com/display/chef/How+to+Contribute


how to train vision-based policy

Hi, Thanks for the amazing work!
We have successfully trained a state-based RL model on drawer and would like guidance on generating operation data based on point clouds and further training the vision-based policy. We would appreciate your expert advice on the recommended approach for achieving this.
Thank you for your assistance.

Will release as soon as possible after testing!

@geng-haoran Any update on this?

We put the original code in the branch "not_polish". We will refine them as soon as possible to fit into our existing released framework. check it at PartManip/not-polished_code in branch "not_polish".


Change compose lock to use DataStore()

In some rare (?) circumstances, DataRoot might not exist yet (eg: fresh install, first command being run being a compose command).
Changing the lock location to rely on DataStore() instead, which does provide existence guarantee (and is also a bit more specific).
Failure was seen on unmerged PRs CI runs when parallelization triggered an execution order that produced the situation above.

@AkihiroSuda at your convenience.

@djdongjin if you are still around, I can use this to fix CI bustage on upcoming PRs (specifically #3535)


fix(recurringjob): keep snapshots for the backup

Add a new global setting that allows users to keep the retain number of snapshots when the recurring job does a backup.
Ref: longhorn/longhorn#2997

@mergify backport v1.5.x


get image links from storage

each json data item has an image on cloud storage, grab the link and add to the provided space in the file

@JemimaNaomiBen comment here so I can assign this to you

How do I access the cloud storage

drop the gmail I can add you with

<EMAIL_ADDRESS>


Add SimpleDB IAM template

I tested this change locally and it works as expected.
One feature we may want to implement is a sdb resource name check to ensure it matches some combination of the project/repo name to isolate permissions.

This looks good to me 👍


update to polaris 1.0 for CI/CD

LGTM, i think you need also to update the version... version.txt

Barnie Thank you so much! I thought I had that's a really good catch