Accessibility: Focus not obscured

Describe the bug
The following ticket was raised on the SML catalogue website: SPP-12221
This is following investigation into WCAG 2.2 guidelines.
I believe the SML website is compliant with this ticket however this may be applicable to the ONS design system so I am raising it here.
Expected behaviour / outcome
Description :
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Note: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content is considered for testing and conformance of this Success Criterion.
Note: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.
Acceptance Criteria:
Ensure any item which gets keyboard focus is partially visible
Team response
This would need some investigate to see whether the problem exists on the website and changes would then need to be implemented.
List the steps necessary to reproduce the bug
See above ticket
Additional context
Not an urgent issue just raising for awareness. This is not an issue on the SML website but may be applicable elsewhere in the ONS design system.
What version of the ONS Design System are you using?
70.0.4
What device(s) are you using?
Desktop
What operating system(s) are you using?
macOS
What browser(s) are you using?
Safari

Hi @joepercival thank you for raising this ticket. We will look into this issue soon.


Extract deserialize_yml to axoasset

We have a function in cargo-dist that's essentially a copy of axoasset's deserialize_toml and deserialize_json, but for YAML:
https://github.com/axodotdev/cargo-dist/blob/81ca476c43ca4016ca0a50cc03c32892ec0e63b4/cargo-dist/src/backend/ci/github.rs#L876-L893
It would be great for us to extract it from cargo-dist and get it into axoasset.

The first half of this (adding the implementation to axoasset) is here: https://github.com/axodotdev/axoasset/pull/235

The second half is #1604.


XAML Xamarin Android missing support

Please, why is missing support for XAML Xamarin Android ? I tried to add, but getting error about missing  Microsoft.Microsoft.CognitiveServices.Speech.core.dll

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

ID: cc2fcd39-a2d6-0a3a-1235-1aae45cae26d
Version Independent ID: db227248-d6d1-b1d3-05bc-522cd1435da2
Content: Speech-to-text with Azure Speech Services - Azure Cognitive Services
Content Source: articles/cognitive-services/Speech-Service/speech-to-text.md
Service: cognitive-services
Sub-service: speech-service
GitHub Login: @erhopf
Microsoft Alias: erhopf

Official Xamarin support is on the roadmap.  Look for the Xamarin logo to show up here: https://docs.microsoft.com/en-us/azure/cognitive-services/speech-service/ early September.

@jjindrich
We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.

Thank you. For future similar questions will be greate put this plan on website to eliminate submitting issues.


How can we use in Swift?

Hi, I have drag class folder in Swift project and trying to use this controller in app but it's not working, so is it possible to used in Swift project?

Hello, I haven't tried running in the swift project. Let me try it on.

I tested it. It works in Swift project (pod install &&  drag class folder). But I just tested the picture editor.
The key is to create bridge files (XXX-Bridging-Header.h)
imagePickerTest_withoutPOD.zip
imagePickerTest.zip

it will work on video? or just for image?

both

Thank you so much... for this awesome project :-) @lincf0912

Hi @lincf0912
do you add any additional features (like instagram or snapchat) to the current code?

Hi @lincf0912
do you add any additional features (like instagram or snapchat) to the current code?

There is no update plan for this project.


Add values to codelist options

This PR adds a value property to the codelist options, so they can have a label different to its value, and then it sets this value to the label for all existing codelists

I am not 100% certain what I say is correct, but my interpretation:
A code-list is a conceptScheme and a conceptScheme has many skos-concepts. It is these skos-concepts that are the "options" of a codelist.
At this point an skos-concept only gets used for this (and for the type of a code-list).
However, this skos-concept feels like a dirty class that just gets molded to whatever it needs to be, making the use of SKOS bring more confusion.

skos-concept has a schema:position property, which only makes sense for ordered list. But skos-concept is also used as a type (with cardinality=one), where this property is not needed.
skos-concept is currently only used as the options of a codelist. However, the options now need some extra data (what this PR provides), which has to be band-aided into skos-concept, making skos-concept even broader, decreasing its reuseability (I am assuming this is the reason it is a separate class?)

I feel like adding this new extra ext:value to skos-concept is not the way to go, but the resources are structured so that it is not really possible differently, except by changing the structure.
I'm guessing we'd rather make this an easy change (like proposed in this PR), instead of trying to fix/think about the underlying issue there might be.
Actual review of the PR:

changing skos:prefLabel to be the new 'label' of options (as defined in the issue) is logical in my eyes and seems to follow the usage meant by SKOS for prefLabel, as far as I can interpret from the SKOS docs.

putting the data somewhere else makes sense. ext:value feels very broad (and not really descriptive), but as skos-concept is used pretty much as a "list of items", giving it a general value (without specifying what it might be) makes sense.

in a sense, the ext:value should be able to be anything (so skos-concept can be used for any type of resource, not just a string resource), but that's just being pedantic and would increase the complexity without any gain. So just making ext:value a string is okay. But I wanted to at least mention it :)

important actionable note: labels are not mandatory (see comments of issue). The exisiting codelists will now end up with the label being the same as the value. This can become a problem if we'd want to limit the label in some way (e.g. text length). As they are not mandatory, it makes sens to instead:

set ext:value to the value of now skos:prefLabel (like you already did)
make the skos:prefLabel an empty string. (users can add labels for it if they want to)

As this is my issue, I can change the above, but as you'd need to review it anyway, asking it in text is the same as writing code that would get reviewed anyway :shrug:

@x-m-el Sorry for the late answer, I agree with what you said, jus take into account that with this changes you will need to modify the frontend and also the plugin that consumes the codelists.
Also thinking about this, we will need to make the same changes to app-mow as the codelists should have the same structure

@x-m-el Sorry for the late answer, I agree with what you said, jus take into account that with this changes you will need to modify the frontend and also the plugin that consumes the codelists. Also thinking about this, we will need to make the same changes to app-mow as the codelists should have the same structure

I thought about this these labels also probably needing to be in mow.
Are MOW database and Reglementaire bijdrage the same database? So if I would set prefLabel to empty string with a migration, it will not work correctly for the codelists in MOW?

Hm, that means that the plugin could break if MOW doesn't get updated or the plugin doesn't get updated? Because the plugin will use our (new) backend structure that is defined with this migration.
Developers might not update the plugin instantly either, so you want to let the plugin keep working.
If I set prefLabel to an empty string, every old instance of the plugin running will break.
I'm not sure how to solve that problem cleanly. Because the plugin uses a direct sparql endpoint (iirc) we can't really catch old usages of the plugin and fix it like that.
Either way, old instances of the plugin will not work with new codelists (that have labels) anyway. So keeping the old way work is only temporarily.
I'm honestly not sure what the best course of action would be.
Or we instantly break any app running the old plugin logic, or we migrate the data in a less clean way and only break old plugin for new codelists.

Conclusion:

