Reference to ".NET Framework" may have been meant to be ".NET Standard".

Where it says:
The recommended way to use Entity Framework 6 in an ASP.NET Core application is to put the EF6 context and model classes in a class library project that targets .NET Framework.
Is ".NET Framework" meant to be ".NET Standard"?

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

ID: f376ed07-b726-292f-eb33-7a918337367b
Version Independent ID: 817b265f-0769-80e1-b42c-e1b0d05ff13b
Content: ASP.NET Core and Entity Framework 6
Content Source: aspnetcore/data/entity-framework-6.md
Product: aspnet-core
Technology: aspnetcore-data
GitHub Login: @tdykstra
Microsoft Alias: riande

Associated WorkItem - 125055

@jeremylikness In the sample solution, both the class library and the MVCCore project target .NET Framework -- is that still the way to use EF6 with .NET Core?

I've since come across this page: https://learn.microsoft.com/en-us/ef/ef6/what-is-new/#ef-630
It states the following:

I agree that this page seems out of date. Since 3.0, you don't have to target .NET Framework to use EF6 with ASP.NET Core.

Where it says: The recommended way to use Entity Framework 6 in an ASP.NET Core application is to put the EF6 context and model classes in a class library project that targets .NET Framework.
Is ".NET Framework" meant to be ".NET Standard"?

The quoted sentence only shows up when ASP.NET Core 2.2 or earlier is selected as the Version. With 3.0 or later selected, all the article says is:

Entity Framework Core should be used for new development. The download sample uses Entity Framework 6 (EF6), which can be used to migrate existing apps to ASP.NET Core.

It's easy to miss that, so I'm going to put a warning notice about out-of-date content on the page.


Remove support for future script macros

libxml2 added support for future script macros based on the below
specification
https://www.w3.org/TR/html401/appendix/notes.html#h-B.7.1
This syntax was reserved, but has yet to be defined. It is still unclear
how these macros will be used and what risks will be created if/when
implemented.
This PR removes support until more information is provided.

Hey @ksolo! Thanks so much for submitting this, I agree we should remove this support in Nokogiri.
It looks like this PR failed CI because the test you added is being run even when Nokogiri is built against the "system" libxml2 (in our CI, this is Ubuntu). We should skip this test unless we're running with the vendored libxml2.
An example of how to do this is in https://github.com/sparklemotion/nokogiri/blob/master/test/html/test_attributes.rb
Basically, skip the test unless Nokogiri::VersionInfo.instance.libxml2? && Nokogiri::VersionInfo.instance.libxml2_using_system?
Does that make sense?

@flavorjones That makes perfect sense. Thank you!

:+1:


🚀[Feature]: Generate documentation with Microsoft.PowerShell.PlatyPS

Description
https://devblogs.microsoft.com/powershell/announcing-platyps-100-preview1/?ocid=powershell_eml_tnp_autoid21_readmore
https://www.powershellgallery.com/packages/Microsoft.PowerShell.PlatyPS/1.0.0-preview1

Tried it and it had some deep errors causing content to never be created due to null-pointers...
Putting this on ice.


Threads

Hey!
This is my implementation for threads. This requires https://github.com/jonas747/discordgo/pull/14 to be merged.
I didn't bother making threads their own thing. For example, in the GuildSet struct, they are nested with channels, instead of being separate.
type GuildSet struct {
	Channels       []ChannelState // Threads will be here also
}

I also made a version where they would be separate like this:
type GuildSet struct {
	Channels       []ChannelState // Normal channels only
	Threads        []ChannelState // Threads only
}

But I see no benefits in doing so, quite the opposite. A bunch of code change would be required.
Anyway, I have it done, if you want I can update this PR to that version instead. Lemme know what you think.
Again just trying to speed things up for when you get back from your vacation. Hope this helps.

So as you probably saw i implemented my own version of this, one which kept them separate.
The reason for keeping them separate is that things would "silently break" if channel functions also returned threads, also this is missing the checks to drop threads when you lose access to them (although its probably not needed at all unless someone deliberately exploits it as a attack vector)


add speech recognition to test10

What do you mean by test10, a cluster/node or user ?

I guess this was opened by accident?

Seems to belong to https://github.com/th-nuernberg/memtest. Closing.

Sorry, that was an oversight. I unfortunately assigned the ticket incorrectly.


feat: Endpoint information presented with model (and used in search)

Is your feature request related to a problem? Please describe.
When using multiple endpoints it's getting hard to distinguish between each of them if they host the same models. Here is example when you search for gpt4 and use both OpenAI API and OpenRouter:

Here is another example from workspace tab showing name clash between OpenRouter and Infermatics:

Another potential issue with current implementation: if unique key in the code is model id (which is a model name) - there is potential for name clash if multiple endpoints use the same model id. This is not something I encountered yet and it's not what this feature suggestion is about (but might be related and might need separate task).
Describe the solution you'd like
Providing endpoint name with the model name. Providing also endpoint name in the model details tab. It could be made by adding endpoint name as a tag for example.
Describe alternatives you've considered
Right now I've manually tagged one endpoint, which allows me to see which models are theirs:

Additional context
n/a
Edit: clarified that model id is right now for me a potential issue, not the actual issue I've already encountered.

Unfortunately, if we were to change the model IDs... every existing model config anyone has customized will break and revert back to the default as shown in your list. Not saying you haven't identified a genuine issue, but the proposed fix is going to be a non-starter.

One workaround for id clash issue would be using a manifold pipeline proxy, which I believe should be the recommended solution.

True, putting your OpenAI endpoints in as manifold pipelines would give them a unique prefix 👌

Admins can now hover over the model selector to check the model id.

In conjunction with the connections prefix id feature, this issue is essentially resolved.


Corrected files included in package.json for bundler / no target (#837)

Make sure these boxes are checked! 📦✅

[x] You have the latest version of rustfmt installed

$ rustup component add rustfmt

[x] You ran cargo fmt on the code base before submitting
[x] You reference which issue is being closed in the PR text

✨✨ 😄 Thanks so much for contributing to wasm-pack! 😄 ✨✨
Closes #837
wasm-pack build and wasm-pack build --target bundler generate a _bg.js file, but it is not added to the package.json. The file that is added, *.js will however reference the _bg.js, so when the package is distributed (both through pack or publish) it is not usable.
This change will fix that by passing the correct bool value to npm_data
As is the same for my other PR, there is some test failure that I locally also have on the master branch. Please let me know how to address this if possible

Thanks!

Is a release scheduled anytime soon in order to fix this issue?

Is a release scheduled anytime soon in order to fix this issue?

+1

@ashleygwilliams

Same here. This bug prevents us from running even a simple example (e.g. https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm). So this patch should be released soon.

A workaround would be to reference this git repository directly in the cargo.toml:
wasm-pack = { git = "https://github.com/rustwasm/wasm-pack" }
But do note that that may include other unreleased changes that have been merged to master as well.

Let me add an easier workaround: adding the _bg.js file to the generated package.json manually.


Migrate to aiosmtp

The used smtpd module has been removed in Python 3.12, with https://pypi.org/project/aiosmtpd as its successor

Hi @sebix,
Not wrong, I had not followed the removal of smtpd in 3.12. Thank you for the information. Now I just need to find the time to move all the code to aiosmtpd.


List of tasks

onetime tasks at startup
background tasks that keep running

onetime:

setup led
setup speaker
setup RFID
setup ADC for photodiode
setup OLED
setup push buttons
setup webpage
scan for available alarm music

background:

webpage
time display
check sleeping: RFID interaction & light sensor
alarm clock


Update Field.php

Fixes #
Proposed Changes

Orchid has checks for allowing "data-" attributes, but I cant set them, because orchid filters attributes by allowed list (universal attributes and inline attributes). So, this fix is allowing to use "data-test" attribute in components without extending them.
adding "data-test" attribute. It is great solution to specify component names, for acceptance testing.

You can inherit any field and add your own list of allowed attributes.
But you're right, this can be a tedious task.
I think we could automatically allow all attributes starting with data-
What do you think about this? This will also solve your problem.

I think we could automatically allow all attributes starting with data-

I can make another fix, and allow to use data- attributes. And I think it is better, really, because you have opportunity to use them, but there no data- attributes in default fields.
Why I dont want to make own fields - because default orchid fields are very good to use, and make own overrides in projects - it is not good way I think.
So, I can just create pull request and change
protected function getAllowDataAttributes()     {         return $this->getAllowAttributes()->filter(function (/* @noinspection PhpUnusedParameterInspection */ $value, $key) {             return Str::startsWith($key, 'data-');         });     }
to
protected function getAllowDataAttributes()     {         return collect($this->getAttributes())->filter(function (/* @noinspection PhpUnusedParameterInspection */ $value, $key) {             return Str::startsWith($key, 'data-');         });     }


New version: Grammarly.Grammarly version <IP_ADDRESS>7

Created by 🥟 Dumplings in workflow run #6507.

Log
Updated: <IP_ADDRESS>4 → <IP_ADDRESS>7
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

https://github.com/microsoft/winget-pkgs/issues/142854


snapcraft: 8.5.0 -> 8.5.1

Things done
Bump snapcraft to latest upstream version: https://github.com/canonical/snapcraft/releases/tag/8.5.1

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 365862

x86_64-linux

:white_check_mark: 2 packages built:

snapcraft
snapcraft.dist


Rollout staging

https://github.com/greenpill-dev-guild/impact-framework-backend/actions/runs/8792858244


Android memory Leak when using "Don't Keep Activities" developer setting

Basic Flutter plugins leak memory when the Android developer setting "Don't Keep Activities" is turned on.
The enclosing "MainActivity" class will not be freed and keeps two instances in memory.

The top activity is "mStopped = false", the bottom one is "mStopped = true", but not destroyed as it should be.
Sample project is available here: https://github.com/ened/demo_flutter_activity_leak.git
HPROF attached.
memory-20181017T072411.hprof.zip
 $ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel dev, v0.10.0, on Mac OS X 10.14 18A391, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 10.0)
