Parent-Childs hierarchy

The idea is, I want to build the hierarchy after rendering. The component will know and easy to access its parent and child component by using Parent and Childrens property.
Is there a way to achieve this?

I have a work-around, hope this helps someone try to address some issue.
`
 protected override void BuildRenderTree(RenderTreeBuilder builder)
        {
            if (CSHTMLHelper.PARENT == null)
            {
                CSHTMLHelper.PARENT = this;
            }

            Parent = CSHTMLHelper.PARENT;
            CSHTMLHelper.PARENT = this;

            if (Parent != null
                && Parent != this)
            {
                Parent.Childrens.Add(this);
            }

            base.BuildRenderTree(builder);

            CSHTMLHelper.PARENT = Parent;
        }

`


Add script to import huggingface model into djl model zoo

This feature allows users to import huggingface models into DJL model zoo.

It will download huggingface models and use pytorch jit to trace the model. It also saves the model in DJL model zoo format.
The script can allows you to limit the amount of models that are loaded so that you don't have to import all of the models at once. Previously imported models will be ignored.
The traced model will be validated using sample input and output. If the model validation fails, the model will not be imported and will be marked as import failure.
If the machine has GPU, the validation will use GPU to run the inference and make sure the model works on GPU.

This program is only tested for the question answering model. The top 20 question answering on huggingface have been tested.
The exported model zoo. model has been manual tested with DJL huggingface QuestionAnsweringTranslator.
This script may not work with non-english models.
To run this program you must install the dependencies described in the requirement.txt file and make sure transformers and huggingface_hub are on the latest version.
Some models have dependencies on protobuf. The protobuf version has to be on 3.20.0.

Codecov Report

Merging #1835 (e2101ab) into master (bb5073f) will decrease coverage by 2.36%.
The diff coverage is 64.82%.

@@             Coverage Diff              @@
##             master    #1835      +/-   ##
============================================
- Coverage     72.08%   69.72%   -2.37%
- Complexity     5126     5523     +397
============================================
  Files           473      526      +53
  Lines         21970    24427    +2457
  Branches       2351     2660     +309
============================================
+ Hits          15838    17031    +1193
- Misses         4925     6084    +1159
- Partials       1207     1312     +105

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...main/java/ai/djl/modality/cv/output/Rectangle.java
72.41% <0.00%> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

...odality/cv/translator/BigGANTranslatorFactory.java
33.33% <0.00%> (+8.33%)
:arrow_up:

...nslator/InstanceSegmentationTranslatorFactory.java
14.28% <0.00%> (-3.90%)
:arrow_down:

.../cv/translator/SemanticSegmentationTranslator.java
0.00% <0.00%> (ø)

.../cv/translator/StyleTransferTranslatorFactory.java
40.00% <ø> (ø)

... and 420 more

Continue to review full report at Codecov.

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


Keyboard does not work when runing keyd as a runit service on Void Linux

I'm using Void Linux and autostarting keyd on boot. When i enter sway or river (wayland window managers), my keyboard does not work.
If i start keyd AFTER starting sway or river (with sudo keyd on river init file), it works fine.
The service file on Void Linux (it uses runit instead of systemd) has just 'exec keyd'.
It's keyd v2.4.1

They keyboard is not responsive and i have to shutdown using the power button.
It probably is a problem of timing. I disabled the service and now i start when i enter the graphical environment and everything is working flawlessly

This sounds like a distro specific init issue. Can you post the keyd log output from the problematic initialization? I assume there is some way to recover it from runit, though I am unfamiliar with it.

Weird. I reverted back to using the runit service and the problem is gone. I'll use a few more days and report back if anything happens again. If not, i'll close the issue.

I have a similar problem on Void Linux when i start it using runit. It seems to capture all keyboard input when the X server starts up. When I use the escape sequence, keyd restarts and then it's all good. i can login and the mapping works.

The problem came back and looking at log files, it does not seem to show anything.
Here is what i found in svlogtail:
keyd_log.txt

