Readd functionality from masche842 libui-rs fork

Hi Leo,
as bespoken on reddit. Let's do this.
I've merged my changes onto your libui-rs fork, and readded all the functionality I need at the moment to iui. It works for me on mac OS, but I'm pretty sure there are issues on other platforms.
Moreover, I'm still using my own libui-fork (git@github.com:masche842/libui) which diverged from libui upstream quite a bit.
Nonetheless, this is all I need at the moment and with these changes in iui, there is no reason for me to maintain my own version of libui-rs. Instead, I can help you with iui.

This is a great PR, thank you. It'll take me a bit to get it into the shape I want (re: documentation especially) but I'll definitely accept it. Thanks!

mas-merge looks great! Exactly the things that bothered me while moving my code over, but I wanted to check back with you first. And now it's already done :-)
Where can I help you with so we can move forward?
As soon as this is merged I think we can ask pcwalton to put a notice into his readme, so more people get aware of this fork.

Hey :wave: I see that an ill-prepared commit of mine is working its way into forks, which is pretty neat-o!
Note that back when I made that commit/PR I wasn't (and still am not) sure that Control should implement Send.
There's a small discussion about it in the original PR.
TL;DR: while you guys are mulling over this PR, please be advised that not all the original PRs (e.g.: mine!) were fully thought out :smile:

@mitchhentges Thanks for the the heads up. I'm reverting that commit along with some documentation fixes in commit dee073

Closing in favor of #11


Pass recordGroup parameter to loadPairedFastq

I left it out, back when.

Resolved by https://github.com/bigdatagenomics/adam/commit/af5f733dbfada0069f7bf0dc6a8b89125f60cef9.


Fixed int64 overflow for timestamp in v1/api parseDuration and parseTime

This led to unexpected results on wrong query with (...)&start=148966367200.372&end=1489667272.372 fields. (additional 00 at the end of start)
That query is wrong because now start > end, but actually internal int64 overflow caused start to be something around MinInt64 (huge negative number) and was passing the end.Before(start) validation.
In my opinion it should return error on API.
Changes:

Added int64 overflow validation inside ParseTime and ParseDuration, stictly on ParseFloat path.
Added mentioned values as test cases for endpoint, ParseTime and ParseDuration tests

Any feedback welcome!
@brian-brazil @fabxc
BTW: Not sure if negative timestamp makes sense even.. But model.Earliest is actually MinInt64 (https://github.com/prometheus/common/blob/master/model/time.go#L36)
Can someone explain me why Prometheus time model supports negative timestamps?
Signed-off-by: Bartek Plotka<EMAIL_ADDRESS>

Thanks, looks good besides nit.

Can someone explain me why Prometheus time model supports negative timestamps?

Negative timestamps simply indicate times before Jan 1, 1970.

:+1: Thanks!


add write support for various 5.25" formats

I wanted to create a FreeDOS boot floppy for an old Pentium III motherboard I had recently salvaged, but had the Teac FD-55GFR I'd bought 30 years ago for my first x86 box and some double-density floppies purchased NIB from an eBay seller.  (My longer-term interest in the FluxEngine is interoperation with the Apple II, but I'm just getting started with it.)  I'm not sure if there's a command-line incantation that sets up all the options just right to write 5.25" floppies, but this PR adds some presets for the common formats.  Separate options handle writing 360K disks in either double-density or high-density drives, and I included a 720K "quad-density" option (80 double-density tracks per side written in a high-density drive) that I used for cheap backups back in the day.
So far, I've tested writing both 360K and 720K formats in a high-density drive, and I've booted FreeDOS from the 360K disk when the drive was hooked up to another system.  I have a double-density drive on order from another eBay seller and should probably snag some high-density disks as well to test that, but I suspect you can tell by looking at the source if I have the options right.

That's awesome, thanks!
However I am currently working on a big rewrite of basically everything, so I'll hold of merging this until that's done to avoid conflicts (the way disk formats are defined is changing completely).
There is Apple II decode support, but Apple II disks are barking mad due to essentially being software-defined. I can't replicate any of the tricks with spiral tracks or partially magnetised areas. Simple AppleDOS disks should work fine, though.
There's also rather poor support for 48tpi drives, which is going to be reworked, so if you have any ideas how you think it should work, please let me know.

There is Apple II decode support, but Apple II disks are barking mad due to essentially being software-defined. I can't replicate any of the tricks with spiral tracks or partially magnetised areas.

Some of those tricks may require more support than you can get from a standard floppy drive.  For instance, since the head-positioning stepper motor phases are under software control, you can power two phases at the same time to get a half-step, which amounts to quarter-track positioning that was used by some copy-protection schemes.  Drives that only expose step & direction controls will never be able to duplicate that; you'd probably need to attach an Apple II floppy drive directly and twiddle the appropriate pins.
Most of what I have is standard ProDOS floppies (and a few DOS 3.3 floppies); the only tricks I used were notching them to write the back side (nearly everybody did that) and formatting 38 tracks instead of the standard 35 to squeeze another 12K per side (not everybody did that, but ProDOS supported it without modification).

I've done the rework and merged a lot of these --- the 48tpi stuff is still TODO, though. Thanks very much!


Add support for Linux and/or OSX in Makefile.toml

I only have access to windows, so I wouldn't be able to test the build script for other systems.

I just remembered I have a linux vm, so I can work on that. I still don't have access to OSX however.


Issue #154 fix for incorrect threshold signature computation

The necessary fixtures to support this work are in #165.


Update package.json scripts

New Scripts
Clean - removes the old output from tsc
Compile - run clean and then run tsc
Docs - generate the documentation into the docs folder
Prepare - install the git hooks from husky
Pre-Publish Only - run compile (this is run right before the package is published)
Test - run the full test suite
Watch - live compile using tsc as changes are made
A lot of this layout was taken from other typescript packages
npm will automatically publish the dist folder for the package and prepublishOnly will ensure that its the newest build

tysm for adding a clean command, I've been using a shitty powershell command for this in the vscode build task
speaking of which, I think this would be a good opportunity to carry out a much-needed overhaul in tasks.json -- make the build tasks in vscode platform-friendly (right now, there's only one build command and it only works on windows)


Change filename/extension in previous loader

Hi @sokra!
I have writting new loader, which will be replace non-alpha png files to jpg (due image size optimization)
So, could you help me, please, to find a way to change the resource extension.
I have tried to do it  in a loader as follows:
this.resourcePath = this.resourcePath.replace(/.png$/,'.jpg');
this.resource = this.resource.replace(/.png$/,'.jpg');

but, file-loader still emits '*.png' file...
And as usual, thank you in advance!)

As i understand loaderContext is separated between loaders, so i can't change context for file-loader from previous loader :(

Found it works in webpack 2.0

yeah... but you shouldn't do this...
better do this:
{
  test: /\.png$/,
  loader: "file-loader?name=[hash].jpg!png2jpg-loader"
}

This loader more complex under the hood and easy-to-use at the same time.
Please, take a look here: https://github.com/glebmachine/image-optimize-loader


CASMCMS-8535: Remove inaccurate information from header of CFS export script

Description
A comment in the CFS export script mentions command line arguments that did not end up getting implemented for the script. The actual usage message the script prints has the right info, so this is only an issue with a comment inside the script itself. The fix is very small -- just remove the nonexistent arguments from that comment.
I don't think this needs SME review -- just any two reviewers should be fine. The changes require no knowledge of any CSM component or service.

Checklist

[X] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[X] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[X] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.4 release/1.3


URGENT: restoring OrbStack containers after deletion

Describe the bug
Hi OrbStack Dev,
I am a Docker newbie and have been exploring OrbStack for personal use on my little Mac Mini. I am having a terrible problem and need your help desperately or countless hours of effort will be lost.

I've installed 50+ Docker containers in OrbStack to experiment with them and find out what provides value. I was preparing to start going through them one by one to experiment with;   I went to stop all of them and accidentally clicked the little trash button.  All of my containers (except the 2 that were running) are all gone.  I have TimeMachine backups but trying to restore the folder "~/.orbstack/data" folder has not been successful.

Is there any hope of recovering my containers? It doesn't seem like OrbStack has its own internal backups. What folder contains the list of containers?  I have the app BackupLoupe so I can browse my TimeMachine backups.
Why o why isn't there some form of confirmation window on that main delete button? A user shouldn't be able to wipe all of his or her data accidentally with 1 accidental click without at least 1 (maybe even 2!) confirmation windows.

Please help and thank you for OrbStack <3
To Reproduce
No response
Expected behavior
No response
Diagnostic report (REQUIRED)
No response
Screenshots and additional context (optional)
No response

Sorry, but you won't be able to recover the data if you can't restore backups of ~/.orbstack/data because that's where the container is stored. The container storage layers are deleted as soon as the containers are deleted.
Please subscribe to #421 for updates on a confirmation prompt or similar. This is why there isn't one right now:

There used to be a confirmation prompt for container and image deletion, but now only volumes have confirmation because the rest can generally (or should be able to) be treated as ephemeral for most use cases. I see how this could still be an issue though — will consider it.
If you used Compose to create the containers (and it looks like you did because of the group), then you can just run docker compose up to get them back.

Thanks for the comment. It is very concerning that a user can literally wipe their entire config for any containers not running with a just a slightly wrong mouse click next to the run button! (Wow!)
Thank you for considering this.

I understand, but as I mentioned in #421, containers are generally not intended to be used in a way where accidental deletion would be a problem, as they're generally meant to be ephemeral and are not intended for persistent storage.
That being said, it can definitely still happen, so you can expect #421 to be addressed soon.


Sep 10 - Even more Rust

Event Information

Category
Details

Reactor Topic
Coding, Languages, Frameworks

Monthly Topic (if applicable)
Skill Up September

Weekly Topic (if applicable)
Rust

Stream Topic

Stream Date
Sep 10, 2020

Stream Time
9AM PT

Stream Duration
110 minutes

Title
Code and Coffee: Build a Rust App