Keep old data intacked (in prefLabel)
Add an ext:summary field instead (that is the actual label)
all old consumers of the db will still work (just won't have the feature of a label)


OpenAI down

The service "OpenAI" has been down since 24                 nov.                 2024                 01h48                 (Downtime: 70.354 seconds).

test comment

Identified - We have identified the root cause of this issue, and are currently working to implement a fix.

Update - We are continuing to work on the fix for our issue. Thank you for your patience.

Monitoring - A fix has been implemented and we are monitoring results. Most users should already see access to TEST restored.

Resolved - This issue has now been resolved. Between 4:06pm and 4:30pm PT, TEST was unavailable to all users. Access was restored to most users by 4:34, with a small number of customers still experiencing issues until 5pm.


BarWidgetUI: Add a skeleton for loading state

Description
Shortcut: https://app.shortcut.com/cartoteam/story/314283/new-loader-ui-for-widgets
[sc-314283]

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 5 (80.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.0008%) to 71.955%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/react-ui/src/widgets/BarWidgetUI/BarWidgetLoading.js
3
4
75.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.0008%

Covered Lines:
2017

Relevant Lines:
2581

💛  - Coveralls

@VictorVelarde added also the HistogramWidget


General linear constraint.

alla old nape, pulley joint being a special case of this constraint.
The deriviation is already done, but the implementation (and it's complexities compared to pair-wise constraints) is not.

Well, technically anyone wanting this can now implement it themselves as a UserConstraint. I do still want it as a predefined constraint though, at least a restricted PulleyJoint form.


Don't link plugin dependencies to products

This fixes two issues with plugins and their dependencies:
- we were traversing plugin products and including their targets as part of any product
- since we are including plugin targets as dependencies as well, we could traverse plugin targets in a similarly incorrect way

@swift-ci please smoke test

Seems like the tests are passing, so maybe this was a mistake.

Locally confirmed fixes #6673 (which I initially mis-diagnosed)

@swift-ci please smoke test

@swift-ci please smoke test windows

I'd like to add some test coverage for this and we probably also want this fix in 5.9. I am not 100% sure how plugins ever worked with these issues in place 😬

I do wonder whether we need to put this fix behind the 5.9 tools-version? At least in theory, it seems like the bug could be load bearing if dependencies ended up being unexpressed because of this. By definition, any package that currently ships couldn't have suffered major consequences from this bug, otherwise it would have been possible to ship said package.

@swift-ci please smoke test

/private/var/folders/7n/r31lzfjx6556jgc6vg55_cg80000gn/T/Miscellaneous_Plugins.tJQMsU/IncorrectDependencies/Sources/MyPluginExecutable/MyPluginExecutable.swift:3:24: error: concurrency is only available in macOS 10.15.0 or newer
static func main() async throws {

Hm, this is legitimate, but I wonder why this issue didn't show up locally?

@swift-ci please smoke test

@swift-ci please smoke test windows

@swift-ci please smoke test

@swift-ci please smoke test windows

Windows build failed with
0.13 sec
          Start 1325: TestFoundation.TestProcess-test_exit1
Build timed out (after 60 minutes). Marking the build as aborted.

Seems like this isn't entirely a fluke...

@swift-ci please smoke test windows


update: codegen for Ruby(Faraday)

PR Description
this PR has Ruby(faraday) codegen part
Related Issues

Related Issue #147
Closes #147

Checklist

[x] I have gone through the contributing guide
[x] I have run the tests (flutter test) and all tests are passing

Added/updated tests?
We encourage you to add relevant test cases.

[x] Yes
[ ] No, and this is why: please replace this line with details on why tests have not been included

all test cases have passed

Did you check that the generated codes for all the test cases are running perfectly on your local PC ?

Yes ma'am they are working you can check

The code has compilation errors. Please ensure that your code has no compilation errors when you raise a PR.

The approach used is not correct. Please look at js or go codegens to see how multipart requests are created.
Also, the code generated for test cases POST 6 to POST 9 are not correct and giving errors, which is not happening when you send a request through API Dash.
Closing this PR, please open a new PR when you have fixed all the above issues.

@ashitaprasad ma'am can you please provide a platform where i can check the ruby code compilation as I am facing problem while using faraday lib on my laptop

@nikkivirtuoso what erro are you getting?

On VS Code using rubyLSR extension it makes the ruby file executable along with this the faraday library I am trying to install using gem install faraday it is showing error


write iteration 1,2,3 wiki pages

[x] write the wiki's of iteration 1

[ ] write the wiki's of iteration 2

[ ] write the wiki's of iteration 3

done


Change pagination on AbstractProductType for availableAttributes

I detected that when there are many attributes, all of these are not displayed in the Product type. This is happening because the AbstractProductType on line 210 is paging up to 25 items
https://discord.com/channels/497326121441034240/765213029163335730/1117888171871572148

With 25:

With 250

IMO this is not the right solution, as we are assuming the max will be 250, might as well don't paginate at all. and the UI doesn't looks good with so many attributes in 1 go.
should have the pagination links at the bottom to navigate and maybe a search field to filter

Going to convert this to draft for the time being, although I believe it's an issue that needs solving, i'm not sure this is the approach as @wychoong said.

Please can you target main for this PR? thanks

Appreciate your work on this @yanielbf I tried to help move this along by rebasing to main but 0.3 is quite far behind main and since it would have been a simple change, the effort to rebase wouldn't be worth it I don't think. So for that reason there is a new PR #1208 just to get things going.


[Question] The master branch code does not work when I specify the collector for the task (rather than the default system scheduling)

Question

Seems it can't be reproduced.
Update your code and have a try.

https://github.com/user-attachments/assets/dfd79ed9-8c51-40e3-8165-cbaf16572113
我这边上传了一个视频，用的就是新代码，直接从master拉去的代码，然后制作的镜像，指定收集器时没有生效，始终是默认系统调度

问题解决了，webapp最新代码修复了此问题，谢谢，打扰了


"All" changed to "Always" for getDebugInfo

Reference - https://msdn.microsoft.com/en-us/library/azure/microsoft.azure.management.datafactories.models.hdinsightactivitydebuginfooption_members.aspx(d=robot)

@prwani-microsoft,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@prwani-microsoft : Thanks for your contribution to the Azure documentation! The author, @sharonlo101, has been notified to review your proposed change.

#sign-off


WebApi: errors added in action filters don't trigger 400 error

Is this a Bug or Feature request?:
Bug
Steps to reproduce (preferably a link to a GitHub repo with a repro project):
    [Route("api/[controller]/[action]")]
    [Produces("application/json")]
    [ApiController]
    public class SampleController : ControllerBase
    {
        [AddSampleError]
        public ActionResult Api1()
        {
            return NoContent();
        }
    }

    public class AddSampleErrorAttribute : ActionFilterAttribute
    {
        public override Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
        {
            context.ModelState.AddModelError("sample-error", "Sample Error");
            return base.OnActionExecutionAsync(context, next);
        }
    }

repro: repository
Description of the problem:
Errors added in action filters are ignored by automatic model validation.
Model state isn't valid, but 204 code is returned instead of 400.
Version of Microsoft.AspNetCore.Mvc or Microsoft.AspNetCore.App or Microsoft.AspNetCore.All: 2.1.2

ModelStateInvalidFilter that produces the bad request is a global action filter that runs before your action filter. Consider using a resource filter instead to do model validation.

@pranavkm, Thanks for your help. My attribute changes ActionArguments so instead, I set Order to -2001.


Accept Arbitrary String for User OData's __id

Currently there are some restrictions for  User OData's __id String.
We should accept arbitrary string without any restrictions

released v1.6.2


Mapping Issue with bag file

Hi @TixiaoShan ,
Can you please have a look at the herewith attached bag file ? I am not getting any trajectory data and the map it is generating is very odd compared to the ground.I collected this ata using ouster lidar mounted on a car.I have made change in the utility.h file in order to adjust the relative change but still do not know why I am getting this error.
https://l.facebook.com/l.php?u=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1BvZiqFwOI9FRk23IK5fU5Oxav6dzWe2y%2Fview%3Fusp%3Dsharing%26fbclid%3DIwAR00pFBehju7tip2cu536zzG-woLD7Q3FYmRdfMG0Ohfb-3FgjU3XKEDLeI&h=AT3Ef6f0J9lUOFcp7PsoXu-mXKNlJhwfRJ_GORz_ENLc_4NkO8TNdiGiNZIQtpHATgzm2tMol3qvuBj6ZVb8J0NfzvU9YeHDO3DPirIKK4NAJOuXDxNx0cjOk84p-w

my launch file is as following

<!--- Sim Time -->
<param name="/use_sim_time" value="true" />

<!--- Run Rviz-->
<node pkg="rviz" type="rviz" name="rviz" args="-d $(find lego_loam)/launch/test.rviz" />

<!--- TF -->
<node pkg="tf2_ros" type="static_transform_publisher" name="camera_init_to_map"  args="0 0 0 1.570795   0        1.570795 map    camera_init " />
<node pkg="tf2_ros" type="static_transform_publisher" name="base_link_to_camera" args="0 0 0 -1.570795 -1.570795 0        camera base_link   " />

<!--- LeGO-LOAM -->
<node pkg="lego_loam" type="imageProjection"    name="imageProjection"    output="screen"/>
<node pkg="lego_loam" type="featureAssociation" name="featureAssociation" output="screen"/>
<node pkg="lego_loam" type="mapOptmization"     name="mapOptmization"     output="screen"/>
<node pkg="lego_loam" type="transformFusion"    name="transformFusion"    output="screen"/>

Thank you very much for your valuable time. I will wait for your  valuable feedback.

Hi @Ashik19
It seems your point cloud data is wrong. The white line in the image represents the horizon. It seems that all your data is offset downwards.

Hi, @TixiaoShan ,
Thank you very much for your kind reply.I have also faced this same issue with some of my other bag files like this.I am using an ouster Lidar(OS-16) mounted on a car. Can you recommend something about how to avoid this issue?
Thanks

Hi @Ashik19
I can't comment on that. I never used that lidar. Probably it's best to ask the tech support.

@tixiaoshan, thank you very much for being patient with me. Can you please tell me how did you get the white line indicating the horizon of the point cloud ?

Hi @ tixiaoshan,
Could it be possible that I have to use a horizontal resolution of 1024 always while using Lego loam in order to resolve this problem. I guess the code in the utility.h looks for a horizontal scan resolution of 1024 while making maps. There are different resolution and scan speed available in ouster like “512x10”, “512x20”,”1024x10”, and “1024x20”. I guess if I wang to use different resolution each time I will have to change the parameter in the utility.h and do the catkin_make?
Thank you for your valuable time

Yeah, the params in utility.h are set for different sensors with different resolutions. You need to re-compile for each resolution.

@TixiaoShan, thank you very much for being patient with me. Can you please tell me how did you get the white line indicating the horizon of the point cloud ?

It's just the Grid in Rviz.

Hi @tixiaoshan,
Thank you very Much for your kind reply. I figured the location of the lidar matters while mounting it on car. Also may I know whether I will have to change the Other parameter like angular resolution  x,y  in the utility.h file since I am using a car to work with LeGO- Loam.

This user's bag has the same issue like yours (point cloud not symmetric relative to the horizon).
https://github.com/RobustFieldAutonomyLab/LeGO-LOAM/issues/94


Hydronet installation on Pearl

When I tried to run hydronet on Pearl I came across the following error:
sciml-bench run --mode training hydronet
The benchmark hydronet does not support training. Have you installed yet? Check with "sciml-bench list benchmarks --verify"
The "sciml-bench list benchmarks --verify" produces this list:
Benchmarks

em_denoise            : Not runnable
dms_structure         : Not runnable
slstr_cloud           : Not runnable
optical_damage        : Not runnable
stemdl_classification : Not runnable
hydronet              : Not runnable
inelastic             : Not runnable
mnist_tf_keras        : Not runnable

This is now working for me. Closing.


Kacper: Add filters to sort items

I wouldn't implement this. I'm planning to move items frontend to ember.js anyway.


Update Required roles to add resources to a catalog table with Identity Governance administrator

The docs recommends to use Identity Governance administrator role instead of User administrator as User administrator will no longer be able to create catalogs or manage access packages in a catalog they do not own. However, it seems Identity Governance administrator is not able to add resources that they do not own to a catalog. Could you please add in the table the permissions for Identity Governance admin as it seems they are not the same as User admin?

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

ID: e42fb095-d0d2-bcc8-9048-615027626c22
Version Independent ID: 54e26c06-0d56-b390-b257-82d584506bd2
Content: Delegation and roles in entitlement management - Azure AD - Microsoft Entra
Content Source: articles/active-directory/governance/entitlement-management-delegate.md
Service: active-directory
Sub-service: compliance
GitHub Login: @OWinfreyATL
Microsoft Alias: owinfrey

@tanjakersten
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

Hey @tanjakersten
We recently added Identity Governance administrator to the table of permissions. Thanks for bringing this to our attention!

#please-close


Allow npm install

Hey,
I need to perform some stuff before running protractor, meaning I need to run npm install, and in my post-install script part, I add the transpiling of the code to javascript.

Hi @xsellier,
First of all, thanks for your contribution.
I am not sure if npm install should be part of protractor.sh. I think it should be possible to run transpilation and everything else required before you run protractor. In case I'm missing something would you mind sharing your use case?

@jciolek Indeed, but I'm using gitlab-ci, and I use this image as a job image, meaning I cannot modify the entrypoint. But I understand your point, I've done something hackish meanwhile, like mounting the file protractor.sh from a custom file.


Clean up README

Remove the irrelevant sections generated by ember-cli and replace them with relevant installation instructions.

Thanks @pauln


Bluetooth: Fix using correct IRK when generating RPA

The code in le_set_private_addr() was hardcoding identity 0, even
though it is given a specific identity as an input parameter.
Signed-off-by: Johan Hedberg<EMAIL_ADDRESS>

Codecov Report

Merging #9726 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9726   +/-   ##
=======================================
  Coverage   52.23%   52.23%
=======================================
  Files         212      212
  Lines       25945    25945
  Branches     5591     5591
=======================================
  Hits        13552    13552
  Misses      10159    10159
  Partials     2234     2234

Impacted Files
Coverage Δ

subsys/bluetooth/host/hci_core.c
2.56% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Build optimizer of batchfile

Now that there is a way to specify expected output it is possible to algorithmically change the settings of the batchfile until it generates the best possible output. The main goal would be to use this to find better defaults of the batchfile and to have a better view of how each parameter influences the final output.

This was done recently in the ModelAngelo benchmark, very likely keeping the logic there would be better then including it in stitch itself.


UI - Property Manager Fixes - From QA Testing

Issue:

https://github.com/bcgov/entity/issues/23751

Description of changes:

[ ] Country code in phone number
[ ] No validation on Email - can enter wrong emails
[ ] When you fill out Property Manager info and then decide that you have no property manager, data is kept (you can see that when you say again that you have a propman)
[ ] Property Manager fields layout is not aligned, group titles and indents differ from the last group
@rstens

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

/gcbrun

Temporary Url for review: https://strr-ui-dev--pr-224-8f52y0ek.web.app


[Version 7.0.0] NSParameterAssert causes app to crash

Hi @jessesquires .
Small question about 7.0.0 changes.
I have an iPad version of my app, using UISplitViewController.
After update to 7.0.0, there is a crash with it. There are two newly added NSParameterAssert calls in viewWillAppear method of JSQMessageViewController:
- (void)viewWillAppear:(BOOL)animated
{
   NSParameterAssert(self.senderId != nil);
   NSParameterAssert(self.senderDisplayName != nil);
 // more code ...
}

Thos crashes my app because collection view will be not loaded at all (I take senderId and senderDisplayName from Core Data model), because if there is no messages senderId and  senderDisplayName will be nil
What I've done is to add to my  viewDidLoad implementation default values of displayName and senderID like this:
-(void)viewDidLoad
{
  [super viewDidLoad];
  self.senderDisplayName = @"Banana";
  self.senderId = @"Monkey";
}

but still not sure, that this is good/ correct way to do it.
So my question is: why this asserts was added, and have I done fix correctly?
P.S Sorry if question is kind of silly, but I need to be sure :)

Hey @Foriger - prior to 7.0, the library provided default values for these 2 properties. This change was made because it didn't really make sense for the library to do this.
There are no "good" default values here from the library's perspective, so it is now left up to the client. The asserts are there because it doesn't make sense to display this view without these 2 pieces of information.
Also, the previous default values resulted in tons of questions (#882, #695, and others) because people would forget to set these values.
So, yes. This is almost the correct solution. You shouldn't have to have default values (though it does fix the problem). The senderId and senderDisplayName refer to the user who is currently using your app — which is why these values should never be nil. You should always know who the current sender is, even if you are pushing an empty messages view.

I understand.
Thanks @jessesquires


fix captions

Mostly eyeballed the timing, fix typos, add missing words, etc

Thank you!! I’ll add the new version to your video now.

It’s up! I did have to fix one timing typo so if you want to make additional changes just fetch first!


Consider switching CLI library to cobra

Many of the most widely used Go projects are built using Cobra including Kubernetes, etcd, Docker, and CockroachDB.
Though it is not necessarily the best CLI library of all, switching to cobra helps apex removing quite a bit of boilerplate code it currently has with docopt. It can arguably scale better too when the number of sub-commands and options grows over time.

Nice yea sounds good to me. Part of me prefers docopt since you get the arguments for each command right there, but you don't get the command description which does kinda suck. We'd have to rename apex help to apex wiki but that's totally cool with me, more appropriate name anyway

@tj Just submitted PR #89.
Not sure what to do with autocompletion. I know Cobra has autocompletion feature built in but I haven't explored it yet.

no worries about autocomplete for now, we need to support dynamic generation there for function names anyway, we can remove the current stuff in the PR or a separate request

@tj Alrighty, let's keep it together with this PR.


BUG: /validator-exits-to-prepare without operator returns 10 validators

A request to /validator-exits-to-prepare without operator specified does return 10 validators:
http://KAPIURL:3600/v1/modules/1/validators/validator-exits-to-prepare/
For example:
https://holesky.beaconcha.in/validator/1461263
I would expect that a request to that endpoint returns zero validators or an error if an invalid or no operator id is given.
A request to an operator that does not exist returns zero validators:
http://KAPIURL:3600/v1/modules/1/validators/validator-exits-to-prepare/88899

This issue has been preview on the Pull Requests. To resolve,
Contact the Ethereum support page to initiate a chat with the live agent on the chat button to get more information about your request via ETH Support
Regards.


SafeA9LHInstaller 2.0.3, but current is 2.6.7

Page: installing-arm9loaderhax
Is old SafeA9LHInstaller 2.0.3 really needed? I noticed there was an issue with 2.0.2, but 2.0.3 seems to be old now.
Disclaimer: I'm going to hack my first 3DS soon, and I want to do it right, and with latest stuff possible.

installer 2.5 (the version after 2.0.3) is just for the otpless method using New 3ds. 2.5-2.6.7 only focus on this method, and it's been known to cause random bricks.
As such, version 2.0.3 is the version recommended in the guide for both N3ds and O3ds, until the issue is solved.

Okay. :)


Kotlin 1.7.22

For a Gradle dependency:

Update the dependency version in the root gradle.properties
Update the dependency locks

For Gradle plugins: ./gradlew dependencies --write-locks
For Gradle dependencies: ./gradlew resolveAll --write-locks

Verify no unexpected entries appear in the lockfiles. A supply chain attack could occur during this stage. The lockfile narrows the supply chain attack window to this very moment (as opposed to every time a build occurs)
Are there any new APIs or possible migrations for this dependency?

org.jetbrains.kotlin:kotlin-allopen [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-annotation-processing-gradle [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-gradle-plugin [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-parcelize-compiler [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-parcelize-runtime [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-reflect [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-stdlib [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin:kotlin-test [1.7.20 -> 1.7.22]
https://kotlinlang.org/
org.jetbrains.kotlin.plugin.allopen:org.jetbrains.kotlin.plugin.allopen.gradle.plugin [1.7.20 -> 1.7.22]
https://kotlinlang.org/

Just bump to 1.7.21 since 1.7.22 isn't a real release.  (IntelliJ plugin won't be updated for it)


"git tfs help " fails when using MinTTY or other non-conhost console with cygwin

It looks to be a problem internal to CSharpOptParse library. It works under regular conhost.exe console sessions but fails when I move over to using MinTTY with cygwin (my primary usage of git).
The latter part: 'tfs' is not a git command, is probably driven by the non-zero exit code of the help function.
$ git tfs help pull
Usage: git-tfs pull [options]
Function 'ext:FormatText()' has failed.
Exception has been thrown by the target of an invocation.
Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: startIndex
git: 'tfs' is not a git command. See 'git --help'.
Did you mean this?
tfs

I started swapping out option parsing over the weekend.

please re-open if this problem isn't resolved.

Looks good to me - awesome work @spraints


Multiple users report that the settings are visible and frozen

[ ] Contact users that leave their contact info when providing feedback via the form. Are you a user with this issue? Then please leave your feedback here or email me at<EMAIL_ADDRESS>so we can debug and fix it together!
[ ] Find the cause
[ ] Fix the issue

Reports:

Date
Version
Browser
Problem

2020/02/01 04:32:03
2.32
Opera 66.0.3515.44
Always open

2020/02/19 04:31:20
2.33.5
Edge
Always open

2020/03/13 01:02:42
2.33.5
Edge
Never open

2020/03/21 05:28:19
2.33.5
Opera
Always open

2020/03/21 11:41:39
2.33.5
Opera
Always open

Possible stacktrace for no settings button
TypeError: Cannot read property 'prepend' of null
  at HTMLButtonElement.HTMLElement.prependTo(chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:30:10)
  at Ambilight.initSettingsMenu(chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:4301:28)
  at Ambilight.initSettings(chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:3281:12)
  at new Ambilight(chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:2849:12)
  at tryInitAmbilight(chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:4644:24)
  at ambilightDetectVideoPage(chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:4670:9)
  at ? (chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:4693:7)
  at ? (chrome-extension://paponcgjfojgemddooebbgniglhkajkj/scripts/youtube-ambilight.js:4700:2)

Might  be related to #34

It might be visually incorrect due to the fact that the timeline is hidden when the settings are still open.

[x] Keep the timeline visible when the settings are open


RClick Thaumcraft's crucible with empty hands fills it with water when AA is installed

Right clicking Thaum's crucible auto fills it with water when Arcane Archives is installed.
Arcane Archives 2.0.3
Thaumcraft 6.1.BETA26
Forge 23.5.2838

This is a function of having a Rivertear in your inventory. Also works on the Petal Apothecary from Botania.

I don't have the Rivertear.

Will look into it.


Make scalar, iterative root finding methods robust against steps outside domain

Reference issue
Closes gh-12625.
What does this implement/fix?
A simple method to "backtrack" to previously known points inside the domain.
Additional information
This makes newton work for log(x), which on current master fails as described in gh-12625:
In [1]: import numpy as np
   ...: from scipy.optimize import newton
   ...: def f(x):
   ...:     return np.log(x)
   ...:
   ...: newton(f, 3)
<ipython-input-1-1799d1561f0e>:4: RuntimeWarning: invalid value encountered in log
  return np.log(x)
Out[1]: 1.0

and makes the code more robust than MATLAB and as robust as GNU Octave:
In [2]: newton(f, 10)
<ipython-input-1-1799d1561f0e>:4: RuntimeWarning: invalid value encountered in log
  return np.log(x)
Out[2]: 1.0

In [3]: newton(f, 15)
<ipython-input-1-1799d1561f0e>:4: RuntimeWarning: invalid value encountered in log
  return np.log(x)
Out[3]: 0.9999999999999989

In [4]: newton(f, 100)
<ipython-input-1-1799d1561f0e>:4: RuntimeWarning: invalid value encountered in log
  return np.log(x)
Out[4]: 1.0

In [5]: newton(f, 1000)
<ipython-input-1-1799d1561f0e>:4: RuntimeWarning: invalid value encountered in log
  return np.log(x)
Out[5]: 1.0000000000000009

In [6]: newton(f, 10000)
<ipython-input-1-1799d1561f0e>:4: RuntimeWarning: invalid value encountered in log
  return np.log(x)
Out[6]: 1.0

This PR is incomplete and requires some discussion. In particular:

Should this behavior be opt-in?
Should we implement this as a separate method?

If we decide to extend Secant, Newton and Halley (instead of adding this as a separate method) and to not make this behavior optional or configurable (my current approach), this PR is missing a couple of things:

[ ] Extend this to Newton and Halley methods as well
[x] Add tests (where? I found scipy/optimize/tests/test_zeros.py a bit daunting, and the test functions f1 and such seem to be repeated)
[x] Increase the iteration count if we need to change p1?

cc @alexs12 @martosc

Hi @astrojuanlu
newton is not robust for a variety of reasons.  It can iterate outside the function's domain.  It can jump between intervals of the function's domain.  It can find a root far from the initial x0. It can cycle amongst a finite set of iterates. Convergence may be much slower than quadratic. It may just not converge.
In its current incarnation newtoncan be quite devoid of robustness as the initial guess should be close, and so the robustness features don't come into play.
This PR attempts to address one of the reasons above.
If the function value is infinite or NaN at any iteration, it would be reasonable to return immediately indicating a convergence error. Then the user can provide a closer guess, rather than performing one or more bisection steps at a location far from a root, losing the quadratic convergence property. I.e. the user knows much more about the function than does SciPy.
Having the caller provide an interval [x0, x1] would allow constraining the iterations without having to guess/infer.  However if an interval is known, then other algorithms (brentq, toms748) are likely to be more efficient ( depending on how expensive it is to compute the derivative fprime.)

Thanks @pmla and @ilayn for your prompt review, I modified the logic to avoid infinite loops and increase iter.
However, this changed the expected number of iterations in test_newton_full_output, so for the moment I changed the behavior to be opt-in, although I would prefer it to be either (a) opt-out or (b) part of a newly named method ('secant-robust'? 'secant-modified'? more on that below)
Thanks also @pvanmulbregt for your comments as well, answering inline:

This PR attempts to address one of the reasons above.

Yes, I don't try to amend all the possible ways in which newton can fail. I picked one that particularly affected me that I think can offer a big benefit with a low effort.

If the function value is infinite or NaN at any iteration, it would be reasonable to return immediately indicating a convergence error.

I see your point, however I think that in certain situations this might be too unforgiving. Nevertheless, I acknowledge that performing this bisection without informing the user might be troublesome, therefore I went ahead and added an OutOfDomainWarning if this happens.

I.e. the user knows much more about the function than does SciPy.

As I said in #12625:

Although understanding one's problem and looking for better initial guesses is always a good thing, I think it would be more user friendly to not fail when one step returns a non finite value.

So it's a matter of ease of use, especially given the fact that MATLAB and GNU Octave do not have problems with this.

Having the caller provide an interval [x0, x1] would allow constraining the iterations without having to guess/infer.

That's true, but I assume that the user would already be using a bracketing method if they know a proper interval?

Going back to what @pvanmulbregt said at the beginning:

newton is not robust for a variety of reasons. ...

To avoid the "that's not the proper Secant/Newton/Halley method" arguments, if it's less controversial to folks and for the sake of user friendliness, perhaps the best option is:

Make the behavior opt-in, and
Add new methods {newton,secant,halley}-robust (or -modified or whatever color one wants to paint the bike shed with) to scipy.optimize.root_scalar that enable it.

This also paves the way in case someone (myself?) wants to mitigate other ways in which these methods can fail in a future PR.
Another alternative I propose is to abandon the idea of naming these "newton/secant/halley" and implement a MATLAB or Octave-like method, that appears to be way more robust. The problems I see:

These methods seem to evaluate the function a lot of times.
I don't know what are the legal/licensing implications of implementing the method that MATLAB follows. I abstained from looking at GNU Octave source code because it's GPL.

I didn't say it explicitly at the beginning so I'll say it here: my objective in opening #12620 and 12625 is to make the transition from MATLAB easier.
What do others think?

(Edits: Typos and one mistake)

I... guess the Windows fatal exception: stack overflow is unrelated?

I... guess the Windows fatal exception: stack overflow is unrelated?

Yeah, see #12638

Docs failing with:

    OutOfDomainWarning

This issue can be fixed by adding these objects to

the function listing in __init__.py for this module

will wait for the next review rounds to address it if it still applies.

I don't know what are the legal/licensing implications of implementing the method that MATLAB follows.

You can read docs/papers, and reimplement a method from there. But if you have looked at MATLAB source code, that's proprietary and you therefore cannot use that knowledge to reimplement the algorithm.

I didn't say it explicitly at the beginning so I'll say it here: my objective in opening #12620 and #12625 is to make the transition from MATLAB easier.

That is a valid reason for adding something I think, at least if it's a reasonable change in itself and doesn't make anything less Pythonic - and this change seems to meet those criteria.

You'll need to update _array_newton as well.

I'm not a big fan of the algorithm change in this PR.
If newton doesn't converge to a root, it's because the initial estimate wasn't good enough.  And that is a really important signal to the user.   Silently reverting to bisection removes that signal.
The Newton-Raphson method works well under several conditions:

The function is twice differentiable
The cost of computing the derivative is cheap relative to the cost of computing the function
The initial estimate is close enough to a root of multiplicity one
For real-valued functions, the initial estimate is on the right side of the root (and there is always a right side of the root!)

If one proves ahead of time that the estimate satisfies these conditions, then Newton's algorithm works great.  Otherwise it may not converge, or is not very efficient (iteratively or computationally) in converging.
Newton's "quadratic convergence" attracts users to it, but in practice it requires work to achieve anything close to that beyond the simple text book cases.  As @ev-br  noted elsewhere, brentq (or toms748) are robust algorithm(s) for real root finding.
Changing the implementation to better handle Nan and Inf results should be done. I'll suggest that the right thing to do there is just stop iterating and return.  Preserves that all important signal.
Could newton be made more robust?  Yes!
But it requires more than handling just the out-of-domain.
It requires guarding against getting stuck in a cycle or local minima.  It requires checking that the convergence is at least linear and not sub-linear. It could notice that  it has a bracket after some iteration and stay within that (for real-valued functions).  It may require checking that the algorithm find a root close to the initial estimate rather than one far away. Perhaps starting from the Boost library would be one way to achieve that.  That would make newton fully robust.

I agree with most of @pvanmulbregt remarks about how to make SciPy Newton-Raphson implementation, newton, fully robust.
However, my intention with this PR was to have some non-bracketed method in SciPy that can handle trivial out-of-domain errors, backtrack properly, and still try to find a solution instead of returning immediately, with the option of making this method gradually more robust in the future.
I acknowledge that changing the newton function to do something that's not part of the Newton-Raphson original algorithm might be confusing to users1. However, Boost, which has been mentioned also on the mailing list, seems to "fall back to bisect if the next computed step would take the next value out of bounds" for its Newton-Raphson and Halley & Schröder methods, hence "removing the signal" that something went wrong. Therefore, @pvanmulbregt I am a bit confused about your suggestion of getting inspired by what Boost does, because from my understanding Boost does exactly what I propose in this pull request. Is it that you are against only falling back to bisection, and that you would be happier to see a pull request that address all the potential sources of non-robustness at the same time?
I did not succeed in looking for references of other existing, non bracketed root finding methods that handle these kind of situations. Octave fzero has no references and MATLAB fzero only mentions references for the bracketed version.
1 although I find the fact that calling newton(func, x0) does not get you Newton-Raphson, but the Secant method, even more controversial.

I totally agree that newton(func, x0) reverting to secant could be surprising to the user.  It's historical behavior.  optimize.root_scalar addresses that by requiring the the user provide all the inputs required for the method chosen.  E.g.
root_scalar(..., method="newton", ...) requires that the user provide fprime, root_scalar(..., method="secant", ...) requires that the user provide both x0 and x1.
newton is not "robust".  (halley even less so. The number of tests needing to be marked as failing in optimize.tests.test_zeros.test_halley_collections() is testament to that.)  The newton documentation contains some of the caveats but they are in the Notes section.  Truth in advertising might suggest that there should be a big warning at the beginning of the docstring, rather than hidden in the fine print.
Just handling the out-of-domain doesn't make it robust.   And yes I would be happier to see a PR which gave more complete protection against choice of x0, which removed the sub-linear convergence.

As much as I wanted this change to happen when I started, the truth is that @pvanmulbregt arguments are very compelling, and this PR not only feels like a hack but also doesn't even fully address all my concerns (see my last comment in #12620).
I think the best course of action for what I want to achieve would be to implement a octave method by reverse engineering it without looking at the source code (I formally and solemnly declare that I won't do so). It will take me some time but I believe it's feasible.
In the meanwhile, I don't think I will continue pushing this PR, so I will close it without removing the branch immediately.
Thanks everyone for the input!


Multicast commands from zwavejs2mqtt not working

Checklist:

[X] I am not using HomeAssistant. Or: a developer has told me to come here.
[X] I am not using ZWaveJS2MQTT. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
Sending a multicast command to zwavejs2mqtt results in a timeout of the command and all communication with the nodes included in the command getting queued until the timeout occurs.
Device information
Which device(s) is/are affected (make/model)?  Zooz Zen 22 and Nortek PD300Z-2
What are the node IDs? 4 and 5
Did you change anything?

[ ] Yes: (please describe)
[X] No

Did this use to work before?

[X] Don't know, this is a new device
[ ] No, it never worked anywhere
[ ] Yes, in: (specify application with versions)

How are you using node-zwave-js

[X] zwavejs2mqtt (latest) docker image
[ ] zwavejs2mqtt (dev) docker image
[ ] zwavejs2mqtt Manual Docker build

node-zwave-js branch:
zwavejs2mqtt branch:

[ ] ioBroker.zwave2 adapter
[ ] HomeAssistant version XYZ
[ ] Pkg
[ ] Manual Docker build

node-zwave-js branch:
zwavejs2mqtt branch:

[ ] node-red-contrib-zwave-js

Module version (double click node):

[ ] Manually built (as described in the docs)
[ ] Other:

To Reproduce
Steps to reproduce the behavior:

Publish following data to zwave/_CLIENTS/ZWAVE_GATEWAY-zwavejs2mqtt/multicast/set

{
"nodes": [
4, 5
],
"commandClass": 38,
"property": "targetValue",
"value": 33
}
Additional context
I thought the issue might be related to the one node supporting SupervisionCC, and the other not, but I tried sending commands to two nodes that both do not support SupervisionCC and saw the exact same behavior. I did change the light states individually on the two nodes in the log file so that can be seen working.
Logfile:
zwavejs_1.log

Can you please post your mqtt log too? Also at a silly level.

zwavejs_1.log
zwavejs2mqtt.log
Two fresh logs both set to silly.

The command gets sent
2021-03-29T20:50:16.525Z DRIVER » [REQ] [SendDataMulticast]
                                  │ target nodes:     4, 5
                                  │ transmit options: 0x25
                                  │ callback id:      36
                                  └─[MultilevelSwitchCCSet]
                                      target value: 0
...
2021-03-29T20:50:16.536Z DRIVER « [RES] [SendDataMulticast]
                                    was sent: true

but we're not getting the callback whether it was received or not. Are both nodes in range of the controller?

Both nodes have an almost literal line of sight to the controller, there's a single hollow core door in between them and the controller, and about 10 to 15 feet away from it. Non-multicast commands work perfectly, but when I try to do a multicast command it sends the command, then after a few minutes I get the timeout notification, for the second attempt, then again for the third. I just tried again using 5 nodes that are the same type of device and I'm seeing the exact same behavior. The controller I'm using is the Zooz 700 series stick.

Then it looks like the stick is not behaving as it should. You'll need to wait a few days though - I'm in contact with Silabs to verify, but that will likely take until after easter.

Thanks. Let me know if there’s anything else I can test. I do have the pc z-wave controller software installed, so if there’s a way to send multicast commands from that I can try to determine if it’s the stick or Zwave js.
Matt

On Mar 29, 2021, at 5:32 PM, AlCalzone @.***> wrote:

Then it looks like the stick is not behaving as it should. You'll need to wait a few days though - I'm in contact with Silabs to verify, but that will likely take until after easter.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

The command is being sent and we get confirmation from the stick, so I'd say it's very unlikely that zwave-js is messing up here.

Fix is up at #2194


JSONParser: fix to unicode escape handling

The new JSONParser does not properly handle certain aspects of the JSON Spec.
Description

The computation of the codepoint was fixed to (d0 << 12) + (d1 << 8) + (d2 << 4) + d3 (from (d0 << 24) + (d1 << 16) + (d2 << 8) + d3)
Control characters (U+0000 - U+001F) are now correctly marked as errors, even in strings
Unicode escapes in the range U+E000 - U+FFFF are no longer rejected
The generated UTF8 bytes are inserted into the outputs in the correct order (previously they were added in reverse order).

Motivation and Context
This fixes an issue with the fix in #284 that was added in 10.99.5
How Has This Been Tested?
I ran a JSON testing suite on the parser, and used https://html.spec.whatwg.org/entities.json to test the validity on an example document.

I'm not convinced that the change for non-printing ASCII characters is necessary, since the scanUTF8 function will signal the NonPrintingASCII exception when the first byte is ASCII.

From testing, I do know that the change is necessary. But from your comment I believe there may be another bug in the implementation regarding when the source is not properly backtracked. I will try and get a minimal counterexample.

The existing JSON parser in 110.99.5 does appear to detect non-printing ASCII characters in strings.

I created a branch in my forked repo that includes some basic testing infrastructure code and a bunch of JSON unit tests. I was able to confirm that I don't need the check for non-printing ASCII characters. But it may be something that's worth adding to the main repository if there is a use for it. https://github.com/Skyb0rg007/smlnj-legacy/tree/testing-infrastructure

Code is updated and ready to merge.

Looks okay.

Looks like you accidentally closed without merging


DSA <IP_ADDRESS> Strings : Palindrome Problems (Problem-1)

Description
Description### Description
Check if given string is a palindrome or not
Task

[ ] Audio
[ ] Video
[ ] Documentation

Note

While requesting the issue to be assigned, please mention your NAME & BATCH NUMBER.
Mention the type of contribution you want to make.
Kindly refer to the Issue Guidelines.
Do not use the assign command for this issue. Follow the above procedure.
In case you see that the issue has already been assigned, try to request a different task within the same issue.
Changes should be made inside the DSA/directory & DSA branch.
Name of the file should be the same as the issue.
This issue is only for 'GWOC' contributors of the 'DSA' Domain.

Domain
DSA
Type of Contribution
Audio, Video, Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign documentation

/assign documentation

@ritikaxx Pls read the guidelines properly. It has been already told to you that don't use self-assign on issues created by supervisors. Pls refrain from doing this from now on.
Make sure to submit a PR within 7 days.
All the best !!

@goelesha  Sorry about that,
Name-Ritika Singh
Batch-7 (DSA)
Thnakyou!

@goelesha  can I work on the audio part?
Name- Ishita Roy
Batch- 8 (DSA)

@goelesha can I work on the audio part?
Name- Ishita Roy
Batch- 8 (DSA)

@ISHITA-ROY016 I am creating a separate issue for audio. You can take that up.

I would like to work on this issue (documentation).
batch-2
Dhruti Gandhi


Add module "base64id" to compression blacklist. Fixes gh-1345

Smoke Test

Create a new project directory and cd into it
Run t2 init
Run npm install base64id
Run echo "console.log(require('base64id').getRandomBytes());" > index.js
Run t2 run index.js
You should expect to see:

INFO Looking for your Tessel...
INFO Connected to sumobot.
INFO Building project.
INFO Writing project to RAM on sumobot (3.072 kB)...
INFO Deployed.
INFO Running index.js...
<Buffer ec 96 4b ce 52 58 6f 0e ff d1 ac 6a>

(Not exactly, because you'll have different bytes)

r? @hipsterbrown
(tessel-highfive has picked a reviewer for you, use r? to override)

Coverage decreased (-29.2%) to 50.573% when pulling a53669337309c7c5db0d894d7dd0ba8136052130 on 1345 into b5f169f37600f3d7739de1547e07f5305fec7a91 on master.


Use gabby, not bamboo, in test vectors

I also updated the readme with instructions on how to generate the vectors, and tweaked the hierarchy of the sections :)
supercedes #25

Note: I did a quick hack in https://github.com/ssb-ngi-pointer/go-metafeed/commit/9a10c516241e10b9c1585c43dc6db30133750917
Basically: I noted down which hexes we received in the test got, assumed those values were correct, and swapped out the previous hardcoded hex values with these new ones. :sweat_smile:


feat WAI-ARIA - Modal dialog

Mainly brings accessibility to modal dialogs.
Dialog features
Label (title)
Added the label information for the popup associated to the modal dialog. It is bound to the element containing the text of the latter's title.
Accessible icons
Features:

labels for icons can be specified: they will result in tooltips and aria labels

this implied opening a new property for icons allowing the specification of a label (the tooltip one was already existing)

icons are accessible using tab
icons react on "return" and "enter" keys, to trigger their action
the outline is displayed around icons when they are focused

Issues:

the "initial" outline width for Firefox is too big and does not correspond to the actual native outline we can see on focused elements
JAWS can't read properly the label of the first inserted icon (first in the DOM)

Glitches:

the tab order for icons is visually reversed, due to the floating positioning being contrary to the DOM insertion order

Background elements hiding
Features:

the elements of the body that visually resides behind the opened modal dialog are now ensured as hidden as long as the dialog is opened. These elements are restored to their previous state when the dialog is closed.

Glitches:

this feature implementation is limited to a sequence of modal dialogs that are closed in the reverse order of their opening.

Focus restoration
Features:

the element that was focused just before opening the dialog is memorized and the focus is put back on it when closing the dialog

Issues:

the icon reacts on the key down event: if the element on which the focus is put back opens the dialog upon the counterpart key up event (same key), it makes it impossible to close the dialog without having it opened again immediately afterwards

Glitches:

a simple reference to the native DOM element is internally saved: if this element instance is not present in the DOM anymore, this won't work (usually the case upon AT refreshes)

Side changes
fix - Action widgets (Button & Link)
Ensure keyup is handled only if keydown happened.
feat - WAI-ARIA - Icon
Features:

icons accept a new property to specify their labels
icons are accessible using tab
icons react on "enter" and "space" keys, to trigger their action
the outline is displayed around icons when they are focused

Issues:

the "initial" outline width for Firefox is too big and does not correspond to the actual native outline we can see on focused elements

feat - MultiSelect
The escape key now closes the dropdown.
fix - Fixed the escape behavior for several widgets
That way widgets such as the dialog can be closed with this key.
Now their associated controllers properly stop the behavior of the events as needed.
I had to add an additional property to the controllers' report model so that they can tell to prevent the default behavior of the browsers without making the propagation stop. This is needed to keep a bug fix while enabling the new behavior on escape.

:ok: e597d567f5f645a1ccdd3bee358130e26b0a4200 seems fine for me. You can integrate it once the travis build is :ok:


Invalid signature.

I run it in local and it will show "invalid signature"
my device is Win 11 22H2 and enable WebNN

@akau16, could you check the Chrome Developer tools for detailed error message? I guess you may fail to access to the test data, which is a submodule of WebNN-Samples.

@akau16 please make sure the --recurse-submodules was added when you clone this repo:
git clone --recurse-submodules https://github.com/webmachinelearning/webnn-samples

Can we close this issue?


[3.1] Sema: Fix materializeForSet for members of extensions of imported classes

Fixes rdar://problem/31334272.

@swift-ci please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 40a5e84ed75f30a5ab517ec822c9132904eea145
Test requested by - @DougGregor

@swift-ci please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 40a5e84ed75f30a5ab517ec822c9132904eea145
Test requested by - @DougGregor

@slavapestov please look at this last, somewhat-unexpected commit

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 40a5e84ed75f30a5ab517ec822c9132904eea145
Test requested by - @DougGregor


Make noarch

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

This package qualifies to be noarch which is implemented in this PR.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Note: The CircleCI Pipeline failure is a conda-forge internal thing and can be ignored.

Failure is because of an old dependency. Because the package is not maintained anymore, I'll close the PR.


Cross-Distro/Vendor communication in ROS 2

There has been some questions and discussion related to cross-vendor and cross-distro communication support in ROS 2.

https://answers.ros.org/question/341372/can-nodes-from-different-ros-2-distributions-communicate-compatibly/
https://discourse.ros.org/t/ros-cross-distribution-communication/27335

And the answer is NO for both cases. currently ROS 2 does not support any cross-distro or cross-vendor communication officially. (which is my understanding, if i am mistaken, let me know) some of these cases are implemented in test code, but that does not mean that we support these compatibility.
No matter this is being current limitation or specification, it would be probably nice to describe clearly that is not supported in ROS 2 documentation officially? So that we can avoid potential unexpected problems and questions in the future.
Adding documentation would not be good enough to guarantee to avoid these cases, maybe we can add warning if the communication takes place with different distro or vendor implementation at runtime.
This topic was from today's MW WG meeting. (CC: @wjwwood @alsora @asorbini @ros2/middleware_working_group )
Related but out of scope from this issue:

Service Interoperability with different RMW implementation

CC: @MiguelCompany @clalancette @eboasson

And the answer is NO for both cases. currently ROS 2 does not support any cross-distro or cross-vendor communication officially. (which is my understanding, if i am mistaken, let me know) some of these cases are implemented in test code, but that does not mean that we support these compatibility.

So I guess it depends on what we mean by "support".  We know (and test) that we can publish topics between all 3 of our in-core DDS vendors (Fast-DDS, Connext, and CycloneDDS).  I also happened to test today that we can call services between Fast-DDS and Connext (but not with CycloneDDS) (this also implies that actions should work between Fast-DDS and Connext, though I did not test that).
So with the two exceptions of services Fast-DDS <-> CycloneDDS and services Connext <-> CycloneDDS, all of the rest of it should work.  The question is whether we want to officially call that supported or not.

FYI, as of ROS 2 Galactic sending a service request using CycloneDDS to a Fast-DDS application results in a crash during deserialization of the packet.
I think that @MiguelCompany is working on making it reject the data, rather than crash.
IMO unless we guarantee that everything works between all Tier 1 middlewares, we should discourage users to not even try to mix middlewares.
The same applies for communication between distributions.
For example, by default we could print very loud warnings if someone is mixing stuff.
An environment variable could be set by advanced users who are explicitly looking for cross-communication.
Trying to use different versions of ROS or different middlewares (by mistake!) are some of the most common causes of the issues reported by Create 3 (and Turtlebot 4) users.

So for the service interoperability, there is another issue open. I've understood from @gavanderhoorn (who BTW has rightfully been bugging me about it) that it really is necessary because of some devices only supporting middleware 1 and the other only middleware 2, and yet they have to be combined into a single system. The only way forward is therefore to agree on a portable way of doing service invocations.
I promised him that I'd try to come up with a proposal that might be agreeable to both @MiguelCompany and myself — the idea being that open source tier 1 parties ought to band together, and not let the commercial people try to bully us into something we don't want.
To me, the only sensible path forward is to do something that builds on top of the (spec'd) DDS API and respects the layering at the DDS level. Cyclone's RMW implementation currently meets this requirement, the only trickery it requires is encapsulating the ROS service payload in a slightly larger message. I believe the separate service type support exists precisely to make this possible — and doing it in a cleaner way than what the Cyclone RMW layer does.
The downside on the higher levels of the stack of doing the layering properly is (or might be) that the transformation between application data and DDS data becomes more involved and that zero-copy becomes impossible. I don't think that additional overhead would be a big deal for service invocations.
On the lower level of the stack, it adds some wire overhead in that it means you can't re-use the sequence number used by the reliable protocol for the request, and that you may decide to also add a unique client identifier to the header. For the reply, I don't think there is a material wire overhead.
About the identifier: you can basically chose to reuse the identifier of, e.g., the client's writer, or you can create a new unique id for that. Reusing means you already know the GUID from the low-level protocol machinery and it is accessible from the API, so it meets my layering constraint while avoiding a few bytes of overhead. Nonetheless, adding a new unique id is, in my view, a solution that more cleanly separates the concerns and avoids some order dependencies on creating the reader/writer pair for a client.
Since I have failed to do as I promised @gavanderhoorn ... perhaps we can just use this latest trigger to finally do something about it. Of course I'd be happiest if @MiguelCompany would be happy to rework the rmw_fastrtps_cpp implementation to match Cyclone's, but that's probably a stretch and the way forward is to share the pain a bit.
I don't think this ticket is necessarily the place for that discussion. I did feel it unacceptable to not at least do something to make good on that promise of mine ...

it really is necessary because of some devices only supporting middleware 1 and the other only middleware 2, and yet they have to be combined into a single system.

@eboasson totally agree.

For example, by default we could print very loud warnings if someone is mixing stuff.

@alsora yeah, that was the idea. and i think documentation and warning would do some work, we user still can try with warning message if we want to.

So I guess it depends on what we mean by "support".

@clalancette i take support is if issue happens that is the bug we must fix? i think that it still makes sense to add doc like cross-distro and cross-vendor communication is not supported officially. some might work but it is anti-pattern and not recommended.
I do not have detailed implementation idea how to add the warning though...

@clalancette i take support is if issue happens that is the bug we must fix? i think that it still makes sense to add doc like cross-distro and cross-vendor communication is not supported officially. some might work but it is anti-pattern and not recommended.

See, I think that is the wrong way to go.  We are essentially taking current bugs (inter-service operability between CycloneDDS and our other RMWs), and upgrading them to policy.  I think we should be going the opposite way; attempting to make these interoperable (with tests), so that we can officially claim that cross-vendor compatibility is supported.  If we don't allow this, then we are making it difficult to produce a robot running ROS 2 that can be communicated from outside the robot.
With that in mind, my proposal for this would be the following:

Re-enable tests in https://github.com/ros2/system_tests/tree/rolling/test_communication that test cross-vendor service calls between Fast-DDS and Connext.
In the special case of CycloneDDS, add a warning in rmw_cyclonedds_cpp when connecting to it from a non-CycloneDDS peer.  That warning would say something like "services don't currently interoperate, this may or may not work".
Update our documentation to point out that the special case of CycloneDDS doesn't work.

We are essentially taking current bugs (inter-service operability between CycloneDDS and our other RMWs), and upgrading them to policy.

ah, that is true, there is already issue and discussion taking place.

I think we should be going the opposite way; attempting to make these interoperable (with tests), so that we can officially claim that cross-vendor compatibility is supported.

totally good to go for cross-vendor communication. and your proposal makes sense to me to support cross-vender communication.
what about cross-distribution communication? according to current API/ABI management, i do not think this can be supported?

@clalancette i take support is if issue happens that is the bug we must fix? i think that it still makes sense to add doc like cross-distro and cross-vendor communication is not supported officially. some might work but it is anti-pattern and not recommended.

See, I think that is the wrong way to go. We are essentially taking current bugs (inter-service operability between CycloneDDS and our other RMWs), and upgrading them to policy. I think we should be going the opposite way; attempting to make these interoperable (with tests), so that we can officially claim that cross-vendor compatibility is supported. If we don't allow this, then we are making it difficult to produce a robot running ROS 2 that can be communicated from outside the robot.
With that in mind, my proposal for this would be the following:

Re-enable tests in https://github.com/ros2/system_tests/tree/rolling/test_communication that test cross-vendor service calls between Fast-DDS and Connext.
In the special case of CycloneDDS, add a warning in rmw_cyclonedds_cpp when connecting to it from a non-CycloneDDS peer.  That warning would say something like "services don't currently interoperate, this may or may not work".
Update our documentation to point out that the special case of CycloneDDS doesn't work.

I do need to point out here that we (the Eclipse Cyclone DDS project) do not consider it a bug. There never was any expectation of service interoperability in the past, there never was a concrete proposal on how to implement it in an interoperable manner (other than some handwaving in some call that I recall), and we are the only ones who do it without requiring support for yet another bad specification (RPC over DDS). When all the pros and cons are considered of the various options, you'll find that that bad specification adds exactly nothing to the end result.
What we do consider a bug is that service interoperability was ignored in ROS 2 from day one. A proper path to addressing that is something we're happy to be involved in, but simply expecting us to abide by the technical choices of others where we strongly believe those choices to be bad is not the way.
If you wish to pin it on Cyclone DDS and state that it doesn’t work, i.e., “is broken”, that is your good right. It is not an attitude that would motivate us to “fix” things.

If you wish to pin it on Cyclone DDS and state that it doesn’t work, i.e., “is broken”, that is your good right. It is not an attitude that would motivate us to “fix” things.

Apologies, my intention was not to call out Cyclone DDS.  From my perspective, I didn't really know that DDS didn't have a standard for a long time, and that there was contention about the standard that exists.
I'm honestly not sure of a way forward (which I guess is why we've been in this situation for a long time).  It seems like Fast-DDS and Connext both implement the standard that exists (as flawed as it may be).  Cyclone implements something potentially better, but which is not standardized.  Some ways forward I see are:

Have ROS 2 define the standard (as you suggest), and then implement it in the all of the RMWs.
Have Cyclone implement the (contentious) standard as an option, either in the RMW layer or in Cyclone itself.

I take it that Erik is in favor of 1.  @eboasson just for my information, is there any potential for 2?  Also do you have any other ideas on a way forward here?

we are the only ones who do it without requiring support for yet another bad specification (RPC over DDS). When all the pros and cons are considered of the various options, you'll find that that bad specification adds exactly nothing to the end result.

@eboasson I am trying to catch up with this. this has been explained in https://github.com/ros2/rmw_cyclonedds/issues/184? (which is almost 3 years old...) specifically on this comment https://github.com/ros2/rmw_cyclonedds/issues/184#issuecomment-630679396?

This issue has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2023-02-16/29927/1

https://github.com/ros2/ros2_documentation/pull/4736 is merged, i will close this issue.


feat: environment variables validation

Description:

When updating CI we noticed with the configuration updates, that if an environment variable such as OPERATOR_ID was defined with not value, it would override the values in the .env file.  This caused tests to fail when the relay tried to submit a transaction.  Ideally, the relay to fail fast, during bootstrap if required environment variables are not set.
Solution:
Consolidate environment variable loading to the start of the relay.  Fail to start if any required environment variables are not set.  Better to fail fast.
All environment variables should be handled in one class that can also validate them, list their usage in a --help option, and exit appropriately if a validation fails.
We should also replace environment variables with a yml settings file.
Needed validations:

Make sure that CHAIN_ID, HEDERA_NETWORK, MIRROR_NODE_URL, OPERATOR_ID_MAIN, OPERATOR_KEY_MAIN, SERVER_PORT are non-empty and in the expected format
Make sure that if OPERATOR_KEY_FORMAT is not specified, the provided OPERATOR_KEY_MAIN is in the DER format
Make sure that HBAR_RATE_LIMIT_TINYBAR is more than HBAR_RATE_LIMIT_BASIC, HBAR_RATE_LIMIT_EXTENDED, HBAR_RATE_LIMIT_PRIVILEGED

Implementation Steps

[ ] Consolidate all environment variables into one service class
[ ] Add validations and exit on fail of validation, to the environment service class
[ ] Add help/usage message and option
[ ] Enhance to use yml instead of dotenv.

There are several solid proposals by @AlfredoG87 that we should take into account as well. Described here https://github.com/hashgraph/hedera-json-rpc-relay/pull/2956#pullrequestreview-2338214042.
cc: @ebadiere
Related issue(s):
Fixes #3023
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

@AlfredoG87 @ebadiere please read the TODOs as well.


SAK-50341 Lessons missing condition picker when editing text on a subpage

https://sakaiproject.atlassian.net/browse/SAK-50341

It doesn't work!


No quotes in object keys

You wrote that if you write object in such way:
var obj = {
'option': 'This is template string',
new_option : 'This is another template'
}
there will be Syntax error on new_option line, cause you should put it incide quotes. In modern JavaScript, you can write without quotes and it won't be any error.
Saw this in Russian localisation.

Thanks! Please include this in a PR and we'll merge.

The relevant section must have changed, but new_option is a valid variable identifier, so it can be an unquoted property key even in older engines.


There are six traffic routing methods available in Traffic Manager today (not four)

The statement "There are four traffic routing methods available in Traffic Manager:" is no longer accurate, as there are six Traffic Manager routing methods available today.

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

ID: fec705c3-1ca3-f5e7-d5ff-3e2baa11a5e8
Version Independent ID: 3936b98a-94e1-8781-15de-d8fa6fd552b7
Content: Azure Traffic Manager - traffic routing methods
Content Source: articles/traffic-manager/traffic-manager-routing-methods.md
Service: traffic-manager
GitHub Login: @KumudD
Microsoft Alias: kumud

@rodsorbara Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

Fixed. Thanks!
#please-close

@rodsorbara We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


feat: use form for react projects

What kind of change does this PR introduce?

[ ] Bugfix
[ x ] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes, and the changes were approved in issue #___
[ x ] No

Checklist

[ x ] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
[ ] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[ ] I have added a convincing reason for adding this feature, if necessary

Other information
Used a form for the input to allow pressing "Enter" to submit the form.

closing in favor of https://github.com/tauri-apps/create-tauri-app/pull/331 , thanks


inline editing causes browser tab to freeze

I'm submitting a ...  (check one with "x")
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
When trying a custom inline editing with specific combination of Angular Material 2 components the browser tab freezes and doesn't recover. One CPU thread is then always at 100%. Specific set of components that causes the freeze: two md-select and one md-datepicker elements. If any one of those is removed problem disappears. Outside of the table any combination of the said components does not cause this issue.
Expected behavior
Browser tab shouldn't freeze.
Reproduction of the problem
Reproduced in this repository: https://github.com/Neverminder/quickstart
Launch the application with npm start and click "edit" on the table
What is the motivation / use case for changing the behavior?

Please tell us about your environment:
Ubuntu 16.04, IntelliJ IDEA, npm, nginx

Table version:  9.3.0

Angular version: 4.2.2

Browser: [all | Chrome 59 | Firefox 54 | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript 2.3.1 | ES6/7 | ES5]

I imagine its because of dirty checking.

With the latest version of Material 2 the issue is now gone.


Horizontal slices in vanilla client handler

This extends the vanilla client support to allow slicing the world in intervals along the X and Z axes as well as Y. This prevents Bedrock edition clients from glitching out at high coordinates.
As this feature is primarily useful only for Bedrock edition, I've added a system for detection of bedrock clients. By default, horizontal slices are only enabled for Bedrock players.

I've tried this in every combination of:

logging in at
walking over the border to

the following locations

all coordinates in range
x coordinate beyond horizontal slice size
y coordinate above 256
x coordinate beyond horizontal slice size and y coordinate above 256

on the following versions

vanilla 1.12.2
vanilla 1.15.2
bedrock

and had no issues (or even noticeable lag).


fix: Add support for aliases and grants on aws_kms_external_key

Add to support aliases and permissions for aws_kms_external
Description

In first test it is not possible to add aliases and the permissions to aws_kms_external_key.
Motivation and Context

Breaking Changes

How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[ ] I have executed pre-commit run -a on my pull request

This PR is included in version 1.0.3 :tada:


YTDownloader Portable

can you make YTDownloader portable?
link https://github.com/aandrew-me/ytDownloader
Used technologies

yt-dlp
Electron
ffmpeg
nodeJS

done!
https://github.com/gek64/build-apps-scripts/raw/main/portable/YTDownloaderPortable.zip
use 7zip to extract files from YTDownloader_Win.exe/$PLUGINSDIR/app-64.7z
then put all files to YTDownloaderPortable\App\YTDownloader\
run YTDownloaderPortable\ytDownloaderPortable.exe


Feature request:  Option for anonymous supplicants

It can be useful in some cases to offer people the option to contact the mod teams anonymously.  Notwithstanding the fact that records can still be extracted from the logs and the console, it might be worth looking into allowing people to open an anonymous help request which would have a channel name not identical to the supplicant's Discord name, and with the supplicant's name redacted or replaced in the dialogue.

This is now possible on the v3 of the bot :)
This can be closed now.


Update lockfile hash

Description
Update lockfile hash

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.97%. Comparing base (3fb76fe) to head (7a51c77).
Report is 18 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1826   +/-   ##
=======================================
  Coverage   94.96%   94.97%
=======================================
  Files          61       61
  Lines        2763     2766    +3
=======================================
+ Hits         2624     2627    +3
  Misses        139      139

see 1 file with indirect coverage changes


[Epic] Semi Auto tuning (bespoke codegen/MicroKernel)

@mattwalsh New Epic, need to add context/tasks here.
### Tasks
- [ ] #13086
- [ ] Demonstrate tuning result speedup on Performance Focus Set models.
- [ ] Run dispatch sweeps to generate 10000+ dispatches for tuning

Note from today: @mattwalsh talking to Nvidia about alternate cublas techniques.


Update index.mdx

I learned that the simplified Chinese version of index.mdx was outdated, so I updated it based on the English version of index.mdx.

Hello! Thank you for opening your first PR to Starlight! ✨
Here’s what will happen next:

Our GitHub bots will run to check your changes.
If they spot any issues you will see some error messages on this PR.
Don’t hesitate to ask any questions if you’re not sure what these mean!

In a few minutes, you’ll be able to see a preview of your changes on Netlify 🤩

One or more of our maintainers will take a look and may ask you to make changes.
We try to be responsive, but don’t worry if this takes a few days.

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

zh-cn
index.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Thank you @ax-6! In fact this was an error in our i18n tracking system.
#1784 changed some frontmatter in the English homepage, marking the page as needing updating.
We then updated all translations in #2233 but used our i18nIgnore keyword, which means it did not mark the page as up-to-date.
Nevertheless, the page was already updated. Thanks all the same!


device-schema.json structure problems?

I’m using AJV to validate data against the schema, but AJV is unable to resolve the refs in “Device-Commons” definition that reference definitions within it’s own schema. Testing on http://jsonschemalint.com/ shows that device-schema.json is a valid schema under the draft-06 specification but not the draft-04 specification.
I also noticed that the “SupportedProtocolType” definition is currently nested inside the “ControlledPropertyType” definition.

@10aboskin to be honest i didn't study the difference. what i can say that the validation is based on a version of ajv that use draft-04 schema.

all schemas are validating ok, thus closing this issue.


Error message from PAHM

Hi @pvelissariou1 @SorooshMani-NOAA,
Do you have any ideas on how to fix the following error in PAHM that I run into it:
---------- MODEL PARAMETERS ----------
InitLogging not called :: ProcessAsymmetricVortexData: 4 isotachs were nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 6 isotachs were nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 6 isotachs were nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 4 isotachs were nonzero.
InitLogging not called :: ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@: The GAHM asymmetric data structure has more than 4 iSotachs in cycle 37.

Thank you!
Yunfang

@Yunfang Sun - NOAA Affiliate @.***> What is the hurricane
you are working on? Can you share the input data (deck file) you are using?
I haven't experienced this error before.
Takis
Panagiotis Velissariou, Ph.D., P.E.
UCAR Scientist
National Ocean and Atmospheric Administration
National Ocean Service
Office of Coast Survey CSDL/CMMB
Physical Scientist - Project Lead
cell:<PHONE_NUMBER>
email: @.***
On Wed, Jun 7, 2023 at 7:32 PM Yunfang Sun @.***> wrote:

Hi @pvelissariou1 https://github.com/pvelissariou1 @SorooshMani-NOAA
https://github.com/SorooshMani-NOAA,
Do you have any ideas on how to fix the following error in PAHM that I run
into it:
---------- MODEL PARAMETERS ----------
InitLogging not called :: ProcessAsymmetricVortexData: 4 isotachs were
nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 6 isotachs were
nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 6 isotachs were
nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 4 isotachs were
nonzero.
InitLogging not called ::
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@: The GAHM
asymmetric data structure has more than 4 iSotachs in cycle 37.
Thank you!
Yunfang
—
Reply to this email directly, view it on GitHub
https://github.com/noaa-ocs-modeling/PaHM/issues/26, or unsubscribe
https://github.com/notifications/unsubscribe-auth/APC7TP24O7LYDVDTEMPMLETXKEMSHANCNFSM6AAAAAAY6SLJPQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Only four (4) isotachs are allowed per cycle.
Panagiotis Velissariou, Ph.D., P.E.
UCAR Scientist
National Ocean and Atmospheric Administration
National Ocean Service
Office of Coast Survey CSDL/CMMB
Physical Scientist - Project Lead
cell:<PHONE_NUMBER>
email: @.***
On Wed, Jun 7, 2023 at 8:25 PM Panagiotis Velissariou - NOAA Affiliate <
@.***> wrote:

@Yunfang Sun - NOAA Affiliate @.***> What is the
hurricane you are working on? Can you share the input data (deck file) you
are using?
I haven't experienced this error before.
Takis
Panagiotis Velissariou, Ph.D., P.E.
UCAR Scientist
National Ocean and Atmospheric Administration
National Ocean Service
Office of Coast Survey CSDL/CMMB
Physical Scientist - Project Lead
cell:<PHONE_NUMBER>
email: @.***
On Wed, Jun 7, 2023 at 7:32 PM Yunfang Sun @.***>
wrote:

Hi @pvelissariou1 https://github.com/pvelissariou1 @SorooshMani-NOAA
https://github.com/SorooshMani-NOAA,
Do you have any ideas on how to fix the following error in PAHM that I
run into it:
---------- MODEL PARAMETERS ----------
InitLogging not called :: ProcessAsymmetricVortexData: 4 isotachs were
nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 6 isotachs were
nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 6 isotachs were
nonzero.
InitLogging not called :: ProcessAsymmetricVortexData: 4 isotachs were
nonzero.
InitLogging not called ::
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@: The GAHM
asymmetric data structure has more than 4 iSotachs in cycle 37.
Thank you!
Yunfang
—
Reply to this email directly, view it on GitHub
https://github.com/noaa-ocs-modeling/PaHM/issues/26, or unsubscribe
https://github.com/notifications/unsubscribe-auth/APC7TP24O7LYDVDTEMPMLETXKEMSHANCNFSM6AAAAAAY6SLJPQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi Takis, @pvelissariou1
I am working on the 2022 Hurricane Ian case, my input files are in the folder of /scratch2/STI/coastal/noscrub/Yunfang.Sun/run_schism/pahm on Hera.
Thank you!
Yunfang

@yunfangsun I'm not sure what that error is, but I have a couple of questions that might help find the answer: Are you using stormevents to download the track file? If so what advisory are you using?
One thing is that using stormevents for non-BEST tracks gives you a track file where the date for each advisory is the advisory issuance date, not the forecasted date. I'm not sure if that's a problem. In BEST track file you only get the hindcast dates.
I'm also tagging @FariborzDaneshvar-NOAA here as well as he will start using PaHM on SCHISM soon.

@SorooshMani-NOAA
Yes, I am using stormevents to download the track file.
The commands are as follows:
from stormevents.nhc import VortexTrack
track = VortexTrack.from_storm_name('ian', 2022)
storm_best_track = storm.track()
storm_best_track.to_file('hurricane-track.dat')

@pvelissariou1 please let me know if anything needs to change in stormevents when writing the .dat file for PaHM. Based on @yunfangsun's script, he's getting the best track, so the date issue described at https://github.com/noaa-ocs-modeling/PaHM/issues/26#issuecomment-1582481689 shouldn't be the issue here!

I am in the ADCIRC Meeting. I  will try to take a look at the data file,
most likely tomorrow. @yunfang have you tried to download the original and
use PAHM to create the output ATM data? PaHM does some basic filtering
before starting the calculations.
On Thursday, June 8, 2023, Soroosh Mani @.***> wrote:

@pvelissariou1 please let me know if anything needs to change in
stormevents when writing the .dat file for PaHM. Based on @yunfangsun's
script, he's getting the best track, so the date issue described at #26
(comment) shouldn't be the issue here!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.<
https://ci5.googleusercontent.com/proxy/J-wBB8hA8WER6lxobIdpf_Gtwo6WPrDkyEiorkFgEHHXy3xu230XmpXolY6-lmk-ixegJYgcCCtwQ6fuuLJVzcBVoCXg3FbXqhnFPPXShQiMaIEhKDWnmazqe-hq1XnTO8VSqNDhFtAwtvhT15fi2x0kAniKT0fdjiaq81P9VDbtt0Tgfnj9RmNOgZmPnAAwmRVeLFnIUN6qEXrA4FuYWxQ1fLidfilPFv9MtdEmQoZlY4xMrw=s0-d-e1-ft#https://github.com/notifications/beacon/APC7TP2ODOCTBI4A6ZVUZXLXKHFY3A5CNFSM6AAAAAAY6SLJPSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTS6KP4W6.gif>Message
ID: @.***>

--
Panagiotis Velissariou, Ph.D., P.E.
UCAR Scientist
National Ocean and Atmospheric Administration
National Ocean Service
Office of Coast Survey CSDL/CMMB
Physical Scientist - Project Lead
cell:<PHONE_NUMBER>
email: @.***

Hi Takis, @pvelissariou1
I will be on leave tomorrow, we can talk about it next week, and I will try the original PAHM to see how it works.

On Mon, Jun 12, 2023 at 12:45 PM Panagiotis Velissariou - NOAA Affiliate<EMAIL_ADDRESS>wrote:
Hi Yunfang,
I used your data file for Ian in PaHM. My mesh was set to ESTOFS-250m.
PaHM digested the file just fine.
Holland model:  no errors reported and it generated the output wind data just fine.
GAHM model:  errors reported for number of isotachs > 4
Offending lines:
AL, 09,<PHONE_NUMBER>,   , BEST,   0, 333N,  792W,   70,  978, HU,  34, NEQ,  190,  130,  100,   60, 1007,  210,  40,  90,   0,   L,   0,    , 355,   9,        IAN,,,,,,,,
AL, 09,<PHONE_NUMBER>,   , BEST,   0, 333N,  792W,   70,  978, HU,  50, NEQ,   80,   60,   80,   40, 1007,  210,  40,  90,   0,   L,   0,    , 355,   9,        IAN,,,,,,,,
AL, 09,<PHONE_NUMBER>,   , BEST,   0, 333N,  792W,   70,  978, HU,  64, NEQ,    0,   30,   40,    0, 1007,  210,  40,  90,   0,   L,   0,    , 355,   9,        IAN,,,,,,,,
AL, 09,<PHONE_NUMBER>, 05, BEST,   0, 333N,  792W,   70,  978, HU,  34, NEQ,  190,  130,  100,   60, 1007,  210,  40,   0,   0,   L,   0,    ,   0,   0,        IAN,,,,,,,,
AL, 09,<PHONE_NUMBER>, 05, BEST,   0, 333N,  792W,   70,  978, HU,  50, NEQ,   80,   60,   80,   40, 1007,  210,  40,   0,   0,   L,   0,    ,   0,   0,        IAN,,,,,,,,
AL, 09,<PHONE_NUMBER>, 05, BEST,   0, 333N,  792W,   70,  978, HU,  64, NEQ,    0,   30,   40,    0, 1007,  210,  40,   0,   0,   L,   0,    ,   0,   0,        IAN,,,,,,,,
So, basically the 3 "red" lines are duplicates of the 3 "green" lines. Delete the 3 "red" lines in the file and you should be ok.
I am not sure that if this is a rare occurrence or, we need to filter out the extra entries based on some criteria. I'll investigate further.
It is the first time I encountered this type of error.
In SCHISM, the PaHM code is identical to the standalone PaHM so, it shouldn't be an issue from SCHISM's side.
SCHISM, by default uses the GAHM model (hardcoded in schism/src/Core/PaHM/PaHM_Utilities.F90, modelType=10 - line 266).
You might want to change this by setting modelType=1 to use the Holland model.
Takis
Panagiotis Velissariou, Ph.D., P.E.
UCAR Scientist
National Ocean and Atmospheric Administration
National Ocean Service
Office of Coast Survey CSDL/CMMB
Physical Scientist - Project Lead
cell:<PHONE_NUMBER>
email<EMAIL_ADDRESS>


fix: disappears more info table

fix the code to maintain opened more-info table

This wasn't the Issue mentioned. The more-info table should be hidden by Default. When the user clicks on the "Show More" button, it should display the Table. But when user requests a new city weather data, by clicking button below or by searching, then it should remain opened and show new data of the city.

Is this the behavior this issue wanted?
If yes could you please retest it
If not could you explain more in detail

Yes, This is exactly what is expected behavior. I am merging your PR to to Master branch. Thank You for your Contribution 👍🏼 .
Please Consider Starring ⭐ the repository. #Happy OpenSourcing


Update README.md

Added TextNow

Thanks for contributing! Could you please make sure the locations are in alphabetical order?

Updated

Thanks!


weird gif output

using:

yosemite
gifsicle-1.82.1-lossy (from here)
ffmpeg version 2.1.4 (from brew)
ImageMagick 6.9.0-3 Q16 x86_64 2015-01-09 (from brew)

here's what I get from a .mov recorded with Quicktime:
gifify recording.mov -o recording.gif

Hi @maxogden, so you are not happy with the output scaling I guess?
Can you send me the .mov so I can test for myself? Thanks

@vvo here ya go: http://max.ic.ht/dropbox/bucket/recording.mov
that .mov is created from the builtin Quicktime Player > File > New Screen Recording

I am a linux guy, talk to me about quicktime I will talk to you about realplayer .
Looking at your issue.

 I had the original gifify in my .bash_profile and it was getting used instead.
Using your gifify results in this which looks great:

This is what I got:

NO NO REOPEN! I WANT TO START A LINUX-OSX WAR!!

 If not I will

oww you mean a runnable docker container exposing a binary? that would be cool indeed. MAKE IT HAPPEN!

@vvo alright here ya go https://github.com/maxogden/gifify-docker


adds Nucleum

adding game: Nuclem #269
Submitting this PR means you have:

[x] searched the readme file and searched the open pull requests (no duplicates please)
[x] and will follow the desired format
[x] used image links that resolve correctly, are appropriately sized, and are served over HTTPS

Once your PR is created, it will trigger a build a GitHub Action (Awesome-Lint). This includes a format linting process, so if there are any issues with the build, please address them.
Do you have further questions? Check the contribution guidelines or open an issue.
When you're ready, check off the above acknowledgments and continue with your Pull Request... and thanks!

Thank you for your submission. This game has already been added to the list via PR #379, from 3 days ago. Please feel free to submit a different game, but to save both our time, please also check any open Pull Requests. I updated the title of this one to reflect the game name, searching the open PRs should help show whether one is already being added or not.


Test PR for Policy Service

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

This appears to be a testing PR, so I'm applying the https://github.com/microsoft/winget-pkgs/labels/Blocking-Issue label to prevent merging.