I spent some time digging into this, and it looks like it is indeed related to initialization order.
From what I understand void initializes udev twice (for reasons I don't fully understand), once as a core service and then again as a system service.
The system service kills the original instance and then starts a new one, creating a gap in which udev is not actively monitoring kernel events. It seems keyd is started between the first and second udev instances which prevents eudev from responding to the kernel event and creating a database entry. This subsequently causes libinput/X not to identify it as an input device.
If my understanding is correct, this should probably be regarded as a void bug, but it is possible I have misunderstood something.
In the meantime the solution is to add a timeout to the keyd runit service, E.G:
#!/bin/sh
sleep 1
exec keyd

or else to simply disable the system udev service (rm /var/service/udevd) and rely on the core-service, though this might have other implications.
or else to simply disable the

The second call as a system service is then needed so that udev is monitored by runit (and can for example be cleanly terminated on system shut down).

This makes sense, though it seems like a bit of a kluge.

While this should very likely fix the problem most of the time, it technically still does not guarantee proper startup in all cases.

Indeed, it was intended as stopgap.

The safest route here is to check whether the “right” (i.e. system service) udev is running, using a combination of runit's sv status and udevadm control --ping instead of the sleep.

I considered this, but neither will work. The second will produce a false positive before the first instance of udev has terminated and the first will produce a false positive after the init script has been run but before the second instance has been started.

For the same reason, this issue can be closed here as keyd itself can't do anything about it.

+1.
I'm closing this for now.

pinging @

^pinging @Barbaross93 who appears to be the void package maintainer.

Hey @rvaiya, thanks for the ping.
I've been having this problem as well and was just using the Backspace+Esc+Enter key combo and letting the service restart keyd.
Regarding your earlier comment:

The safest route here is to check whether the “right” (i.e. system service) udev is running, using a combination of runit's sv status and udevadm control --ping instead of the sleep.

I considered this, but neither will work. The second will produce a false positive before the first instance of udev has terminated and the first will produce a false positive after the init script has been run but before the second instance has been started.

Por que no los dos?
We could do something like:
#!/bin/sh

sv status udevd || exit 1
udevadm control --ping || exit 1

exec keyd

In this way, we first check to make sure that the udevd service started before checking to see if its actually operational. The problem currently is that eudev for whatever reason doesn't have the --ping flag for the control subcommand. I've been looking over the man page and haven't really found a suitable replacement. Any ideas @herrsimon ?

The problem with that is there is still a window in which the service has started but the old udevd is still running. This may or may not be an issue in practice, but it is still technically a race condition.

The problem currently is that eudev for whatever reason doesn't have the --ping flag for the control

You could check if the process exists using something like pgrep, but the problem above remains.

Hmm, I suppose that's true. It's about a one half of a split second wide window with those checks, but it is a window nonetheless.
Well, the good news is that runsv keeps track of the pid of the program that is being supervised. All we need to do instead is confirm that the currently running udevd has the same pid as the one that is being supervised.
So something like this should work:
#!/bin/sh

sv_pid=$(sv check udevd | cut -d'(' -f2 | cut -d')' -f1 | cut -c 5-)

[ "$sv_pid" = "$(pgrep -x udevd)" ] || exit 1

exec keyd

Obviously it could be cleaner; this is just a quick proof of concept.

That looks like the ticket. You can use the supervise subdirectory in the service directory to get the pid directly instead of parsing sv check. You should probably also redirect the output to a log file to avoid polluting stdout and make soliciting logs easier.
Something like this:
#!/bin/sh

[ "$(cat /var/service/udevd/supervise/pid)" = "$(pgrep -x udevd)" ] || exit 1
exec keyd >> /var/log/keyd.log 2>&1

I want to post this here being the only Void related matter I could find, is setup the same, meaning create a keyd folder in /etc and putting the config in there? Asking just because I am new to Void


Only define __dead if it's missing

I propose we only define __dead to the empty string if it's missing
since the current ifdef-logic is rather complex and we don't want to
maintain support for all various platforms and compilers.

Good call. Looks good to merge!

Thanks, merged.

Thanks, merged.


Integration test stage damage

Once you have those test cases set up, re-request review, and we'll get this branch merged.


[ENH] should we have a reset method?

Should sktime estimators have a reset method that sets the estimator's entire state to what it would be after initialization?
The main reason is that this would be a clean way to reset the estimator at the beginning of fit whenever called for the second or any repeated time.
This would prevent bugs such as in #1595 which can lead to unexpected and hard-to-debug behaviour in grid search etc, where fit might be called multiple times.
Of course, a "clean" implementation would use clone, but not all contributors/extenders are aware of the convention.
A more implementer friendly logic is the described behaviour, where fit resets the estimator when called a second time - this is "like" a call to sklearn clone, but it requires no proactivity and advanced knowledge of sklearn internals.
FYI @mloning, @aiwalter, @ltsaprounis, @danbartl, @TonyBagnall, opinions?

@fkiraly - Should we also raise another issue to add clone in all Cross Validation and Grid Search classes/functions?

@ltsaprounis, excellent idea! Could you kindly open this and point to the instances where it's not done?

Will do shortly, need to find where we need to do it and make a checklist.


Clarify documentation around selecor.relabel-config option

[ ] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.
[x] Change is a doc change

Changes
Clarify the sharding configuration on the various components.
It was unclear to me that the relabel configuration acted on the blocks, not their contents. The link to the prometheus relabel config docs was also not very helpful, as the selector config only supports a few of the actions. I've made it link to the sharding documentation instead, which is more helpful and contains a link to the prometheus relabel config specification anyway.

Verification
make doc

I went and improved some of the text on the sharding page too while I was at it, I hope I understood it all correctly.


Intake openfe graphml

Fixes #1192
Developers certificate of origin

[X] I certify that this contribution is covered by the MIT license as defined in our LICENSE and adheres to the Developer Certificate of Origin.

@jthorton you may find this useful for running PLB as discussed cc @JenkeScheen

@jthorton this is ready to go now, would you be able to review?

@jthorton I think this is ready for another round of review!


Problem with OOV words

Can anyone tell me, why i received 2 different rouge scores when:

Both summary and reference used <unk> for OOV words
Both summary and reference used UNK for OOV words

For example, a piece of Gigaword:
summary file (summary.txt):

nec UNK computer to join forces
sri lanka closes schools schools
five anti-nuclear protesters arrested
factory orders up #.# percent in september
bank of tokyo urges calm after us decision
croatia croatia agree to meet saturday
toyota banned from world rally championship
israel prepares for rabin 's state funeral
indian pm 's promise of more autonomy for kashmir
UNK UNK UNK UNK
turnout heavy for trinidad and tobago
jordan 's crown prince hassan visits jerusalem
poland 's main opposition party endorses walesa
rand gains against dollar
amnesty international condemns guinea arrests
syrian woman arrested in turkey on terrorism charges
hong kong us sign air agreement
us citizen given suspended sentence for spying
love leads world cup of golf
france names team for second test

reference file (reference.txt)

nec UNK in computer sales tie-up
sri lanka closes schools as war escalates
protesters target french research ship
us september factory orders up #.# percent
bank of UNK UNK for calm in financial markets
rebel serb talks to resume saturday : tudjman by peter UNK
toyota are banned for a year
israel prepares jerusalem state funeral for rabin
indian pm 's announcement on kashmir polls autonomy sparks outrage
russian liberal party wins registration
trinidad and tobago poll draws heavy turnout by john babb
jordan 's crown prince makes first visit to jerusalem
walesa receives opposition boost
rand gains ground
amnesty deplores human rights violations in guinea
canada investigates syrian woman with alleged ties to pkk
hong kong us sign breakthrough aviation pact
us citizen who spied for east germans given suspended sentence
americans lead UNK by ## strokes
french keep same team for #nd test

with command: files2rouge summary.txt reference.txt, rouge scores are:

1 ROUGE-1 Average_R: 0.44461 (95%-conf.int. 0.34635 - 0.54301)
1 ROUGE-1 Average_P: 0.50481 (95%-conf.int. 0.38311 - 0.61899)
1 ROUGE-1 Average_F: 0.46588 (95%-conf.int. 0.36164 - 0.56812)
1 ROUGE-2 Average_R: 0.21717 (95%-conf.int. 0.12431 - 0.31208)
1 ROUGE-2 Average_P: 0.25701 (95%-conf.int. 0.14881 - 0.37060)
1 ROUGE-2 Average_F: 0.23201 (95%-conf.int. 0.13381 - 0.33325)
1 ROUGE-L Average_R: 0.39034 (95%-conf.int. 0.30762 - 0.47060)
1 ROUGE-L Average_P: 0.44722 (95%-conf.int. 0.34667 - 0.55026)
1 ROUGE-L Average_F: 0.41168 (95%-conf.int. 0.31882 - 0.49881)

But when I replaced all UNK by <unk> in both files, run with the same command: files2rouge summary.txt reference.txt, rouge scores are:

1 ROUGE-1 Average_R: 0.52403 (95%-conf.int. 0.40460 - 0.63460)
1 ROUGE-1 Average_P: 0.52284 (95%-conf.int. 0.39659 - 0.64956)
1 ROUGE-1 Average_F: 0.49917 (95%-conf.int. 0.38423 - 0.60513)
1 ROUGE-2 Average_R: 0.25412 (95%-conf.int. 0.14458 - 0.38097)
1 ROUGE-2 Average_P: 0.24722 (95%-conf.int. 0.13810 - 0.36190)
1 ROUGE-2 Average_F: 0.22912 (95%-conf.int. 0.13134 - 0.33379)
1 ROUGE-L Average_R: 0.46976 (95%-conf.int. 0.35841 - 0.57774)
1 ROUGE-L Average_P: 0.46525 (95%-conf.int. 0.34667 - 0.57706)
1 ROUGE-L Average_F: 0.44497 (95%-conf.int. 0.34012 - 0.54241)

Hi,
Thanks for reporting it. All I can say for now is that this isn't any kind of know issue/behavior.
It seems like the < is interpreted, somewhere, i.e. i tried multiple replacement for UNK, it turns out things are weird when < comes in (even when alone, i.e. sed 's/UNK/</g).
Use any token without <.
You should only take the scoring with UNK into account.


bls test vectors

Test vectors for bls12-381, still under construction!

What's going on? Why are we getting PRs with Rust?

So this is for the test vectors. We were thinking the other day with @tdammers were should the script that creates test vectors for BLS12-381 bindings live. The conclusion was that the best place for that code to live was in the repo where the test-vectors lived, hence cardano-base. However, this is obviously open to discussion if you think it should be outside of the repo.
The motivation to put it here is that we could include a test in the CI that checks that the file used for the test vectors is equal to what is generated by the rust script. However, the idea is that we don't put any dependencies on the haskell build with rust. i.e., the rust script only needs to be run by the CI or anyone wanting to re-generate the test vectors.
WDYT?

I understand. The reason why we decided to do the test vectors in rust was to compare the library we use (blst) with zkcrypto's library of the same curve, which is a library used in production. Creating the test vectors in C or Haskell would require bindings, and we'd depending on the rust library regardless, so IMO it doesn't really make sense.
I understand wanting to leave rust outside of the build CI, in which case we can upload the rust code in another repo, link to that in the README and only have here the test vectors.
If that's your preferred path, we'll go that way 👌

Creating the test vectors in C or Haskell would require bindings

I don't understand why would we need any sort of bindings if we wanted to write a C program that generates test vectors. I would expect it to be same as the rust program in this PR, which depends on Rust implementation of bls, except that program would be written in C and depend on then C implementation bls

I understand wanting to leave rust outside of the build CI, in which case we can upload the rust code in another repo, link to that in the README and only have here the test vectors.

If you think what I am suggesting is too hard to do then we don't need to waste any time and I am not gonna stand in way of having this code in this repo. After all, it will only be used once to generate the test vectors. If we had to run it on CI and locally every time we had to run the test suite that would be a different story and I would be pushing back much harder against it.

my intention was to include a check in CI that the test-vectors file used for tests corresponds to the output of the rust binary

The output of the Rust program will be checked-in in this repo, no? Then why do we need to run Rust on CI?

But we want to create these test vectors with the rust library, which is the 'other' reference implementation of bls12-381. We could do it with the underlying library, but the goal of these test vectors is that they are independently generated.

Which library are you trying to test? Are you trying to test the libblst library implementation or do you want to test the Haskell binding to liblst that we provide in cardano-crypto-class library? If it is the latter, then there is nothing wrong with using the same C library to generate test vectors. However, if it is the former and you want to test that Rust implementation matches the C implementation, then such test suite has no business being being in this repository as it is unrelated to our Haskell bindings in any way. A test like this would belong in either the Rust library or in the C library repository.
My understanding was that the reason for writing this script in Rust was only because it is easier to write Rust, rather than C.

@iquerejeta This PR is up your alley. We've already talked about this work, so if you can oversee this work further that'll be great.
I suspect Haskell tests will be added in a separate PR, right?

Haskell tests will be added in a separate PR, yes. I will oversee the PR. If you could approve it to unblock your change request, so that once I approve we can merge.


Auto updates fix - update actions main

Changes

:broom: Update Github actions

/kind cleanup
Fixes #19
Fixes #5

I wonder if closing the older PRs and letting knative-automation create fresh ones would have the same effect maybe? Anyway manual update is also fine I guess. :)

It won't. I needed to do things in https://github.com/knative-sandbox/kn-plugin-event/pull/58/commits/ad11c478796a5314e69c4dbdef69714fbfe86095 to make it work.

/cc @dsimansk
/cc @rhuss


Create a template-lidar-plot repo and populate it

Task to do
Create a Lidar plot-level template similar to template-rgb-plot template except dealing with Lidar data.
Reason
Enables plot-level Lidar algorithm developers to easily create working workflow components
Result
Have a repository that can be used as a template to create new workflow algorithms
Steps to take

[x] Create algorithm_lidar.py template file (filled in)
[x] Create generate.py executable script that's used to create Dockerfile and supporting files
[x] Create testing.py executable script to be used when testing algorithm
[x] Obtain plot-level lidar files, ZIP them together and place on google drive along side the RGB testing files
[x] Create HOW_TO.md file with detailed instructions on how to use new template file
[x] Let AgPipeline owner know when new repository is created so correct permissions can be applied to repo
[x] Integrate into TravisCI: use testing.py script to validate default algorithm using ZIP of Lidar data (include pylint, etc as well)

Notes:

cloning the template-rgb-plot repo to use as a starting point is probably the fastest approach to finishing this
the generated Dockerfile should reference the Lidar specific base image (created through different ticket(s))

Link above is no longer relevant, this repo has been moved to it's rightful home below
https://github.com/AgPipeline/template-lidar-plot/tree/master

PR is located here
https://github.com/AgPipeline/template-lidar-plot/pull/1


added missing numbered module dependency

@matt-kruse<EMAIL_ADDRESS>uses the numbered module, but it's not specified in the package.json file. This fixes it. Should publish a new version to npm asap because the current version is totes busted. :-/

Wow, I'm not sure how that happened. Thanks for the quick fix.

At some point we should add some basic tests based on https://www.npmjs.com/package/tap and add this as a prepublish step in package.json. Won't totally fix the problem but it'd give some nice fast boundary checks.

Agreed, would love to have tests, especially since this framework is getting increasingly popular.
BTW, this missing dependency was introduced in the SSML merge, which is why I missed it. I need to pay closer attention when merging other peoples' pull requests...

I'm working on another PR with some fledgling tests and the prepublish hook. I'll have something for ya in a few mins.

see https://github.com/matt-kruse/alexa-app/pull/48
I went with tap because it's very lightweight and minimal. I tend to prefer tiny testing libraries rather than large frameworks.


[Feature] Add an approach to build and commit images of flows

Feature Description
Currently, we have a build mechanism for the flows; however, this requires a stakeholder to clone and build this locally to view the images. This issue proposes a practice to build images of flows and include them in the repo as part of the documentation.
The simplest approach is to manually update flow images.
A more automated approach is to build images automatically as part of a build script and a pre-commit hook can verify that the images are built when the flow is updated. Automating image building as part of the pre-commit is beyond the scope of this proposal as it can change the set of files being committed.

Additional Information

Seems like this should be closed as it was done in other PRs.


[Suggestion]: Add a comment don't forget to handle memory leak

It'd be nice to have a sample app or, in Readme file, you mentioned to this: https://gist.github.com/Zhuinden/ea3189198938bd16c03db628e084a4fa#gistcomment-3619736
with a code snippet, maybe.
So, developers will be known they have to handle that to prevent memory leaks.

They typically don't have to do that, and it's just general usage of lifecycleObserver over the ViewLifecycle.
Separate observers aren't within scope of the library as I'd probably want to make some doOnDestroy { extension function over the LifecycleOwner/Lifecycle but that's clearly out of scope.


Include runningUnitTests in Application Contract

resubmit of https://github.com/laravel/framework/pull/21033  , now on master

Probably best to just call it runningTests.

You want that part of this PR? Then I'll make a new commit.


Global install

This PR checks if Garn is installed globally and will then execute ./node_modules/.bin/garn instead of doing anything itself. This means that you can install Garn globally and run garn from CLI without needing to have ./node_modules/.bin in your PATH.
This PR is based on top of #11 and the diff looks horrible because I had to indent all lines in the garn-bin.js file. But it's just the code above https://github.com/avensia-oss/garn/compare/garn-as-npm-executable...global-install?expand=1#diff-85172683fabc78444c6393e9e761ab81a24ef08c975b168c667eacc95a785905R26 that has changed.

Cool!
How would this work with workspaces? When running garn workspace core it does expect there to be a garn executable there right?

Ah, that's true, forgot about that one! Will have to add code to make that optimal.

Pushed a commit to the other PR where workspaces no longer requires a checked in garn.cmd file!

Awesome! :100:
I needed to do some tweaking to get the workspaces to work:
function expandWorkspaces(packageJsonPath: string) {
  const packageJson = JSON.parse(workspace.readFileSync(packageJsonPath).toString());
  if (Array.isArray(packageJson.workspaces) || Array.isArray(packageJson.workspaces?.packages)) {
    const workspaces: WorkspacePackage[] = [];
    for (const workspace of packageJson.workspaces.packages ?? packageJson.workspaces) {
      // Find each workspace that have a garn installed.
      const expanded = glob.sync(path.join(workspace, 'node_modules', '.bin', garnExecutable()), {
        cwd: path.dirname(packageJsonPath),
      });
      workspaces.push(
        ...expanded.map(e => {
          // Goes from excite-packages/packages/core/node_modules/.bin/garn to excite-packages/packages/core
          const relativeWorkspacePath = path.join(e, '..', '..', '..'); // Ugly af. Do you have a better solution?
          return {
            name: path.basename(relativeWorkspacePath),
            workspacePath: path.join(path.dirname(packageJsonPath), relativeWorkspacePath),
            garnPath: path.join(path.dirname(packageJsonPath), e),
          };
        }),
      );
    }
    return workspaces;
  }
  return undefined;
}

And on line 167 in workspace.ts:
-await spawn(pkg.garnPath, args);
+await spawn(pkg.garnPath, args, { cwd: pkg.workspacePath });

That looks good to me! Feel free to push changes to the PR.


feat: CLI status command v2

Formatting, progress bar and more information
Formatting follows the mock-up in notion docs

https://github.com/user-attachments/assets/4126af33-48f9-4861-9e72-348ad0a8f4a0
CLI Showcase

Full filter showcase
https://github.com/user-attachments/assets/b4fa9c98-515b-4d23-ba50-f468715fec45


Permission to read static site needs to be granted to Azure DNS

Note - if Azure DNS does not have Reader permission  (I'm not sure if this is the minimum required permission or not) to the static webapp  the step to add an ALIAS record in Azure DNS will fail with an error.
You need to grant permission to the Azure DNS application object to be able to read the endpoint in order to update DNS.

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 190b1ed3-0712-2f19-4e8f-a2a8519d136e
Version Independent ID: b02adbf4-d2a8-6c84-e70a-ff59fb3cbb7b
Content: Set up a custom domain in Azure Static Web Apps
Content Source: articles/static-web-apps/custom-domain.md
Service: static-web-apps
GitHub Login: @burkeholland
Microsoft Alias: buhollan

@piquet-h Thank you for your feedback . We will investigate and update the thread.

I have added this message to the doc. Thanks, @piquet-h!
#please-close


Fixed issue #9701

Issue Reference
Fixed issue #9701

Checked and Foundt hat the issue has been fixed and working fine. Please check the video for reference.
Video
https://github.com/bagisto/bagisto/assets/92721837/7b1d3684-7100-4f50-9f64-4a0c03690f53


Invalid flat config

Configuring the plugin by
// eslint.config.js
import vitest from 'eslint-plugin-vitest';

export default [
  vitest.configs.recommended
];

results in the following error:
ESLint: 8.56.0

A config object has a "plugins" key defined as an array of strings.

Flat config requires "plugins" to be an object in this form:

    {
        plugins: {
            vitest: pluginObject
        }
    }

I think the issue is caused by the createConfig function. A possible workaround it to tweak the returned config object in the following way:
export default [
  { ...vitest.configs.recommended, plugins: { vitest } }
];

Yes, the plugin needs some changes to work with flat configs, see https://eslint.org/docs/latest/extend/plugin-migration-flat-config#migrating-configs-for-flat-config.

@tobiasdiez a pr is welcome!

@tobiasdiez did you try this?
import vitest from "eslint-plugin-vitest";

export default [
  {
    files: ["tests/**"], // or any other pattern
    plugins: {
      vitest,
    },
    rules: {
      ...vitest.configs.recommended.rules,
    },
    languageOptions: {
      globals: {
        ...vitest.environments.env.globals,
      },
    },
  },
];

rules: {
      ...vitest.configs.recommended.rules,
    },

this part errors on 0.4.2-beta.1, Configuration for rule "plugins" is invalid. Expected severity of "off", 0, "warn", 1, "error", or 2.
You passed '"vitest"'.


Fix script value in JSON-RPC invokes

What current issue(s) does this address, or what feature is it adding?
The script value being returned from JSON-RPC invoke methods was incorrect, as it was being double-hex encoded. For example, this was a value being returned from a testinvoke:
30356162616261626162616230343662363537393331303537303735373435663338363765326365613061653036326436663133636535336237393965306434666136656161313437633338
but the proper value that should have been returned was just:
05ababababab046b657931057075745f3867e2cea0ae062d6f13ce53b799e0d4fa6eaa147c38
The incorrect value being returned was the hex-encoded version of the proper/expected result.
Confirmed by comparing script values returned from NEO CLI JSON-RPC implementation.
How did you solve this problem?
Fixed the issue so that the script is not double-encoded.
How did you make sure your solution works?
Tested it and compared to NEO CLI output for identical JSON-RPC calls.
Are there any special changes in the code that we should be aware of?
No.
Please check the following, if applicable:

[ ] Did you add any tests?
[X] Did you run make lint?
[X] Did you run make test?
[X] Are you making a PR to a feature branch or development rather than master?
[X] Did you add an entry to CHANGELOG.rst? (if not, please do)

Coverage remained the same at 75.634% when pulling 0445af1b3c1e9fd58110f400eacdd9beae44cc85 on brianlenz:fix-json-rpc-script into<PHONE_NUMBER>4f15b30a3f22f5dbba7b04dbfdd486 on CityOfZion:development.


errrrrrrrrrrrrrrror

zen me an zhuang dou shi zhe ge bao cuo a...miaomiaomiao...

I don't think the error has anything to do with this project. Closing.


garage door functionality

I implemented a garage door opener with your module and find that it works differently than my garage door.
Push to open, push to close is the simple model. However, when you push the button while the door is opening or closing, the door stops. Push again and the door starts moving in the reverse direction. So, the first time I push the iPhone Garage icon while the door is moving, the iPhone and the door are out of sync. The icon goes into from opening to closing while the door in reality has stopped moving.
As far as I know, all garage doors work like mine with the intermediate stop facility. There is a door state 'stopped'. I think this should be set if a button push arrives while the door is in motion, i.e., the respective end sensor is still open or, alternatively, the respective emulated duration has not yet expired (door is in CLOSING or OPENING state).
Would it be possible to realise this intermediate button push?
I can read JavaScript (a bit) but I am not capable of doing this myself.
In my opinion you would increase the value of your plugin very much and help a lot of garage door owners.
I would appreciate a reaction. Thank you.

Hi - that is also how my garage door works. You can get around this issue by setting up close and open sensors (magnetic reed switches in my case). That way the plugin always knows what state the door is in. Secondly, it will know if its "opening" or "closing..." as the two pins can be in four separate combined states - both open, both closed, one open/one closed and one closed/one open...
Now I can use the garage door opener on iphone, or the supplied door remote, or a hard switch I installed myself. Homekit will always immediately update with exactly the correct state of the door.
Hope this helps.
Kind regards,
Shane


A more flexible abstraction for gNSI Certz

Currently, gNSI certz assumes the following:
Target (as seen from gNSI.certificate microservice point of view)
 |
 +-+ certificate (used by all gRPC services)
 | +- certificate (with public key)
 | +- private key
 |
 +-+ trust bundle (Certificate Authority certificates)
 | +- CA Root certificate
 | +- CA Intermediate Certificate
 |
 +-+ Certificate Revocation List bundle
   +- Certificate Revocation List A
   +- Certificate Revocation List B

 The above shown topology implies that every operation performed using this
 service changes a credential for all gRPC services at the same time.

I would like to propose a different abstraction here, based on the idea of an SSL profile which encapsulates all of the certs/bundle/CRLs.
An SSL profile would have the same structure as above:
SSL profile
 |
 +-+ certificate
 | +- certificate (with public key)
 | +- private key
 |
 +-+ trust bundle (Certificate Authority certificates)
 | +- CA Root certificate
 | +- CA Intermediate Certificate
 |
 +-+ Certificate Revocation List bundle
   +- Certificate Revocation List A
   +- Certificate Revocation List B

The name of the profile would have to be specified through a new string field ssl_profile which is added in the RotateCertificateRequest type.
If the ssl_profile field is left blank then the gNSI service should rotate the SSL profile which is currently in-use by the gNSI service.
An example of what this would look like in the certz.proto file:

// Request messages to rotate existing certificates on the target.
message RotateCertificateRequest {
  // If set to `true` the requested operation will succeed even if the
  // `version` is already in use (is not unique).
  // If set to `false` the requested operation will fail and the streaming RPC
  // will be closed with the `AlreadyExists` error if the `version` is already
  // in use (is not unique).
  // It is a no-op for the `finalize_rotation` request.
  bool force_overwrite = 1;

  // An identifier for the specific SSL profile
  // (collection of certs/bundles/CRLs)
  // which is being rotated through this stream
  // Leaving this field blank means that this stream
  // will rotate the SSL profile which is currently
  // being used by the gNSI service.
  string ssl_profile = 2;

  // Request Messages.
  oneof rotate_request {
    GenerateCSRRequest generate_csr = 3;
    UploadRequest certificates = 4;
    FinalizeRequest finalize_rotation = 5;
  }
}

In the current proto spec, it is assumed that the system is pre-configured through the CLI so that all gRPC servers are using the same certs/bundles/CRLs.
For Arista systems, this means defining SSL profiles, assigning them names, then assigning these profiles to the gRPC servers that are started.
Compared to the current proto spec then, the only difference with these changes from the client's perspective would be that now they have to declare in their RotateCertificateRequest messages which SSL profile they are intending to rotate (or leave the field blank).
This brings advantage that multiple SSL profiles can be set up on the device and configured through gNSI.

For example in the case of grpctunnel, the client may want to use one SSL profile to secure the tunnel, and another SSL profile to secure the gNMI data within the tunnel. Supporting multiple SSL profiles in gNSI would allow this to be an option.

A client may also want to have one SSL profile used for all gRPC services, and another SSL profile used for some other non-gRPC service. They could then use gNSI as a general-purpose tool to rotate the certs on the system.

I do have concerns though on users trying to swap the "g* service certs" with other profiles
This would lead to confusion and require explicit configuration of services seperate from the servers they maybe implemented on
So if the use case is all g* services use a default profile and the ssl_profile is only relevant to "other servers or use cases like grpctunnel then i am good with that
@tomek-US
@robshakir

The idea of having multiple sets of credentials for different purposes sounds tempting (and it was in a bit different form part of the previous version of this API) but I do not think we can simply add the profile name as a new field.
At least there would have to be a new API call added to list the available profiles.
Perhaps we would also need the Install() call back to create them. And a Delete() to remove them.
Also the question remains how to assign a profile to a service. I do not think that leaving the process unspecified is the best approach. In my opinion it calls for another API call(s) that would have to be able list available services and map the profiles to them. In theory using gNMI is another option but we might hit the 'chicken and egg' problem with this approach.

Also the question remains how to assign a profile to a service.

This question is still an issue either way here. The main way for clients to associate a SSL profile with a service is through CLI. For gRPC services at least a leaf like this seems to have been made for this purpose over gNMI under /system/grpc-servers
   leaf certificate-id {
      type string;
      description
        "Name of the certificate that is associated with the gRPC service. The
        certificate ID is provisioned through other interfaces to the device, such
        as the gNOI certificate management service.";
    }

For users that don't want to have to think about this no SSL profile could mean the currently active profile so this would be transparent for users that don't want to care about it. Having an Install, list and Delete RPC also sounds like a good idea to me.
I'll need to think more on if there are other non gNMI/CLI ways to do this as it might be difficult to refer to a particular service through other means. I think gNMI way be the best solution here.

This leaf is marked as not supported here: https://github.com/openconfig/gnsi/blob/d96c5b33d6ba5290ea48f7a12fbd5475a09c0f41/certz/gnsi-certz.yang#L104 ;-)

I'm not sure I agree with that? Imo new YANG models should only be additive, it should be left to the vendor to decide if they want to implement it or not.
Arista for example already implements this leaf. This means that we will not be able to pull updates from this repo easily as they are added as we will need to have our own forked copy which removes this deviation.

I have prepared a change that adds SSL profile management to gNSI.certz. Please take a look.


Typo in flushFilesWhenSettled and getting 'Maximum call stack size exceeded'

Think file.status should be file.state here?
Also, set(this, 'files', Ember.A()) gives me RangeError: Maximum call stack size exceeded

Still getting Maximum call stack size exceeded on line #83

😞

On Oct 11, 2016, at 12:55 AM, Timmie Sarjanen<EMAIL_ADDRESS>wrote:
Still getting Maximum call stack size exceeded on line #83
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.


Unable to migrate to google domain to AWS

Before opening, please confirm:

[X] I have checked the custom domains troubleshooting guide.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
No response
Region
ohio
Step
taralaistressrelief.com
Status
failed
Issue or question
Migrating a google domain to AWS.
Created host, updated name server in google domain, switched to custom server, added domain to was amplify
It's been a week and the website is still now published.

Error message

 this is what I see when look for the website
Additional information
was on the line with google today everything looks good on that end, I am just stuck on was side by not being able to see the domain
Migrating a google domain to AWS.
Created host, updated name server in google domain, switched to custom server, added domain to was amplify
It's been a week and the website is still now published.

@saverna12345 Have you run tests in Route 53 to verify everything is working? https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-test.html


Error: The workspace can only contain one instance of item [object Object]

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
When working with multiple panes, Atom throws
this error when trying to open non-editor tabs that are already open:
item-registry.coffee:8 Uncaught (in promise) Error: The workspace can only contain one instance of item [object Object](…)
module.exports.ItemRegistry.addItem @ item-registry.coffee:8
module.exports.PaneContainer.addedPaneItem @ pane-container.coffee:241
(anonymous function) @ pane-container.coffee:235
module.exports.Emitter.simpleDispatch @ emitter.js:25
module.exports.Emitter.emit @ emitter.js:129
module.exports.Pane.addItem @ pane.coffee:455
module.exports.Pane.activateItem @ pane.coffee:410
(anonymous function) @ workspace.coffee:525

Also, the result looks glitchy:

Take note, that both Settings panes have focus. The left pane has the correct title (“Settings”), but the view remains empty. The right pane is untitled and shows the Settings view.
Steps to Reproduce

Launch new Atom window
Split Pane (for this example I used Split Right)
Select the left pane, then open Preferences
Select the right pane, then open Preferences again

Expected behavior: Either show the settings pane in both tabs or focus to the first opened pane.
Actual behavior: Throws error and produces visual glitch
Reproduces how often: 100%
Versions
$ atom --version
Atom    : 1.13.0
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0

apm --version
apm  1.14.1
npm  3.10.5
node 4.4.5
python 2.7.5
git 1.9.5

Additional Information
Tested in both, normal and safe mode, on Mac OS X 10.9.5

Thanks for taking the time to contribute!
We noticed that this is a duplicate of https://github.com/atom/settings-view/issues/723. You may want to subscribe there for updates.
Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


OpenCensus: Update EXPORT interval

OpenCensus Stackdriver exporter exports every 60s by default, we need make sure main thread is running for longer than that.

/cc @songy23

@kurtisvg Please review.


Please add author support in rss feed item

I saw the source code and figured out author support is not available. We want the blog authors name in the feed items.
Can you add that please?

Could you further document your idea?
Should we use git contributor or page.meta.author?
How should the final tag be formatted?
It would really help to implement it quickly :)

Could you further document your idea?
Should we use git contributor or page.meta.author?
How should the final tag be formatted?
It would really help to implement it quickly :)

We can add the feature through page.meta.author.
git contributor is also a good feature but page.meta.author should override git contributor.
The formatting should be like this
  <author>
  <name>Krishan Subudhi</name>
  </author>

We can add the feature through page.meta.author.
git contributor is also a good feature but page.meta.author should override git contributor.
The formatting should be like this
  <author>
  <name>Krishan Subudhi</name>
  </author>

Thanks for your inputs.

We can add the feature through page.meta.author.

I think we should take into an account that a page can have multiple authors, like co-contributors in git.

git contributor is also a good feature but page.meta.author should override git contributor.

The plugin was first thought to use git information. Nevertheless, we can move forward more easily with the metadata of the page. Let's start by this side, then I'll see the git logic from @timvink plugins.

The formatting should be like this
 <author>
 <name>Krishan Subudhi</name>
  </author>

Refering to the RSS standard to ensure our compliance. the author tag should have an email address:

https://www.w3schools.com/XML/rss_tag_author.asp
https://validator.w3.org/feed/docs/rss2.html#hrelementsOfLtitemgt

It'll be natural with the git log, but for the page.meta it's on the page writer.

Thanks for your inputs.

We can add the feature through page.meta.author.

I think we should take into an account that a page can have multiple authors, like co-contributors in git.

git contributor is also a good feature but page.meta.author should override git contributor.

The plugin was first thought to use git information. Nevertheless, we can move forward more easily with the metadata of the page. Let's start by this side, then I'll see the git logic from @timvink plugins.

The formatting should be like this
 <author>
 <name>Krishan Subudhi</name>
  </author>

Refering to the RSS standard to ensure our compliance. the author tag should have an email address:

https://www.w3schools.com/XML/rss_tag_author.asp
https://validator.w3.org/feed/docs/rss2.html#hrelementsOfLtitemgt

It'll be natural with the git log, but for the page.meta it's on the page writer.

Thanks Julien.
On Mon, Jan 18, 2021, 11:24 AM Julien<EMAIL_ADDRESS>wrote:

Closed #34 https://github.com/Guts/mkdocs-rss-plugin/issues/34 via #36
https://github.com/Guts/mkdocs-rss-plugin/pull/36.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Guts/mkdocs-rss-plugin/issues/34#event-4219564584,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC27YWBFVTRTQNGHUXYQOXTS2SDGDANCNFSM4V6A5B4A
.

Thanks Julien.
On Mon, Jan 18, 2021, 11:24 AM Julien<EMAIL_ADDRESS>wrote:

Closed #34 https://github.com/Guts/mkdocs-rss-plugin/issues/34 via #36
https://github.com/Guts/mkdocs-rss-plugin/pull/36.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Guts/mkdocs-rss-plugin/issues/34#event-4219564584,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC27YWBFVTRTQNGHUXYQOXTS2SDGDANCNFSM4V6A5B4A
.


Add in map.jinja/defaults.yml and split init into state files

Summary

Add defaults.yml + map.jinja
split states into contextually grouped states, include from init

@puneetk , I like the changes, except for the file.sls, shouldn't it be called config.sls or something like that?

@aboe76
I called it file.sls cause all the states in it are file.*
I am ok with any name, it should be reflected in the template formula, https://github.com/saltstack-formulas/template-formula, though so that we know what the standard is, imho.

@puneetk already changed it a bit, I like the idea of the defaults.yaml and the states,
but I think they should represent what the state does, that makes it clearer I think.


Enum default value is ignored

For enum attributes, the default value is always set to the first value listed in the enumeration, ignoring the actually set default.
The following rule erroneously defaults to "Val1":
@Enum("Val1", "Val2", "Val3")
attr testVal = "Val2"

Task

Make enum attributes default to the right default value.

Duplicate of #23


Sprint 4 karthik

modified:   partners/templates/registration/campus_partner_register.html
modified:   partners/templates/registration/campus_partner_register_for_projects.html
Fixed validations for campus partner and removed  contact work phone fields.

Changed uno-cpi/partners/forms.py

merged


clock 24hr format

The clock always display in 12hr format. Would it be possible to use android system setting? Or a configuration in the app?

That's strange.
Yes, my device is set to 24-hour format, which is used for example in the notification bar.
But in Alarm Panel, both on the main screen and in the screen saver, 12-hour  format is used.

I can’t reproduce the behavior. Whatever format I set my system to, the application immediately follows.  Which device and version of Android are you running?

You shouldn’t need to reboot the application to have device changes reflected within the application such as time format, this should be automatic, at least it is when I update the time format in the settings.  The application time format automatically updates.


EVEC VEC01 - can't start charging

I've successfully managed to connect my charger, an EVEC VEC01 (which is using OCPP 1.6J), using v0.5.1 of the custom component, and various diagnostic values are shown correctly in the entities. Various entities also change correctly if I turn the charger on manually, and the charge control toggle shows as being turned on. The charger is connected via ethernet (it doesn't support OCPP over Wi-Fi). If I turn the charger on manually, and off using home assistant, no error is shown.
However if I toggle the charge control in Home Assistant when the charger is off, the control reverts to the off position, and I get the error
'list index out of range'
The error details are as follows:
Logger: custom_components.ocpp
Source: custom_components/ocpp/api.py:961
integration: Open Charge Point Protocol (OCPP) ([documentation](https://github.com/lbbrhzn/ocpp/blob/main/README.md), [issues](https://github.com/lbbrhzn/ocpp/issues))
First occurred: 22:53:14 (630 occurrences)
Last logged: 23:25:23

Unexpected exception in connection to '': 'list index out of range'
Traceback (most recent call last):
  File "/config/custom_components/ocpp/api.py", line 961, in run
    await asyncio.gather(*self.tasks)
  File "/config/custom_components/ocpp/api.py", line 432, in post_connect
    resp = await self.get_configuration(ckey.number_of_connectors.value)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ocpp/api.py", line 830, in get_configuration
    value = resp.configuration_key[0][om.value.value]
            ~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: list index out of range

Further logs:
Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:239
integration: Home Assistant WebSocket API ([documentation](https://www.home-assistant.io/integrations/websocket_api), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+websocket_api%22))
First occurred: 22:55:10 (6 occurrences)
Last logged: 23:51:07

[546945187648] list index out of range
[546913669184] list index out of range
[546939491648] list index out of range
[546939006144] list index out of range
[546866619328] list index out of range
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 239, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2319, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2356, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 905, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 975, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/config/custom_components/ocpp/switch.py", line 125, in async_turn_on
    self._state = await self.central_system.set_charger_state(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ocpp/api.py", line 301, in set_charger_state
    resp = await self.charge_points[cp_id].start_transaction()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ocpp/api.py", line 698, in start_transaction
    resp = await self.get_configuration(ckey.authorize_remote_tx_requests.value)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ocpp/api.py", line 830, in get_configuration
    value = resp.configuration_key[0][om.value.value]
            ~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: list index out of range

can you add a log of the OCPP messages between charger and server?

Sure thing. I turned on debug logging for the websockets server see below. This is just 9 seconds, but it does this constantly. If I leave it on for very long then the log gets so big it won't render in the web browser any more.
I triggered the charge control at 19:29:44, just before the final message included here.
2024-03-25 19:29:41.722 DEBUG (MainThread) [websockets.server] = connection is OPEN 2024-03-25 19:29:43.728 DEBUG (MainThread) [websockets.server] > TEXT '[2,"01a4b8b1-86ed-4f50-9d04-36fd63b6c213","GetC...rtedFeatureProfiles"]}]' [98 bytes] 2024-03-25 19:29:43.960 DEBUG (MainThread) [websockets.server] < TEXT '[3,"01a4b8b1-86ed-4f50-9d04-36fd63b6c213",{"con...ing, RemoteTrigger"}]}]' [206 bytes] 2024-03-25 19:29:43.964 DEBUG (MainThread) [websockets.server] > TEXT '[2,"f0d1bf8d-dee7-42dd-bcab-02af59789b46","GetC..."NumberOfConnectors"]}]' [92 bytes] 2024-03-25 19:29:44.426 DEBUG (MainThread) [websockets.server] < TEXT '[3,"f0d1bf8d-dee7-42dd-bcab-02af59789b46",{"configurationKey":[]}]' [66 bytes] 2024-03-25 19:29:44.438 DEBUG (MainThread) [websockets.server] = connection is CLOSING 2024-03-25 19:29:44.439 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes] 2024-03-25 19:29:44.617 DEBUG (MainThread) [websockets.server] ! failing connection with code 1006 2024-03-25 19:29:44.618 DEBUG (MainThread) [websockets.server] = connection is CLOSED 2024-03-25 19:29:44.620 DEBUG (MainThread) [websockets.server] x half-closing TCP connection 2024-03-25 19:29:44.621 INFO (MainThread) [websockets.server] connection closed 2024-03-25 19:29:44.735 DEBUG (MainThread) [websockets.server] = connection is CONNECTING 2024-03-25 19:29:44.739 DEBUG (MainThread) [websockets.server] < GET / HTTP/1.1 2024-03-25 19:29:44.740 DEBUG (MainThread) [websockets.server] < Upgrade: websocket 2024-03-25 19:29:44.740 DEBUG (MainThread) [websockets.server] < Host: <IP_ADDRESS> 2024-03-25 19:29:44.740 DEBUG (MainThread) [websockets.server] < Connection: Upgrade 2024-03-25 19:29:44.741 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:44.741 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13 2024-03-25 19:29:44.741 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: JATeGott6Se1fYM67pryfg== 2024-03-25 19:29:44.742 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols 2024-03-25 19:29:44.743 DEBUG (MainThread) [websockets.server] > Upgrade: websocket 2024-03-25 19:29:44.743 DEBUG (MainThread) [websockets.server] > Connection: Upgrade 2024-03-25 19:29:44.743 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: r+OeyfD+dePRJm87SwhoaeIkAVE= 2024-03-25 19:29:44.743 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:44.744 DEBUG (MainThread) [websockets.server] > Date: Mon, 25 Mar 2024 19:29:44 GMT 2024-03-25 19:29:44.744 DEBUG (MainThread) [websockets.server] > Server: Python/3.12 websockets/11.0.3 2024-03-25 19:29:44.746 INFO (MainThread) [websockets.server] connection open 2024-03-25 19:29:44.746 DEBUG (MainThread) [websockets.server] = connection is OPEN 2024-03-25 19:29:46.751 DEBUG (MainThread) [websockets.server] > TEXT '[2,"e66d0719-bba6-4543-a62d-5df95d27c39a","GetC...rtedFeatureProfiles"]}]' [98 bytes] 2024-03-25 19:29:46.980 DEBUG (MainThread) [websockets.server] < TEXT '[3,"e66d0719-bba6-4543-a62d-5df95d27c39a",{"con...ing, RemoteTrigger"}]}]' [206 bytes] 2024-03-25 19:29:46.983 DEBUG (MainThread) [websockets.server] > TEXT '[2,"7c2936eb-b00a-4643-9987-0871a0548131","GetC..."NumberOfConnectors"]}]' [92 bytes] 2024-03-25 19:29:47.448 DEBUG (MainThread) [websockets.server] < TEXT '[3,"7c2936eb-b00a-4643-9987-0871a0548131",{"configurationKey":[]}]' [66 bytes] 2024-03-25 19:29:47.462 DEBUG (MainThread) [websockets.server] = connection is CLOSING 2024-03-25 19:29:47.462 DEBUG (MainThread) [websockets.server] > CLOSE 1000 (OK) [2 bytes] 2024-03-25 19:29:47.643 DEBUG (MainThread) [websockets.server] ! failing connection with code 1006 2024-03-25 19:29:47.643 DEBUG (MainThread) [websockets.server] = connection is CLOSED 2024-03-25 19:29:47.646 DEBUG (MainThread) [websockets.server] x half-closing TCP connection 2024-03-25 19:29:47.647 INFO (MainThread) [websockets.server] connection closed 2024-03-25 19:29:47.760 DEBUG (MainThread) [websockets.server] = connection is CONNECTING 2024-03-25 19:29:47.764 DEBUG (MainThread) [websockets.server] < GET / HTTP/1.1 2024-03-25 19:29:47.765 DEBUG (MainThread) [websockets.server] < Upgrade: websocket 2024-03-25 19:29:47.765 DEBUG (MainThread) [websockets.server] < Host: <IP_ADDRESS> 2024-03-25 19:29:47.765 DEBUG (MainThread) [websockets.server] < Connection: Upgrade 2024-03-25 19:29:47.766 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:47.766 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Version: 13 2024-03-25 19:29:47.766 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Key: RHdH1FU67X4Im+NY2nUD1Q== 2024-03-25 19:29:47.767 DEBUG (MainThread) [websockets.server] > HTTP/1.1 101 Switching Protocols 2024-03-25 19:29:47.767 DEBUG (MainThread) [websockets.server] > Upgrade: websocket 2024-03-25 19:29:47.768 DEBUG (MainThread) [websockets.server] > Connection: Upgrade 2024-03-25 19:29:47.768 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Accept: 8GSjzMU4gYjuVvfBSLI/cHfxsYI= 2024-03-25 19:29:47.768 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:47.768 DEBUG (MainThread) [websockets.server] > Date: Mon, 25 Mar 2024 19:29:47 GMT 2024-03-25 19:29:47.769 DEBUG (MainThread) [websockets.server] > Server: Python/3.12 websockets/11.0.3 2024-03-25 19:29:47.770 INFO (MainThread) [websockets.server] connection open 2024-03-25 19:29:47.770 DEBUG (MainThread) [websockets.server] = connection is OPEN 2024-03-25 19:29:50.081 DEBUG (MainThread) [websockets.server] > TEXT '[2,"57d37a8f-69ec-4ccd-bda9-763427f4143e","GetC...rtedFeatureProfiles"]}]' [98 bytes]
Here are the ocpp logs from the same time period:
2024-03-25 19:29:41.397 INFO (MainThread) [ocpp] : receive message [3,"3277e24f-4992-4109-a989-59426f633ae6",{"configurationKey":[]}] 2024-03-25 19:29:41.398 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to '': 'list index out of range' File "/config/custom_components/ocpp/api.py", line 961, in run File "/config/custom_components/ocpp/api.py", line 432, in post_connect File "/config/custom_components/ocpp/api.py", line 830, in get_configuration 2024-03-25 19:29:41.593 INFO (MainThread) [custom_components.ocpp] Charger disconnected from <IP_ADDRESS>:9000. 2024-03-25 19:29:41.718 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:41.720 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:41.723 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-03-25 19:29:41.723 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/ 2024-03-25 19:29:41.723 INFO (MainThread) [custom_components.ocpp] Charger reconnected to <IP_ADDRESS>:9000. 2024-03-25 19:29:43.727 INFO (MainThread) [ocpp] : send [2,"01a4b8b1-86ed-4f50-9d04-36fd63b6c213","GetConfiguration",{"key":["SupportedFeatureProfiles"]}] 2024-03-25 19:29:43.961 INFO (MainThread) [ocpp] : receive message [3,"01a4b8b1-86ed-4f50-9d04-36fd63b6c213",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core, FirmwareManagement, LocalAuthListManagement, SmartCharging, RemoteTrigger"}]}] 2024-03-25 19:29:43.964 INFO (MainThread) [ocpp] : send [2,"f0d1bf8d-dee7-42dd-bcab-02af59789b46","GetConfiguration",{"key":["NumberOfConnectors"]}] 2024-03-25 19:29:44.427 INFO (MainThread) [ocpp] : receive message [3,"f0d1bf8d-dee7-42dd-bcab-02af59789b46",{"configurationKey":[]}] 2024-03-25 19:29:44.428 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to '': 'list index out of range' File "/config/custom_components/ocpp/api.py", line 961, in run File "/config/custom_components/ocpp/api.py", line 432, in post_connect File "/config/custom_components/ocpp/api.py", line 830, in get_configuration 2024-03-25 19:29:44.621 INFO (MainThread) [custom_components.ocpp] Charger disconnected from <IP_ADDRESS>:9000. 2024-03-25 19:29:44.741 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:44.743 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:44.747 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-03-25 19:29:44.747 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/ 2024-03-25 19:29:44.747 INFO (MainThread) [custom_components.ocpp] Charger reconnected to <IP_ADDRESS>:9000. 2024-03-25 19:29:46.750 INFO (MainThread) [ocpp] : send [2,"e66d0719-bba6-4543-a62d-5df95d27c39a","GetConfiguration",{"key":["SupportedFeatureProfiles"]}] 2024-03-25 19:29:46.981 INFO (MainThread) [ocpp] : receive message [3,"e66d0719-bba6-4543-a62d-5df95d27c39a",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core, FirmwareManagement, LocalAuthListManagement, SmartCharging, RemoteTrigger"}]}] 2024-03-25 19:29:46.983 INFO (MainThread) [ocpp] : send [2,"7c2936eb-b00a-4643-9987-0871a0548131","GetConfiguration",{"key":["NumberOfConnectors"]}] 2024-03-25 19:29:47.449 INFO (MainThread) [ocpp] : receive message [3,"7c2936eb-b00a-4643-9987-0871a0548131",{"configurationKey":[]}] 2024-03-25 19:29:47.450 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to '': 'list index out of range' File "/config/custom_components/ocpp/api.py", line 961, in run File "/config/custom_components/ocpp/api.py", line 432, in post_connect File "/config/custom_components/ocpp/api.py", line 830, in get_configuration 2024-03-25 19:29:47.647 INFO (MainThread) [custom_components.ocpp] Charger disconnected from <IP_ADDRESS>:9000. 2024-03-25 19:29:47.766 DEBUG (MainThread) [websockets.server] < Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:47.768 DEBUG (MainThread) [websockets.server] > Sec-WebSocket-Protocol: ocpp1.6 2024-03-25 19:29:47.771 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-03-25 19:29:47.771 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/ 2024-03-25 19:29:47.772 INFO (MainThread) [custom_components.ocpp] Charger reconnected to <IP_ADDRESS>:9000. 2024-03-25 19:29:50.080 INFO (MainThread) [ocpp] : send [2,"57d37a8f-69ec-4ccd-bda9-763427f4143e","GetConfiguration",{"key":["SupportedFeatureProfiles"]}] 2024-03-25 19:29:50.316 INFO (MainThread) [ocpp] : receive message [3,"57d37a8f-69ec-4ccd-bda9-763427f4143e",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core, FirmwareManagement, LocalAuthListManagement, SmartCharging, RemoteTrigger"}]}] 2024-03-25 19:29:50.319 INFO (MainThread) [ocpp] : send [2,"2b49cb95-261c-46d0-971b-afaeb8c4620b","GetConfiguration",{"key":["NumberOfConnectors"]}] 2024-03-25 19:29:50.783 INFO (MainThread) [ocpp] : receive message [3,"2b49cb95-261c-46d0-971b-afaeb8c4620b",{"configurationKey":[]}] 2024-03-25 19:29:50.784 ERROR (MainThread) [custom_components.ocpp] Unexpected exception in connection to '': 'list index out of range'


exship, aneurisms

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[a,e]

/trunk merge


C++ compilation error fix

"fixed error: designator order for field ‘Color::r’ does not match declaration order in ‘Color’" and "error: designator order for field ‘Image::mipmaps’ does not match declaration order in ‘Image’".

Thanks a lot!


feature request ; "context": "any" // Allow this command to apply to both files and folders

i would like it to work for folders too
{
"title": "ls -l",
"script": "ls -l ${absolutePath}",
"description": "ls -l",
"context": "any" // Allow this command to apply to both files and folders
//"context": "file"
}

@springyworks
Thanks for the suggestion!
We're planning to make this command work with directory paths as well in our next update.


refactor registration - add role to new users

need to add 'student' role in api route

already working


fix(example): modify JetIssues's android app title

Overview

Just noticed example JetIssues app uses IDE as an application's title on Android platform, this PR addresses that.

Screenshot

Before
After

thx!

thx!


Add volume to comicinfo to SQLite

Added volume after issue number in all aspects of the script. Tested working this AM.

Great minds think alike! I just had pushed that change to the script a few minutes after you submitted this. I also included the web link.


yarn/npm/this repo: Versions mess

Hi.
I am a bit confused about the last actual version of griddle-react package.
npmjs says that 1.3.1 is the latest release.
yarnpkg also says so, but it also knows about newer releases:
May 17, 2017 1.6.0 (What is this? Version in this repo master branch is 1.5.0. Where is 1.6.0 from?)
May 8, 2017 1.5.0
April 21, 2017 1.4.0

The most sad thing is yarn behaviour with this package.
yarn add installs griddle-react 1.3.1 and creates the following package.json:
{
  "dependencies": {
    "griddle-react": "^1.3.1"
  }
}

But when you run yarn install with this package.json you get installed (non-existent!) griddle-react 1.6.0.

1.3.1 is the recommended version to use. Not sure why 1.6.0 would be coming up as the version in yarn -- it does not do this for me on my projects.

@ryanlanciaux
As I said yarn add installs and adds version 1.3.1.
But if you run yarn install in a clean directory containing package.json, produced by yarn add, you get version 1.6.0.

+1 I see same problem. I set version explicitly in package.json to avoid.

Hmm - very odd. I'm planning on releasing a new release version very soon. Maybe this problem will go away then? I wonder if yarn is going off whatever version is most recent and not necessarily the latest tag?

dahlbyk committed on 25 Jun

version 1.6.0
onClick, onMouseEnter, onMouseLeave

npm view<EMAIL_ADDRESS>gitHead and yarn info<EMAIL_ADDRESS>gitHead show 96722acfcf1bc6bb086a6991baf4936e378e5bc7.
This does seem to be a yarn (0.27.5) bug:

However, if the yarn.lock file from the original install is kept (it should be), a yarn install does correctly reinstall 1.3.1.


Edit a product

edit:

profile image
short description
long description
fact table (CRUD)
file gallery (no upload here!) : change order

to get more details, take a look at the pflichtenheft

done


[Mutant Year Zero] Translation tags added

Changes

added translations tags
minor code formatting(helped the ACSi script to make less mistakes)

Comments

Link to test campaign
Heavy lifting was made with ACSI v0.33

Closing this ticket since we talked about just running the program again on the new html.


Integration tests breaks for components that inject notifications

Hello !
After upgrading a project from ember 2.11 to 2.13, I noticed that all the integration tests of the components that injects ember-cli-notifications are breaking : Assertion Failed: Attempting to inject an unknown injection: 'service:notification-messages'.
In these components, I inject your addon "individually" via :
notifications: Ember.inject.service('notification-messages'),.
I also tried to inject via an initializer afterward, and tests are ok with that method. The problem is I don't need to inject it everywhere, so I shouldn't use an initializer in my project..
I made a small repo that replicate this problem : https://github.com/Edralo/notification-test-fail
I haven't looked much to find where the problem is, but maybe it's linked to https://github.com/emberjs/rfcs/blob/master/text/0150-factory-for.md since the problem appeared with ember 2.12.
That's pretty much all i know about the issue for now, sorry

@Edralo This issue may not relate to this project but an issue with qunit: https://github.com/ember-cli/ember-cli/issues/6945.  Did you have this issue after migrating ember-cli?

@Edralo my last comment may not be helpful to you, I was able to resolve this issue partially by correctly requiring the notification-messages by its' correct resolver name in my unit tests like so:
moduleFor('route:account', 'Unit | Route | account', {
  needs: ['service:notification-messages-service']
});

Note that the services actual name in the container is: notification-messages-service as that is its' original filename.  I'd be curious to know if these errors in our integration tests are some kind of side effect?  I'll update once I get my tests passing.

I think I was on the right track.  I'm not sure how we are able to inject notification-messages in our development environment but our tests are wanting to register: notification-messages-service which yields the following error:
TypeError: Attempting to register an unknown factory: 'service:notification-messages'

Updating your needs to my above code snippet will then generate the following error:
Assertion Failed: Attempting to inject an unknown injection: 'service:notification-messages'

You can correct this error, as a quick fix, by registering 'service:notification-messages-service' as service:notification-messages like so:
moduleFor('route:tmp-fix', 'Unit | Route | tmp-fix', {
  needs: ['service:notification-messages'],
  beforeEach() {
    const notifications = this.container.lookupFactory('service:notification-messages-service');
    this.register('service:notification-messages', notifications);
  }
});

However I was able to remove all these errors by renaming app/services/notification-messages-service.js to app/services/notification-messages.js which wont work for you outside your dev environment.

Fresh<EMAIL_ADDRESS>app example documenting issue: https://github.com/Matt-Jensen/ember-cli-notifications-test.  Pull and run tests to reproduce above errors.

Thanks for the unit tests !
Unfortunately, I'm still stuck about the integrations tests. Maybe I should investigate about ember-qunit and ember-cli-qunit (since we're using the latter)

I was able to clear up the integration test issues with the same approach:
moduleForComponent('my-component', 'Integration | Component | my component', {
  integration: true,
  beforeEach() {
    const notifications = this.container.lookupFactory('service:notification-messages-service');
    this.register('service:notification-messages', notifications);
  }
});

Sorry for the late comment, we finally fixed it.
We still had injections issue with your solution but it was easily fixable. We also needed to import the service via its installed directory inside the project and used it directly inside this.register :
import NotificationsService from 'ember-cli-notifications/services/notification-messages-service';

moduleForComponent('my-component', 'Integration | Component | my component', {
  integration: true,
  beforeEach() {
    this.register('service:notification-messages', NotificationsService);
    this.inject.service('notification-messages', { as: 'notifications' });
  }
});

Thanks a lot for the help @Matt-Jensen

@Edralo I don't believe you should close this issue.  Our solutions are just hacks to get the test suite to pass.  We should close this once GH-171 is merged.

Oops, sure

I'll merge #171 and roll it in to the 5.0.0 release as its a breaking change 🛠

While this will work, its only a half measure and breaking convention over configuration. You will note on the documentation page you still have to import notification-messages-service to extend which is not what would be expected. The service really should be renamed everywhere for a complete fix.
In the meantime just creating a new service and extending the service under whatever name you wish (notification-messages in this case) will work as well without this pull request.

@cah-briangantzler I'll be renaming the service hence the breaking change and a required major release with 5.0.0.

This has changed with the release of https://github.com/mansona/ember-cli-notifications/pull/251 and shouldn't be an issue anymore 👍 let me know if you have any questions or are still having problems


system-probe: init remote tagger and global container provider

What does this PR do?
This PR adds a RemoteTagger component to system-probe and uses it, alongside the remote workload meta component, to init a global container provider.
Motivation
This is done in preparation of future changes to the service discovery feature of system-probe, that will need to rely on being able to get container info, like container ID and container tags.
Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes

This is a lot of additional dependencies for windows. Can you explain the data flow and why these components must be in system-probe? Is this something that could be handled in the core agent which already has the remote tagger?

/merge


Add method for obtain password reset token

Add this https://docs.loginradius.com/api/v2/user-registration/forgot-password-token on the php-sdk

Hi Nicolas,
Thanks for providing your inputs, based on your inputs we have included this API in our Latest release 4.5.0.
If there is anything else please do let us know.
Thanks for your help.


(android) added file type parameter to preview

I have a pdf that's served from an internal url that has a ".cls" extension, but actually returns a pdf stream.
The mime type is calculated incorrectly from the url as ".cls".
I've added the optional type parameter to the previewFileFromUrlOrPath function, that will override the mime type calculation from url.
Usage example:
DocumentViewer.previewFileFromUrlOrPath(
        function () {
        console.log('success');
        }, function (error) {
        if (error == 53) {
            console.log('No app that handles this file type.');
        }else if (error == 2){
            console.log('Invalid link');
        }
    },
    url, 'pdf.pdf', 'application/pdf');

@syonip
This is very special case, so in order to make it working for you, and not breaking others that are using this plugin, make sure that type param is optional and if not provided to work for pdf documents by default.

Hi @vkajtazov thanks for reviewing.
I've made it optional, so it doesn't change behavior if not sent.
See comments on relevant lines.

Any progress on this?

@syonip
There is an new npm version with your changes.
Cheers :)