[✓] Android Studio (version 3.2)
[✓] VS Code (version 1.28.0)
[✓] Connected device (1 available)

A possible solution may be to clean up manually:
public class MainActivity extends FlutterActivity {
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        GeneratedPluginRegistrant.registerWith(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();

        try {
            Field delegate = MainActivity.class.getSuperclass().getDeclaredField("delegate");
            delegate.setAccessible(true);
            delegate.set(this, null);

            delegate = MainActivity.class.getSuperclass().getDeclaredField("eventDelegate");
            delegate.setAccessible(true);
            delegate.set(this, null);

            delegate = MainActivity.class.getSuperclass().getDeclaredField("viewProvider");
            delegate.setAccessible(true);
            delegate.set(this, null);

            delegate = MainActivity.class.getSuperclass().getDeclaredField("pluginRegistry");
            delegate.setAccessible(true);
            delegate.set(this, null);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }
}

Then at least I get the MainActivity count down to 1 when the App is active & inactive, but it really should be zero when the App is in the background (& activity has been killed by the Android system).


reporting: rename "systemhealth" prefix in scripting / directories / configd with "health"

Important notices
Our forum is located at https://forum.opnsense.org , please consider joining discussions there in stead of using GitHub for these matters.
Before you ask a new question, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

The API stuff is still called Systemhealth/systemhealth but I'm only concerned about directory structure and the bulk cleanup was the system/health/syslog split for consistency.


gallery: set Dart SDK location in IDEA

Thanks!
Curious if @devoncarew has any reservations to this approach.
If not, would we want to do this for all the examples?

lgtm for my part!
All the examples, I don't know. But all the ones we expect people to open as separate projects? flutter_gallery, and the main repo itself?

See: https://github.com/flutter/flutter-intellij/issues/860
cc @mit-mit


Push SMS to non-service raters

Celery task to find people who have completed registration but not completed service rating and send message. Needs contact API.

@gsvr review please

@gsvr one more pass please then I'll land

:+1:


Eth2 shorthand standardized

Community seems to have coalesced around "Eth2" as the go-to shorthand―updated accordingly. (Examples: https://blog.ethereum.org/2019/09/19/eth2-interop-in-review/ • https://Eth2.news • https://twitter.com/search?vertical=default&q=Eth2&src=typd • etc.)
Plz squash to a single comm 👍

for posterity: @hwwhww's poll 📊
https://twitter.com/icebearhww/status/1186924584429219841

uh oh, didn't squash..


Spike on 12 hour time input in locales that use 24 hour format

Feature Request
Description
The translation team has noted that en-US, es-US, and ar are the only locales from our supported locale list that should include 12 hour display. Some guidance is needed on how we should handle the 12 hour time input when the locale is set to one that only uses 24 hour time formatting. Currently, we display 12-hour input, with the final input for a.m./p.m. being empty. Logging an issue so we can spike on this with the translation team / UX team to figure out a reasonable solution.

We are currently running into this problem. If you set a datetime picker to 12 hour format, but set your locale to en-GB, you get a date time picker with no am/pm that cannot select anything larger than 12:59

Some options we've discussed
Putting preference on the locale over the time-format variant. e.g. If locale is set to a place that uses 24 hour format, but the variant is set to 12 hour format, the control would use the 24 hour format.
Another option is putting preference on the time format variant. e.g. If the locale is set to a place that uses 24 hour format, the control would display the 24 format display, unless the time format variant was set to 12 hour format, then it would display in 12 hour format.

My preference is towards the later of the these two, I'm curious to hear what @benbcai and @mmalaker think on this.

I went ahead and changed to 24 hour for en-GB and now we get an onChange event when you first click the time picker that has a value of empty string, and no further onChange events after that.

I'm concerned that the former option would be considered a breaking change.
Isn't the latter option the current behavior? The default variant for both date-time-picker and time-input is the TimeUtil.FORMAT_24_HOUR so unless the consumer chooses to use the 12-hour format,
The time-input does log out this warning for such scenarior:
This locale only uses 24 hour clock. The ante meridiem and post meridiem will not be displayed

Basically the time input needs to work properly in any supported locale. If the 12 format doesn't apply in a given locale, the input should allow time in the 24 hour format.

I did some more testing, re my previous comment. I set an onBlur to see what would happen. Even though we're setting an initial value for the datetime picker (and that value is displayed correctly on the page), if you change only the time, no onChange is fired, and onBlur shows only the time, not the date. If you change the date and the time, it works correctly (even though a date is already set).
This is both for 12 hour and 24 hour time formats, and only in en-GB. It works correctly in en-US (changing either date or time is respected).

The purpose of the 12 hour variant is to allow users enter time in a familiar format for the locales that support it. I don't think the intention was to force 12 hour time entry in locales that use a 24 hour clock. But regardless, the time input has to function in any locale so I agree this sounds like a bug.

I also agree that the time-input shouldn't get in this state for the 12-hour variant. Given the two options in @bjankord's comment, it looks like the second option will not address this issue since that's how it currently works (honoring whatever the variant is set). Sounds like @mmalaker's preference is to go with the first option (to ignore the 12-hour variant if set and use the default 24-hour variant for locales that do not use the 12-hour format).

The translation team has noted that en-US, es-US, and ar are the only locales from our supported locale list that should include 12 hour display.

Why is that?  Just trying to understand why en-GB, for example, shouldn't include a 12 hour display.

Talked in scrum today with @benbcai and @mmalaker. The consensus was to move forward with putting more weight on locale instead of time format variant.
If you set the variant to 12-hour but the app is being rendered in a locale that uses 24-hour format, the time input will not honor the 12-hour variant and instead honor the locale indicating that it should use 24-hour. Essentially, the 12-hour variant will only work in locales that commonly use 12-hour formats. (en-US, es-US)
There is some ambiguity around if en-GB should work similar to en-US in this regard, or if that locale should always use 24-hour format. We'll be working with the translation team to find an answer for that.
@gerard-isdell Is 12 hour format common in the UK or is 24-hour format more common?

After discussing with the Terra team, we decided to handle locales that only use the 24-hour format by always displaying the component in the 24-hour variant regardless what the variant prop is set to. For locales that use both the 12-hour and 24-hour formats, it will continue to work like it does today by honoring the variant prop.
Currently, if the variant prop is set to 12-hour for locales that only use the 24-hour format, consumers are only able to enter a time from 12:00 a.m. to 11:59 a.m. The fix will fall back to the default 24-hour format, which will still allow consumers to enter what ever time they were able to enter with the addition of the time from 12:00 p.m. to 11:59 p.m. For this reason, we do not think this would be a breaking change.
@gerard-isdell According to these references (1 and 2), en-GB does use the 12-hour format. I will reach out to the translation team to figure out which of the currently supported locales do and do not use the 12-hour as this is important for this implementation.

@calebmeyer I believe the issue that you described above about the onBlur is because 2019-04-09 is an excluded date that you either set in the excludeDates or filterDate props. It is also possible that this date is outside of the minDate and maxDate range. Hence, once you click on the date input, the date gets cleared because it is an excluded date.

The translations team indicated that the following locales/languages accept and do not accept the 12-hour time notation.

Do not accept 12-hour time notation. If the variant prop is set to 12-hour for ones of these locales, it will be ignore and defaults to use the 24-hour variant.

de
es-ES
fr-FR
fr
nl-BE
nl
pt-BR
pt
sv-SE
sv

Accept both 12-hour and 24-hour time notations. Honors the variant prop as set.

ar
en-AU
en-CA
en-GB Note: The NHS only accepts the 24-hour notation but the 12-hour notation is still accepted in the UK. Since this component can be consumed in non-clinical/healthcare applications, we should also allow the 12-hour notation.
en-US
en
es-US Note: reference
es Note: Spain uses only 24-hour notation but Mexico and Dominican Republic are examples that use the 12-hour notation.

Nice work on the spike @benbcai, I think this gives us a good path forward for how we should resolve this issue.


Web Icons and Badges-1 (the first three badges)

In the OctopOs Prime project, one of the 8 teams, namely the Web Team, requires the following designs from the Design Team:

Designing the main icon for the Web Team
Designing 10 badges that determine the levels of members in the Web Team

Obtaining the outputs as an icon
Obtaining the outputs in PNG format

The badge names for the Web Team are listed below.
1) HTML Sorcerer
Master the basic HTML structure and tags skillfully.
2) CSS Crusader
Master CSS styling and layout techniques to visually enhance your web pages.
3) JavaScript Jedi
Explore the power of JavaScript and make your web pages interactive.
4) Responsive Guardian:
Optimize user experience by creating websites that adapt to every device.
5) DOM Navigator
Control your web pages proficiently using the Document Object Model (DOM).
6) Framework Hero
Develop powerful web applications by skillfully using popular web frameworks.
7) API Overlord
Skillfully use APIs to exchange data between applications.
8) Version Control Emperor
Skillfully use version control systems for collaborative development.
9) Security Sentinel
Develop and protect your web applications securely and robustly.
10) Full-Stack Galaxy Lord:
Master both front-end and back-end development and dominate the web universe.
The works in icon format (.ico extension files) will be uploaded to the op-design repository's Src/2D/Badges/Web/Ico directory, and those in PNG format (.png extension files) will be uploaded to the op-design repository's Src/2D/Badges/Web/Png directory.
The standardization of file names for the uploaded files will be as follows:
<Date>-<description of the logo>(<size>).<file extension>
Example:
07-03-24-op-logo-black-and-blue-colors-futuristic-laboratory-setting(1280x720).jpg
08-03-24-op-logo-sleek-and-futuristic-clean-white-background(1280x720).jpg