Description
You may know the basics of Rust: that it is a memory-safe, fast, general-purpose programming language. In this session, we will dust off our programming skills and take a deeper dive into coding with Rust as we build and test a Rust app using VS Code. If you would like to follow along, please make sure to install VS Code (https://code.visualstudio.com/Download), Rust and the "rustup" VS Code extension (https://rustup.rs).

Speaker
Ryan Levick

Moderator
@meaghanlewis

SharePoint ID
7962

Additional Resources:

Event Checklist
10 Weeks Prior

[X] Reactor Content Team (RCT) or Speaker opens a new issue for an upcoming stream filling in the Event Information table. Both RCT and Speaker are marked as assignees.
[X] RCT and Speaker discuss details of the event in the comments of this issue. RCT adds a confirmed-event label and global-twitch-event tag to the issue and adds event to the Global Live Streams project. Issue will appear in the Upcoming Streams column
[X] Speaker adds a ready-for-marketing-edit label so the RCT can review title and description

8 Weeks Prior

[x] RCT does a review of title and description and removes the ready-for-marketing-edit label
[x] RCT moves the issue to the Ready for SharePoint column
[ ] RCT informs the Reactor Marketing Team of the new event information
[ ] RCT provides speaker with assets (e.g. slides, overlays) and the survey data for the event
[ ] RCT moves the issue to the MONTH Streams Prep column (according to the month it will be streamed in)

2 Weeks Prior (Done in /microsoft/Reactors)

[ ] Speaker opens a PR with the new content for the stream on the customer-facing Reactor repository and adds the content-development and global-twitch-event tag to the PR.
[ ] Speaker adds to the same PR a modification to the Streaming README to include their stream information.
[ ] Speaker adds the RCT assigned to the issue as the reviewer when it is ready for review/merge
[ ] RCT reviews, approves, and merges the changes

1 Week Prior

[ ] Speaker and Moderator test setup for streaming (instructions coming soon)
[ ] RCT checks in with the speaker and moves the issue to the Ready to Stream column

During and After Stream

[ ] Speaker and Moderator run the stream
[ ] RCT submits recording to be uploaded to the Reactor YouTube and to be made available on LearnTV
[ ] RCT moves issue to the Stream Complete column

@rylev
Edited abstract for your review. Please add any additional tools or knowledge you would like your audience to have to get the most out of your session.
Code and Coffee: Build a Rust App
You may know the basics of Rust: that it is a memory-safe, fast, general-purpose programming language. In this session, we will dust off our programming skills and take a deeper dive into coding with Rust as we build and test a Rust app using VS Code. If you would like to follow along, please make sure you have VS Code installed.

@KimberlyBolton1 this abstrct looks good to me. ✅

@mebaumb
Abstract final and moved to Ready for Sharepoint.

Event Published on (6/25)

Sorry I'm late to this. Perhaps we should add that people will want to install Rust and the rust-analyzer VS Code extension as well. The last line of the description could read:
"If you would like to follow along, please make sure to install VS Code and the "rust-analyzer" VS Code extension as well as Rust following the instructions on https://rustup.rs."

Added to description per late-arriving feedback from content owner.

Thanks @rylev! Apologies for not waiting to get your feedback here.

Event Cancelled 8/10


option to specify csvSettingsDetector

Motivation
I am using a different text delimiter. Slang cannot parse my csv.
Developer Experience
There should be an option to specify csvSettingsDetector.
var d = new FirstOccurrenceSettingsDetector(eols: ['\r\n', '\n'], textDelimiters: ['"', "'"]);
new CsvToListConverter(csvSettingsDetector: d);

Thanks for this issue!
I think that your solution is good enough to be default as it supports both CRLF and LF, " and '.
Released in v3.5.0.

Actually, I use a different delimiter and wanted to specify it as a parameter. I checked the changelog, docs, tests and couldn’t see that kind of parameter. I guess you added the above as builtin default values.

Friendly reminder :) This is the only blocking issue to switch from another localization package.


Trying to write to multiple characteristics

Describe the bug
Trying to write to multiple characteristics
To Reproduce
I was following this example where they mentioned you only get rxBleConnection in the fist flatMap
    mConnObservable.flatMap(rxBleConnection -> {
        return rxBleConnection.writeCharacteristic(SSID, mSsidView.getText().toString().getBytes())
                .flatMap(ssidBytes -> rxBleConnection.writeCharacteristic(SSID2, mPassPhrase.getText().toString().getBytes())
                .flatMap(ssid2Bytes -> rxBleConnection.writeCharacteristic(SSID3, mSecurityModeSpinner.getSelectedItem().toString().getBytes())));
    })
            .observeOn(AndroidSchedulers.mainThread())
            .subscribe(ssid3Bytes -> {
               //do something
            }, this::onError, this::onComplete);

Expected behavior
I should be able to write to multiple characteristics, but this is resulting in an error.
no instance(s) of type variable(s) R exist so that Single<R> conforms to ObservableSource<? extends R>
Smartphone (please complete the following information):
Generic
Based on me searching google, I think that the interfaces have been changed with the rxandroidble2 and so the example might be old. It would be great if you someone can help me out.

Where is the example you're following?

Hi,
I was trying to follow this example:
https://stackoverflow.com/questions/43667549/rxandroidble-multiple-characteristic-notifications-and-read-write

The compiler shows you what is the problem. It is not a library issue. I have edited the answer in SO link you posted above so it should be now compatible with RxJava2 library version.
Best Regards


Design Select country and language pop-up

We need to design a pop-up where Customer could select country and language (in case there are multiple languages in a specific country). Let's use an existing style guide to design this component.

Related to #455

Hi @pkarw I would like to try to do this, the only thing that leaves me hesitant is the mentioned style guide. You mean that there are out there style guides that tells you how to make a language switcher popup? 😁For instance, a dropdown language list rather than a modal with form fields to set the settings?
Maybe we can make it as a modal in which user can set language country and in case currency?

Ah, ok, uhm, i found this:

so it must be this way? 😁

Corect

great! i'll try although i surely would have doubts on something so probably I would ask lots of questions 😁 ✌

ah one other thing, the modal should be open by click on united states in the footer?

Yes :) we have to figure out how to support the multi site installation - but it’s a topic for different discussion:)

@pkarw can u please assign me this? 😁

Hi Lorena
Are You Working on the popul as well?
I’ve put my research for Multiwebsite in here:
https://github.com/DivanteLtd/vue-storefront/issues/1135
https://github.com/DivanteLtd/vue-storefront/issues/1134
Please check the comments / there is a config file example that can be used in the pop up to list the available stores.
This is the specification on how multiwebsite will be implemented
It will be additionally switching the current i18n Lang regarding the shop setting so the local culture names like the example with “United States” should be solved via i18n (translation in the Italian CSV in this case)
Does it make sense?

Done in the https://github.com/pkarw/vue-storefront/commits/feature/1135_multistore

I need to know which are the color codes for countries and languages links in this modal because from the jpg it's hard to know, they seems to be grey but I'm not sure, maybe @StasiekDivante could help me? 😁

and @pkarw does your implementation provides more than one language per country?

Hi @pkarw I did a little refactoring, added some style and divided the list in two column when storeviews enabled are more than a minim number (by default 3 + 1 - the current country).
But this function still needs to be completed: https://github.com/bitbull-team/vue-storefront/blob/59e853a1f275c4aad06a372b3cb2021fa1034d8d/src/themes/default/components/core/blocks/Switcher/Language.vue#L45
Here are two screenshots of the two cases:


Bug Report template shows Rubrik SDK for Python

Expected Behavior
Do not show the code block documented below.
Current Behavior
---
name: Bug Report
about: Report a bug encountered while using the Rubrik SDK for Python.
title: ''
labels: kind-bug
assignees: ''

---

Steps to Reproduce
Create a new bug report in this repo

Bug Report template location: .github/ISSUE_TEMPLATE/bug-report.md


Issue with x.* versions