Fixes in type conversion rules

Fixes:

separates rules for integer and float conversion to string. Previously, all numeric types were recommended to be converted using libcs "%g", which unnaturally represents integers:
printf "%g", 1234567 -> 1.23457e+06

an example of unwanted behavior was qualified with "may not", I've changed that to "MUST NOT".

Good point... but, at the level of the filtering language, how does the API implementation know if it has a float or an integer? As far as I can see we have not defined them as different lexical tokens, so we only have "a number". Is there any way we can phrase this conversion without separating into separate cases for floats and integers?

You're right. I was thinking more about backends, which will likely know the difference between integer and float (i.e. MySQL, MongoDB, ...). The current filter language specification does not differentiate between integers and floats.
Nevertheless, the problem remains. For example, volume, number and pages properties of references entries, all of which are string. Searching for pages = 1234567 will yield unexpected results (as of now, "1234567" != 1234567).

Is there any way we can phrase this conversion without separating into separate cases for floats and integers?

I can't think of a better solution right now.

I lifted the formulation about libc's "%g" from older text without thinking carefully about this.
But, now that you point specifically at it, I think this description of conversions is flawed in the context of parsing a serialized format. In a filter string, a number comes in as a token, deciphered from a series of characters. All conversions of tokens into other formats are conversion from strings. I.e., the text should just say that if the property is a string, then, in comparisons, the characters comprising the number token should instead be interpreted as a string. I believe this can be a MUST requirement, because it can be fully handled by the OPTiMaDe layer.
Is the text clear about all other conversions?:

Given a number token and an integer property, how is the number token interpreted? Presumably we should say somewhere that this conversion should be equivalent to glibc atoi. MUST, SHOULD, or MAY it throw an error if atoi throws an error? MUST, SHOULD, or MAY it convert decimal numbers into integers by rounding?
Given a number token and a float property; we presumably should point at glibc atof-equivalent?
Given a string token and a float or integer, MUST, SHOULD, or MAY the implementation just 'recast' it to a number token?

Hmm...

All conversions of tokens into other formats are conversion from strings. I.e., the text should just say that if the property is a string, then, in comparisons, the characters comprising the number token should instead be interpreted as a string.

This sounds good.

MUST, SHOULD, or MAY it throw an error if atoi throws an error?

I'd say MUST.

Given a string token and a float or integer, MUST, SHOULD, or MAY the implementation just 'recast' it to a number token?

I tend to think atof could suffice, but I feel there are numbers x for which atof( "x" ) != x.

So, to me this is the final thing that remains before we can release v0.10 (I optimistically expect #154 to be merged any second without debate...)
@merkys Will you re-edit this PR to avoid the unnecessary request to convert number tokens into numbers and then back into strings? Or do you want me to rewrite it?

@merkys Will you re-edit this PR to avoid the unnecessary request to convert number tokens into numbers and then back into strings? Or do you want me to rewrite it?

@rartino I'll do that tomorrow.

I have rewritten the paragraph according to @rartino's suggestions. Please have a look and let me know whether it makes sense or not.

Thanks for the review @rartino! I've accepted most of your suggestions, only a couple of issues remain.

Thanks for approval @rartino!

Also, a third question: does this PR (or other parts of the specs) require that a DB backend is able to distinguish between integers and floats? While this seems natural to me, I just discovered a few days ago with a lot of surprise that JSONB fields in Postgres store a general "numeric" type and it's very hard to have a proper distinction between them. There it works like this: 1.2e2 is considered as integer since it's 120. 1.200e2 is instead float 120.0... So also large numbers with exponent > ~16 are always considered as integers... (e.g. 1.2e20). Would it be a problem to use such a backend for Optimade?

I don't think it is a problem, but it can be a bit tricky to get the full picture before someone has tried an actual implementation.
My line of thinking is: the types of the underlying database comes into play when an API Implementation translates an OPTiMaDe filter into a query for the backend. However, the API Implementation knowns the types of all properties that are involved. So, regardless of the backend data types, the API Implementation will know whether to use atoi or atof semantics (or whatever we decide), and should know how to rewrite the filter correctly for the backend. Whatever data type is then returned from the backend for each property can be correctly "upcasted" to the correct OPTiMaDe type, since the API Implementation knows what that type is. So, as far as I can see, this should all work.
But, I am certainly open to discussing if OPTiMaDe properties really need to separate floats and integers, or if we should merge them to a 'Number' type. A single 'Number' type would fit the query language better. On the other hand, the two best arguments for separate floats and integer types I have are:

It makes it possible for alternative response formats that support separate integer and float types to naturally use the right one in responses.
It makes our definitions of what the properties are more clear.

ok thanks! what about my other two inline comments?

ok thanks! what about my other two inline comments?

There should be replies to them now.

In the discussions with @giovannipizzi and @rartino a consensus was reached that no type conversions should be done (except timestamps). I have edited the PR to reflect this. Please review and let me know whether the text is acceptable as of now.

Hi,
as a very quick comment (sorry for the delay), I think atol and atof are not the best functions to standardise the behaviour on them, mostly because they do not check any errors (such as overflow, underflow, non-digits, empty strings, etc.). If we a re looking for standardised function for string->numeric conversion, my first instinct would be to look into strtol and strtof instead. To quote from a Linux man page (man atoi):
      The atoi() function converts the initial portion of the string pointed to by nptr to int.  The behavior is the same as

           strtol(nptr, NULL, 10);

       except that atoi() does not detect errors.

Lack of error detection (in particular, overlows) is a bad think, IMHO. Also, the particular behaviour is dependent on what the sizes of the int and long types are, and thus would be architecture-dependent.
Another though: it is probably not wise to set as a standard a particular implementation, even on a standardised and wide-spread implementation as libc strtol. Rather, we probably want to describe what is meant by writing x > "1.0", and allow different compatible efficient implementations (if which strof would be one, Python float() would be another and so on).

Let me share some thoughts on type matching and comparisons, to see I understand the problems the same way as you guys (sorry for a long post):

Filter language defines 2 constant types on syntactic level: Strings (quoted) and Numbers.

1a. If necessary, Numbers can be further subdivided into Integers and Reals, to match the rest of the specification (JSON schema definitions of responses).

In a filter Comparison expression, both values MUST have the same lexical type. I.e. that x > 1.0 and x > 1 is only permitted if the property x is numeric (integer or float); whereas s = "abrakadabra" is only permitted if s is string. Constants in comparisons, consequently, MUST also have identical types: comparison 1 = 1 is valid and true; comparison 1 != "1" is invalid (and not even false :).

Comparing numeric values:

Lexical Real (like 1.12) numbers are not actually floating point since we do not describe any arithmetic on them; thus all fractional numbers are actually rationals. That is to say, comparison x > 1.12 is exactly the same as comparison x * 100 > 112, except that OPTiMaDe Filter language does not (currently) support arithmetic.
Backends MAY implement OPTiMaDe Filter Numbers and Response schema Integers/Float as floating point numbers (including IEEE floats). Without arithmetic, number comparisons should not be problematic even if different back ends us different floating point implementations. E.g. if x is a real-valued property, x = 0.5 should give the same result regardless whether the back-end uses IEEE float, IEEE double or decimal floating-point values, if all implementations correctly convert 0.5 fraction into their respective representation (and this should be equivalent to x * 10 = 5 assuming infinite-precision arithmetic). Most actual implementations already behave this way. Comparisons like 1.2E-100 < 1.2E+100 should also be possible.
It remains to be decided how implementation MUST behave when the number can not be handled exactly. Problems might be x > 1E-600 AND x < 2E-400 (both values are too small to be represented by a floating point back-end and may underflow to 0); or x > 0.12345678901 (on different implementations, different number of digits might be used to represent x and comparisons will be different even with the same data).
Regarding the underflow or overflow, we can:

either require that an implementation returns an error if underflow or overflow conditions occur (thus x > 1E-200 would produce and error response if 1E-200 can not be represented on a backend, so this comparison will be computed on a host using double IEEE floats for x but not on a host using single precision IEEE floats);

or allow inexact comparisons (and potentially different results from different databases) if such conditions occur;

To cope with rounding errors on long fractions, such as in x > 0.12345678901, we can settle in the OPTiMaDe specification that at least 6 decimal digits MUST be taken into account by the implementation. This AFAIK corresponds to the IEEE single-precision float capabilities. Thus decimal fractions with no more than 6 digits will give the same results on all hosts.

String comparisons.

Comparisons like s > "Abc" depend on collation order. I would specify a default (Unicode) collation order, regardless of the language and locale; for higher Unicode characters (outside the ASCII range) a normalised representation MUST be compared. In this way comparisons should be unambiguous.

For all other properties, like dates, the values will lexically be represented as strings, and the back-end will have to make a conversion to whatever representation is needed. We can describe comparison semantics on the representation strings alone; for example date comparisons in last_modified > "2019-01-10" will follow the usual date comparison semantics.

Such agreement will allow to define comparison semantics for any types with internal structures, such as formulae.
This unfortunately breaks @rartino desiderata that all string fields are compared using the same semantics, but I do not see any convenient way around it. One could introduce type definitions and typed constants, but this is definitely too complex for the OPTIMaDe purposes :).