Web team first four badges.

Fourth badge of the web team Responsive Guardian


error running make imports

@zhengj2007
Running make imports does not update the owl files and instead gives this:
[Fatal Error] :1:50: White spaces are required between publicId and systemId. INVALID ONTOLOGY FILE ERROR Could not load a valid ontology from file: import_EFO.owl For details see: http://robot.obolibrary.org/errors#invalid-ontology-file-error
The same occurs with any import file (not just EFO). However, the Ontofox site works, and ROBOT has not updated recently. The import owl files not missing.

It seems the ontoFox service has some problem. I have contacted Oliver He for fixing it.

Fixed the issue. Should work now.

@zhengj2007 I still get the same error.

make -B imports worked. Thanks.


Icon buttons .pf-m-plain, justify-content: center

Icon buttons icons justify left after we merged #2050. Need to update the justification for .pf-m-plain buttons.

@christiemolloy is already on top of this one w/ #2066


unreponsive

Issue Type: Bug
Extension Name: LiveServer
Extension Version: 5.6.1
OS Version: Windows_NT x64 10.0.19041
VSCode version: 1.49.3

:warning: We have written the needed data into your clipboard. Please paste! :warning:

Would you like to elaborate the issue so that it's clearer...


ERROR CODE

Notice: Undefined index: month in C:\xampp\htdocs\cbt-exam-main\media\php\dbTool.php on line 513
Warning: join(): Invalid arguments passed in C:\xampp\htdocs\cbt-exam-main\media\php\dbTool.php on line 186
HOW CAN I FIX THIS?
AM USING XAMPP 7.0

Which of the page do you encounter this error,?
I am also test running it on another server of php 7.2

the application has been updated, retry the package again to see updates
On Fri, Feb 17, 2023 at 3:13 AM Ucgodman @.***> wrote:

[image: image]
https://user-images.githubusercontent.com/97987253/219531871-20ceb809-c6b0-48e7-97d4-45fc085d0a3e.png
Notice: Undefined index: month in
C:\xampp\htdocs\cbt-exam-main\media\php\dbTool.php on line 513
Warning: join(): Invalid arguments passed in
C:\xampp\htdocs\cbt-exam-main\media\php\dbTool.php on line 186
HOW CAN I FIX THIS
—
Reply to this email directly, view it on GitHub
https://github.com/mayorjo4ever/cbt-exam/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADM4OD4YMBH4OVHCPPJO2X3WX3NDVANCNFSM6AAAAAAU64RD3A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


feature: new dashed option for line charts

This PR introduce a new feature that we can apply dashed styling to each dataset in line chart.
You can define the dataset as you were but now there is a new option strokeDasharray
In react-native-svg this option is where you define your line styling so i adopted the same logic and name to use it also here
Example below.
datasets: [
 {
	strokeDasharray: ['5', '25'],
	data: [
	  Math.random() * 100,
	  Math.random() * 100,
	  Math.random() * 100,
	  Math.random() * 100,
	  Math.random() * 100,
	  Math.random() * 100,
	  Math.random() * 100,
	],
  }
]

This change is crashing android.  Google "strokedasharray react native svg" it seems to be a known problem. In the short time I spend looking into this, I did not find a solution.

Closing this because of a merge conflict and an unaddressed crash on android


[T4A5][T09-B1]Zhang Yunxuan

Ready for review (sorry about the mess because I tried to fix git)

@yunxz Some comments added. Please close the PR after reading comments.


⚠ Bofrost.be has degraded performance

In 1ddd5f5, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2534 ms

Resolved: Bofrost.be performance has improved in 4d32b5e.


import cvzone error

I installed cvzone via pip install cvzone. It was installed correctly.
But I get the following error message.
ModuleNotFoundError: No module named 'cvzone'
Any method to fix this?

you fint solution?


Update build environment for GitHub Actions from macOS 12 to 15

Summary
The macOS 12 runner has been deprecated by GitHub, so I've upgraded us to macOS 15.
NONE

@toninis Had to patch an issue with the runner: https://github.com/actions/runner-images/issues/11021
Quick re-review if you could? :)

/cherry-pick release-5.10

Cherry pick is scheduled.


Cannot reproduce failure on bevy_prototype_debug_lines

I wanted to reproduce https://asan.saethlin.dev/ub?crate=bevy_prototype_debug_lines&version=0.8.1 locally so created a file containing bevy_prototype_debug_lines and ran cargo run -- --crate-list that_file but all I got was
[2022-11-02T12:16:37Z INFO  miri_the_world::db_dump] Downloading crate database
[2022-11-02T12:17:04Z INFO  miri_the_world::db_dump] Processing crate database
[2022-11-02T12:17:09Z INFO  miri_the_world] Building list of crates to run
Running bevy_prototype_debug_lines 0.8.1
Finished bevy_prototype_debug_lines 0.8.1
2022-11-02T12:17:09Z INFO  miri_the_world] done!

I am on the asan branch and cargo 1.67.0-nightly (7e484fc1a 2022-10-27).
I didn't see any build logs, and after processing the database the output was done very quickly.
Any idea what might have gone wrong?

I didn't see any build logs

Nothing appeared in logs/? At a guess, did you build the docker image this requires first? (The Rust program should really do this for you...)
The build logs end with a copy of the Cargo.lock that the build used. It looks from the backtrace like this issue is actually in bevy_ecs. Is there a newer version of bevy_ecs that fixes this issue?


Support optimum-quanto

Feature request
Let's add a new quantization method to LoRA, namely optimum-quanto.
There is some more context in this diffusers issue.
Motivation
First of all, the more quantization methods we support the better. But notably, quanto also works with MPS, which distinguishes it from other quantization methods.
Your contribution
I did some preliminary testing and partly, quanto already works with PEFT, as the QLinear layer is a subclass of nn.Linear and as such, lora.Linear is applied. Some features like inference appear to work already. However, some features don't work correctly, like merging. Here is a very quick test:
import torch
from peft import LoraConfig, set_peft_model_state_dict, get_peft_model
from optimum.quanto import quantize, freeze, qint8
from transformers import AutoModelForCausalLM