Getting NU1100 errors for all package references that use *:
Unable to resolve 'FastEndpoints (>= 5.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'mediatr (>= 12.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'MudBlazor (>= 7.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'tngtech.archunitnet.xunit (>= 0.10.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'xunit (>= 2.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'coverlet.collector (>= 6.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'FastEndpoints (>= 5.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'mediatr (>= 12.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'MudBlazor (>= 7.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'MudBlazor (>= 7.0.0)' for 'net8.0/browser-wasm'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'FastEndpoints.Security (>= 5.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'FastEndpoints (>= 5.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'FastEndpoints.Swagger (>= 5.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'MudBlazor (>= 7.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.
Unable to resolve 'mediatr (>= 12.0.0)' for 'net8.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, LocalNuget, Microsoft Visual Studio Offline Packages, nuget.org.

Hey @ardalis I'm looking into this. What version of the template and .Net SDK are you using? Also, could you share the cli commands you used to instantiate the template that produced those errors?

Looking at the error message the issue is caused by the PackageSourceMapping configuration which discards nuget.org as a source in that environment. If the package is not present in any of the mapped configured packages the restore will fail.

A workaround is to specify the specific versions that are present in the nuget sources of that particular environment.
Or I could reverse the change specifying a wildcard for the minor versions. The downside to this is that newer minor versions and patches will need to be updated from time to time manually to allow new template instantiations with  updated updated.

dotnet --version
9.0.100-preview.7.24407.12

I'd just freshly installed the templates.

It's probably better for the templates to work consistently (and maybe require a manual nuget update afterward) than for them to not work at all (but be "up to date").
Also if there's a way to support Directory.Packages.props out of the box with the templates that would be ideal. Probably worth a separate issue for that if there isn't already one.

I figured out the issue here - it's a sourcemapping problem not something with the project (helps if I read the error message)...
If fixed my issues with SourceMapping and now everything here:
https://github.com/ardalis/modulith/blob/main/Test-UiWithDotnetCli.ps1
works fine on my machine. :)


Enable golden tests for ghc86

Test: Choose golden file depending on ghc version
Test: Create golden files for ghc86
Test: Enable golden-file creation for new versions

Working on fixing the builds


dotnet script Could not execute because the specified command or file was not found

For some reason, my dotnet script does not work anymore.
What I probably did was trying to run dotnetscript from cmd
when I try to do it again in packagemanager console it does not work anymore. Maybe I have to clear the cache or something.

At line:1 char:1

dotnet script test.csx

  + CategoryInfo          : NotSpecified: (Could not execu... was not found.:String) [], RemoteException
  + FullyQualifiedErrorId : NativeCommandError

Possible reasons for this include:

You misspelled a built-in dotnet command.
You intended to execute a .NET program, but dotnet-script does not exist.
You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.

Could you try dotnet script --info ?

Solved it by uninstalling and reinstalling it. Then adding it manually to my path environments
open package manger console:
dotnet tool uninstall dotnet-script -g
dotnet tool install -g dotnet-script


Template for R

The Python chapter has a reference to our Python Template, as a way to start your project with the good practices we encourage everyone to use (license, testing, citation information, etc).
Talking to @PabRod, apparently in R-land, it is more common to use the usethis library. Instead of creating a template for R, it would make sense to have a few lines of R that serve the same purpose (start your project with good practices we encourage).
I guess it would look something like this:
library(usethis)
usethis::create_package()
usethis::use_readme_md()
usethis::use_apache_license()
usethis::use_testthat()
usethis::use_github_action()
usethis::use_citation()
usethis::use_cff()

Would more experienced R people be able to give their opinion?

usethis is really very useful and already does a lot of templetization for you, so you could technically write a small R script to which you pass some parameters, like the name of the package etc. and then just rune the usethis library to init most of the things :)

@maltelueken What do you think about this?

I agree with the above! usethis is also what I would recommend to those who want to start a new R package. Having such a script (maybe publish it as a GitHub Gist?) would be a nice idea.

During the research software templates session in RSECon24, there were some comments about "other tools used in R instead of templates":

devtools
https://github.com/benmarwick/rrtools

Are these equivalent? competitors? I take it our preferred / recommended way is to use usethis?

Dear @c-martinez, here my answer:

In this regard, devtools is essentially equivalent to usethis (actually, usethis is kind of part of devtools).
Never heard of rrtools. It is not an official R package (yet).

So yes, usethis shall still be our focus.

https://book.the-turing-way.org/reproducible-research/code-reuse/code-reuse-packages#walkthrough-of-creating-a-package-in-r


FatalErrorException

Call to undefined method Appzcoder\CrudGenerator\Commands\CrudControllerCommand::qualifyClass()

@24tech Did you followed all instructions correctly.
And let me know your laravel version to reproduce the issue.

Hi. I'm having the same issue.
Yes, I followed all the instructions correctly and my laravel version is 5.4.

Fatal error: Call to undefined method Appzcoder\CrudGenerator\Commands\CrudControllerCommand::qualifyClass()
in CrudControllerCommand.php line 76
at CrudControllerCommand->alreadyExists('admin\ExpenseController') in GeneratorCommand.php line 56
at GeneratorCommand->fire()
i am using laravel admin and version 5.2.* and having the same problem here

Hi Guys,
I couldn't reproduce the issue. I just tested with Laravel v5.4.23
Please update and check again or let me know your version & command

  [Symfony\Component\Debug\Exception\FatalThrowableError]
  Call to undefined method Appzcoder\CrudGenerator\Commands\CrudControllerCommand::qualifyClass()

I just digged into it.. If you look at  it:
CrudControllerCommand looks if a class exists or not using AlreadyExists method of it and inside it calls QualifyClass.
Now, QualifyClass should be there somewhere in ::
A. CrudControllerCommand
B. GeneratorCommand
C. Command
D. SymfonyCommand
E. Command -- In console -- this is base command
However, qualifyClass method does not exist in any of these classes.
Apparently, people who are facing this have upgraded Laravel framework from older to 5.2

its ok with 5.4.* i have tested but not in the 5.2.* :(

Not worked in 5.1 :(

Not worked in 5.2
"Call to undefined method Appzcoder\CrudGenerator\Commands\CrudControllerCommand::qualifyClass()"
:(

I just changed a line of code in vendor\appzcoder\CrudGenerator\Commands\CrudControllerCommand.php line #76, to return $this->files->exists($this->getPath($rawName));
replacing return $this->files->exists($this->getPath($this->qualifyClass($rawName))); and its worked!
It may not the solution but, at the moment, that's what I did.
Hey @Appzcoder dev, I think you missed that qualifyClass() in somewhere.
Please update it.
Cheers!

I have the same error using Laravel 5.3.31.

Sorry guys, I could no manage time to fix the issue.
Just fixed it now at the new release 2.0.5 please check and let me know if you having any issues.


scaffolder: default templates register step fails when description is omitted

Expected Behavior
Since the "description" field in default software-templates like react-ssr-template is optional, I'd expect it to be possible to scaffold a new component from these templates successfully without supplying a description.
Current Behavior
Currently, omitting the description produces the error below during the register step:

12022-01-27T17:15:49.542Z Beginning step Register
22022-01-27T17:15:49.547Z info: Registering https://github.com/mtlewis/test-mtl/tree/master/catalog-info.yaml in the catalog {"timestamp":"2022-01-27T17:15:49.546Z"}
32022-01-27T17:15:49.890Z Error: {"error":{"name":"Error","message":"InputError: Policy check failed; caused by Error: Malformed envelope, /metadata/description should be string","level":"error","service":"backstage","stack":"Error: InputError: Policy check failed; caused by Error: Malformed envelope, /metadata/description should be string\n    at DefaultLocationService.processEntities (webpack-internal:///../../plugins/catalog-backend/src/service/DefaultLocationService.ts:89:15)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async DefaultLocationService.dryRunCreateLocation (webpack-internal:///../../plugins/catalog-backend/src/service/DefaultLocationService.ts:127:22)\n    at async eval (webpack-internal:///../../plugins/catalog-backend/src/service/createRouter.ts:184:24)"},"request":{"method":"POST","url":"/locations?dryRun=true"},"response":{"statusCode":500}}
4    at CatalogClient.addLocation (webpack-internal:///../catalog-client/src/CatalogClient.ts:259:13)
5    at runMicrotasks (<anonymous>)
6    at processTicksAndRejections (node:internal/process/task_queues:96:5)
7    at async Object.handler (webpack-internal:///../../plugins/scaffolder-backend/src/scaffolder/actions/builtin/catalog/register.ts:127:24)
8    at async NunjucksWorkflowRunner.execute (webpack-internal:///../../plugins/scaffolder-backend/src/scaffolder/tasks/NunjucksWorkflowRunner.ts:277:11)
9    at async TaskWorker.runOneTask (webpack-internal:///../../plugins/scaffolder-backend/src/scaffolder/tasks/TaskWorker.ts:113:13)
10    at async eval (webpack-internal:///../../plugins/scaffolder-backend/src/scaffolder/tasks/TaskWorker.ts:104:9)

Possible Solution
Seems like we should either update the scaffolder such that registration doesn't fail when description is missing, or update the default templates to make the field required. Not sure which is the right path here, but very happy to contribute the fix once we've discussed it!

So testing this out a little bit, it looks like indeed that if a description is not provided, then the templating will no coerce this to a string. I gets left as null or undefined which makes it all the way to the template like this:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: "asd"
  description:
  annotations:
    github.com/project-slug: blamdemo/asdsafasgasgasgasg123d
    backstage.io/techdocs-ref: dir:.
spec:
  type: website
  lifecycle: experimental
  owner: "boxoffice"

That means that in json terms, when submitting to the backend, that this becomes description: null which is interesting. As the catalog accepts description: '' which has all the same noninformation.
Thinking that there's a few ways we could fix this here, @freben @rugvip thought's behind allowing null as a description in the policy and is there a reason why it's not supported today? The other solution feels a little bit weird to add some templating logic to go ${{ parameters.description or '' } just to make the policy happy.

Hey could the template even contain
{% if parameters.description %}
description: ${{ parameters.description }}
{% endif %}

Yeah we could wrap up the description - maybe that's fine for now.
I feel that optional !== null, even though this could translate to NULL in the db somewhere maybe, could get confusing though.
@mtlewis do you wanna wrap up the descriptions in the templates like @freben mentioned with the block guard.

Hey @benjdlambert sorry for the slow reply on this! I gave this suggestion a try, but I actually don't think it's possible. Seems like these templates are parsed as yaml on load, so you can't wrap up individual object keys in nunjucks conditional blocks.
How about explicitly defaulting the description parameter to '' in templates?
2022-02-09T12:25:23.536Z catalog warn YAML error at url:https://github.com/backstage/software-templates/blob/optional-description/scaffolder-templates/springboot-grpc-template/template.yaml, YAMLSemanticError: Implicit map keys need to be followed by map values type=plugin entity=location:default/example-templates-remote

How about explicitly defaulting the description parameter to '' in templates?

Gave this a spin, seems to work as expected! https://github.com/backstage/software-templates/pull/13

Sorry to clarify @mtlewis amending the catalog-info.yaml that is called with fetch:template to wrap it up in that yaml bit file not the template.yaml file

I think updating those files is a cleaner fix 🙏

Done, and backstage/software-templates#13 updated!


[Event Dispatcher] Added a way to set the priory

Added a way to order event dispatcher running.
This will remove a lot of pain with getting domain events handled in the correct order

@jrdnhannah eyes please

Please review @jrdnhannah and merge

Can't see anything glaringly wrong with it


#121: Fix issue with compare modal not opening in GUI.

cy.readFile is a function to register a command on the cypress command loop. This command loop does not run while tests are not running. Thus the promise generate by cy.readFile will never resolve when called outside of an executing test. The solution is to bypass the command loop and call directly the underlying api.
Fixes also #121 hopefully.

Might be related https://github.com/archfz/cypress-terminal-report/issues/145


Ship a 1.0 release

Part of https://github.com/rust-embedded/wg/issues/383
Settled blockers:

~#169~ (closed for later consideration)
#163
~#172~
~[RFC] digital::v3 interface + moving to a single interface~
#234
#98 PR: #222
#140
#147 PR: #230
#156
#110
#244 PR: #246
#298
~#249~
#229 PR: #296
~#182 PR: #183~
#287
#321
#351
#365
Alternative SPI word lengths: #320
~#340~
#398
~#387~
#394
#392
#432
#440
#443
#445
#367
~https://github.com/rust-embedded/linux-embedded-hal/issues/87~ discussed in WG meetings, we decided we're OK with the solutions in https://github.com/rust-embedded/linux-embedded-hal/issues/87#issuecomment-1267641344
#349
#480

Open blockers:

#283 PR: #284
#482
#483
Show that MCU and linux implementations work fine
Show that drivers can work fine with the new changes
Your issue here!

Feel free to nominate issues also by commenting below

Here is a link to the video call discussion had by myself and most of the members of @rust-embedded/hal team. This includes initial decisions made, and justification/reasoning for each point. The next steps for this would be to codify this into an RFC, and get approval for it (though there is already general consensus within the embedded-hal team).
by the way, this was the "issue with the list of big topics" we were looking for during the meeting :)

I believe the only unresolved issue as of the list above is https://github.com/rust-embedded/embedded-hal/issues/172
I would also add the dependency on https://github.com/japaric/nb/issues/20
Then we need to think about the dev-dependencies which are at the moment stm32f3 and futures. I guess specially these will hold us back for a while.

This async story began just recently and I do not expect it to end in the coming year. Why should we block on it? We can always add this later. In the worst case, these async traits will be released in embedded-hal v2.0.0.

I also think we should keep async separate because it's a different paradigm and might need require a different approach anyway. I can imagine taking an approach similar to async-std vs std, i.e. have the async traits in a separate crate async-embedded-hal which would allow crates to move indepedently and express more clearly what is supported where.

I'd like to nominate #249 as a blocker for the 1.0 release.

@rust-embedded/hal Would you consider releasing 1.0-alpha.2? I'm working on a driver that I'd like to release soon, and it would be great if I had access to PinState.

Thanks for the reminder, shipped in #255

I've recently learned something that I'd like to share, in case it isn't common knowledge yet: A cargo update will pick up alpha.2, if alpha.1 is specified in Cargo.toml. I think this is problematic, as new alpha releases might introduce breaking changes. HAL crates that would like to test-drive the alpha can't do so while guaranteeing semver stability.
Maybe it would be best to yank the existing alpha releases and test the new changes in a 0.3 series instead? As far as I can see, the alternative would be breakage, inhibited adoption, or additional hoops to jump through (like hiding all alpha implementations behind a feature flag).

I believe an exact version should be needed for alphas. i.e. embedded-hal = "=1.0.0-alpha.2"

Oh yeah, for a moment I completely forgot that you could do that. Seems to be a good way to work around the issue! (Although in general, the situation is still not ideal, as not everyone will remember to do that. Still, probably not worth yanking and re-releasing.)

Yeah, plus if you use alpha versions for production code, you should be aware that things might break at any time :slightly_smiling_face:

Yeah, plus if you use alpha versions for production code, you should be aware that things might break at any time

But that issue affects not only those running the alpha, but everyone using a HAL that supports it in addition to the 0.2.x version. Of course, you might say that HALs intended for production use shouldn't support the alpha version, but then what is the point of an alpha, if it can't be used? :-)
In any case, @eldruin's workaround is good enough, so I'm fine.

But that issue affects not only those running the alpha, but everyone using a HAL that supports it in addition to the 0.2.x version. Of course, you might say that HALs intended for production use shouldn't support the alpha version, but then what is the point of an alpha, if it can't be used? :-)

I don't think you can support multiple versions at once. We do have a few implementations with a non-released separate branch for the alpha versions but I'm not worried about breakage there.

I don't think you can support multiple versions at once.
No issue there, see (and various impls of both in master):

https://github.com/lpc-rs/lpc8xx-hal/blob/6e787f8e26d908b3cea13c3c47f04695f4112837/Cargo.toml#L40

Hello. I think that you must address such issue as https://github.com/rust-embedded/embedded-hal/issues/29
There are many MCUs that do not have open-drain like pins (like Arduinos), but it is still possible to "emulate" similar behavior to communicate with devices via only single data line.
Basically it is mostly about combining two traits together OutputPin + InputPin considering that each HAL implementation will perform under the hood magic while calling function from different traits.

Thoughts on ditching 'try-' before this goes live? It clutters up syntax, isn't applicable in many uses, and doesn't provide much value.

I think the try_ naming is a mistake.

It is noisy
It is inconsistent with the rest of the Rust ecosystem, therefore unidiomatic. For example, all IO in std is fallible, yet doesn't have try_.
AFAICT, the only reason for try_ is avoiding naming collisions if infallible traits are ever introduced, but:

Infallible traits can be achieved by impls having Error = ! (or core::convert::Infallible)
Infallible traits are a bad idea anyway, IMO:

If drivers use infallible traits, it fragments the ecosystem.
If drivers stick to fallible traits, no usability improvement is achieved.
HAL crates will have to implement both the infallible and fallible traits, unless a blanket impl is done. Such blanket impl can be done in an external crate, there's no advantage in having these in embedded-hal.

If infallible traits were still introduced, naming collisions wouldn't be that bad honestly. You either import the fallible or infallible trait, and go use the methods. No code will use both at the same time, realistically.
It is very unlikely that

I think the way to go is keep the decision of having only fallible traits, but name the methods foo instead of try_foo.

Less visual noise
Consistent within the embedded-hal crate
... but also consistent with the rest of Rust.

I have to agree. Unnecessary as Rust won't let you mistake the return type.

@Dirbaio Thanks for your writeup.
I almost fully agree with your assessment. However there is precedence for methods which are using try_ to differentiate from the previous infallible methods like try_fold vs fold. Fallible methods in e-h were always a mistake IMHO, but some people have (maybe had?) strong opinions about keeping the door open to go infallible without cognitive and computational overhead and having the fallible methods to include try_ is the idiomatic way to achieve that.
The reasoning from the critical meeting where this decision was made can be read here: https://hackmd.io/ck-xRXtMTmKYXdK5bEh82A?view#Final-Summary
I think the best way to achieve that would be for someone who deeply cares to create an RFC so people can properly weigh in and we can have a vote in the end.

I want to make a point for keeping the try_ prefix.  I came to like it quite a bit while building a HAL against the alpha-version because it allows a HAL-API design that clearly discerns the generic interfaces from the hardware-specific ones.
Generally an inherent problem with an effort like e-h is that the provided API must be a one-fits-all design.  This of course leads to decisions like having every method fallible.  Such things are absolutely necessary to ensure drivers written against e-h will work in every situation, but it limits the ergonomics for code that is written against a specific hardware.  For example you have fallible methods for setting pins which is super strange on a microcontroller where it obviously cannot fail.  No matter whether the method is called try_set_high() -> Result<> or set_high() -> Result<>, the problem is the same.
I think the solution to this is to not view the e-h API as the general HAL API users are meant to use.  Instead, a HAL crate should provide its own hardware-specific API for direct users and implement the e-h traits alongside for generic drivers to interface with.
I think this is a useful Rust pattern in general which especially applies here:  A type should implement its full featureset as an API consisting of inherent methods (impl Type {}) and then implement appropriate traits (impl Trait for Type {}) ontop of this.  Using a trait for the primary API has its uses (e.g. io::Read) but comes with the huge drawback of locking everyone into a set API that might not fit them perfectly (see fallible vs. infallible).  I think especially in the heterogeneous world of MCU peripherals, it is important that every HAL can make its own API decisions here.
As such I think it is wrong to use the e-h traits for anything else than enabling generic drivers that work across HALs.  In particular using them as the main way to interact with the hardware from application code is not a design which scales in my opinion.
To put it into more concrete terms, here is a GPIO pin implementation for a HAL which leverages such a design.  I have a HAL-crate locally where I explored this in more detail, if there is interest, I can publish it.
pub struct Pin<...> {}

impl<...> Pin<Output> {
    pub fn set_high(&mut self) {
        // non-fallible method for direct users
    }

    pub fn set_low(&mut self) {
        // non-fallible method for direct users
    }
}

impl<...> embedded_hal::OutputPin for Pin<Output> {
    pub fn try_set_high(&mut self) {
        // generic method for generic drivers
        self.set_high();
        Ok(())
    }

    pub fn try_set_low(&mut self) {
        // generic method for generic drivers
        self.set_low();
        Ok(())
    }
}

This allows direct code to look clean; no cluttering by try_ prefixes nor any handling of impossible errors (the never ending let _ = pin.set_high();, pin.set_high().void_unwrap();, or pin.set_high().ok();).  Additionally, no magic traits need to be imported into scope first, because the API is made from inherent methods.
#[entry]
fn main() -> ! {
    // ...

    loop {
        pin.set_high();
        d.delay_ms(100);
        pin.set_low();
        d.delay_ms(100);
    }
}

But it also allows writing generic drivers which can work with any HAL, fallible or not, and such driver code will clearly show that it is able to handle errors by having the try_ prefix visible:
impl<PIN: OutputPin, DELAY: DelayMs> BlinkyDriver<PIN, DELAY> {
    pub fn blinky(&mut self) -> Result<!, SomeError> {
        loop {
            self.pin.try_set_high()?;
            self.d.try_delay_ms(100)?;
            self.pin.try_set_low()?;
            self.d.try_delay_ms(100)?;
        }
    }
}

In more complex situations, the benefit of the HAL being able to define its own API is even greater.  Suppose peripherals like a SPI controller which often have custom features the HAL might want to expose.  A design like outlined above places no limitations on doing this while still keeping the generic layer supported alongside (with reduced featureset) so generic drivers can be "connected" with zero effort (one of the big benefits of embedded rust in my eyes).

I agree with all Rahix said re how to use EH, and how that mitigates try_ by reducing the number of places it occurs, and how it doesn't seem like a good fit for hardware-infallible pins etc, but don't see how that justifies it.

This allows direct code to look clean; no cluttering by try_ prefixes nor any handling of impossible errors (the never ending let _ = pin.set_high();, pin.set_high().void_unwrap();, or pin.set_high().ok();). Additionally, no magic traits need to be imported into scope first, because the API is made from inherent methods.

BTW: If everything is fallible you can also chain calls rather than handling (or ignoring) the possibility of failure on each of them individually...
self.pin.try_set_high()
    .and_then (|_| self.d.try_delay_ms(100))
    .and_then (|_| self.pin.try_set_low())
    .and_then (|_| self.d.try_delay_ms(100))

I do think the ability to combine peripheral operations with the incredible Result API is a big feature, not a bug. And compared to the times of thetry! macro of the early days this is constantly becoming more and more convenient to use every other Rust release.

@therealprof: However there is precedence for methods which are using try_ to differentiate from the previous infallible methods like try_fold vs fold.

As outlined in my previous post, try_ would be idiomatic if we had fallible and infallible traits. However, we don't have them right now, it's unlikely that we'll have them in the future, and IMO it's a bad idea to have them.

@Rahix: I came to like it quite a bit while building a HAL against the alpha-version because it allows a HAL-API design that clearly discerns the generic interfaces from the hardware-specific ones.

You're saying the try_ prefix is good because it allows distinguishing embedded-hal methods from HAL-speficic methods. I disagree this is a good thing, in fact I think it's yet another symptom of the prefix being the "wrong" choice:
In idiomatic Rust APIs, try_ is supposed to distinguish fallible from infallible. As a user, if I see a struct has try_foo and foo methods, I expect try_foo to return Result<X, Error> and foo to return X (and panic/block/etc on failure).
However, HAL methods are likely to be fallible too! For example, it's likely that a HAL Uart will end up with a HAL-specific read() method returning Result and the e-h try_read() method returning Result too. This is inconsistent and unidiomatic. As a user, if I see read and try_read I'd expect read to be infallible.
Maybe the HAL-specific method be named try_read() too for consistency, but then the "advantage" of being able to distinguish HAL vs e-h methods by the try_ prefix is gone.

As an aside, if we were to keep the try_ prefix, the traits themselves should be named TryFoo too, right? See From + from vs TryFrom + try_from. This is yet another reason the current naming is unidiomatic.

This has been discussed in today's Rust Embedded meeting.
           Dirbaio:  maybe the real question here is "do we want infallible versions of the traits or not"
           Dirbaio:  if yes, then try_ makes sense (but traits should be renamed to TryFoo too)
           Dirbaio:  if not, then try_ should be removed
             rahix:  I didn't get around to reply yet, but I do see the point Dirbaio made. I would be okay with removing the prefix as well, my point was related but not at its core a reason to keep try_.
           Dirbaio:  so maybe to unblock the issue, the discussion of "do we want infallible versions of the traits or not" should be had now, not posponed?
            Lumpio:  IMHO the traits are most useful for building generic drivers, and I don't see infallible traits being a thing there if we want fallibleness ever. Which I think is a good thing. HALs can add infallible methods in their concrete implementations if they want, which can even have the same names because of how traits work.
         adamgreig:  having the HAL provide infallible methods for end-users and implement e-h to provide infallible seems like a really nice way to keep the HALs nice for direct end users to use while keeping e-h suitably generic for drivers
           Dirbaio:  IMO postponing the discussion of infallible traits, but adding the try_ naming "just in case" is not the way to go
           Dirbaio:  if the answer is "we don't want infallible traits" then we're stuck with bad naming forever for no reason
         adamgreig:  what's the argument for infallible types in e-h?
            Lumpio:  And hopefully in the Future Rust will be expanded so that you can just ignore Result<T, !>, and use the fallible methods in app code without any extra boilerplate or warnings.
             rahix:  From a technical standpoint I think infallible traits don't get us much at this point, the performance will be the same.
       therealprof:  re adamgreig "having the HAL provide infallible...": Not sure how you would do that. That'd bring you back right to the "no panic" issue.
            Lumpio:  I think adamgreig might've means "implement e-h to provide fallible"
            Lumpio:  meant*
         adamgreig:  sorry yes, second one should be fallible
         adamgreig:  same point Lumpio is making
           Dirbaio:  I haven't seen any convincing argument for having infallible traits in e-h to be honest
           Dirbaio:  usually it's "ease of use"
         adamgreig:  ease of use" seemed appealing until rahix pointed out we don't need it in e-h
             rahix:  yeah, that was exactly my point
           Dirbaio:  but it can be achieved by having HALs add infallible / friendlier methods, it can be achieved by wrapper traits in external crates: impl InfallibleOutputPin for OutputPin<Error=!>
           Dirbaio:  and the disadvantages are many (see my comment)
       therealprof:  I think the main proponent of the infallibe traits should be lurking here on the channel. \U0001f609
           Dirbaio:  who is it?
       therealprof:  Not going to out anybody here if they don't want to speak up.
           Dirbaio:  great! no infallible traits then \U0001f61c
       therealprof:  Yeah, I guess that's what it's going to be.
             rahix:  would it make sense to have a vote for this or is it uncritical enough to just make a decision right now and here?
            Lumpio:  (IRC seems to have died to switching to Matrix for a while)
       therealprof:  Well, one of the team members is not present due to timezone issues.
 firefrommoonlight:  I took rahix's advice and use infallible gpio methods in HAL. I bring this up, since that's an option when using HALs directly, ie you aren't dependent on the EH trait. For generic drivers, you are, and I don't have an opinion.
         adamgreig:  perhaps the best option is PR making the name change and the hal team can vote on it? it's their call in the end, and at least the pr is hopefully fairly quick to put together
         adamgreig:  sed s/try_//
 firefrommoonlight:  I'm treating EH traits as a bolt-on to HAL - not the HAL's primary API
       therealprof:  Let's do that.
         adamgreig:  re firefrommoonlight "I'm treating EH traits as a bolt-on to HAL - not the HAL's primary API": yea, this shift in perspective has definitely brought me around to not needing infallible traits in e-h, personally

Can I nominate #201? E-H CountDown timers can't really be used generically right now, because the choice of Time type varies heavily:

core::time::Duration (imxrt-hal)
Nanoseconds (u64 wrapper in esp32-hal, u32 wrapper in atsamd-hal)
Hertz (STM32 HALs)
1MHz clock cycles as a u32 (NRF HALs)
Maybe others, I don't know of every impl.

Right now a generic driver that needs to use a timer in some way has to ask a user for both a timer and as many different time values as it may need. (Or if it only needs one value, maybe ask a user to preconfigure a Periodic timer)

@AlyoshaVasilieva #201 certainly highlights a problem but at the moment there are no concrete PR proposals to fix it. I think this will require more time to iron out and would not include it in 1.0.
In any case, please do not feel discouraged. We would welcome proposals on how to fix it.

Perhaps CountDown should be removed before 1.0, and added later when fixed then? The current trait is useless in generic drivers, and fixing it is a breaking change.
There are other traits with completely unconstrained type Time, which I think suffer from the same problem.

CountDown
WDT
Capture
PWM

Are there any generic drivers using them?

We should not forget that embedded-hal is useful not only for generic drivers but also as a common abstraction for MCU HALs. Thanks to embedded-hal it should be easier to change between MCUs.
If you find no HALs using a particular trait, removing it initially and readding them later on would also be possible.

In that regard, it provides a standard interface.
I've chosen set_freq(freq: f32) in my code bases, where freq is in Hertz. This is an arbitrary choice over period: f32, where period is in seconds. Note that this interface doesn't make sense for non-FPU MCUs, except perhaps in initial setup as a once-off.

Are there any generic drivers using them?

Stepper is using timer::CountDown, but with a where clause that requires conversion from embedded_time::duration::Nanoseconds to CountDown::Time to be possible. I've extended LPC8xx HAL to support this, but I'm not aware of any other HALs that do so.
By itself, timer::CountDown is not very useful.

https://github.com/dbrgn/espresso is an incomplete driver for interfacing with ESP devices running the ESP-AT firmware. ESP-AT firmware is designed to let you add an ESP microcontroller to a project and give your already-in-use microcontroller ability to use WiFi (plus other things). espresso expects timers to have Time: From<u32> and interpret it as milliseconds, which will fail for most HALs, whether due to it not being supported or because it interpreted 1000u32 as 1000Hz (1ms) or 1000ns (0.001ms).
It's built on an old version of atat; the current version uses CountDown timers in the same way.
I also have a never-finished driver for interfacing with devices running ESP-AT firmware; the idea was to be able to add WiFi/maybe Bluetooth to any E-H UART-capable MCU by adding an ESP32. While working on it I found a bug in ESP-AT firmware where it would crash and stop responding forever (until RESET pin was pulled low). I added a 10s timeout using a Timer with core::time::Duration and then found out that:

Only the HAL I was using had defined Time like that
None of the other HALs had agreed on a common Time unit, and STM32 HALs couldn't handle >1s times due to using Hertz instead. An STM32 was the next board I was going to try it with.

So I stopped working on it and moved on to other things. (I planned to come back and keep working once ESP-AT bug was fixed, but didn't; pretty sure it would still need a timer)
I didn't need any advanced features of a timer, just to be able to say 'start timing ten seconds' and 'has that time passed?'

u32 milliseconds isn't much better than STM32fxx's Hertz: In this case, it's limited to no higher than 1Khz, which is a non-starter for many uses. On FPU-MCUs, thoughts on f32 seconds or Hz?

I think time / duration / frequency related interfaces should be postponed and not be included in the 1.0 release as it is very obvious from the discussion above that the current abstractions are not useful enough on its own and the community has to further explore what the best solution is.
There are some solutions, like using f32 / f64 based timing values or generic approaches, like embedded-time or other proposals I've missed.
But my feeling is, that as of now, we do not have enough experience with those approaches to consider including them into embedded-hal.

I prefer no floats, because:

Not all MCUs have FPUs
Even if you do have an FPU, you may want to not enable it to save power (I use the nrf52840 like this, for example).

I prefer "time units" (seconds/milliseconds/microseconds/ticks/whatever) to "frequency units" (hertz), because;

With Hz you can't delay for 2s, or for 0.75s (unless you use floats or fractions)
(almost?) all MCUs timers specify the "time to delay for" in time units (number of ticks) instead of frequency units. Converting from frequency to time requires expensive reciprocals (1/x), vs converting between differnt time units just requires multiplying by constants.

Either way, I guess our options are the following:

Delay 1.0 until "how to handle times" is resolved.
Release 1.0 as-is, knowing that we will have to do breaking changes to fix this later.
Remove all traits that use time before releasing 1.0, add them back later when resolved.

Traits that use time that would ahve to be renamed

delay: DelayMs, DelayUs
timer: CountDown, Cancel
WDT
Capture
PWM

I think option 3 is best.

Seems like we could keep DelayMs and DelayUs given they specify precisely their integer units?

True, they don't suffer from the problem. If we leave them in then they'll probably end up being inconsistent with how time handling works in the rest of the traits, which would be a shame....

I agree that delay_ms(ms: u32) and delay_us(us: u32) are fine APIs for short blocking delays, eg cortex-m systick. delay_μs(μs: u32) I'm less sure about.

Should we rather have the units in the trait names everywhere?

DelayMs, DelayUs, DelayNs
CountDownMs, CountDownUs, CountDownNs

I buy that, but still find it arbitrary if using floats. I've now added set_period(time: f32) to my timer APIs, so you can do either. (time is in seconds.)

16777216.0 + 1.0

Yet one pre-release maybe?
cc @eldruin

@burrbull Seems appropriate, yes. -> https://github.com/rust-embedded/embedded-hal/pull/327

I would like to nominate #264 as blocking for 1.0.

We had a brief chat about 1.0 in the meeting today and two interesting points were raised:

Should we remove the nb traits entirely for 1.0? It's not clear that they're especially useful or widely used, many users report confusion with them, and ultimately the async traits should fully replace nb. Plus, we could always add them back, but we can't ever delete them later if they're included in 1.0.
Could we keep embedded-hal-async a separate crate forever, with embedded-hal just containing the common types/errors and the blocking traits? It would mean we could remove the ::blocking sub-modules which simplifies the crate, but we couldn't easily merge async traits back in the future.

Both worth resolving before we release 1.0.

I guess there is no need to depend on nb because of async. For compatiblity nb should be in separate trait that probably will be deprecated one day.

How would you do non-blocking calls without the traits where the methods return nb? It's entirely valid to spin in a reactor loop without using async/await syntax, and without using Futures.

Hi! What is the missing work to drive this to completion? How can folks help?

What exactly is needed by "Show that drivers can work fine with the new changes"? I think this may be difficult short of actually porting the drivers, but is it worth reaching out to driver/PAC authors of major drivers to ask them to review?
Same goes for "Show that MCU and linux implementations work fine", that's a bit abstract.
It seems like a release must be close since the only blocking thing with an open issue is docs.

Those mean porting a variety of drivers and MCU and linux HAL implementations to the -rc.1 version and reporting if there are any problems or not.
That is where I see help needed the most, since it is based on community work.

What exactly means a variety of drivers and HAL implementations?
Is it a number? A percentage? A list of important crates? A feeling?
The goal is not measurable unless there is some kind of definition.

I would in general be interested in starting a migration for imxrt-hal. The important open question to me is: How stable is the embedded-hal 1.0 API already? How much can we expect it to change? Is it intended to stay as-is and only change if we discover problems? Or are there still open design decisions?

1.0-rc1 should be identical to the final 1.0, unless some problem is discovered.

Is there a target release date? I think crates are probably more likely to start a port in seriousness (and discover bugs) if there is a solid plan to release before the end of the year, barring anything fatal. After all, some crates have had open issues for switching to 1.0 for three years https://github.com/atsamd-rs/atsamd/issues/332

esp-hal already supports this rc https://github.com/esp-rs/esp-hal/issues/926

https://github.com/rp-rs/rp-hal does too :)

Just searching around https://grep.app/search?q=embedded-hal\w* %3D.*1\.0.*(rc|alpha)&regexp=true, it seems like it is actually pretty well used already.

linux-embedded-hal https://github.com/rust-embedded/linux-embedded-hal
Everything Embassy https://github.com/embassy-rs/embassy (Dirbaio is a maintainer of both)
Raspberry Pi silicon HAL https://github.com/rp-rs/rp-hal (thanks @ithinuel)
The Raspberry Pi PAL https://github.com/golemparts/rppal
EspressIf https://github.com/esp-rs/esp-hal/issues/926
A mock library for the HAL https://github.com/dbrgn/embedded-hal-mock
W5500 ethernet over SPI driver https://github.com/newAM/w5500-rs
An epaper driver https://github.com/caemor/epd-waveshare
Flipper SDK https://github.com/flipperzero-rs/flipperzero
Drogue IoT https://github.com/drogue-iot/drogue-device
BME280 I2C sensor driver https://github.com/VersBinarii/bme280-rs
BME680 sensor driver https://github.com/marcelbuesing/bme680
BL602 HAL https://github.com/sipeed/bl602-hal
Generic GPIO/SPI/I2C display interface driver https://github.com/therealprof/display-interface
RTIC https://github.com/rtic-rs/rtic
U-Blox cell driver https://github.com/BlackbirdHQ/ublox-cellular-rs

I excluded anything that is still on an alpha or hasn't been updated in a year, which adds 5 or so more crates.
That all seems like pretty good coverage the biggest missing ones are atsamd-hal and the stm32 crates (I opened an issue here https://github.com/stm32-rs/stm32f1xx-hal/issues/473 and poked here https://github.com/atsamd-rs/atsamd/issues/332). But embassy covers the STM32 hardware so I wouldn't think this would be too different.
It would be good to have a list of specific crates that are need to be tried with the new interface before making it official.

thanks a lot for your list, @tgross35 !
your regex is missing some dependencies which are written in a different format. e.g. stm32f4xx-hal supports embedded-hal v1.0.0-alpha.11 (and there's an issue for the RC upgrade: https://github.com/stm32-rs/stm32f4xx-hal/issues/686), so a major stm32 HAL is already supporting it, which should be a good sign 🙂

After some discussion last week, we now plan to release the final 1.0 version on Dec 28th, assuming no major issues come up before then. Please keep testing the RC in the meantime!

Hey, I've opened a few issues pertaining to the API surface we're stabilizing: https://github.com/rust-embedded/embedded-hal/issues/523, https://github.com/rust-embedded/embedded-hal/issues/524, https://github.com/rust-embedded/embedded-hal/issues/526, https://github.com/rust-embedded/embedded-hal/issues/527 and to a lesser extent https://github.com/rust-embedded/embedded-hal/issues/525.
I'll volunteer to do the work for each of these, if you think the changes are desired?
Also, this is only the v1.0 release of the embedded-hal crate, right? E.g. the release of v1.0 of embedded-hal-async should probably wait until the async trait functionality reaches stable Rust - at which point its functionality will probably just be included in embedded-hal itself.
Speaking of async, we should probably decide at least a rough plan for how that integration will look like, given that async fn in traits will be stable in 1.75.

Thank you for the review and issues!
Not coincidentally, December 28th (the planned e-h 1.0 release) is the day Rust 1.75 is released, and thus the day async traits are in stable Rust, so I think (?) the plan is to release 1.0 of e-h-async at the same time. However, I don't know if there's still a plan to merge it into embedded-hal, though I haven't heard it discussed in some time.

I wouldn't be against it :) Although I don't think the plan to do so would interfere with an eh 1.0 release.

this was discussed when we did the split initially, the decision was to leave them split after 1.0.

:mega:  we just released v1.0.0-rc.3 with a small GPIO trait change (require &mut self in all methods, previously InputPin and StatefulOutputPin required only &self).
We'd appreciate it if you could do another round of testing. Change looks small but InputPin is a quite foundational trait, and the change might have unintended consequences in type inference / method resolution, we'd love to hear if it's causing issues for you.

I have updated the list of pending issues here. @Dirbaio could you have a look?

I'd like to nominate https://github.com/rust-embedded/embedded-hal/issues/455 for the 1.0 release. I.e. specify whether I2C operations can return early like the SPI ones. If so: do we need a flush()?

thanks @eldruin @Florob for bringing these up, I've sent a few PRs and believe they're all cleared now.

No release today, it's going to be delayed a bit due to being blocked on https://github.com/rust-embedded/embedded-hal/pull/547

embedded-hal and embedded-hal-async 1.0.0 have now been released.
Thank you so much to everyone that was worked and helped through all this time to make this a reality.
🎉

Thanks a lot to all people involved for pushing this forward week after week over the last 6 years! It's been a while 🙂
Embedded Rust has a bright future ahead! 🦀

Awesome!!!


Display an MRU list for playground libraries

When you add a library to a playground, we currently display the complete, alphabetical list of available libraries. However, it’s likely that users will use the same libraries over and over again, and therefore, we should explore displaying an MRU list at the top of the library list, to allow quickly picking your favorite library, in addition to being able to search for one.

Closing in favor of CodeSwing


How to build a smart contract with multiple signature asynchronously?

Here I need to develop a contract with mutiple signature. I know how to achieve it with multiple signature synchronously.
contract with multiple signature synchronously is follow.

At cleos ,I just enter  cleos push action child.acnt execute '["boy.acnt","girl.acnt"]' -p boy.acnt -p girl.acnt, that's OK!
Here is the screenshot！

Yesterday I read a article that eos supports multiple asynchronous signature techniques at eosio developer portal website.
Here is part of this article:

I have read the eosio.msig code ,But I don't know how to develop a contract with multiple signature  asynchronously and how to implement a transaction with multiple signature  asynchronously .
So help me please! give me some suggestion about how to implement a transaction with multiple signature asynchronously. It's best to be more detailed! because this is the first time I develop multiple signature  asynchronously .
Thank you very much!

Here is a suggestion about how to call eosio.msig

I understand a little and don't konw how to implement it!
Can anyone give more detail suggestion?

I have solve it !
Firstly ,No need to modify smart contracts.
Secondly, deploy eosio.msig to blockchain
Thirdly, call cleos multisig propose
cleos multisig approve
cleos multisig exec with necessary parameter.
That's ok!


Optimize skybox jpeg files

Optimized with jpegoptim

Thanks for the pull request @fredj!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

The difference is barely perceptible to me. Ideally we would compress again from the source but I see no problem merging this in and saving ~100kb.


feat: Support alt/control/meta modifiers for keyboard events

Created according to the opened issue: https://github.com/dmtrKovalenko/cypress-real-events/issues/561
This is my very first PR, please let me know if I messed something up.

@dmtrKovalenko I updated src/getModifiers.ts and added shift + alt + control keybinding test which was passed locally. Kindly review.

:tada: This PR is included in version 1.11.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Main

Hi,
I hope this PR finds u well :)
Description:
gimdow lock battery_state support
[Deprecate]Device Log Query replacement with Get Operation Log
Tuya docs: https://developer.tuya.com/en/docs/cloud/Device-Log-Query?id=Kalf83ml5vajf

hi,
i put the gimdow folder in the custom_components and add the gimdow lock integration. then i put the user_code from the tuya app and it finds all my tuya devices include the A1 PRO MAX smart door lock but i can do anything with the device.
what i'm doing wrong here?


about acdc_dataset

I'm interested in your project. Could you share the preprocessed acdc_dataset with me please?
If you can't  share the preprocessed acdc_dataset, can you tell me which patients you use as the training set and which patients do the test set
Thank you in advance.

Hi, friends. Did u get the preprocessed acdc_dataset?  Could you share it?

sorry,I did not get acdc_data
------------------ 原始邮件 ------------------
发件人: @.>;
发送时间: 2023年5月13日(星期六) 下午3:39
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [Beckschen/TransUNet] about acdc_dataset (Issue #117)
Hi, friends. Did u get the preprocessed acdc_dataset?  Could you share it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


silent truncation of numpy int64 arrays to int32 range

Description
import jax
import numpy

y = jax.jit(lambda x: x + 0)(numpy.array([2**32]))
print(y)  # Array([0])

Consider fixing!
#15275 was an attempt, but it bitrotted.
What jax/jaxlib version are you using?
No response
Which accelerator(s) are you using?
No response
Additional system info
No response
NVIDIA GPU info
No response

I believe this is related to the TODO here: https://github.com/google/jax/blob/1c1dd7c8c7ff2e5790159d9cdbbbb1f029a92d4b/jax/_src/numpy/lax_numpy.py#L2066-L2070
Related discussion in #6047


chore: Remove InstanceTypeProvider dependency from Instance Provider

Fixes #N/A
Description
Remove InstanceTypeProvider dead dependency in Instance Provider
How was this change tested?
make presubmit
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 83.121%

Totals

Change from base Build<PHONE_NUMBER>8:
0.04%

Covered Lines:
5550

Relevant Lines:
6677

💛  - Coveralls


NOOS-513/customise-theme

Description

JIRA Reference: NOOS-513

Thanks @filiperosa, I applied a fix here, since the issue was already there in feature/upgrade-react-18-typescript branch


enable custodian double relaxation

This pull is to use the aiida-cusp calculations to enable the standard custodian workflow. To enable the change, a couple places are modified

enable user defined custodian job lists, so the cstdn_spec.yml can contain more than one jobs
allow the output nodes to contain multiple outcar, vasprun.xml by checking suffix in the parsers

The way to use the new function is like below
    vasp_job = CalculationFactory("cusp.vasp").get_builder()
    ....
    vasp_job.incar = VaspIncarData(incar=mp_set.incar)
    ...

    jobs = custodian.VaspJob.double_relaxation_run(
            vasp_cmd="null",
            auto_npar=auto_npar,
            ediffg=ediffg,
            half_kpts_first_relax=half_kpts_first_relax,
     )
    vasp_job.custodian.settings = dict(max_errors=max_errors)
    vasp_job.custodian.jobs = {
        f"{idx}": {
            k: v
            for k, v in job.__dict__.items()
            if k not in ["vasp_cmd", "vasp.out", "stderr_file"]
        }
        for idx, job in enumerate(jobs)
    }
    ...
    submit(vasp_job)

Hi @nw13slx ,
sorry for the long radio silence :-/
Is this functionality still of interest for you?
Thanks!

Hi @nw13slx
I was working on this topic in the meantime and I am going to close this PR in favor of #41, which basically introduces what you asked for.


Test staged binaries

Travis configuration changes
Matrix should now test both the production VENDOR_URL source of Python binaries and the staging python binaries
This PR requires some binary backfill to succeed, so first test run is to ensure the Travis matrix generates tests correctly

These are false positives :( need to pass the vendor_url into the docker environments directly, not just the travis environment

These are still false positives - no 3.4 binary exists in staging, for example, so TESTRUN=run-versions should be failing.

BOOYA TEST FAILS


Add alias option for compatibility with serverless-plugin-canary-depl…

…oyments
Closes #241
@ramgrandhi  can you test this and provide some feedback?

Sure, I will pick it up this weekend.

Sure, I will pick it up this weekend.

@juanjoDiaz - I tested it with the following setup.

package.json:

  "devDependencies": {
    "serverless-plugin-warmup": "https://github.com/juanjoDiaz/serverless-plugin-warmup#add_alias_option",
    ...
  }

serverless.yml:

custom:
  warmup:
    default:
      ....

functions:
  function-1:
    warmup:
      default:
        enabled: true
        alias: 'live'
  ...

plugins:
  ...
  - serverless-plugin-canary-deployments
  - serverless-plugin-warmup
  ...

This set up has caused the warmer-lambda to trigger application lambdas with an alias name now :)
Now, when I trigger the application lambda from the real consumer, it is observed that the same lambda container (that was warmed up earlier) was being reused for application calls. So, we get the benefit of warmup.
Thanks for the fix, my next question, when are you planning to merge it? :)
Cheers,
ram

@juanjoDiaz - I tested it with the following setup.

package.json:

  "devDependencies": {
    "serverless-plugin-warmup": "https://github.com/juanjoDiaz/serverless-plugin-warmup#add_alias_option",
    ...
  }

serverless.yml:

custom:
  warmup:
    default:
      ....

functions:
  function-1:
    warmup:
      default:
        enabled: true
        alias: 'live'
  ...

plugins:
  ...
  - serverless-plugin-canary-deployments
  - serverless-plugin-warmup
  ...

This set up has caused the warmer-lambda to trigger application lambdas with an alias name now :)
Now, when I trigger the application lambda from the real consumer, it is observed that the same lambda container (that was warmed up earlier) was being reused for application calls. So, we get the benefit of warmup.
Thanks for the fix, my next question, when are you planning to merge it? :)
Cheers,
ram

Thanks for the testing! 🙂
I'll try to cut a new release today.

Thanks for the testing! 🙂
I'll try to cut a new release today.

v5.1.0 including this is already released.

v5.1.0 including this is already released.


New package: Google.Picasa version 3.9

Pull request has been created with komac v2.3.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

The URL of the installer is from an Internet Archive saved version of the original installer webpage. Google no longer hosts the executable on its own website (see https://support.google.com/picasa/answer/6383491) and using the original URL (https://dl.google.com/picasa/picasa39-setup.exe) returns a 404 error. As of now it seems like the executable only exists either on the Internet Archive or on various third-party rehosting websites such as Softonic.

Unfortunately, if the developer no longer hosts the package, we can't really link to rehosts. Web Archive might be an authentic image of the data on the site at the time, but using it in this way is the same as using a 3rd party rehost.

Closed this thread because it isn't possible to get the package without linking to third-party rehosting websites.


Problem with higher-precision lines

Hi. For some lines at higher precision I'm finding that while fast-polylines agrees with itself, it doesn't agree with the javascript libraries. Have you encountered this?
points = [[53.05863, -3.81751], [53.05859, -3.81737]]
path = FastPolylines.encode(points, 8)
    # => "otdcg{HnlfcwU~xF_jZ"
FastPolylines.decode(path, 8)
    # => [[53.05863, -3.81751], [53.05859, -3.81737]]

import { decode } from "@googlemaps/polyline-codec";
decode("otdcg{HnlfcwU~xF_jZ", 8);
  # => [[10.10895704,-3.81751],[10.10891704,-3.81737]]

I get the same wrong decode result with @mapbox/polyline, but interestingly the old Polylines library decodes your path string correctly.

@will-r that is weird, the results are completely different... Did you find any updated spec that @mapbox/polyline could be using?


Move README examples into sub directory

PR summary
Moves embedded examples into test sub directory for consistency with the rest of SDKs and as a preparation for managed examples.

Fixes: <! -- link to issue -->
Note: An existing issue is required before opening a PR.
PR Checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the
Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] New tests
[x] Build/CI related changes
[ ] Documentation content changes
[ ] Other (please describe)

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Changes of automation for README.md  done in a separate PR and pending merge of this one.

Preview of PR to confirm that embedded examples are not broken: https://github.com/IBM/cloudant-go-sdk/tree/move-readme-examples

I think you're going to see some whitespace changes when the auto-updated README follows-on, but it shouldn't be an issue.

yeah, auto-trimmer kicked in and I thought it's better to fix it instead of fighting with it. I'll check not to reintroduce it in follow-up automation change.


Sponsorship opportunities

An individual reached out in the chat room about making a monetary contribution to Ramda.
I am realizing that I don't know much about who keeps the lights on around here. I assume there are probably costs associated with hosting / domain / etc?
Is there interest in setting up something like github sponsorship (or whatever) so that people can contribute?

I've footed the very minor bill for our domain name (less than $20/year, if I recall correctly).  The few times we've done some contests, @buzzdecafe or I put up the inexpensive prize.  I can't think of any other costs we've incurred.  Hosting has been free through GitHub.
However, if people want to make donations, I certainly don't want to discourage it!  I'm quite sure we can discover some useful and creative way to use it.
I have no experience setting any of this up, or managing money for such an organization.  Is there anyone around who has some experience and wants to offer suggestions?
Pinging @ramda/core!

We could set up an Open Collective project. I've never done it myself but I see other projects using it.

Open collective, github sponsors, liberapay, donorbox, bountysource salt, there's a few different options. It may also be nice to have a couple of different ways of donating.

@kabo: Have  you had better or worse experiences with any of these?  I've supported coders through github sponsorship and Patreon, as well as various kickstarter sites, and all have been painless.
I'm mostly worried about how to manage it from this end.  I will try to do some research over the next week into tools.  I will investigate all those in your list.  Anyone have others?

GitHub Sponsors puts the focus on individual contributors rather than teams, which does not feel quite right for Ramda. I don't have much experience with the other options.

@CrossEye LiberaPay, Open Collective, Donorbox have been good. Bountysource salt has not been a good experience.
I'm primarily interested in making a one-time donation, another aspect to add to the mix :)

@kabo: Thank you.   I'll be looking into this sometime soon.

bump

@kabo:
Thanks.  I have been looking, and like Open Collective best so far.  But I would like to stew on it another few days before making a recommendation.

Ok, there are lots of options, and I've spent some time on a bunch of them, and I definitely prefer Open Collective.
What I especially like is that this it is all about doing everything in the open, and helping teams keep accountable for it.
I'd like to hear if anyone has a suggestion they really prefer.  And if not, are there any objections to my starting up an account there for the Ramda projects?

Sooo... any update? :)

Sorry.  While I have created an Open Collective account (https://opencollective.com/ramda), I have done little more than setting it up.  I will add links to our README, etc. sometime soon.

I've donated now, I'm glad I'm able to contribute back :)

@kabo: Sorry that took so long.

@CrossEye I've assigned this issue to you as a reminder to update the README. I checked and couldn't find anything and I'm assuming you're probably the best person to set this up?

Perhaps something like the following?:

Sponsorships
Ramda has few expenses and does not actively seek financial support, but if you would still like to contribute, it is welcome and we will find good use for it.  You can contribute at Open Collective.


Change picture size

Testing changing picture size

Codecov Report

Merging #220 (4bc38bb) into master (21a1e41) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #220   +/-   ##
=========================================
  Coverage     78.78%   78.78%
  Complexity     1346     1346
=========================================
  Files           167      167
  Lines          3860     3860
  Branches        515      515
=========================================
  Hits           3041     3041
  Misses          673      673
  Partials        146      146

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 21a1e41...4bc38bb. Read the comment docs.


Provide property to return parent directory on DirectoryPath

Currently getting the parent directory of a DirectoryPath requires some additional steps. Having a DirectoryPath.Parent property would be helpful.

Sounds good, but should be a method unless we construct this at the point that the directory is created.


Default parameters & tensorboard logs

Hello,
first thank you for your research and the useful gym environment and simulator! I am currently trying to reproduce your results and I noticed that I get some noticeable differences in evaluation performance for the PPO2 Mlp agent. Would it be possible to get to know the exact parametrization and could you also share your tensorboard file to make it easier to compare the results.
Thank you!

Hi,
Terribly sorry for the uselessly late reply.
Note that as stated in the README, the MLP controller was not used in the paper and is simply provided as an example that is runnable without installing my fork of the stable-baselines package.
Unfortunately, I no longer have the tensorboard files and do not have an overview of what parameters are left unspecified as the model was simply obtained by running the exact commands listed in the README.
Closing this issue, feel free to open it again should the issue still be relevant to you.


Update rules schema to support USDM v3.0 and v4.0

Update the rules schema to:

Accept "USDM" instead of "DDF" for Standards.Name
When Standards.Name is "USDM", accept:

"3.0" or "4.0" instead of "2" for Standards.Version
"USDM Conformance Checks" instead of "DDF Conformance Checks" for Standards.References.Origin

The pattern for Standards.References.Rule Identifier.Id should remain unchanged as DDFnnnnn.

Duplicate of #642


Email template design gets break after implement patch APSB22-48

We are facing the issue in the email template as well as in CMS pages where the "getCmsFilterContent" function is used in code files to parse the content WYSIWYG editor content after implementing the patch APSB22-48 Security Patches.
Email templates not parsing the {{inlinecss file="css/email-inline.css"}} file and email design get broken in actual received email copy.
Please provide some solution to fix this issue.

Hi @digitaldeve ,
The patch makes changes in the Magento 2 template processor which breaks nested template parsing.
Is the email you're sending perhaps sent via custom code? and Might it be that the entire email is wrapped in the Magento 2 translation function(__()).

No there is no customization implemented in the email template from our side. Also, we checked with Default Magento 2.3.7-p2 by applying the patch APSB22-48 and the email template design get broken after implementing the patch. Please check the attached screenshot for the same.


Improved subtype compatibility rules for types of object literals

Fixes #1446.
Fixes #1448.
Fixes #1655.
Fixes #1723.
With this PR the type of an object literal has increased subtype compatibility until it is widened, similar to how we treat null and undefined in expressions.
In #919 we tightened subtyping rules such that optional properties are required to be present in subtypes. This change is desirable because it makes subtyping more selective to the benefit of union types and overload resolution.
However, #919 is too strict in certain situations involving object literals. For example, the object literal { a: "foo" } is not considered a subtype of { a: string; b?: string; } because it is missing the optional member b. That just doesn't seem right. But at the same time it is entirely meaningful to say that { a: string } is a supertype (and not a subtype) of { a: string; b?: string; }.
The interesting fact here is that when an object literal omits optional properties, we can say for certain those optional properties aren't present, and it is therefore safe to consider it a subtype. But once we infer a variable's type from an object literal, that variable might acquire additional properties that we don't know about and we need to be stricter.
And that's the gist of this PR: The type of an object literal is a subtype of a given type T even when it is missing optional properties from T, but once the object literal type is widened to a regular type that is no longer the case.
An example:
interface Item {
    name: string;
    description?: string;
}

declare function foo(item: Item): string;
declare function foo(item: any): number;

var x1 = foo({ name: "Sprocket" });  // x1 of type string
var x2 = foo({ name: "Sprocket", description: "Bumpy wheel" });  // x2 of type string
var x3 = foo({ name: "Sprocket", description: false });  // x3 of type number

var o1 = { name: "Sprocket" };
var o2 = { name: "Sprocket", description: "Bumpy wheel" };
var o3 = { name: "Sprocket", description: false };

var y1 = foo(o1);  // y1 of type number
var y2 = foo(o2);  // y2 of type string
var y3 = foo(o3);  // y3 of type number

Note the difference between x1 and y1. In the x1 case, the object literal argument is considered a subtype of Item. It omitted description so we know for sure description isn't anything else. But in the y1 case, o1 has type { name: string } and might very well have a description property that isn't of type string. So we can't consider it a subtype.
The PR fixes #1446 and provides a better solution to #1723 (effectively removing the fix in #1774). It also fixes #1448 and #1655 which were caused by incorrect tracking of null and undefined types in unwidened types.

To clarify, are we keeping change #1774? I think it would only make a difference for object literals returned from contextually typed function expressions.

@JsonFreeman No, #1774 (and it's funny effects on error reporting) is reverted by this.

:+1:


Spin up AWS Kubernetes cluster for workshop

Follow the installation instructions from ZeroToJupyterHub:
https://zero-to-jupyterhub.readthedocs.io/en/latest/amazon/step-zero-aws-eks.html
and Pangeo:
https://pangeo.io/setup_guides/cloud.html
Related issues with good suggestions/advice:

https://github.com/pangeo-data/pangeo/issues/71

https://github.com/pangeo-data/pangeo/issues/71#issuecomment-475253509

https://github.com/ESIPFed/esiphub-dev/issues/26

There are two ways to deploy Kubernetes on AWS. Until recently, kops  was needed but now AWS supports Kubernetes natively with EKS.  My plan is to start with EKS and use kops as a fall back if I encounter any show-stopping issues.

We will have AWS credits for the workshop but in the near term,  I am using my own AWS account for testing.

(Following the style of https://github.com/ESIPFed/esiphub-dev/issues/26#issue-406797237 here)
https://zero-to-jupyterhub.readthedocs.io/en/latest/amazon/step-zero-aws-eks.html
Create a IAM Role for EKS Service Role.

It should have the following policies

AmazonEKSClusterPolicy
AmazonEKSServicePolicy
AmazonEC2ContainerRegistryReadOnly
(From the user interface, select EKS as the service, then follow the default steps)`

I created an IAM Role (not a user) associated with EKS.   I expect that soon AWS will automatically create a service-linked role for me, but for now I created a role called eksServiceRole.  I added the AmazonEC2ContainerRegistryReadOnly policy after the role was created.

I use MacOS locally, so Homebrew seems the easiest way to get the required CLI tools installed:
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl
brew install awscli

Since we are setting up the cluster for an audience in Australia, it makes sense to me to use the region ap-southeast-2 (Sydney).
~ $ aws configure
AWS Access Key ID [****************33N7]:
AWS Secret Access Key [****************1s5c]:
Default region name [ap-southeast-2]:
Default output format [None]:

This is taken several kicks at the can but I now have BinderHub up and running on AWS.  I could not manage to get AWS ECR working, so I am using DockerHub instead.  I also don't have any autoscaling going on so my plan is to scale this cluster up for the training and bring it back down manually afterwards.
The only remaining issue is to figure out how to do ingress properly with an Nginx server.  Right now, the binderhub URL needs to be retrieved with
kubectl get svc --namespace pangeo binder
I should create DNS record that is not going to change and set up something that points to the ephemeral IP that AWS is assigning to me.


Fix log-cache URL in CC / endpoint response

This change ensures that CC's / endpoint provides the "https" scheme in
the log_cache href field, so that CF CLI v6.50.0 and later can connect
to the log-cache service correctly. This change also matches the
URL value present in the CAPI BOSH release.
Additionally, this change reverts #14, the previous attempt to
correct this endpoint response value, restoring it to the same kind of
scheme-less host value that is present in the CAPI BOSH release.

getting a conflict generated by https://github.com/cloudfoundry/capi-k8s-release/pull/16 - it seems like there still needs to be some coordination here?  maybe you just want to change the log_cache.url property and not the logcache.host property?

@selzoc Sure, I've removed the logcache.host change in deference to #16.


Use fixed size node tooltip

Overview
Currently, the tooltip overlay displayed when hovering over a node is scaled with the canvas---if the you zoom out, the overlay shrinks with the nodes; if you zoom in, it grows.
This zooming behavior is not desirable in many cases since the tooltips are meant to be read. If it's too small to read, it's not very useful; if it's larger than the desired font size, then it's taking up unnecessary real estate on the screen. The tooltip should be treated the same way as the menu pane, which remains fixed size.
Current Behavior
For example, here's the current behavior at 0.5x zoom, where the text is barely legible:

And at 2x zoom, it much more screen space than needed:

New Behavior
After the changes in this pull request, the tooltip is a fixed size regardless of the zoom level. The same examples of 0.5x and 2x zoom look like the following on this branch:

@tonysyu That's great, that's a super meaningful contribution. Thanks a lot for your work! 💪


Add option for auto/max ranging

Fix #260

Add option into server configuration to choose between AUTO or MAX ranging run. (Not 100% sure if this is the correct place to put it, any thoughts?)
Run auto or max ranging according to this parameter
Reintroduce the changes removed in this PR

@pgmpablo157321 I suspect you need to update compliance/sources_checksums.json as well.

@pgmpablo157321 I suspect you need to update compliance/sources_checksums.json as well.

Updated