This unfortunately breaks @rartino desiderata that all string fields are compared using the same semantics, but I do not see any convenient way around it. One could introduce type definitions and typed constants, but this is definitely too complex for the OPTIMaDe purposes :).

I had already somewhat reluctantly accepted that the timestamp property type is encoded in the filtering language as a string token. However, it is important to me that these different comparison semantics are due to properties being of different types. I.e., if you want special semantics for comparison of, e.g., smiles strings, there has to be a well-defined smiles property type that clearly defines these semantics.
But now that you point at it... Doesn't the introduction of "timestamp strings" resurface the problem with allowing value vs. value comparisons? How should my implementation handle the following?:
"2019-07-14T22:06:43-01:00" < "2019-07-14T22:06:43Z"
Does this filter match or not?
If the answer is "no" (at least that is my interpretation of the present spec), then does it really make sense to leave out the facility for value vs. value comparisons of timestamps?
Should we change over to simply define a timestamp token as a bare rfc3339 timestamp?, i.e. 2019-07-14T22:06:43-01:00 ?

@rartino :

I had already somewhat reluctantly accepted that the timestamp property type is encoded in the filtering language as a string token. However, it is important to me that these different comparison semantics are due to properties being of different types. I.e., if you want special semantics for comparison of, e.g., smiles strings, there has to be a well-defined smiles property type that clearly defines these semantics.