torch.manual_seed(0)
inputs = torch.arange(5).view(-1, 1)
print("loading model")
model = AutoModelForCausalLM.from_pretrained("facebook/opt-125m").eval()
with torch.inference_mode():
    output_base = model(inputs).logits

# Step 3: Quantize the Model
print("quantizing model")
quantize(model, weights=qint8)
print("freezing model")
freeze(model)

with torch.inference_mode():
    output_quantized = model(inputs).logits

config = LoraConfig(r=8, lora_alpha=16, lora_dropout=0.1, init_lora_weights=False)
print("adding adapter (random)")
model = get_peft_model(model, config)
model.eval()

with torch.inference_mode():
    output_lora = model(inputs).logits

    with model.disable_adapter():
        output_disabled = model(inputs).logits

    output_after_disabled = model(inputs).logits

model.merge_adapter()
with torch.inference_mode():
    output_merged = model(inputs).logits

model.unmerge_adapter()
with torch.inference_mode():
    output_unmerged = model(inputs).logits

unloaded = model.merge_and_unload()
with torch.inference_mode():
    output_unloaded = unloaded(inputs).logits

print("output_base")
print(output_base[0, 0, :5])
print("output_quantized")
print(output_quantized[0, 0, :5])
print("output_lora")
print(output_lora[0, 0, :5])
print("output_disabled")
print(output_disabled[0, 0, :5])
print("output_after_disabled")
print(output_after_disabled[0, 0, :5])
print("output_merged")
print(output_merged[0, 0, :5])
print("output_unmerged")
print(output_unmerged[0, 0, :5])
print("output_unloaded")
print(output_unloaded[0, 0, :5])

Note that all the outputs involving merging are not as expected.
I can certainly take this when I have time but contributions are highly welcome. For inspiration, check out past PRs that add new quantization methods.

not stale

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

not stale

This would be extremely helpful, currently Flux with lora mostly run on A100 like this, but flux can comfortably run on 4090, a consumer card. If this issue is resolved, it would be a way to run Flux with lora on consumer card like 4090. Thank you for your work @BenjaminBossan

I am able to run this on a 4090:
from diffusers import DiffusionPipeline
import torch

pipeline = DiffusionPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-dev", torch_dtype=torch.bfloat16
)
pipeline.load_lora_weights(
    "TheLastBen/Jon_Snow_Flux_LoRA", weight_name="jon_snow.safetensors"
)
pipeline.fuse_lora()
pipeline.unload_lora_weights()

pipeline.enable_model_cpu_offload()

prompt = "jon snow eating pizza with ketchup"

out = pipeline(prompt, num_inference_steps=20, guidance_scale=4.0)
out.images[0].save("output.png")

What am I missing?

Thanks for the write up. I will try it again later

Thank you @sayakpaul  I was running it using the FP8 version following diffusers doc, and it did not load lora successfully. Running a bfloat16 will cause my 4090 out of CUDA memory
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 90.00 MiB. GPU 0 has a total capacity of 23.65 GiB of which 38.06 MiB is free. Including non-PyTorch memory, this process has 23.60 GiB memory in use. Of the allocated memory 21.21 GiB is allocated by PyTorch, and 1.94 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

import torch
from diffusers import FluxTransformer2DModel, FluxPipeline
from transformers import T5EncoderModel, CLIPTextModel
from optimum.quanto import freeze, qfloat8, quantize

bfl_repo = "black-forest-labs/FLUX.1-dev"
dtype = torch.bfloat16

transformer = FluxTransformer2DModel.from_single_file("https://huggingface.co/Kijai/flux-fp8/blob/main/flux1-dev-fp8.safetensors", torch_dtype=dtype)
quantize(transformer, weights=qfloat8)
freeze(transformer)

text_encoder_2 = T5EncoderModel.from_pretrained(bfl_repo, subfolder="text_encoder_2", torch_dtype=dtype)
quantize(text_encoder_2, weights=qfloat8)
freeze(text_encoder_2)

pipe = FluxPipeline.from_pretrained(bfl_repo, transformer=None, text_encoder_2=None, torch_dtype=dtype)
pipe.transformer = transformer
pipe.text_encoder_2 = text_encoder_2

pipe.enable_model_cpu_offload()

prompt = "A cat holding a sign that says hello world"
image = pipe(
    prompt,
    guidance_scale=3.5,
    output_type="pil",
    num_inference_steps=20,
    generator=torch.Generator("cpu").manual_seed(0)
).images[0]

image.save("flux-fp8-dev.png")

Why are you quantizing when you can perfectly run it without quantization? And we haven't yet landed the support to load LoRAs in a quantized base model. So, I am not going to comment on that.

I have provided a working codebase. If you run the example with the latest versions of peft, accelerate, transformers, and diffusers -- they are expected to work. If not, please create a new issue on diffusers. If they do work, please notify this thread, as well.

Sure, will run the test again

Sure, will run the test again

Sorry you are right. Using latest hugging face libraries they do work on 4090. Sorry for the trouble @sayakpaul

No issues, glad things worked out. You might also be interested in https://github.com/huggingface/diffusers/pull/9213/ :)

not stale


Set the crate version centrally via the workspace

I think the devtools/set_version.sh also needs updating (or we just remove it and update the wiki page for publishing)

What happens to the internal versions that use = right now? See the dependencies in check/Cargo.toml.

Tbh the entire release process could be streamlined with cargo-release.
It automatically:

bumps all the versions across the workspace (it also keeps locked versions, i.e. =[version], as locked versions)
creates Git tags for each crate in the workspace
publishes the crates to crates.io

https://github.com/crate-ci/cargo-release