I agree with you, I think each property that is not specified as a string or as a numeric value must have a semantics clearly specified in the specification, and compared according to that specification, whereas lexically in the filter (and in the response JSON) they will be specified as strings (since strings are the most general way to encode values, more general than just numbers).
In this way we can easily introduce any special type; time-stamps are available at the moment but, as you say, SMILES can be introduced in the future with more useful semantics than just a string comparison.
I see two ways to look at the situation, both are equivalent IMHO:
a) one can think of a property that needs to be compared in a special way as having a special type (e.g. type timestamp); strings are converted to that type implicitly according to the type of the property; error is returned if the string value does not match the property description or conversion is not possible (e.g. an overflow occurs). This means that such strings have internal structure that can be specified, say, a regular expression.
b) one can alternatively think as special_prop = "value" being property comparison with a string where a comparison operator has special semantics (think of overloaded operators a-la C++). We still compare special_prop with a string, but the comparison is different from comparing a string with a string. Internally, this will probably involve parsing a string and converting it to a suitable internal prepresentation, which makes it equivalent to a)

But now that you point at it... Doesn't the introduction of "timestamp strings" resurface the problem with allowing value vs. value comparisons?

I think the problem is very minor, if it exists at all :). If value vs. value comparison is requested, and both are strings, we compare them as strings, that is, in exactly the same was as a string-valued property with a string. Since such comparisons are needed anyway, we will have them defined in the specs in one way or another. Thus, "str" = "str" will be true, "ab" < "a" will be false and so on. Strings will be sorted in dictionary order.
Actually, ISO 8601 were designed with string comparisons in mind! Vis.:

Date and time values are ordered from the largest to smallest unit of time: year, month (or week), day, hour, minute, second, and fraction of second. The lexicographical order of the representation thus corresponds to chronological order, except for date representations involving negative years or time offset. This allows dates to be naturally sorted /.../

(https://en.wikipedia.org/wiki/ISO_8601)

How should my implementation handle the following?:
"2019-07-14T22:06:43-01:00" < "2019-07-14T22:06:43Z"
Does this filter match or not?

If we follow the string comparison semantics  as suggested above, the answer follows directly and it says that the filter matches ("yes"), since "2019-07-14T22:06:43-01:00" comes lexicographically before "2019-07-14T22:06:43Z" (because the first differing characters are "-" and "Z", and "-" comes before "Z" in ASCII):
saulius@koala OPTiMaDe-specification/ $ perl -le 'print "YES" if "2019-07-14T22:06:43-01:00" lt "2019-07-14T22:06:43Z"'
YES

If the answer is "no" (at least that is my interpretation of the present spec),

Why "no"?

then does it really make sense to leave out the facility for value vs. value comparisons of timestamps?

I would be reluctant to exclude value-value comparisons, this would make grammar (or specification, or both) more complex and non-orthogonal. Given that above interpretation of ASCII string comparison is straightforward and widespread, I see no point putting extra work to limit syntactic capabilities.
Also, value-value comparisons will be rare, with some niche applications (I see their utility mostly in the computer-generated requests), so the problems even if they arise will not be grave.

Should we change over to simply define a timestamp token as a bare rfc3339 timestamp?, i.e. 2019-07-14T22:06:43-01:00 ?

This is dangerous since we can introduce grammar ambiguities (both because of limited look-ahead of common parser generators and inherent in the grammar). Even if we squeeze the time-stamp syntax into the filter language now (and I see no point doing this, honestly), we will have problems in the future if we want to extend the query language and add other types, such as SMILES, formula (we already have several flavours of formulae), person names, etc, etc.
When string values are "shielded" by quotes from the rest of the Filter language grammar, we can be sure that there will be no syntactic clashes between different value tokens, and any value is representable.
To wrap up, I suggest leaving numbers and strings as we have now, and use number tokens to represent values for numeric properties, and strings for everything else. The type for the property will dictate how a particular string is interpreted, and value-value comparisons will be either number-with-number (using numeric <, >, =, etc. comparisons), or string-with-string (using dictionary order comparisons), with no type conversions.


How to drag table COLUMNS using this directive?

Hello,
Is there any way that I can use this directive to reorder table columns using its drag & drop feature and get new column order in callback function? Column should be draggable  by using its header tag < th > .
I know there are other directives which provides such feature, but I have tried all of them and they are not compatible with my project in one or another way.

You won't be able to see the entire column while dragging, since columns are no HTML elements, but other than that I see no reason why this wouldn't work. You need a model with all your column names, and then use the directive on the th elements. Once your model changed after the user drag and dropped a th element, your table should re-render.

Hi marceljuenemann,
Can you please provide a code sample, how to change order of columns with drag drop. It will be very appreciable.
Thanks.


Make the chunk work with transfer_size 42 in spdm-emu.

Signed-off-by: Jiewen Yao<EMAIL_ADDRESS>with change: #define LIBSPDM_DATA_TRANSFER_SIZE 42

libspdm unit test pass
spdm-emu test pass

Thank you! @richkong88 .
@steven-bellock , we need merge it soon to perform test in spdm-emu and spdm-dump to see if there is any other gap.
Feel free to comment or submit issue, and we will follow up.


FCS_CKM.1/KEK Inclusion conditions for optional requirement

Need to document inclusion conditions for this requirement:

When the TOE needs to encrypt keys
When the TOE provides key encryption as a service to tenant software.

Does use of trusted channels imply that the TOE needs this capability?

Standard mode, FIPS Mode, CNSA Mode

Removed


Add logo and info about the name

Pull Request Test Coverage Report for Build 329

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 77.814%

Totals

Change from base Build 328:
0.0%

Covered Lines:
852

Relevant Lines:
1026

💛  - Coveralls


Increase number of file descriptors in calico-felix.conf

This increases the number of file descriptors available to Felix, which should mitigate issue #534 (Felix gets sad when it can't create any more VMs/tap interfaces).
I picked 32K just because it was the first number suggested in that issue. We don't have any documentation for editing calico-felix.conf, so I assume it gets put in place by our installers. This is the only felix.conf file in the /calico repo, so I'm guessing this is it.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Do we not need to make a similar change on Ubuntu?

I think this isn't quite right. That file is only used for RPMs, not for the normal upstart job (I think). That means you should also change debian/calico-felix.upstart
Net of this is that

You should change that file too.
Run the changes past @matthewdupre since he's more expert in this area.
Add a changelog entry for this change.

Comments crossed - @Lukasa and I spotted the same thing, but he didn't get distracted by a mail in the middle!

Added the Debian file and changelog entry.

Debian and RHEL 6.5 upstart job changes are fine, but you also need to update the RHEL 7 systemd service file (rpm/calico-felix.service).
Specifically LimitNOFILE=32000 in the [service] section - see http://man7.org/linux/man-pages/man5/systemd.exec.5.html.