Haven't used cargo-release before, but after trying it out, it looks pretty good. Switching to it would be fine from my side.
If we want to use the tagging feature, we need to update the changelog before running cargo release (see https://github.com/CosmWasm/cosmwasm/wiki/Releasing). Also, we would want to specify something like tag-name = "v{{version}}" to keep the current tag naming.

I'm gonna have a look at integrating it. Gonna do that in a separate PR
Because having the entire release process in one, plus edge case avoidance, feels like a pretty worthwhile addition

@chipshort Mind giving this a last quick look so we can merge this?


update() with limit()

I got an unexpected behavior with update() combined with limit().
The following code:
ItemQuery::create()
->filterByStatus('A')
->filterByHome(2)
->orderByArrivalDate(Criteria::DESC)
->limit(1)
->update(array('Status' => 'B');

is expected to give the query
UPDATE `item` SET status = 'B'
WHERE item.status='A' AND item.home='2'
ORDER BY item.arrival_date DESC
LIMIT 1

which updates a SINGLE row (the last arrived).
I got instead an update on ALL items filtered by the query, like the limit(1) was ignored by update().
Is it a known Propel behavior?

@jwong-dayspring
Your link is not working anymore.
Is there a status if this gets fixed or a general way to work around?
This is our workaround.


Atom adds new line on save.

Hi.
When saving a file, atom adds a new line character at the end of a file.
Is it issue or a feature?
Ubuntu 14.04. Atom 0.134.0.

Like how this "feature" looks like a bug.

I think this should be considered a bug.
If a user opens an existing file that doesn't have a trailing newline, modifies some text in the middle of the file, and saves, I'd bet you the user won't expect (or want) a new line to be added to the end of the file.

Why should a file end with a newline?

@izuzak can you reopen this issue for consideration given the above feedback?

@vmaha please see https://github.com/atom/whitespace/issues/111#issuecomment-186388941, and for future reference whitespace-related issues should be reported to the whitespace package.

@50Wliu thanks for the link. sad to hear that, but you guys are doing a great job otherwise, so i respect your decision.

@vmaha @denysvitali If you're curious for the context behind why files should end in a newline, take a look at this Stack Overflow answer: http://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline/729795#729795

We're not objecting to the general principle.
We're objecting to enforcing the principle on already existing files, without any indication to to the user.
IMO a better solution would be to enforce this rule for new files only. Or, if you want to enforce it for existing files, then indicate that you've cleaned the file, and provide an affordance for the user to [undo], and [disable rule] whenever this is done.

@mnquintana Seems a good reason, thanks!

It's back now. But without whispace package enabled


color issue

VSCode Version: 1.42.0-insider (user setup)
OS Version: 19546.rs_prerelease.200110-1443

Steps to Reproduce:

install it
start it

Does this issue occur when all extensions are disabled?: Yes
as you should see vs code is much "darker" as it should be
this started to happen with one of the latest insider releases
unfortunately i cant show it with Windows "Screen snip" because the colors are than ok so i needed to use a cam

and again issues, do you see the difference between 1.42 and 1.43 ?
what are you doing that i always have this problems @bpasero @deepak1556 ?

@cyberh0me can you try the steps outlined here to see if that helps: https://github.com/microsoft/vscode/issues/88491#issuecomment-585273752

@bpasero 1.) your last link https://az764295.vo.msecnd.net/insider/a1f569c66f67287c525ee50b5f46ced8a50b4551/VSCode-darwin-insider.zip does not include an exe file we could execute
so i used https://az764295.vo.msecnd.net/insider/7428f161b0def9c82f5582b977f837fb0ad63453/VSCode-win32-x64-1.42.0-insider.zip and the colors are better

@cyberh0me thanks for trying this out and finding the correct build. To clarify: once you set srgb as forced color profile you see the issue fixed on that build right?
Other versions will not support this flag yet.

This is probably a duplicate of #88491

Just to reconfirm this, @cyberh0me are you using a HDR display ?

"@cyberh0me thanks for trying this out and finding the correct build. To clarify: once you set srgb as forced color profile you see the issue fixed on that build right?"
@bpasero if you mean with that bild https://az764295.vo.msecnd.net/insider/7428f161b0def9c82f5582b977f837fb0ad63453/VSCode-win32-x64-1.42.0-insider.zip yes
@deepak1556 yes i am using a HDR display

Thanks for confirming and testing so far, this is an upstream issue with chromium. I am merging this to #88491


[Docbug][Fix Typo sample]

Acrolinx Scorecards
We do not currently enforce a minimum score for content merged to the default branch. This will change in the future.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/get-started/get-started-dotnet-app-studio.md
89
18
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit 5abfc69:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/get-started/get-started-dotnet-app-studio.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


COPS-5580: Fix Jersey exceptions filling scheduler stderr logs.

Fix ClassNotFoundException errors in scheduler stderr logs due to removal of JAXB from JDK-9 and later runtimes.
JIRA: COPS-5580

Will merge this soon, trying to sort out build tooling issues here.


Provide ability to filter out invalid parquets or parquet metadata from glob path

When there are malformed parquet files (such as invalid footer, invalid metadata) due to upstream writes which were interrupted or disrupted, the downstream jobs are all unable to run and any such problem is completely blocking.
For cases where the success of the remainder of the jobs are more important than the completeness of the data, this poses a big problem as the filtering out or deletion of malformed files plus consequent retriggering of the tasks can be tedious and manual.
It would be good if there can be the choice to either (1) end the job on such errors (status quo), or to (2) write out invalid paths into a separate small log file and continue with the job.

This is really tricky... We need to balance user experience with not "failing silently"
What if we provided a way to pass in a list of filepaths, and run some kind of Daft expression to validate if each of those files were valid Parquet? Users can then run these jobs as a mechanism to figure out which Parquet files are invalid in a given glob.
e.g.
df = df.from_glob_paths("s3://...")
df = df.where(~df["path"].is_parquet_file())
df.collect()

Then a user could potentially do cleanups by themselves if they have a job that is failing because some Parquet files are invalid/corrupted.

Yes I think that would be a great way to go about it! I wouldn't mind having to call an additional function.
I actually tend to use the /** directly in read_parquet though so I guess this needs to be able to do the filter before the read fails?
Or maybe a daft.validate_parquet() to keep it completely separate?
Also, failing silently wouldn't be the norm if we had to activate the functionality with another function or new parameter. It would be controlled failing with nice fallbacks! I definitely wouldn't want it to be the default behaviour for people who aren't looking for it.

Resolved on Slack


nvidia: expose nvidia_x11_legacy390

Motivation for this change
Reference issue #49679
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

can somebody please speed up the process here? I would like to use this driver.

See https://github.com/NixOS/nixpkgs/issues/51768#issuecomment-446859746 if you don't use a local nixpkgs.

thanks a lot. this worked.

@nek0 , what did you do to make it work?
I put this in my configuration.nix and it didn't do anything:
  nixpkgs.config = {
    allowUnfree = true;

    packageOverrides = super: let self = super.pkgs; in
    {
        linuxPackages = super.linuxPackages_latest.extend (self: super: {
          nvidiaPackages = super.nvidiaPackages // {
            stable = super.nvidiaPackages.stable_390;
          };
        });
    };
  };

@sib-null You also need the following line in your configuration.
services.xserver.videoDrivers = [ "nvidia" ];

@GrahamcOfBorg eval


Test restart on crash

Pull Request Checklist

[x] implement the feature
[x] write the documentation
[x] extend the test coverage
[x] update the specification
[x] modify the json schema
[x] mention the version
[x] include a release note

Thanks for all adjustments, now looks good!

Yeah, but there's a bug breaking some tests. It's about overwriting output.txt, I thought I resolved it, but apparently I did not. So, working on that...

Yeah, just noticed that. Thanks for looking!


alpha_cell and beta_cell are inconsistent and have no cell ontology label

There is an entry named beta_cell  (IHECRE00001868.2) does not have a cell ontology name, can this be renamed to "type B pancreatic cell" for which a cell ontology numbest exists (CL:0000169)?
There is an entry named alpha_cell (IHECRE00003717.1)  does not have a cell ontology name, can this be renamed to "pancreatic A cell" for which a cell ontology numbest exists (CL:0000171)?

added the proposed ontology and renamed the cell_type


Class property types are ignored when passed as an argument object vs. assigned directly

TypeScript Version:  3.4.0-dev.201xxxxx

Search Terms:
Class, constructor, ignore.
Code
You can see this code from the Scrimba link below, under the "Playground Link".
This example will type check, as expected, no issues.
class Person {
    firstName: string;
    middleName: string;
    lastName: string;

    constructor(data?: any) {
        this.firstName = data.firstName || 'Dylan';
        this.lastName = data.lastName || 'Israel';
        this.middleName = data.middleName;
    }
}

example1.firstName = 'Dylan';
example1.middleName = 10;  // this will flag in the linter and fail type check as expected
example1.lastName = 'Israel';

With the same code, but passing the object for the new Person, it will not type check:
// ... same code as above

// nothing here will be flagged at all. It also compiles just fine, so it's not just the linter.
const testPerson = new Person({firstName: 10, lastName: false, middleName: 'actually string'})

// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.

Expected behavior:
Class property types would be respected when assigning their values whether passed as an object or assigned individually.
I'm not a TS expert by any means, but this behavior seems contradictory.
Actual behavior:
Class property types are not respected when passed as an argument to a parameter?: any, although they are already assigned on the class.
Playground Link:
I discovered this while taking a intro course on TS here:  https://scrimba.com/p/pKwrCg/cbyMBtW
It failed in the linter there, so I reproduced the issue inside VSCode. Both the linter and compiler fail to catch this.
Related Issues:

I should also note that assigning unique parameters for each respective property, then passing them to the new Person as an argument will respect the typing, even though the same properties are being referenced.
Exa.
class Person {
    firstName: string;
    middleName: string;
    lastName: string;

    constructor(first: string, last: string, middle: string) {
        this.firstName = first;
        this.lastName = last;
        this.middleName = middle;
    }
}

const newPerson = new Person('Bill', 10, false); /* the last two arguments get flagged by the linter and throw an error during compile, as expected */

If you explicitly type a parameter as any you can assign anything to it. This is the expected behavior.
If you want to pass in an object with the same properties as the class but all optional, you can use the Partial mapped type:
class Person {
    firstName: string;
    middleName: string;
    lastName: string;

    constructor(data: Partial<Person> = {}) {
        this.firstName = data.firstName || 'Dylan';
        this.lastName = data.lastName || 'Israel';
        this.middleName = data.middleName || "";
    }
}
new Person({firstName: "", lastName: false, middleName: 10}) //err

If you explicitly type a parameter as any you can assign anything to it. This is the expected behavior.
If you want to pass in an object with the same properties as the class but all optional, you can use the Partial mapped type:
class Person {
    firstName: string;
    middleName: string;
    lastName: string;

    constructor(data: Partial<Person> = {}) {
        this.firstName = data.firstName || 'Dylan';
        this.lastName = data.lastName || 'Israel';
        this.middleName = data.middleName || "";
    }
}
new Person({firstName: "", lastName: false, middleName: 10}) //err

I appreciate the explanation, and I kind of get it, but then why do both examples I gave reference the original properties when you hover over?
It seems like if I understand correctly the constructor is overriding the class properties when using any; is that correct?

It looks like this is a question rather than a bug report. This issue tracker is for tracking bugs and active work on TypeScript itself, rather than a general forum for programmers using TypeScript to get help or ask questions.
You can ask questions on sites like Stack Overflow. We are not able to provide one-on-one support on the issue tracker. Please read the issue template carefully - it has important information on what kinds of reports can be acted on here, as well as links to useful TypeScript resources. Thanks!

@RyanCavanaugh
I read it just fine - maybe you didn’t read my original post.
I originally thought it was a bug.
Sorry to assume asking a question for understanding was reasonable.
I’ll be sure to stick to other non-MS open-source communities where developers treat each other like humans instead of inconveniences.

@methodbox if you imagine a world where everyone learning TypeScript files "bugs" when they don't understand why something happens, it's one where this issue tracker is completely disregarded by anyone working on TypeScript itself due to the overwhelmingly huge amount of noise that would generate.
We're only able to read these reports at all because the vast majority of people learning TS don't use the issue tracker as a forum for asking introductory questions. I only ask that you do the same. Please consider the context of a popular programming language that is six years old and has 30,000 extant reports - is the thing being described truly novel and likely to have been overlooked for all that time?


Why do I want input state instead of the "traditional model"

From your docs:

The structure of an effective Transformer LLM call is:

System Prompt
Preamble
Few shot-examples
Question

With statecraft and your SSM, we instead simply have:

Inputted state (with problem context, initial instructions, textbooks, and few-shot examples all baked in)
Short question

So the goal of this new framing is to take:

System Prompt
Preamble
Few shot-examples

And mush them all into a "state". So now instead of having to pass all the prompt / few-shot examples around, I can just pass the state.
Pros: cheaper/faster in terms of compute, you can hide proprietary prompts and examples, you can use statespace-specific "warmup" techniques that might not be possible with transformers, e.g. closed-loop warmup
Cons: you can't look under the hood of the prompts that created the state
Something Docker did well was the "docker file" vs "docker image" thing. The dockerimage is the binary recording of a machine state, the dockerfile are the instructions that creates the image. So you can understand an image by looking at its dockerfile, and you can hack a dockerfile to get a new image.
If I understand correctly, Statecraft has an analog to "docker image", but it is missing the analogous "dockerfile". Do I understand the system correctly?

Hey Ned, great question!

So the goal of this new framing is to take:
System Prompt
Preamble
Few shot-examples
And mush them all into a "state". So now instead of having to pass all the prompt / few-shot examples around, I can just pass the state.
Pros: cheaper/faster in terms of compute, you can hide proprietary prompts and examples, you can use statespace-specific "warmup" techniques that might not be possible with transformers, e.g. closed-loop warmup

Yes that's exactly correct, I love the way you frame it here! 🙌

If I understand correctly, Statecraft has an analog to "docker image", but it is missing the analogous "dockerfile". Do I understand the system correctly?

I really like the Docker analogy perhaps I should lean into this more!
You're correct that the state acts as the Docker Image in this case. In terms of the Dockerfile, each state comes with a metadata json file which contains the name of the model that was used to create it (and hence the configuration) as well as the prompt that was used to create the state (or a url_reference to the text that was used for the prompt, if the prompt is long).
This acts as the Dockerfile analogue which can be used to create the image and the metadata also contains a plain-text description for any other notes on the state creation or intended usage.
Perhaps I should align the messaging with Docker and call this object the Statefile or similar, that's an interesting point 💡
Yeah you have a great understanding, thanks again for your question!


Deberta sentiment analyzer

PR checklist:

[x] Tested by creator on localhost:8000/docs
[x] Tested by creator on refinery
[ ] Tested by reviewer on localhost:8000/docs
[ ] Tested by reviewer on refinery
[x] (If added) common code tested in notebook/ script
[ ] Conforms with the agreed upon code pattern

Implements #302

tested common code without success:

running it again didn't yield the result anymore.
Maybe the request had some issues :D

Implements #302


Typing

Fixes #6

Coverage remained the same at 95.765% when pulling f05d8a35a1c3135e91527f71927a3e24d9b805df on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling f05d8a35a1c3135e91527f71927a3e24d9b805df on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling f05d8a35a1c3135e91527f71927a3e24d9b805df on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling f05d8a35a1c3135e91527f71927a3e24d9b805df on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling a6881d988c2b974940972a9876e44c49e60e5b0e on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling a6881d988c2b974940972a9876e44c49e60e5b0e on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 42ea467e4be4782a18fb12ef2167afb42bdd42a8 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 42ea467e4be4782a18fb12ef2167afb42bdd42a8 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 42ea467e4be4782a18fb12ef2167afb42bdd42a8 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 42ea467e4be4782a18fb12ef2167afb42bdd42a8 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling e1b2cae8394f86190a227dcb0a6eb51270d2eb7c on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 40314a57b819539f3164c9b4fbe8cbff9beeab86 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 8c815a69b6e8445c77318e0e48a4ae58f51befe2 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 8c815a69b6e8445c77318e0e48a4ae58f51befe2 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 8c815a69b6e8445c77318e0e48a4ae58f51befe2 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.765% when pulling 8c815a69b6e8445c77318e0e48a4ae58f51befe2 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.513% when pulling e1ae21287e1e2224308cf62eac7324a8c59185c7 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.513% when pulling e1ae21287e1e2224308cf62eac7324a8c59185c7 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.513% when pulling e1ae21287e1e2224308cf62eac7324a8c59185c7 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.513% when pulling 42efb408a40c073c4f954e96e62d5b87188cc8b6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 586bbb2eaab1c427b778b6f214ecf02a7c43c9b3 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 586bbb2eaab1c427b778b6f214ecf02a7c43c9b3 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 586bbb2eaab1c427b778b6f214ecf02a7c43c9b3 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 586bbb2eaab1c427b778b6f214ecf02a7c43c9b3 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 586bbb2eaab1c427b778b6f214ecf02a7c43c9b3 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 89d5c464e371701d26bc36db4bbddc0c372e475f on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 89d5c464e371701d26bc36db4bbddc0c372e475f on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 89d5c464e371701d26bc36db4bbddc0c372e475f on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 89d5c464e371701d26bc36db4bbddc0c372e475f on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 89d5c464e371701d26bc36db4bbddc0c372e475f on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 9578ec51074fe8840528e6fa7214f9fcb567c7fc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 9578ec51074fe8840528e6fa7214f9fcb567c7fc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 9578ec51074fe8840528e6fa7214f9fcb567c7fc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.673% when pulling 9578ec51074fe8840528e6fa7214f9fcb567c7fc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.534% when pulling e56f88b7ccc2e227d0190632496ed456c2595b2d on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.52% when pulling 97dcd93c145f7b87e1974192f18317fb71e00dc1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.52% when pulling 97dcd93c145f7b87e1974192f18317fb71e00dc1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 19.68% when pulling d1f49d12dc5a364129a27cfad2976c749ce49847 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.813% when pulling fccffc6d13e2a41d1972433ed5e4c0e951fa4080 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.248% when pulling a5d904b849fd22d80a71f883768bb62dc45f5bfa on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.242% when pulling b505e797be7741d769333275d1f3032b9f7d725d on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.242% when pulling b505e797be7741d769333275d1f3032b9f7d725d on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.242% when pulling b505e797be7741d769333275d1f3032b9f7d725d on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.254% when pulling be3bb8afbbfea0febac65628aa40273e6aa7388a on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.254% when pulling be3bb8afbbfea0febac65628aa40273e6aa7388a on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.254% when pulling be3bb8afbbfea0febac65628aa40273e6aa7388a on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.254% when pulling be3bb8afbbfea0febac65628aa40273e6aa7388a on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.254% when pulling be3bb8afbbfea0febac65628aa40273e6aa7388a on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.284% when pulling 961ed83731d3342be169b69104e5f142455d71be on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 96.284% when pulling 961ed83731d3342be169b69104e5f142455d71be on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.693% when pulling b2b861880f717b34edbeaa926deafe7254451533 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.693% when pulling b2b861880f717b34edbeaa926deafe7254451533 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.7% when pulling 46e1be6d3017ab199ae77ad3f8edfa3e400ead1b on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.7% when pulling 46e1be6d3017ab199ae77ad3f8edfa3e400ead1b on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.7% when pulling 46e1be6d3017ab199ae77ad3f8edfa3e400ead1b on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.7% when pulling 46e1be6d3017ab199ae77ad3f8edfa3e400ead1b on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 94.7% when pulling 46e1be6d3017ab199ae77ad3f8edfa3e400ead1b on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.125% when pulling f21677d986201c3bb701be0e563a636e7ee5f245 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling 536465f45060512b8960629ed0e24e0ae30a735d on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling d716d0ef828ed1bcd9099eb6b9862849ab5de1a1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling d716d0ef828ed1bcd9099eb6b9862849ab5de1a1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling d716d0ef828ed1bcd9099eb6b9862849ab5de1a1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling d716d0ef828ed1bcd9099eb6b9862849ab5de1a1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling d716d0ef828ed1bcd9099eb6b9862849ab5de1a1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.166% when pulling d716d0ef828ed1bcd9099eb6b9862849ab5de1a1 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.387% when pulling 102ff0fb0a96a5284e7fd79bacf2bf1b161b2d7f on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.399% when pulling 6ee5aee5000d7ce0db492a0a962b42f56b6cc46c on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.399% when pulling f3d73a8b1b0f24adf2f5f8238a5f3777acf74cc0 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.399% when pulling f3d73a8b1b0f24adf2f5f8238a5f3777acf74cc0 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.399% when pulling f3d73a8b1b0f24adf2f5f8238a5f3777acf74cc0 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.399% when pulling f3d73a8b1b0f24adf2f5f8238a5f3777acf74cc0 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.399% when pulling f3d73a8b1b0f24adf2f5f8238a5f3777acf74cc0 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.535% when pulling b9568e54250d0a443599e89205c88a9c057a0152 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.535% when pulling b9568e54250d0a443599e89205c88a9c057a0152 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on containenv:development.

Coverage remained the same at 95.535% when pulling 12182859bcc8f20eee245a489c892d5abf69fb74 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling 1c0229a4487ce33c6c425203b11ed43f80386af2 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling 9b7aee1225d920feb9e69ca6faebe2f0efa83fc0 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling dca4789acc5bd9cb781991465d62f01cf60a91d6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling dca4789acc5bd9cb781991465d62f01cf60a91d6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling dca4789acc5bd9cb781991465d62f01cf60a91d6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling dca4789acc5bd9cb781991465d62f01cf60a91d6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling dca4789acc5bd9cb781991465d62f01cf60a91d6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling dca4789acc5bd9cb781991465d62f01cf60a91d6 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling f71ff61f8cf63189bddb62139092f75efda59ebc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling f71ff61f8cf63189bddb62139092f75efda59ebc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling f71ff61f8cf63189bddb62139092f75efda59ebc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.535% when pulling f71ff61f8cf63189bddb62139092f75efda59ebc on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.04% when pulling 37372019b3c5ad08d5eebeb0f4755f6c7c8a1548 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.04% when pulling 37372019b3c5ad08d5eebeb0f4755f6c7c8a1548 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.04% when pulling 37372019b3c5ad08d5eebeb0f4755f6c7c8a1548 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling b57cc788555851029ce784cd875c7160560eb410 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling b57cc788555851029ce784cd875c7160560eb410 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling b57cc788555851029ce784cd875c7160560eb410 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling b57cc788555851029ce784cd875c7160560eb410 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling b57cc788555851029ce784cd875c7160560eb410 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling 8544502b785fbe241a5e7243a53e8f383569ad6e on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling 343d1d9c44439b62571bc81f25afc4a7a4d00521 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.

Coverage remained the same at 95.187% when pulling 343d1d9c44439b62571bc81f25afc4a7a4d00521 on dangle:typing into 3fc93b4906d89ce2aded6a90f220dfb29dbba252 on contains-io:development.


Removing parameters from id

Coverage remained the same at 75.831% when pulling a28cd0a20ebcef1849135eda46cd51b453e32af7 on hotfix_3.2.1 into fb040c9b33567efd2e459fc0b6acea0fb67e3c71 on master.


Error when implements multiple context files

Hi there, I am getting this issue when trying to use multiple context files. I have checked so many times the class names, paths, .. everything - but I don't understand how this issue is still coming up.
  [Behat\Behat\Context\Exception\ContextNotFoundException] 'src/suites/0_global_setup/GlobalSetupContext' context class not foun   d and can not be used.
behat.yml
autoload:
    '': src/context_base

  suites:

    global_setup:
    # Description: This feature will test Login functionality
      paths:
        - src/suites/0_global_setup
      contexts:
        - src/suites/0_global_setup/GlobalSetupContext

    account_setup:
    # Description: This feature will test Login functionality
      paths:
        - src/suites/1_account_setup
      contexts:
        - src/suites/1_account_setup/AccountSetupContext

Project Dir

Thanks for any help!

I basically want to group the relevant feature files with the context files that define the scenario steps

Did you have namespaces?  I need each context file to extend the AbstractWebDriver class - but this seems impossible when the context files are in different directories.

@spolischook I don't understand how using namespaces will do anything. I need each context file to extend the AbstractWebDriver class - but this seems impossible when the context files are in different directories.

I'm using namespaces and it's works perfect, if you have composer.json you can configure namespaces https://getcomposer.org/doc/04-schema.md#psr-4


whereKey used 'id' instead of 'key' in select statement

Laravel Version: 8.25.0
PHP Version: 7.4.14
Database Driver & Version: mysqlnd 7.4.13

Description:
Using the whereKey method on a model uses 'id' instead of 'key' in select
Steps To Reproduce:
Create a model with
php artisan make:model KeyValue -m

modify the migration
Schema::create('key_values', function (Blueprint $table) {
            $table->id();
            $table->string('key');
            $table->string('value')->nullable();
            $table->timestamps();
        });

Migrate
php artisan migrate

Try to get a record
$record = KeyValue::whereKey('test')->first();

will produce this
select * from `key_values` where `key_values`.`id` = 'test' limit 1

whereKey is a dedicated method on the Eloquent builder to select by a primary key.

whereKey is reserved method. You can use where('key', '=', 'test') instead.


Support live form updates

As mentioned in #15, I'll be looking to use ExAdmin with my existing live form updates.

How "live" should be form updates? You can have:

forms being update when another client submits (easy, just send the new html with populated from the server, and set innerHTML on the JS side- effectively a page reload) or

Forma updates keystroke by keystroke, google docs style. Cool but requires instrumenting all text fields with JS for this to work. Cosemirror (plaintext) and quilljs (rich text) already provide enough instrumentation to make it easy to implement realtime collaboration.

Which one of this options are you suggesting? Please not that the naïve solution to option 1 breaks option 2

When I say live updates, I mean that fields changes will be saved on a field by field basis. Not that the form will be updated if 2 browsers are updating the same form at the same time.

With a save button for every field? Or each time the input changes?

A live updated form will provide the following:

When you start editing a text input, a save and cancel button will be shown and CR will save the field.
radio/checkboxs will save when clicked
select will save when option is changes
etc.

Of course, this will be an optional feature, when defining the form. It will be opt in.

Making it opt in is smart. It avoids breaking changeser validation rules that depend on multiple fields.


[stdlib] Optional.map, .flatMap: Remove @_disfavoredOverload

Explanation: Reverts the addition of @_disfavoredOverload on the retroactive generalizations of Optional.map and Optional.flatMap. The attribute was added speculatively to defend against potential source breaks while rdar://125016028 is being investigated; however, it leads to "expression too complex" issues that are non-hypothetical source breaks.

Scope: Impacts usages and external reimplementations of Optional.map and Optional.flatMap.

Risk: Low. This resolves regressions that have come to light, although it does potentially introduce ambiguity issues in code that have local definitions for Optional.map/.flatMap that used to shadow the originals.

Testing: Source compat suite.

Reviewer: @slavapestov

Main branch PR: https://github.com/apple/swift/pull/73296

Issue:  rdar://127015095&127015541

(Leaving it as a draft while testing is in progress.)

@swift-ci test

@swift-ci test source compatibility


Feature Request: trigger onChange when clicking the same value

It would be nice if the component called the onChange method even when clicking the same value again. I want to use it to reset the value.
This used to work in earlier versions: https://github.com/dreyescat/react-rating/issues/35 but it seems that something changed since then

It's a fair request. Let me think about it. If I cannot figure out an easy way to accomplish this functionality with the current API I will bring onClick back.

Thank you for a quick reaction. If you are open for suggestion, maybe you could introduce a boolean prop for example "allowSameValueSelect" and handle it inside condition of handleClick method of RatingAPI layer. That way you retain backwards compatibility for others who prefer current implementation.

I have been thinking about your suggestion... but I feel unconfortable with habing a callback onChange that behaves differently depending on a flag. I even see it confusing because of the name. It conveys changing but if you have this flag enabled then it is called even if no change is done.
Anyway. I have reintroduced the onClick callback. With this new property you should be able to accomplish what you need. Same way as before #35.
Released in 1.4.0

Cool, makes sense. This will work prefectly. I'll implement it when it gets published on npmjs.
Cheers

@Vodzo Sorry! I forgot to publish it. Done!


Legends missing and in wrong place

Taken from https://oscovida.github.io/html/Germany.html :

(i) the legend for the doubling time (lowest plot) is missing
(ii) the legend for the daily new deaths is wrong (it reads doubling time). Seems to apply to all countries.

Already fixed in #134


is this Plugins supports Androidx?

No or not yet try Flutter Exoplayer

Note: Flutter Exoplayer does not play m3u8 files.

I have created an different branch for androidx from the one of the pull request. we can test together and if no issues are found we can merge it to master branch.
Special thanks and cheers for huergomartin for pull request.


Add support for packages hosted in arbitrary repositories

Description
It would be amazing if Typst supported git packages in addition to local and preview packages. This would allow users to download unofficial packages easily without the hassle of needing to use install scripts or the like.
The syntax could look something like this:
#import "@git/battlech1cken/notebookinator:1.0.0"

This would then automatically download the package from that repository and make sure its in the correct directory, automatically excluding the files specified in the typst.toml file.
There are two major problems with this feature that I haven't really thought about yet.

git packages obviously can't be reviewed by Typst team, leading to possible security problems.
I'm not sure how the web app will handle these types of packages, because I know that network requests there should be kept to a minimum.

Use Case
Currently I maintain a library called The Notebookinator which is rather large. For this reason I doubt it will be accepted as an official package, and I've had to resort to having users install it as a local package. I've included a script which allows for automatic installation, similar to the CeTZ package.
This is less than ideal for my users who now have to go through several steps to download my library, whereas official packages are incredibly easy to acquire.
This problem only gets worse if I need to modify or use unreleased versions of other packages I depend on, users or fellow developers will need to download all of those packages locally as well.

iirc it is not supported by design.(correct me if i'm wrong)

It's planned, see this message in discord's #forge channel

Git imports would need to be handled with a lot of care to ensure Typst remains safe to run on untrusted input. I've written a longer comment explaining things here: https://github.com/typst/typst/pull/5579#issuecomment-2545034781


MAIN B-19458 add linehaul service item order to service item list

INTEGRATION PR
Agility ticket
Summary
Need to ensure that when a linehaul item is auto rejected & a new one created, we keep it in the same position of the list. Followed what is being done for SIT items and placing the linehaul service items (DLH & DSH) above those in the list. Lemon squeezy.
How to test

Create a LOCAL move as a customer, set up your shipments using different ZIPs, and send it
Login as the service counselor and approve all of that bidness
Login as the TOO and approve the shipment, head over to the MTO page and you'll see a linehaul service item at the top
Login as the prime and request the dest address be changed to a ZIP further than 50 miles
Login as the TOO and approve the change as TOO
Navigate to the MTO page and you should see the linehaul item rejected at the bottom and the new one essentially "replaces" it at the top of the list

Screenshots

Warnings

:warning:
This PR does not include changes to unit tests, even though it affects app code.

  Generated by :no_entry_sign: dangerJS against 3a373ab914d43cb1bc1c6e34c8bc868fd5c71cb5


Error message contains version. Task crashes trigger backup save.

Edits instantiation of mapstudionew to a singleton instance inside the class.
Version string is made public.

No longer needed due to #172 , #176 , and #179


update nuget package, update .net target framework and fix bug to support "10.45 PM"

update target framework to 4.6.1
update nuget packge
add some new test cases
fix bug to support "10.45 PM"

I found that this is the wrong way to fix the "10.45 PM". just delete or ignore this pull request.


Support for updates of 3sdk / containers

Make it possible for users of 3sdk to know when there are updates available and allow them to upgrade by means of the 3sdk:

[x] When issuing the --version or version command we will inform the user if there is a new version available.

[x] An extra command update will be added to do an update (this will update all repos of all known containers) and update the 3sdk binary itself

[x] In the admin panel a check will be added to inform the user about a new update

verified.


In lib.d.ts hasn't signature for formData types (Fetch API)

TypeScript Version:  2.2.1
After adding typings for Fetch API in core typescript I got an error Property 'formData' does not exist on type 'Response'. Because in lib.dom.d.ts I see:
interface Body {
    readonly bodyUsed: boolean;
    arrayBuffer(): Promise<ArrayBuffer>;
    blob(): Promise<Blob>;
    json(): Promise<any>;
    text(): Promise<string>;
}

But for typings whatwg-fetch:
interface Body {
    readonly bodyUsed: boolean;
    arrayBuffer(): Promise<ArrayBuffer>;
    blob(): Promise<Blob>;
    formData(): Promise<FormData>;
    json(): Promise<any>;
    json<T>(): Promise<T>;
    text(): Promise<string>;
}

And this types in Fetch API spec https://fetch.spec.whatwg.org/#body
I sent a PR to the repository TSJS-lib-generator

PRs welcomed. You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes.

My PR was merged.

We still need to port the changes from https://github.com/Microsoft/TSJS-lib-generator. keeping it open until a new drop is ported.


Copy-editing overview.md

Extensive grammar revisions for zeppelin/docs/usage/interpreter/overview.md
What is this PR for?
The documentation at zeppelin/docs/usage/interpreter/overview.md contained numerous instances of bad grammar. This PR improves it.
What type of PR is it?
Documentation

great, thx!

LGTM
merging if no more comment

this was merged? is github not syncing?


Which command line is targeting to download module/map/data?

When I ran the script ./docker/script/dev_start.sh, the module/map/data could be downloaded with the permission <username>.
However, when I ran the script with CI script, the data was downloaded with the permission root.
I have checked the scripts in ./docker/scripts/dev_start.sh and ./docker/scripts/restart_map_volume.sh, unfortunately, I haven't targeted the specific commands for the download action.
Is there anyone could provide some hints? Thanks.
CI scripts:
  script:
    - echo $(whoami)
    - ./docker/scripts/dev_start.sh

CI repo downloaded (modules/map/):
drwxrwxr-x 20 gitlab-runner gitlab-runner 4096 Apr 19 18:01 ..
-rw-rw-r--  1 gitlab-runner gitlab-runner  136 Apr 19 18:01 BUILD
drwxr-xr-x  4 root          root          4096 Apr 19 18:02 data
drwxrwxr-x  4 gitlab-runner gitlab-runner 4096 Apr 19 18:01 hdmap
drwxrwxr-x  3 gitlab-runner gitlab-runner 4096 Apr 19 18:01 pnc_map
drwxrwxr-x  2 gitlab-runner gitlab-runner 4096 Apr 19 18:01 proto
drwxrwxr-x  6 gitlab-runner gitlab-runner 4096 Apr 19 18:01 relative_map
drwxrwxr-x  3 gitlab-runner gitlab-runner 4096 Apr 19 18:01 testdata
drwxrwxr-x  2 gitlab-runner gitlab-runner 4096 Apr 19 18:01 tools

I removed all my images and containers of apollo, re-ran ./docker/scripts/dev_start.sh, unfortunately, module/map/data was downloaded as root whatever in my local machine or CI host.
I am wondering if there is any updates in the Dockerfile, bash scripts or python scripts?

Hi @xiaoxq,
I found the problem might be caused by unable to find user : no matching entries in passwd file when it ran restart_map_volume.sh:
  MAP_VOLUME_IMAGE=${DOCKER_REPO}:map_volume-${map_name}-${map_version}
  docker pull ${MAP_VOLUME_IMAGE}
  docker run -it -d --rm --name ${MAP_VOLUME} ${MAP_VOLUME_IMAGE}
  MAP_VOLUME_CONF="${MAP_VOLUME_CONF} --volumes-from ${MAP_VOLUME}"

It ran the docker container with the permission root.
When it was mapped by --volumes-from, then the map data is mapped as root.
Is there any solution to solve it? Thanks.

I tested Apollo r2.5.0 on another machine, the same issue was flagged, but it worked on last Wednesday (Apollo r2.5.0) and the previous weeks (Apollo r2.0.0).
I believe it might be something changed on the map-volumes (sunnyvale-xxx) images when configuring and exporting these images recently?