Section Number appearing in Equation Number

Hi Davide
your example code above works in Mathjax 3.1.4 but not as expeted in v. 3.2.0.
When I use <script<EMAIL_ADDRESS>it is fine, but using <script<EMAIL_ADDRESS>it writes in the console that "MathJax: Invalid option "tagFormat" (no default value)." So it resets the numbering at each section, but the section number disappear from equation number.
Originally posted by @parhizkari in https://github.com/mathjax/MathJax/issues/2427#issuecomment-1120108244

I have answered your original comment.


QtWebEngineProcces.exe has encoutered

To Reproduce
Steps to reproduce the behavior:

Install fusion 360 for linux using yad
Just start, and issue

Expected behavior
Should work Normally
Screenshots

Desktop (please complete the following information):

Cant verify since UI is unrepsonsive, latest
GTX 1650ti - nvidia 560.35.03-5
Arch Linux
Kde Plasma

same here, just did a fresh install today

Solved by using the patched DLL as stated in https://github.com/cryinkfly/Autodesk-Fusion-360-for-Linux/issues/473

#473 patched DLL worked


Find() ignoring Soft Delete

There seems to be a bit of an error with Soft Delete feature.  And I don't think this was always the case, not sure how recent it started occurring.
A simple .Find (even passing the ORDER function) will ignore any mention of soft delete.
A more complex Find (using count) will take soft delete into account, but not for the initial count... that will still count all records.
I never really noticed this before because of 2 reasons.
a) Most of my Find requests are pretty complex with preload, count, limit, offset, etc.
b) I have not noticed the count discrepancies because I've only been working with test data.
Can anyone else confirm this?
type Company struct {
ID int
Name string
CreatedAt time.Time
UpdatedAt time.Time
DeletedAt time.Time
}
c := Company{}
if query := db.Model(c).Order("id asc").Find(&c); query.Error != nil {
panic(query.Error)
}
//[2015-08-13 17:20:59]  [30.75ms]  SELECT  * FROM "companies"   ORDER BY id asc
c := Company{}
var count int
if query := db.Model(c).Count(&count).Find(&c); query.Error != nil {
panic(query.Error)
}
//[2015-08-13 16:09:37]  [10.48ms]  SELECT  count(*) FROM "companies"
//[2015-08-13 16:09:37]  [0.98ms]  SELECT  * FROM "companies"  WHERE ("companies".deleted_at IS NULL OR "companies".deleted_at <= '0001-01-02')

seems works for me.
package main

import (
	"fmt"
	"time"

	_ "github.com/go-sql-driver/mysql"
	"github.com/jinzhu/gorm"
	_ "github.com/mattn/go-sqlite3"
)

type Company struct {
	ID        int
	Name      string
	CreatedAt time.Time
	UpdatedAt time.Time
	DeletedAt time.Time
}

func main() {
	dbuser, dbpwd := "gorm", "gorm"
	db, err := gorm.Open(
		"mysql",
		fmt.Sprintf("%s:%s@/gorm?parseTime=True&loc=Local", dbuser, dbpwd),
	)
	// db, err := gorm.Open("sqlite3", "/tmp/gorm.db")
	if err != nil {
		panic(err)
	}
	db.LogMode(true)

	db.AutoMigrate(&Company{})

	c := Company{}
	db.Model(c).Order("id asc").Find(&c)
}

FYI, you could try gorm.Model for id, created_at, deleted_at...

+1 for me. The following:
dbGorm.Debug().Model(&MonitoringInstruction{}).Where(&MonitoringInstruction{AccountId: p.Id}).Find(&monitoringInstructions)
returns
SELECT  * FROM "monitoring_instructions"  WHERE ("account_id" = 'a444cf21-f6e5-43f6-a6ca-8f35826d8cf3')
MonitoringInstructions do feature a DeletedAt field, and it is present in more complex queries.
No mention of soft delete in there. I am using sqlite3 as the driver, and using UUIDs (as shown).

I am having the same issue with Where:
	if err := d.roconn.Where(filter).Find(res).Error; err != nil {...


URLs with empty [] displaying URL now

We upgraded to 3.2 (yay!) and found a possible regression.
Previously, if you had a message like this:
This is a sample message with a sample image [](https://media.tenor.com/images/933c3ba5f9faa828fb55bab4d47e6518/tenor.gif)
It would display like:
This is a sample message with a sample image

Now it displays like:
This is a sample message with a sample image https://media.tenor.com/images/933c3ba5f9faa828fb55bab4d47e6518/tenor.gif

With the url included.
Messages which have no additional text such as:
[](https://media.tenor.com/images/933c3ba5f9faa828fb55bab4d47e6518/tenor.gif)
Still display as:

with no additional url string.
Workaround:
This is a sample message with a sample image [ ](https://media.tenor.com/images/933c3ba5f9faa828fb55bab4d47e6518/tenor.gif)
Displays:
This is a sample message with a sample image

Is this behavior intentional?

I'm not sure -- I think long-term what we should be doing is using the standard markdown syntax for what you're trying to do (![alt](url)), and it's possible that the right fix is just for us to provide that syntax.
@aero31aero @andersk thoughts?

As always, my position is that any deviation from the CommonMark spec is a bug. A link [](https://…) with empty link text should be valid according to the spec, so this is a bug. We have lots of CommonMark compliance bugs, including the misuse of link syntax for image display. But if the empty link text bug is also a regression, we should prioritize fixing it.

I'm definitely onboard with moving to the more correct ![]() syntax, although I believe [](https://…) should like be considered an additional feature due to Zulip's preview functionality, which is available as an option in org settings.

Hey @swallitsch is this issue fixed. I would like to collaborate.

@timabbott @swallitsch I would also like to work on this issue.

I don't think its a regression, though. This was last touched in a8ab745ee408528469796a88719abbee3f9db572 I believe and the behavior was/is to remove link elements when it is a standalone link without any modifications to the title. So:
hello [](https://google.com/logo.png) should keep the link, and in fact use the url as text because the alt text is missing but...

[](https://google.com/logo.png)

would not keep the <a> element, because we don't have an alt text and this link is the only thing in the paragraph.

That said, we should maybe stop doing this 'smart' behavior and leave the formatting entirely to the sender.

#12979 is a relevant PR here.

Is there anything can be done to speedup the fix of this issue / merge of related PR(s) like #12979


Gnome configuration got reset

FYI
b5935aba548e8f4f2fe6a5997d447be08e061c44
Fedora 33, Gnome, gnome-terminal
...ran theme script directly instead of gogh.sh
first ran
> gruvbox-dark.sh
then immediately after (the palette was shown)
> gruvbox
now, the session froze and I had to switch tty to get rid of it
then when logged in again, the gnome configuration was mostly reset to defaults. But gruvbox colors where applied ;-)
Thank you for sharing, none the less!

BTW, I probably did not do the RTFM...


Don't run test suite twice on PR

This PR checks if this settings work correctly in Travis CI. ✅ 👀 ✨
cf. https://stackoverflow.com/questions/31882306/how-to-configure-travis-ci-to-build-pull-requests-merges-to-master-w-o-redunda

Works fine ;)


fix(storage): license time travel feature

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Require paid tier for time travel feature.
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Set the license key to default. In debug mode, this will set the license key to a paid tier key.

I think this doesn't apply to main-cron e2e tests which use release build, so they'll fail? @BugenZhao

Set the license key to default. In debug mode, this will set the license key to a paid tier key.

I think this doesn't apply to main-cron e2e tests which use release build, so they'll fail? @BugenZhao

I think it'll be okay. In main-cron we use ci-release instead of release, which still enables debug assertions.


SLF4J warning getting printed when running Detekt 1.20.0-RC2

When I run detekt, some warnings about SLF4J are printed:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

I believe this has something to do with KtLint. Are you using the detekt-formatting plugin?

Yes, I am using it.

Gotcha. That's not a release blocker and something to look into if we get some spare cycles

I had this issue in another project and I solved it by depending on org.slf4j:slf4j-nop:<whatever version>.
I don't know if that should go in ktlint, or detekt, but I don't think that it should go in the consuming projects.


Improve code style, reconfigure eslint & prettier config

Codecov Report

Merging #60 (4431c14) into main (9a7f6d2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #60   +/-   ##
=======================================
  Coverage   89.30%   89.30%
=======================================
  Files           2        2
  Lines         187      187
  Branches       40       40
=======================================
  Hits          167      167
  Misses         18       18
  Partials        2        2

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Project overwrite autorization should be done  before the project generated

Model Builder Version: In which Model Builder version was the bug encountered?
Visual Studion Version: In which Visual Studio version was the bug encountered?
Bug description
For Console and WebApi projects the project name authorization window popup after a while.  because the project names are checked after the project generated by the code gen , but we need to check just after the user type project name and click on Add to solution.
Steps to Reproduce

List the minimal steps required to reproduce the bug.
Thanks for reporting!

Expected Experience
A description of what you expected to happen. If applicable, add screenshots or "Machine Learning" Output Logs to help explain what you expected.
Actual Experience
A description of what actually happens. If applicable, add screenshots or "Machine Learning" Output Logs to help explain what actually happened.
Additional Context
Add any other context about the problem here, such as unusual system configurations, network restrictions, etc.

@beccamc Sure!

Can repro this issue on main branch, could you help to take a look?

Windows 10 Enterprise, Version 20H2
ML.Net Model Builder (Preview): <IP_ADDRESS>5801
Microsoft Visual Studio Enterprise 2019: 16.9.5
.Net: 5.0.202

The spinner displayed for 2s, then the overwrite window popup and the spinner continue displaying for about 5s.

Yes this is correct! The issue was a spinner on the page (next to the "Add" button). I will close, thanks!


support for changes in rclone 1.39

There have been a handful of changes in the December 23rd, 2017 release, https://rclone.org/changelog/
for instance, the stats / verbose output has changed, which isn't being picked up by the GUI
ticking verbose produces this level of detail now. (filenames changed, sic)

2018/01/29 04:03:14 INFO  :
Transferred:   1.699 GBytes (1.485 MBytes/s)
Errors:                 0
Checks:                78
Transferred:           10
Elapsed time:    19m31.7s
Checking:
* redhat.iso
Transferring:
*      ...folder/filename.ext: 17% /9.481G, 902.198k/s, 2h31m9s
*                                 ...folder/filename.ext: 88% /432.591M, 709.782k/s, 1m10s
*  (6 spaces) ...20160717/files for backup 02/gentoo.iso: 64% /630.585M, 650.039k/s, 5m50s

for files being transferred, it appears to try to align to the right, so that there's a ~43 character area for the folder/file.extension, then the size/speed/remaining states. filenames being checksum'd also appear to have more room, but this could be incidental.
going back to rclone 1.38 or 1.37, transfers show up again.

I don't want upload my change directly, but the change below will fix progress with rclone 1.39 (may be backward compatible width previous rclone).
--- job_widget.cpp.orig 2018-03-07 14:04:39.637384571 +0100
+++ job_widget.cpp      2018-03-07 14:04:48.321715341 +0100
@@ -69,7 +69,7 @@
QRegExp rxChecks(R"(^Checks:\s+(\S+)$)");
QRegExp rxTransferred(R"(^Transferred:\s+(\S+)$)");
QRegExp rxTime(R"(^Elapsed time:\s+(\S+)$)");

   QRegExp rxProgress(R"(^\*([^:]+):\s*([^%]+)% done.+(ETA: [^)]+)$)");

   QRegExp rxProgress(R"(^\*([^:]+):\s*([^%]+)%.+,\s*([^,]+)$)");

   while (mProcess->canReadLine())

@fredlefred You can probably fork it and add it that way.

Some who can compile a new Rclone Browser with the latest changes that have come since the last official version, it should preferably support version 1.39 and up to the last beta version. ?

@toliman @fredlefred @Evoley @M-K-C
Hi, are any of you by any chance using Windows?
Unfortunately, I cannot compile for Linux or Mac as I have no experience nor knowledge of it, but I was able to compile and test the changes to the code that and it works with rclone 1.41.
Nothing else than what @fredlefred posted has been changed, which is why it still says version 1.2, last edited in 2017 etc etc. I've uploaded a Zip-file, which contains "RcloneBrowser.exe" All you have to do is replace your current "RcloneBrowser.exe" with this and you're ready to go.
RcloneBrowser.zip

It works great thanks for the compile :-)
2018-05-02 2:17 GMT+02:00 chroisle12<EMAIL_ADDRESS>
@toliman https://github.com/toliman @fredlefred
https://github.com/fredlefred @Evoley https://github.com/Evoley @M-K-C
https://github.com/M-K-C
Hi, are any of you by any chance using Windows?
Unfortunately, I cannot compile for Linux or Mac as I have no experience
nor knowledge of it, but I was able to compile and test the changes to the
code that and it works with rclone 1.41.
Nothing else than what @fredlefred https://github.com/fredlefred posted
has been changed, which is why it still says version 1.2, last edited in
2017 etc etc. I've uploaded a Zip-file, which contains "RcloneBrowser.exe"
All you have to do is replace your current "RcloneBrowser.exe" with this
and you're ready to go.
RcloneBrowser.zip
https://github.com/mmozeiko/RcloneBrowser/files/1965548/RcloneBrowser.zip
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mmozeiko/RcloneBrowser/issues/85#issuecomment-385828003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ajrp0XEOO0nyj0At0U1EhKx-eKN7iNHxks5tuPsPgaJpZM4Rvx_R
.

--
Med venlig hilsen
Michael Kjær Christensen
Vestergade 59G
9510 Arden
23888850
<EMAIL_ADDRESS>


From ollama to transformer.AutoModelForCausalLM

Dear all,
Thank you for ollama-python.
I was wondering whether it would be possible to create transformers.AutoModelForCausalLM from ollama, e.g.,
import ollama
model, tokenizer = ollama.from('mixtral:8x7b ')

where

model is an instance of transformers.AutoModelForCausalLM
tokenizer is an instance of transformers.AutoTokenizer

It's not (currently) possible to convert an ollama model back into a transformers model


🎉 metadata: tool to preview metadata in data pages

Add a simple web app to help understand how metadata changes are reflected in data pages.
Also, update documentation regarding metadata (and other minor adjustments).
Run it
etl-metaplay

Note: You must update your environment with poetry install.
Demo
https://github.com/owid/etl/assets/18101289/cc0b5ca7-72a4-4da1-a567-e6fcd65aeb23
Summary of what is going on:

To the left, we show a fictional dataset's snapshot metadata (YAML content). And to the right, we show the dataset's garden metadata (YAML content).
The user can edit these as they please (as long as the syntax is correct). Then, they can click the upper-right "Render data page" button. This will run the ETL steps for this fictional dataset and open the data page in a new tab.
The data page shown corresponds to the single indicator of the fictional dataset: dummy_variable.

Under the hood, this tool is editing the metadata of the dummy dataset, available in snapshot (), meadow, garden () and grapher. It then runs its ETL steps to Grapher (inserts into the grapher). Finally, the metadata values for the dataset are re-setted.
Changes to documentation
To get a glance at the documentation, run make docs from the project folder and follow the indications. Most changes are in Architecture -> Metadata.
Files to review

[ ] apps/: Folder for all apps built around / for ETL. For now, only contains etl-metaplay code.
[ ] docs/ and mkdocs.yml: Configuration and markdown files to render the documentation.
[ ] etl/: Add variable with path to apps/ folder.
[ ] others: poetry.lock and pyproject.toml

@Marigold thanks! Agree;
My intuition is that this will be used at first, but once users are familiar with the metadata they might stop using it.
Perhaps in the future we will have some sort of app to edit the metadata in ETL, which could be a natural evolution of this app. Then, cutting baking times could be very useful.


Tagged Union Support

Introducing support of the union trait on structures. Following additions made:

Input validation that checks that only one member is set on a Tagged Union structure.
If a client receives an unknown member it will set SDK_UNKNOWN_MEMBER as the top level key, which maps to the name or tag of the unknown member.

Codecov Report

Merging #2481 (0cb20a8) into develop (c75af12) will decrease coverage by 0.06%.
The diff coverage is 76.08%.

@@             Coverage Diff             @@
##           develop    #2481      +/-   ##
===========================================
- Coverage    95.38%   95.31%   -0.07%
===========================================
  Files           59       59
  Lines        11391    11437      +46
===========================================
+ Hits         10865    10901      +36
- Misses         526      536      +10

Impacted Files
Coverage Δ

botocore/docs/params.py
91.72% <15.38%> (-7.52%)
:arrow_down:

botocore/model.py
98.26% <100.00%> (+0.01%)
:arrow_up:

botocore/parsers.py
99.45% <100.00%> (+0.02%)
:arrow_up:

botocore/validate.py
99.47% <100.00%> (+0.02%)
:arrow_up:

botocore/credentials.py
98.65% <0.00%> (+0.10%)
:arrow_up:

Continue to review full report at Codecov.

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


It is Worst UI if user cant even install it in there apps

It is not showing any error when I am implementing things in gradle but after that it is of no use in my project neither it is showing text nor option to write text, and it is new so I couldn't find solution to this on internet give a step by step manual for this theme otherwise its worst for me.

Hey! Can you check the sample app provided in this repo for examples?
You can clone the repo and build the sample and use that as a reference.

Thank you for your response
--
Disclaimer:- This footer text is to convey that this email is sent by one
of the users of IITH. So, do not mark it as SPAM.

My issue is not resolved and i am still facing problem can u just make a demo or write that will it be implemented  by simply writing code in xml or do i have to do changes in .kt files too


Having cultures have different traits based on EU4 culture group changes

In EU4: Vietnamese, Jurchen, Korean, Tibetan, and the Altaic group can Sinicize to be in the Chinese culture group. Is it possible to convert these cultures into their Victoria 3 equivalents while adding Chinese traits?
Additionally, the British culture group will be able to move into the French culture group in the upcoming Domination DLC.

The current system fully supports mapping any culture to specific traits. So yes, all that's needed is adding appropriate lines to culture_trait_map.txt.
Feel free to edit it and expand the mappings.

Instead of having separate mapping leading to new cultures with these traits, we're using:
configurables/eu4_culture_new_mappings.txt
to dynamically alter vic3 cultures with appropriate traits in case any of the source cultures are present in pops.

I've tried to test changes to eu4_culture_new_mappings.txt, but the converter doesn't seem to detect the cultures, even ones that were already in this file. Is that why this issue was reopened?

I've tried to test changes to eu4_culture_new_mappings.txt, but the converter doesn't seem to detect the cultures, even ones that were already in this file. Is that why this issue was reopened?

Yes, it's not plugged in yet.


Feature request: Provide a hook to handle/report exceptions in processes forked by Supervisor::ForkSupervisor

Recently I had an issue when running rake solid_queue:start where I was seeing the following exception, because I had neglected to generate & run the migrations in the upgrading instructions:
ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/insert_all.rb:161:in `find_unique_index_for': No unique index found for key (ArgumentError)

          raise ArgumentError, "No unique index found for #{name_or_columns}"
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/insert_all.rb:35:in `initialize'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/persistence.rb:363:in `new'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/persistence.rb:363:in `upsert_all'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/app/models/solid_queue/recurring_task.rb:28:in `create_or_update_all'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/dispatcher/recurring_schedule.rb:44:in `persist_tasks'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/dispatcher/recurring_schedule.rb:20:in `block in schedule_tasks'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/execution_wrapper.rb:92:in `wrap'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/app_executor.rb:7:in `wrap_in_app_executor'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/dispatcher/recurring_schedule.rb:19:in `schedule_tasks'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/dispatcher.rb:42:in `schedule_recurring_tasks'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:403:in `block in make_lambda'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:239:in `block in halting_and_conditional'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:602:in `block in invoke_after'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:602:in `each'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:602:in `invoke_after'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:111:in `run_callbacks'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/processes/runnable.rb:13:in `block in start'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:206:in `block in instrument'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications/instrumenter.rb:58:in `instrument'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:206:in `instrument'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue.rb:59:in `instrument'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/processes/runnable.rb:12:in `start'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor/fork_supervisor.rb:40:in `block in start_process'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor/fork_supervisor.rb:39:in `fork'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor/fork_supervisor.rb:39:in `start_process'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor.rb:47:in `block in start_processes'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor.rb:47:in `each'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor.rb:47:in `start_processes'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor.rb:24:in `start'
  from <internal:kernel>:90:in `tap'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/supervisor.rb:13:in `start'
  from ruby/3.3.0/lib/ruby/gems/3.3.0/gems/solid_queue-0.5.0/lib/solid_queue/tasks.rb:4:in `block (2 levels) in <top (required)>'
  ...

These exceptions were not being reported to our exception monitoring tool (Rollbar).
While I have now resolved the ArgumentError problem, I wanted to avoid missing exceptions like this in the future. I tried setting the on_thread_error configuration option, but this didn't seem to handle exceptions like the ArgumentError above. In the end the only way that worked was to add a begin ... rescue ... end construct inside the fork block in Supervisor::ForkSupervisor#start_process. Is there a better way to do this or is it worth providing a configuration hook to report exceptions like this...?

Oh, interesting! It seems like Rollbar doesn't provide a subscriber for Rails's error reporting? Exceptions like this one are handled by Rails's error reporting automatically so you shouldn't need to configure anything... but it's possible Rollbar is outdated?

Oh, interesting! It seems like Rollbar doesn't provide a subscriber for Rails's error reporting? Exceptions like this one are handled by Rails's error reporting automatically so you shouldn't need to configure anything... but it's possible Rollbar is outdated?

Ah, I wondered whether that was the case. Is there somewhere in solid_queue other than in on_thread_error that reports exceptions to Rails' error reporting? I tried printing something to stdout from within that block and it didn't seem to execute, but perhaps that stdout wasn't connected to the parent process stdout...? I guess my question is: are you confident that the exception above would have been caught by the on_thread_error block...?

Thanks a lot @floehopper! 🙏

I guess my question is: are you confident that the exception above would have been caught by the on_thread_error block...?

No, it wouldn't have been captured by that, but I think it should have been handled by Rails's error reporter regardless, being run within executor.wrap. How does Rollbar hook into Rails errors? Sentry, for example, registers an error subscriber during initialization, and it definitely got this kind of error 🤔
In any case, I realise the way on_thread_error works is quite confusing as it is now. It was something I added in the very beginning, before even having a supervisor that forked processes, so I'll revisit it to make it clearer.

No, it wouldn't have been captured by that, but I think it should have been handled by Rails's error reporter regardless, being run within executor.wrap.

Ah, I missed that - thanks so much for explaining.
I have just verified that the ArgumentError exception I was seeing is indeed reported successfully via the Rails error reporter, so I'm going to close this and focus on sorting out the Rollbar integration with the Rails error reporter.

Just in case anyone else comes across this - Rollbar added support for the Rails error reporter in v3.6.0.

Oh, nice! 🙏  Thanks a lot for posting that information.

@npezza93 indeed! Thanks a lot for doing that 🙏


"IndexError: too many indices for tensor of dimension 2" when finetuning "mim train mmsegmentation configs/multi_temporal_crop_classification.py"

Dear Community,
I followed the instructions in GitHub to run the fine-tuning for multi_temporal_crop_classification.
I edited "multi_temporal_crop_classification.py " file as follows:

pretrained_weights_path = '~/Downloads/IBM_weights/Prithvi_100M.pt'     // not sure if I should use this model
data_root = '~/multi-temporal-crop-classification'      // I cloned to multi-temporal-crop-classification repository
splits = dict(
train='~/hls-foundation-os/data_splits/multi_temporal_crop_classification/training_data.txt',
val= '~/hls-foundation-os/data_splits/multi_temporal_crop_classification/validation_data.txt',
#test=  ''  /not sure where I can get the test one
)

Then I run the below command to run finetune:
~/hls-foundation-os$ mim train mmsegmentation configs/multi_temporal_crop_classification.py
it started fine-tuning, but I got below error
[                                                  ] 0/771, elapsed: 0s, ETA:Traceback (most recent call last):
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/.mim/tools/train.py", line 242, in
main()
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/.mim/tools/train.py", line 231, in main
train_segmentor(
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/apis/train.py", line 194, in train_segmentor
runner.run(data_loaders, cfg.workflow)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmcv/runner/epoch_based_runner.py", line 136, in run
epoch_runner(data_loaders[i], **kwargs)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmcv/runner/epoch_based_runner.py", line 58, in train
self.call_hook('after_train_epoch')
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmcv/runner/base_runner.py", line 317, in call_hook
getattr(hook, fn_name)(self)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmcv/runner/hooks/evaluation.py", line 271, in after_train_epoch
self._do_evaluate(runner)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/core/evaluation/eval_hooks.py", line 51, in _do_evaluate
results = single_gpu_test(
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/apis/test.py", line 128, in single_gpu_test
result = dataset.pre_eval(result, indices=batch_indices)
File "~7/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/datasets/custom.py", line 300, in pre_eval
intersect_and_union(
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/core/evaluation/metrics.py", line 76, in intersect_and_union
pred_label = pred_label[mask]
IndexError: too many indices for tensor of dimension 2
Traceback (most recent call last):
File "~/anaconda3/envs/Mah_IBM/bin/mim", line 8, in
sys.exit(cli())
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/click/core.py", line 1157, in call
return self.main(*args, **kwargs)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mim/commands/train.py", line 100, in cli
is_success, msg = train(
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mim/commands/train.py", line 261, in train
ret = subprocess.check_call(
File "~/anaconda3/envs/Mah_IBM/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['~7/anaconda3/envs/Mah_IBM/bin/python', '~/anaconda3/envs/Mah_IBM/lib/python3.9/site-packages/mmseg/.mim/tools/train.py', 'configs/multi_temporal_crop_classification.py', '--launcher', 'none', '--gpus', '1']' returned non-zero exit status 1.
I do appreciate your help.
Kind Regards,
Mahrokh

Hi Hanxli,
Thank you for providing links. My main issue is "IndexError: too many indices for tensor of dimension 2" and not sure how to fix it.

Hello Mahrokh, we have talked to the team, and they are actively working on this right now. I think it is some new issue introduced with the various updates to the model. The initial release works just fine. Also, for the test splits, we use the same one with the validation.

Hi HanxLi, Thank you so much for the update. Please let me know once the issue has fixed, then I can give it a try.

@mahrokh3409 thanks for raising this. Closing this and linking to #42


expect( [ 1, 'a', 'bb' ] ).toInclude( ['bb'] ) passes?

Just want to make sure this is expected behavior, originally I thought it shall fail.

Yep, that's how toInclude works with arrays.


yaml files of a certain structure produce incorrectly generated code.

Reporting a bug?
In the repository at the link there is an en.yaml file (it looks a bit weird, but that's because I tried to keep it as simple as possible to catch the bug). After performing a yarn build with this en.yaml, the build will not work (see screenshots below).
Note that with this en.yaml the build is broken:

But with this en.yaml (for example) the build is not broken:

Expected behavior
Working build. There should be no errors in the console and this page should appear:

Reproduction
https://github.com/schoonc/intlify--vue-i18n-next--issues--575

Clone the repository.
$ yarn
$ yarn build
Open index.html in browser.
See the console.

System Info
System:
    OS: Linux 5.11 Ubuntu 21.04 (Hirsute Hippo)
    CPU: (8) x64 AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
    Memory: 4.73 GB / 15.50 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 14.17.0 - /usr/bin/node
    Yarn: 1.22.5 - /usr/bin/yarn
    npm: 7.18.1 - /usr/bin/npm
  Browsers:
    Chrome: 91.0.4472.77
    Firefox: 89.0.2
  npmPackages:
    vue: ^3.0.0 => 3.1.4
    vue-i18n: 9.1.7 => 9.1.7

Screenshot

Additional context
No response
Validations

[X] Read the Contributing Guidelines
[X] Read the Documentation
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion

Yes, it looks very much like it's because of the literal style. By the way, the problem does not occur in development mode (yarn serve).

@kazupon
It seems this issue is related to the source map that generated by vue-i18n-loader after parses the YAML file.
I have tested, if we replace this line from
this.callback(null, code, map)

to
this.callback(null, code, null)

this problem won't happen.
This is what I found so far, any ideas?

@PeterAlfredLee
thanks for your help!
I’ve checked same happen.
I did some research on the source map generated by the generator. Unfortunately, I couldn't figure out why. 😞
I wondered if it made sense to support source maps again.
In general, source map support makes it possible to identify source code with devtools such as chrome.
At the moment, vue-i18n-loader does support it, so you can break point to files like yaml other than js as shown in the screen capture.
However, even if you can breakpoint yaml files, you cannot check the state of the variables like you can with javascript. Currently, you can only see the call stack.

So, I am beginning to think that source map support is not very useful.
To avoid this problem, I want to add a sourcemap option to the vue-i18n-loader.
The sourcemap option is disabled by default, false. If you set it to true, the behavior is to generate a source map to pass to webpack, as in the current version.
Th sourcemap generation is not generated by default,  so it’s breaking change.
What do you think about this?

The sourcemap option is disabled by default, false. If you set it to true, the behavior is to generate a source map to pass to webpack, as in the current version.

Good point. But I have no idea how to just disable the sourcemap of vue-i18n-loader. I only found the global option productionSourceMap in vue-cli documents.

for vue-i18n-loader, I like the same specification as the productionSourceMap option as well as the Vue CLI.
https://cli.vuejs.org/config/#productionsourcemap

Just opened PR #39. Please check it.

I've just released v3.0.0
please check it!
https://github.com/intlify/bundle-tools/releases/tag/vue-i18n-loader%403.0.0

It works! Thank you!


feat(dal,web): mark as updating during rebases

Ensures we also make the status bar reactive to rebase operations

bors r+

bors retry


Fix typo: Add missing closing bracket

Ah, expected stderr needs to be updated here.

CI is failing due to unrelated snapshot changes


Game crashing when trying to render create blocks with sodium

Describe the Bug
On game loading into a world, runs fine until placing a block from create, crashing the game
Reproduction Steps

Install both sodium and create
Load into a world
Place a block from create

Expected Result
Placing the block without crash
Screenshots and Videos
No response
Crash Report or Log
https://pastebin.com/RHBBk6Zc
Operating System
Windows 10
Mod Version
0.4.0d
Minecraft Version
1.18.1
Other Mods
Sodium
Additional Context
No response

this seems to have been fixed at some point.

This is not fixed

Issue seems to be a issue with Indium not sodium

using sodium and indium, it works perfect for me in both dev and prod.

This is a problem with indium remapping in dev false alarm


twister: allow loading external configuration

Add a new option to Twister that allows to load alternative configuration files, --alt-config-root. This new option takes an arbitrary number of root folders where alternative configuration files can be stored. Twister will check if a test configuration file exists in any of the alternative test configuration folders. For example, given $test_root/tests/foo/testcase.yaml, Twister will use $alt_config_root/tests/foo/testcase.yaml if it exists.
This feature can be useful if an out-of-tree project needs to run upstream tests in different configurations, potentially not available upstream (e.g. an out-of-tree board, or Kconfig setting).
Note that overlaying has been discarded because we can't easily delete fields from the original configuration file, something that in certain cases could be required. Current approach may lead to some dupplication, but guarantees full control of the test configuration.

Note: another approach could be to merge both files, except that common would only be local (to avoid the risk of propagating commons to the alternate config file without the option to remove them). The solution would be a bit more complicated, though. Any thoughts?

Note: another approach could be to merge both files, except that common would only be local (to avoid the risk of propagating commons to the alternate config file without the option to remove them). The solution would be a bit more complicated, though. Any thoughts?

Not sure if the added complexity is worth the gains.

Main usecase: This feature can be useful if an out-of-tree project needs to run upstream tests in different configurations, potentially not available upstream (e.g. an out-of-tree board, or Kconfig setting). For example, an out-of-tree board and SoC can be tested using the standard set of Zephyr tests by using this option to point to a separate, out-of-tree root that contains the same layout of the in-tree one but only has .yaml twister configuration files. This helps avoid keeping patches in a Zephyr fork that only modify those twister .yaml files.

Is this about platform filtering? For example an upstream yaml file has a list of platform allowed, you have an out of tree platform where you want to run the tests without changing the upstream yaml file, so you create some kind of overlay where the platform is "allowed" in the yaml file and are able to run tests on that platform?

Main usecase: This feature can be useful if an out-of-tree project needs to run upstream tests in different configurations, potentially not available upstream (e.g. an out-of-tree board, or Kconfig setting). For example, an out-of-tree board and SoC can be tested using the standard set of Zephyr tests by using this option to point to a separate, out-of-tree root that contains the same layout of the in-tree one but only has .yaml twister configuration files. This helps avoid keeping patches in a Zephyr fork that only modify those twister .yaml files.

Is this about platform filtering? For example an upstream yaml file has a list of platform allowed, you have an out of tree platform where you want to run the tests without changing the upstream yaml file, so you create some kind of overlay where the platform is "allowed" in the yaml file and are able to run tests on that platform?

An example could be a test that needs to be run on an oot board, where overlays/confs are also needed to make it compile/work. I discarded overlaying for a simple reason: they are additive only, but what if something needs to be removed? Or something from the common section is not applicable to me?


sourceSecondsDuration endpoint

For any given account, we need an endpoint to query the sourceSecondsDuration for all streams created thus far in an active billing cycle and at the end of the billing cycle.
sourceSecondsDuration for the active billing cycle will be displayed on the usage tracking page in the livepeer.com admin and must be updated at least daily.  sourceSecondsDuration will also be used at the end of the billing cycle for billing via our Stripe integration. To get an accurate count, we will need to query for streams with a parent id for a given account.
The billing cycle is not the first of the calendar month to the end of the calendar month. The billing cycle should be able to be set arbitrarily.

@wohlner heads up I just transferred this issue to to the livepeer-com repo.


fix abc kde kwarg handling, adapt tests.

Codecov Report

Merging #550 (9f4a7c2) into main (86256e0) will not change coverage.
 Consider uploading reports for the commit f18f034 to get more accurate results

@@           Coverage Diff           @@
##             main     #550   +/-   ##
=======================================
  Coverage   66.82%   66.82%
=======================================
  Files          56       56
  Lines        4181     4181
=======================================
  Hits         2794     2794
  Misses       1387     1387

Flag
Coverage Δ

unittests
66.82% <61.53%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

sbi/inference/abc/mcabc.py
64.81% <ø> (ø)

sbi/inference/abc/smcabc.py
70.33% <ø> (ø)

sbi/utils/kde.py
85.50% <61.53%> (ø)

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 86256e0...f18f034. Read the comment docs.


Make short_weierstrass::Affine's infinity flag conditional

Description

This PR allows short_weierstrass::Affine's layout to conditionally contain a bool flag indicating whether or not it is zero. This is helpful for compressing the representation of the point in memory. Note that due to the unfortunate lack of associated type defaults, we cannot set the type of the flag to be bool by default.
In the future, it would be nice to automatically derive this from certain conditions (e.g., A.is_zero())

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (master)
[ ] Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[ ] Re-reviewed Files changed in the GitHub PR explorer

Note that I'm not sure this is necessarily a change that we want. We should benchmark and see if there's perf differences.


Source Embeddings JSON & Virtual Table Cleanup?

So assuming I follow the pattern where I create a embeddings column. Can those "source" columns be cleaned up afterward? For example, can I delete the articles.embedding column after this operation?
INSERT INTO vss_articles(ROWID, embedding) SELECT ROWID, embedding FROM articles

FWIW, I did this and it seems to work really well. Thoughts?
db.exec('UPDATE articles SET embedding = NULL');
db.exec('VACUUM')


Add CSV report wrapper

Also switch accuracy_checker and benchmark to the new wrapper

LGTM

@ilya-naumov please rebase to current develop


Fix bugs in mvtec exporter

Summary
This PR fixes two small bugs in the MVTec exporter:

When writing images, the defect type was added to the save path as part of the subdirectory, but the defect type was also added by _make_item_filename as part of the item id. So the final path contained the defect type twice (bottle/test/broken_large/broken_large/000.png instead of bottle/test/broken_large/000.png). This was fixed by not appending the defect type to the subdirectory.
Binary anomaly masks were not multiplied by 255 before writing the image, resulting in empty masks.

How to test

Checklist

[x] I submit my changes into the develop branch
[x] I have added description of my changes into CHANGELOG
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below)

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

@vinnamkim Thanks for the suggestion. I added the correction for the detection task type. I also added some unit tests to test this behaviour

Codecov Report
Patch coverage: 100.00% and project coverage change: -0.01 :warning:

Comparison is base (04e23ab) 78.47% compared to head (42ba67e) 78.47%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #835      +/-   ##
===========================================
- Coverage    78.47%   78.47%   -0.01%
===========================================
  Files          191      196       +5
  Lines        23911    24304     +393
  Branches      4912     4946      +34
===========================================
+ Hits         18765    19073     +308
- Misses        4044     4128      +84
- Partials      1102     1103       +1

Flag
Coverage Δ

macos-11_Python-3.8
?

ubuntu-20.04_Python-3.8
78.46% <100.00%> (+0.01%)
:arrow_up:

windows-2019_Python-3.8
78.41% <100.00%> (+0.02%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

datumaro/plugins/data_formats/mvtec/exporter.py
72.72% <100.00%> (ø)

...aro/plugins/data_formats/datumaro_binary/mapper.py
0.00% <0.00%> (-86.42%)
:arrow_down:

datumaro/util/__init__.py
86.73% <0.00%> (-2.63%)
:arrow_down:

datumaro/plugins/synthetic_data/utils.py
83.33% <0.00%> (-1.67%)
:arrow_down:

datumaro/plugins/splitter.py
88.44% <0.00%> (-0.23%)
:arrow_down:

...o/plugins/data_formats/datumaro_binary/importer.py
100.00% <0.00%> (ø)

...ns/data_formats/datumaro_binary/mapper/__init__.py
100.00% <0.00%> (ø)

.../data_formats/datumaro_binary/mapper/annotation.py
100.00% <0.00%> (ø)

...ata_formats/datumaro_binary/mapper/dataset_item.py
81.03% <0.00%> (ø)

...o/plugins/data_formats/datumaro_binary/__init__.py
100.00% <0.00%> (ø)

... and 8 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Depsrems85

Target Live Date: 2020-07-23

[ ] This has been reviewed and approved by (NAME)
[ ] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[ ] I've staged the site and manually verified that my content displays correctly.

CC: @petele

:+1:

Whoops!
There were 1 critical errors that broke the build and prevented it from being automatically deployed.
ERRORS
src/content/en/updates/2020/07/chrome-85-deps-rems.md#L9 - WF Tag 'wf_featured_image' found, but couldn't find image - /web/updates/images/2020/07/dep-rem_485.jpg

:+1:


Mocket can't mock writing compressed data by zlib

I tried to use Mocket to mock redis and write the compressed data, it threw this error.
In [1]: from mocket import compat

In [2]: import zlib

In [3]: s = '{[]}'

In [4]: compat.decode_from_bytes(zlib.compress(s))
---------------------------------------------------------------------------
UnicodeDecodeError                        Traceback (most recent call last)
<ipython-input-4-0af92b1f9211> in <module>()
----> 1 compat.decode_from_bytes(zlib.compress(s))

/usr/local/lib/python2.7/dist-packages/mocket/compat.pyc in decode_from_bytes(s, charset)
     35 def decode_from_bytes(s, charset=encoding):
     36     if isinstance(s, byte_type):
---> 37         s = s.decode(charset)
     38     return text_type(s)
     39

/usr/lib/python2.7/encodings/utf_8.pyc in decode(input, errors)
     14
     15 def decode(input, errors='strict'):
---> 16     return codecs.utf_8_decode(input, errors, True)
     17
     18 class IncrementalEncoder(codecs.IncrementalEncoder):

UnicodeDecodeError: 'utf8' codec can't decode byte 0x9c in position 1: invalid start byte

In your example the problem is that you are trying to decode something
which is not Unicode, so you would have to specify the right 'encoding'.
But I feel like this is not the real problem you are experiencing.
May you open a pull request adding a test with a small example of what you
want to do?
Or at least comment here with a snippet which fails with this error.
Please note I'll be travelling during the next days, so I can't promise
I'll have time to work on it, but maybe to review your code and trying to
help you and understand if it's a bug or not.
Regards,
Giorgio
Il 26 mag 2017 03:34, "wen-aa"<EMAIL_ADDRESS>ha scritto:
I tried to use Mocket to mock redis and write the compressed data, it threw
this error.
In [1]: from mocket import compat
In [2]: import zlib
In [3]: s = '{[]}'
In [4]: compat.decode_from_bytes(zlib.compress(s))---------------------------------------------------------------------------UnicodeDecodeError
Traceback (most recent call
last) in ()----> 1
compat.decode_from_bytes(zlib.compress(s))
/usr/local/lib/python2.7/dist-packages/mocket/compat.pyc in
decode_from_bytes(s, charset)
35 def decode_from_bytes(s, charset=encoding):
36     if isinstance(s, byte_type):---> 37         s = s.decode(charset)
38     return text_type(s)
39
/usr/lib/python2.7/encodings/utf_8.pyc in decode(input, errors)
14
15 def decode(input, errors='strict'):---> 16     return
codecs.utf_8_decode(input, errors, True)
17
18 class IncrementalEncoder(codecs.IncrementalEncoder):
UnicodeDecodeError: 'utf8' codec can't decode byte 0x9c in position 1:
invalid start byte
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mindflayer/python-mocket/issues/54, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgL3VKeaUViwYZdseCvuqaCuTVg-592ks5r9iw_gaJpZM4NnE7n
.

Any step forward, @wen-aa?

I'm going to close this issue. Please reopen it if you feel like there's something more to discuss.


Deprecate toggleableActiveColor

Related https://github.com/flutter/flutter/pull/90317 and #91772
Fixes https://github.com/flutter/flutter/issues/93709
This PR replacestoggleableActiveColor as it is soon to be deprecated.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@HansMuller
I updated the code and simplified it as you suggested, this looks cleaner :)

Looking at this again, I'm a bit confused about why we're still computing a default value for Radio.activeColor. If RadioListTile.activeColor is specified we do need to pass it along. If it's not, Radio seems to already do the right thing with respect to RadioTheme and all possible states of the Radio button. In other words, maybe the right thing to do here is to just remove the RadioListTile code that computes effectiveActiveColor and just pass along activeColor?

Looking at this again, I'm a bit confused about why we're still computing a default value for Radio.activeColor. If RadioListTile.activeColor is specified we do need to pass it along. If it's not, Radio seems to already do the right thing with respect to RadioTheme and all possible states of the Radio button. In other words, maybe the right thing to do here is to just remove the RadioListTile code that computes effectiveActiveColor and just pass along activeColor?

That was unncessary change, only RadioListTile.activeColor should be provided to Radio in this class. When  RadioListTile.activeColor is non-null, this will be pass to Radio, if not Radio already handles its theme

Hey @Piinks
Thank you so much for your comment!

In the case of multiple options for migration, you can just add bulkApply: false to the fix rule. That way folks still have guidance, they just have to choose individually.

I have added other widgets that use toggleableActiveColor in the PR and dart fixes for them with bulkApply: false. (this will make it easier to review changes or revert if needed since deprecation changes are in this PR too)
There are slight golden changes due to CheckBox, Switch, Radio now using ColorScheme.secondary, it is a slightly less blue default color.
Please let me know if I can make any more changes

Golden changes are to Switch, Checkbox, Radiousing ColorScheme color as part of this migration.  It is not possible to keep  puttoggleableActiveColor` conditionality here since it is not nullable property
      if (states.contains(MaterialState.selected)) {
        return themeData.colorScheme.secondary;
      }

Hey guys, do you thing this PR lands before the next stable? Would be awesome if so 😀
Nonetheless great work 💙

I think there is a dart fix issue, I have filed https://github.com/dart-lang/sdk/issues/49065
I am also migrating the customer test that is blocking this due to the issue: https://github.com/flutter/gallery/pull/694

When https://github.com/flutter/tests/pull/133 lands, the customer test failure here should be unblocked.

 Is there anyway to deprecate it while maintaining backwards compatibility during the deprecation period? That is how we usually give folks time to migrate.

toggleableActiveColor is non-nullable so it cannot fallback to ColorScheme color.
I think a better solution would be to add the useMaterial3 condition (we did the same here to upgrade list_tile font https://github.com/flutter/flutter/pull/102167 which was reverted earlier without this condition).
So in a nutshell, when using Material 3, these widgets won't utilize the Theme.toggleableActiveColor property.
Please let me know if this sounds reasonable.

If we use material 3 condition, it would also fix https://github.com/flutter/flutter/issues/104446

Hmm, that does not sound super clear as a user, that choosing Material 3 makes this change. The more changes we put behind the Material 3 flag, the more difficult it will be to make it the new default.
It also is not a sure thing that going with that approach won't still break internal tests. There are a lot that have already adopted Material 3. Let me see what I can do to get customers migrated, I'll sync up with @HansMuller and @darrenaustin about the M3 flag as well.

I saw https://github.com/flutter/website/pull/6626, usually we land migration guides after the change lands, right now this doc is not true. It should be updated to include these component theme migrations as well. That's why we land the guide last, migrating customers usually reveals what guidance is needed.

I am back from being off for a few days, I will check on the status of the remaining customers and report back here tomorrow.

Working on updating the migration guide.

I saw https://github.com/flutter/website/pull/6626, usually we land migration guides after the change lands, right now this doc is not true. It should be updated to include these component theme migrations as well. That's why we land the guide last, migrating customers usually reveals what guidance is needed.

That makes sense, I'll keep that in mind for future PRs.
Filed https://github.com/flutter/website/pull/7243, I'm not sure if the wording needs update too.

This one as well. @TahaTesser can you update this branch with the latest from master? I am having trouble using our tools to sync this with the internal copy for testing. Thanks!

This one is very close to ready with customers, I am going to focus on completing this one before finishing the migration for https://github.com/flutter/flutter/pull/99753. It will take longer for both if I try to do them simultaneously.

@TahaTesser following up from https://github.com/flutter/website/pull/7243 it looks like there may be a bug here, but I am not sure..
Using the default ThemeData() constructor will result in default values for toggleableActiveColor:
light mode: ThemeData.accentColor ?? ThemeData.primarySwatch[600]
dark mode: Colors.tealAccent[200]
and ThemeData.primarySwatch would default to Colors.blue if null.
It looks like this constructor does not set the ColorScheme.secondary when a colorScheme is not provided. Since ColorScheme.secondary is the new default for radio buttons, should it reflect these colors in this case? Or does it already? I found this while migrating a customer.

@Piinks
Really appreciate you looking into this, I'll deep dive and try to figure out what's going on.

Of course! No worries - and I could be wrong. Migrating theme info for customers is always tricky. They could have multiple themes defined anywhere in their app, so it could be that there is no bug here. It's just worth double checking on a breaking change.

Hey @Piinks

Using the default ThemeData() constructor will result in default values for toggleableActiveColor:
light mode: ThemeData.accentColor ?? ThemeData.primarySwatch[600]
dark mode: Colors.tealAccent[200]
and ThemeData.primarySwatch would default to Colors.blue if null.

I looked into this.
If you look at the specs https://material.io/components/switches#theming, ColorScheme secondary is the only color to be used. Colors defined in toggleableActiveColor are hard coded. Looks like it was created when ThemeData.primarySwatch was more prominent part of the theme system, now it is largely ignored.
IMO, this migration doesn't need to be compatible with ThemeData.primarySwatch since it is also need to be deprecated.
theme_data largely ignores primarySwatch when brightness is set to dark and Darren Austin's comment  also indicates ColorScheme colors should be default (matching Material specs here too).

In this case they are broken because ColorScheme.secondary is a different default.

IMO, ColorScheme.secondary is slightly lighter blue by default hence the difference (also native switch is ligher too compared to the one created using `toggleableActiveColor but it is a spec accurate color regardless of the theme brightness (ColorScheme.secondary). In fact track color is even lighter in native Android.

Flutter
Android

Since ColorScheme.secondary is the new default for radio buttons, should it reflect these colors in this case?

I think widgets should reflect ColorScheme.secondary.

It looks like this constructor does not set the ColorScheme.secondary when a colorScheme is not provided.

Default ColorScheme.secondary color  is returned when no colorScheme is provided. Widgets are still blue when you don't define ColorScheme.
    return const MaterialApp(
      debugShowCheckedModeBanner: false,
      home: Example(),
    );

In cases where  ColorScheme.secondary is already defined but it is a different color than what is defined in ThemeData.toggleableActiveColor, app should not break since fix overrides the component themes to match existiing toggleableActiveColor, if component is already defined, fix applies .copyWith and adds toggleableActiveColor color for each widget.

It's just worth double checking on a breaking change.

Agreed. Without looking at specific customer tests, i cannot say if this is deal breaker and how to overcome this if needed but looking the specs and deprecate primarySwatch issue. I cannot find anything else to fix here.

I'm back long weekend break and I see some conflict in this PR. Updating for conflicts and please let me if my feedback https://github.com/flutter/flutter/pull/97972#issuecomment-1153834494 makes sense and what can we do to land this.

Welcome back! Thank you. I apologize for this taking so long. Most of the time, we'll deprecate something without breaking, and customers migrate on their own time. Since this is a hard break, we have to fix them all first and it is a slow process. Thanks for your patience!

If you want, you can likely hold off on resolving merge conflicts until it is ready.

@TahaTesser this is finally ready! Can you update once more so we can get this ready to finally land! :)

@Piinks
I resolve the conflicts and rebased the branch.
However test fixes passes locally
tahatesser@Tahas-MacBook-Pro test_fixes % dart fix --compare-to-golden
Computing fixes in test_fixes... 32.3s
Passed: 6, Failed: 0
tahatesser@Tahas-MacBook-Pro test_fixes %

It doesn't seem to pass in Flutter CI

How odd! I will check this morning and see if I can resolve them.

QQ - did you merge or rebase?

It looks like the only difference between Expected/Actual in CI is white space. I thought dart fix was supposed to ignore whitespace.. let me inquire with the dart team.

QQ - did you merge or rebase?

Resolved conflicts and rebased.

This PR is pretty old so you may have something cached locally that is out of sync with CI.

Let me try a different machine, where I recently Installed Flutter on it.

I can confirm it's the cache issue. The test fails on a different machine locally.

Can you give permission or commit these changes below?

I will make the changes.

Fab! Thank you for being so attentive to this. We will both celebrate this landing for sure!

Is it passing locally for you again? It is still failing here, although differently. Checking the diff now.

@Piinks
Finally green :)

Hooray! Internal tests are running right now one last time, and then we can merge


Defining at least one phytoplankton functional group for each OSMOSE case study

@FIN-JBarile @FIN-casey @jhpoelen
At least one phytoplankton functional group should be defined for each OSMOSE case study.
Phytoplankton species are included in SeaLifeBase. However, their "data richness" - as defined in #59 - is very low (usually 1).
I would like: (1) the bridge between FishBase/SeaLifeBase and OSMOSE to define at least one phytoplankton functional group for each OSMOSE case study; and (2) the phytoplankton group(s) defined to have a maximum of 30 species.
Here are some comments:
(1) The phytoplankton group(s) defined by the bridge between FishBase/SeaLifeBase and OSMOSE should be "background" functional groups.
(2) Since "data richness" is usually equal to 1 for phytoplankton species, here are the default values that should be defined for phytoplankton species only:
(i) Minimum size: 0.0002 cm (OSMOSE parameter: “plankton.size.min.plkX”);
(ii) Maximum size: 0.02 cm (OSMOSE parameter: “plankton.size.max.plkX”);
(iii) Trophic level: 1 (OSMOSE parameter: "plankton.TL.plkX").
(3) If the user selects an ecosystem or a country plus a FAO area (say, the "Iceland Shelf/Sea" ecosystem) and there is no phytoplankton species for the ecosystem or country plus FAO area of interest (e.g., the "Iceland Shelf/Sea" ecosystem), then the UI should still create a "phytoplankton" background functional group in the Table that is provided in Step 2, with the columns "Species" and "Class" both empty. Then, the bridge between FishBase/SeaLifeBase and OSMOSE will provide the following parameter values for the "phytoplankton" group that it created:
(i) Minimum size: 0.0002 cm;
(ii) Maximum size: 0.02 cm;
(iii) Trophic level: 1.
(4) If the user attempts to redefine phytoplankton groups as "focal" functional groups, then a warning message should pop up; this warning message should say: "Phytoplankton groups can only be defined as background functional groups" .
Could you please implement all of the above? Please let me know if you have any questions and/or comments.  Many thanks.

@agruss2 thanks for your detailed description. In my mind the description contains three separate issues:

UI to always include a phytoplankton background group with specified species
UI to warn user when changing the phytoplankton group to a focal functional group
API to apply specific defaults for phytoplankton groups only

Just to make sure - @agruss2 do you expect background groups other than phytoplankton?

Just implemented functionality to allow setting defaults for background functional groups with name "phytoplankton" in file fishbase-mapping-phytoplankton.csv located at https://github.com/jhpoelen/fb-osmose-bridge/blob/master/src/main/resources/com/github/jhpoelen/fbob/fishbase-mapping-phytoplankton.csv . Please note that any background with phytoplankton species in it with a groupname other than "phytoplankton" will not use the suggested default.
@agruss2 please let me know if the current implementation is acceptable. If not, please propose a way to detect whether a background group contains phytoplankton.

@jhpoelen To answer your first question: When the user reaches Step 2, the only background functional groups defined by the bridge will be phytoplankton groups. Then, the user will be free to designate some of the focal functional groups as "background functional groups", if they want, before going to Step 3.

@jhpoelen To answer your second question; What you are envisioning is great, and should be implemented only for those species that are phytoplankton species.
Please let me know when the UI start defining phytoplankton groups in the Table provided in Step 2. At that time, I will run a new test with the bridge to see if I am happy with what has been implemented, and if the present issue should be closed.

@agruss2 you should be able to test the phytoplankton defaults by creating a background group with name "phytoplankton" with some species in it. I understand if you'd like to postpone testing until the UI development is complete. Just let me know if you'd like me to make any changed to the recently introduced phytoplankton implementation.

@jhpoelen
Since there are almost no data for phytoplankton species in SeaLifeBase, here is what I would like the bridge between FishBase/SeaLifeBase and OSMOSE to do regarding phytoplankton:
(1) The bridge between FishBase/SeaLifeBase and OSMOSE should define one single phytoplankton group, which has to be a "background" functional group.
(2) The following parameter values that should be provided for the background phytoplankton group:
(i) Minimum size: 0.0002 cm (OSMOSE parameter: “plankton.size.min.plkX”);
(ii) Maximum size: 0.02 cm (OSMOSE parameter: “plankton.size.max.plkX”);
(iii) Trophic level: 1 (OSMOSE parameter: "plankton.TL.plkX").
(3) The following columns should be empty for the background phytoplankton functional group: "Class", "Species", "Maximum length (cm)", "Habitat", and "Depth".
(4) If the user attempts to redefine the phytoplankton group as a "focal" functional group, then a warning message should pop up; this warning message should say: "The phytoplankton group can only be defined as a background functional group" .
Could you please implement all this?

This is my current understanding -
(2) has been implemented (or at least, a first pass, see https://github.com/jhpoelen/fb-osmose-bridge/issues/119#issuecomment-306260459).
(1), (3) and (4) are UI issues.
Before moving forward, could you please confirm that this matches with your understanding of the current status?

@jhpoelen
I am not sure that (2) is implemented.
I just ran a test where I queried parameter values for an OSMOSE model for the Iceland Shelf/Sea ecosystem.
I defined all the functional groups as "focal" functional groups, except the "cephalopods group which I defined as a "background" functional group.
Then, I clicked on the "Plus" button to create a "phytoplankton" background functional group. I did not enter anything in the "Class" and "Species columns for that phytoplankton group.
However, in the "osm_param-ltl.csv" file provided by the bridge between FishBase/SeaLifeBase and OSMOSE, I got parameter values only for the "cephalopods" background functional group.
--> Could you please let me know how, under your understanding, (2) is currently implemented?
Once I am clear about that, I will define the present issue as a "UI High Priority" issue, which Casey and Skit will have to address.
Many thanks.

Just now (9 June 2017), I created attached osmose configuration by selecting the "Iceland Shelf/Sea" ecosystem and renaming the last two focal functional groups to "notphytoplankton" and "phytoplankton". The generated configuration archive seems to suggest that the functionality has been implemented. Inspecting the osm_param_ltl.csv shows the values included below. Please confirm that you can reproduce my results.
plankton.name.plk0;notphytoplankton
plankton.name.plk1;phytoplankton
plankton.accessibility2fish.plk0;0.0
plankton.accessibility2fish.plk1;0.0
plankton.conversion2tons.plk0;1
plankton.conversion2tons.plk1;1
plankton.size.max.plk0;NA
plankton.size.max.plk1;0.02
plankton.size.min.plk0;NA
plankton.size.min.plk1;0.0002
plankton.TL.plk0;3.23
plankton.TL.plk1;1

osmose_config_phytoplankton.zip

@jhpoelen I confirm that I can reproduce your results.
Therefore, I am going to define the present issue as a "UI High Priority" issue, which @FIN-casey and @FIN-JBarile  will have to address.
Many thanks.

This comment is alsmost similar to my comment in #120.
I implemented this issue. If there is no "phytoplankton" functional group in the table, the UI will add the "phytoplankton" functional group with no classes and species. Since the group is required for each OSMOSE study, I put an alert of "The functional group cannot be deselected." whenever the user tries to deselect the functional group. I also put an alert of "The Phytoplankton group can only be defined as a background functional group", when the user tries to switch the group to focal functional group.
Please verify.Thanks

@FIN-casey This is wonderful, many thanks!
Just one very minor comment:
Could you please replace "The functional group cannot be deselected." with: "The phytoplankton group cannot be deselected."?

The alert text is now modified. Please verify. Thanks.

@FIN-casey I just ran a test on my laptop, and the old text ("The functional group cannot be deselected.") still appears. Is it because I need to "refresh" the http://fin-casey.github.io/wizard.html link on my laptop (I do not remember the technical term); if so, could you please let me know how to do that?

@agruss2 To load the latest version of the page, just do a 'hard refresh' by pressing CTRL+F5.

@FIN-casey Thanks, it worked! The present issue has been solved; therefore, I am closing it now.


add lambda-friendly builder to MethodCallback

Note that this moves the project from Java 6 to Java 8.
fixes #366

@jerith666
I think it not a good idea to restrict resty-gwt to java source 1.8
We should stay aligned with GWT itself that is 1.6

@freddyboucher I ask @jerith666  to prepare this PR as I saw it on a forked repo. probably you are right with sticking to the GWT version of java but the official GWT site (http://www.gwtproject.org/gettingstarted.html#prereqs) is already requiring 1.8 for development.
I am OK with staying with 1.6 for the time being

@mkristian
GWT may require the SDK 1.8 to run and compile BUT the produced output have to be compatible with 1.6 runtime server.
That's why they don't use 1.7 or 1.8  java syntax in the GWT source code.
Breaking this compatibility isn't probably worth it now.
(I'm a fully 1.8 app developer, my dev env is on 1.8 SDK and my app is deployed on a 1.8 server so I'm not fighting for my personal needs but for the good of resty-gwt project).

thanks @jerith666 - let's see when I find time to add a small testcase for jdk8 lambda syntax on travis and then merge this PR with it.


Editor theme has more properties for the same classes

Godot version:
3.2 alpha-3 mono
OS/device including version:
ArcoLinux
Issue description:
The editor template for themes has a bunch of extra useful properties that cannot be found in a normal theme, not with the normal theme template or by using add class item.  It seems to be necessary to manually add these extra properties to make use of them.
Editor theme

Normal theme

Only the editor should be concerned with horizontal offset I suppose?
Editor theme

Normal theme

Icon colors for hovering and pressed are concerns of just the editor, games don't need to make use for them...apparently?
I really don't think the editor should be treated as special in these cases, and I'm sure there's many more inconsistencies to be found, which results in editor themes being preferred as they have more customization for the same classes.  Ideally, all properties that are not truly Godot editor-specific should be included in the normal theme.

Still valid in 9b4399a

It seems to be necessary to manually add these extra properties to make use of them.

Do you have examples of "missing" properties that actually work for the control nodes in your projects? The thing is, the editor theme can have a bunch of outdated properties defined on it because some changes were not synced when the theme properties of some controls were removed. We try and clean them up from time to time, but it's not impossible that such items would appear. They should have any effect though, which is why I am interested in properties that actually do work.
Another thing is that editor theme can add items which are used internally by editor controls. But again, those won't affect your project.

I checked the title_h_offset mentioned in the OP and indeed it works with a regular GraphNode. So we should compare default and editor themes to see what properties are missing.


admin login seems hard-coded to "admin"

the first thing we do when configuring a django app is to rename the "/admin/" url to something else, like "/company-admin" or somthing less obvious. It seems like django-authlib is hard-wired to the "admin" path.

Hey
That would be a bug and a bit unexpected. I have a site where the admin runs on a different path and I'm using the admin OAuth2 module there as well.
It is hardcoded that the admin app namespace is admin, that's for sure, but this cannot be changed anyway (at least I think that's the case?)
The README says to add https://yourdomain.com/admin/__oauth__/ as a valid redirect URI; if you integrate the admin somewhere else you'd have to use https://yourdomain.com/company-admin/__oauth__/ or something?

Hi, thanks for responding so quickly. I see what you mean now.
It just means that even if the admin app is running at company-admin/, django-authlib will still use admin/__oauth_ as the redirect url. This means that in any path-based routing rules we'd have to enable both company-admin/ and admin/.
I'm attempting to specify the urlpattern entry by hand instead of just importing the urls file to see if we can get around this:
if settings.USE_GOOGLE_ADMIN_LOGINS:
    from authlib.admin_oauth.views import admin_oauth
    urlpatterns.insert(0, path("company-admin/__oauth__/", admin_oauth, name="admin_oauth"))

yup, works perfectly. Thanks again for responding.


SCIM IP range documentation documentation is not including all IPs that we are AAD Provisioning requests from.

SCIM IP range documentation documentation is not including all IPs that we are AAD Provisioning requests from ?

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

ID: 271dc426-fb47-7441-d627-ec11f8c7a6ea
Version Independent ID: 4cb8bfc8-4748-e501-425a-e4c2da0f5f5a
Content: Develop a SCIM endpoint for user provisioning to apps from Azure AD
Content Source: articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md
Service: active-directory
Sub-service: app-provisioning
GitHub Login: @msmimart
Microsoft Alias: mimart

@JaredCross Thank you for your feedback . We will investigate and update the thread further.

@msmimart This seems similar to the request at #56588 . Could you please have this reviewed ?

#reassign:kenwith

The service relies on IP ranges under Azure Active Directory https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#ip-ranges
#please-close


Sudden crash when coloring the map

Hi, for some reason it happened twice but when I'm coloring the map (first time the provinces, second time the terrain) the app crashes suddenly...
Here's the crash report.
Thanks for making this wonderful app!
crash_20240820_162343.log

I've released a new version that should hopefully fix this crash. I was able to pin down the crash to originating from the history/undo state becoming invalid, but I wasn't able to figure out what causes it to become invalid. Either way, invalid history shouldn't cause the program to crash.


Investigate flaky startup failures

Few examples on CI:
http://aspnetci/viewLog.html?buildId=481259&tab=buildResultsDiv&buildTypeId=XPlat_Windows_Win10Universe#testNameId-5755570781948725031
http://aspnetci/viewLog.html?buildId=480840&tab=buildResultsDiv&buildTypeId=Lite_MusicStoreTest
Seems to either be:

A race condition
Using a pointer to an already freed variable

Thoughts on narrowing down the issue:

Added logging in ANCM.
Stress test.

COR_E_EXECUTIONENGINE is the failure in the event log.

https://ci.appveyor.com/project/aspnetci/iisintegration/build/1.0.1106
https://ci3.dot.net/job/aspnet_IISIntegration/job/dev/job/windows-Configuration_Release_prtest/159/console
Seems like something is AVing on startup.


Add sync-setting for config.cson keys to README

Relates to issue #161

Updated

Thanks for improving the docs!


Feature/canshoottotarget

This is probably useful for passing and detecting passes within trees

Has clearshot specifically only looks at their goal...

yes. that other skill can probably be removed and this one should be extended. I prefer doing that later though

I guess this is getting outdated.


add selector to the generate k8s sd config

it must increase parallelisiation of discovery at vmagent
vmagent creates k8s api connection per given watch url - role + namespace + selector
it must allow to speed up initial syncronization for vmagent config

It's not bring any performance tips, no point to use it.


[23.11] gnutls: apply patches for CVE-2024-0553 and CVE-2024-0553

Description of changes
Patches for CVE-2024-0553 and CVE-2024-0553

Things done

Built on platform(s)

[x] x86_64-linux (as well as pkgsStatic variant)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

@OfBorg build pkgsStatic.gnutls

At a quick glance, I think we need to fix CVE-2024-28834 and CVE-2024-28835.

Yup it's the correct patches but I got confused by the order of the security advisories on their page when getting the IDs.

Built passthru.tests, macos 12 x86_64 & nixos x86_64. Built pkgsStatic, pkgsMusl, pkgsCross.aarch64-multiplatform, pkgsi686Linux variants successfully.

Patches also LGTM now - @vcunat satisfied?


fix: avgpool without counting padding and inception

little hack to correct included padding in avgpool
the only still failing avgpool tests are the ones captured by the asserts: auto_pad == "NOTSET" and ceil_mode == 0
also fixes inception model

Nice!


Moving from Travis to GitHub Actions

Hello 🙂
Over the last few months we've been transferring all our CI from Travis to GitHub Actions (GHA). We've found that GHA are easier to work with, more reliable, and much much faster.
Based on our success with GHA and increasing intermittent failures on Travis, we have now decided to try and remove Travis from Exercism's org altogether and shift everything to GHA. This issue acts as a call to action if your track is still using Travis.
For most CI checks this should be a transposing from Travis' syntax to GHA syntax, and hopefully quite straightforward (see this PR for an example).  However, if you do encounter any issues doing this, please ask on Slack where lots of us now have experience with GHA, or post a comment here and I'll tag relevant people. This would also make a good Hacktoberfest issue for anyone interested in making their first contribution 🙂
If you've already switched this track to GHA, please feel free to close this issue and ignore it.
Thanks!

Hello Erik,
I have created a pull request to migrate over to GitHub Actions.  I had to update to fetch-configlet as well to get the test to pass.  Let me know if there is anything that needs fixing: https://github.com/exercism/haxe/pull/54

@davidbruce Looks good to me! I've did a review.

@ErikSchierboom
I have made the change you pointed out in the PR.

@ErikSchierboom
This has been outstanding for a couple of days now; is there someone else that needs to approve this before merging?

@davidbruce Ah no, I was waiting for you to merge :) Sorry about that. Just merged!
Closed by https://github.com/exercism/haxe/pull/54


Refactor suite_report.py

This builds on the changes in #33 and refactors suite_report.py.  The goals are to:

fix compliance with pylint as far as possible
improve code structure by

splitting the monolithic SuiteReport class
moving global variables into classes
separating trac table generation on a separate class
making internal methods private

use pathlib and associated functions in place of os.path and strings
improve/add google-style docstrings
update exception handling by

using appropriate builtin exceptions
removing broad except Exception catches
moving exception handling to the top level
using custom exceptions where necessary

The result should be a modernised version of the script which produces the same - or very similar - output as the unmodernised version.

Changes merged in from refactoring branch with a complete revision history.  Hopefully this will make it a bit easier to review because the refactoring touches a lot of the code.  With hindsight, this should've been split out into a series of tickets.

Nightly Testcases
Comparison between a summary generated with the refactored script and an one generated with the pre-issue #33 version, with a diff that ignores whitespace changes.
Set Revisions
The set-revisions shows a very minimal set of changes:
vdi> python suite_report.py -L /var/tmp -S ~frzz/cylc-run/um_set-revisions_nightly_2024-09-03/runN
vdi> diff -w /var/tmp/trac.log ~frzz/cylc-run/um_set-revisions_nightly_2024-09-03/runN/trac.log
7c7
<  || Report Generated: || 2024/09/03 14:22:52 ||
---
>  || Report Generated: || 2024/09/03 08:47:14 ||
11c11
<  || ''ROSE_ORIG_HOST'': || els055.metoffice.gov.uk ||
---
>  || ''ROSE_ORIG_HOST:'' || els055.metoffice.gov.uk ||
27a28
>
38c39
<  || '''''' || '''Resource Monitoring Task''' ||
---
>  |||| '''Resource Monitoring Task''' ||
vdi>

Heads
The results of a comparison using the heads nightly testing shows different revision numbers for some projects.
vdi> python suite_report.py -L /var/tmp -S ~frzz/cylc-run/um_heads_nightly_2024-09-03/runN
vdi> diff -w /var/tmp/trac.log ~frzz/cylc-run/um_heads_nightly_2024-09-03/runN/trac.log
7c7
<  || Report Generated: || 2024/09/03 14:25:30 ||
---
>  || Report Generated: || 2024/09/03 08:28:40 ||
11c11
<  || ''ROSE_ORIG_HOST'': || els055.metoffice.gov.uk ||
---
>  || ''ROSE_ORIG_HOST:'' || els055.metoffice.gov.uk ||
14,15c14,15
<  || CASIM ||  fcm:casim.xm_tr@HEAD  ||  [https://code.metoffice.gov.uk/trac/monc/browser/casim/trunk?rev=11389 fcm:casim.x_tr@HEAD]  ||  ||  ||  ||
<  || JULES ||  fcm:jules.xm_tr@HEAD  ||  [https://code.metoffice.gov.uk/trac/jules/browser/main/trunk?rev=28870 fcm:jules.x_tr@HEAD]  ||  ||  ||  ||
---
>  || CASIM ||  fcm:casim.xm_tr@HEAD ||  [https://code.metoffice.gov.uk/trac/monc/browser/casim/trunk?rev=11387 fcm:casim.x_tr@HEAD] ||  ||  ||  ||
>  || JULES ||  fcm:jules.xm_tr@HEAD ||  [https://code.metoffice.gov.uk/trac/jules/browser/main/trunk?rev=28867 fcm:jules.x_tr@HEAD] ||  ||  ||  ||
17c17
<  || MULE ||  fcm:mule.xm_tr@HEAD  ||  [https://code.metoffice.gov.uk/trac/um/browser/mule/trunk?rev=125861 fcm:mule.x_tr@HEAD]  ||  ||  ||  ||
---
>  || MULE ||  fcm:mule.xm_tr@HEAD ||  [https://code.metoffice.gov.uk/trac/um/browser/mule/trunk?rev=125856 fcm:mule.x_tr@HEAD] ||  ||  ||  ||
20c20
<  || UKCA ||  fcm:ukca.xm_tr@HEAD  ||  [https://code.metoffice.gov.uk/trac/ukca/browser/main/trunk?rev=4568 fcm:ukca.x_tr@HEAD]  ||  ||  ||  ||
---
>  || UKCA ||  fcm:ukca.xm_tr@HEAD ||  [https://code.metoffice.gov.uk/trac/ukca/browser/main/trunk?rev=4566 fcm:ukca.x_tr@HEAD] ||  ||  ||  ||
27a28
>
38c39
<  || '''''' || '''Resource Monitoring Task''' ||
---
>  |||| '''Resource Monitoring Task''' ||
vdi>

These differences are probably the result of a bug in the existing version of suite_report.py, which uses fcm loc-layout to get the heads revision from the peg_revision.  Where the target is the head of the trunk, the peg_revision ID refers to the most recent change on the repository, not the most recent change to the trunk.  Consequently, if a new branch has been cut since the trac.log was generated by the nightly testing and before the new report was generated, the revision IDs in the URLs will be different (and wrong) in each case.
This problem is marked with a # FIXME note.  Resolution probably requires input from someone with a better understanding of fcm branches and versioning.


Deliver the application in development mode using the HTTPS protocol

The application should be accessible in development mode via the HTTPS protocol.
To differentiate between HTTP and HTTPS protocol in the development environment, the developer must set the environment variable HTTPS to 'true'. The application is then started with the following command:
HTTPS=true npm run serve

Wenn der Entwicklunsserver das HTTPS Protokoll benutzt, muss auch das Protokoll für Websockets angepasst werden:
module.exports = {
  devServer: {
    server: {
      type: https',
      options: {
        key: 'path/to/key.pem',
        cert: 'path/to/cert.pem'
      }
    },
    client: {
      protocol: 'wss'
    }
  }
}

mode = development => HTTPS
mode = production => HTTPS
Server certificate in $HOME/.local/share/wolkenschloss/ca/localhost+1/crt.em
Private key in $HOME/.local/share/wolkenschloss/ca/localhost+1/key.pem
overwrite configuration with environment variables: WOLKENSCHLOSS_HTTPS_CRT and *WOLKENSCHLOSS_HTTPS_KEY"


Workspace with Kobuki for Simulation and Real Robot Control

Closes: #2 #14

Hi, I have fixed all the issues mentioned above and added the new feature as well. I have tested this workspace on both my laptop and NV Orin, and it works perfectly on both platforms. Lastly, I want to express my gratitude for the information on cross-compilation; it is incredibly helpful and has saved me a lot of time during the package-building process. I have added the steps for cross-compilation at the end of the Readme. However, I'm unsure if I've explained each step clearly enough. I did my best to make it understandable. XD

As discussed in today's offline meeting, please update this PR to include the kobuki driver in the Docker image to minimize compilation time. This can be isolated in a separate workspace layer for ease of development. See: 9dc57e8f8aeedce726490721dd43e72ca7ad64b7


Python anaconda install conflicting with git/gettext

Hey guys, installed Anaconda3 v5.3.0 like so
$ asdf install python anaconda3-5.3.0

and it seems that something is in conflict with gettext/git now.
What is the experienced (undesired) behaviour?
$ git pull
GNU gettext shell script function library version <IP_ADDRESS>
Usage: . gettext.sh

What points me this way?
With python anaconda3-5.3.0
$ which gettext
~/.asdf/shims/gettext

where
$ cat ~/.asdf/shims/gettext
#!/usr/bin/env bash
# asdf-plugin: python
# asdf-plugin-version: anaconda3-5.3.0
exec /usr/local/opt/asdf/libexec/private/asdf-exec python bin/gettext "$@"

and
$ ls -al ~/.asdf/shims | wc -l
     415

Without it
After uninstalling it
$ asdf uninstall python anaconda3-5.3.0

$ git pull
Current branch master is up to date.

🎉, and FWIW, there are far fewer shims now.
$ ls -al ~/.asdf/shims | wc -l
      31

Honestly, I don't even know if this is the right place to ask this question versus this being an asdf issue, or python, or anaconda, or something completely different?
I'm open to getting help on debugging this further, or being guided to a better place to ask this, or anything else. Thanks in advance! :v:

PS: Context folded below

I'm running macOS with git 2.19.1
$ sw_vers -productVersion
10.13.6

$ git --version
git version 2.19.1

Update / fix / workaround:
Upon digging deeper gettext is installed on my machine via homebrew.
In it's info, there was a hint at the "solution":
$ brew info gettext
gettext: stable <IP_ADDRESS> (bottled) [keg-only]
GNU internationalization (i18n) and localization (l10n) library
https://www.gnu.org/software/gettext/
/usr/local/Cellar/gettext/<IP_ADDRESS> (1,934 files, 16.9MB)
  Poured from bottle on 2017-01-16 at 20:56:16
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/gettext.rb
==> Caveats
gettext is keg-only, which means it was not symlinked into /usr/local,
because macOS provides the BSD gettext library & some software gets confused if both are in the library path.

If you need to have gettext first in your PATH run:
  echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile

# …snip…

The last bit is the relevant one: changing ~/.bash_profile to have gettext first in the PATH "fixed".

Exactly the same issue for me https://github.com/asdf-vm/asdf/issues/693

Same issue for me using plugin Python mambaforge. Installing matplotlib pulls down gettext, conflicting with the system version. Uninstalling fixes things.
Removing specs: ['gettext']
Transaction

  Prefix: /home/axel/.asdf/installs/python/mambaforge

  Removing specs:

   - gettext

  Package              Version  Build               Channel       Size
────────────────────────────────────────────────────────────────────────
  Remove:
────────────────────────────────────────────────────────────────────────

  - alsa-lib             1.2.3  h516909a_0          installed
  - dbus                1.13.6  h48d8840_2          installed
  - expat                2.4.1  h9c3ff4c_0          installed
  - fontconfig          2.13.1  hba837de_1005       installed
  - gettext           <IP_ADDRESS>  h0b5b191_1005       installed
  - glib                2.68.4  h9c3ff4c_0          installed
  - glib-tools          2.68.4  h9c3ff4c_0          installed
  - gst-plugins-base    1.18.4  hf529b03_2          installed
  - gstreamer           1.18.4  h76c114f_2          installed
  - libclang            11.1.0  default_ha53f305_1  installed
  - libevent            2.1.10  hcdb4288_3          installed
  - libglib             2.68.4  h3e27bee_0          installed
  - libllvm11           11.1.0  hf817b99_2          installed
  - libogg               1.3.4  h7f98852_1          installed
  - libopus              1.3.1  h7f98852_1          installed
  - libpq                 13.3  hd57d9b9_0          installed
  - libuuid             2.32.1  h7f98852_1000       installed
  - libvorbis            1.3.7  h9c3ff4c_0          installed
  - libxcb                1.13  h7f98852_1003       installed
  - libxkbcommon         1.0.3  he3ba5ed_0          installed
  - matplotlib           3.4.3  py39hf3d152e_0      installed
  - mysql-common        8.0.25  ha770c72_2          installed
  - mysql-libs          8.0.25  hfa10184_2          installed
  - nspr                  4.30  h9c3ff4c_0          installed
  - nss                   3.69  hb5efdd6_0          installed
  - pcre                  8.45  h9c3ff4c_0          installed
  - pthread-stubs          0.4  h36c2ea0_1001       installed
  - pyqt                5.12.3  py39hf3d152e_7      installed
  - pyqt-impl           5.12.3  py39h0fcd23e_7      installed
  - pyqt5-sip          4.19.18  py39he80948d_7      installed
  - pyqtchart             5.12  py39h0fcd23e_7      installed
  - pyqtwebengine       5.12.1  py39h0fcd23e_7      installed
  - qt                  5.12.9  hda022c4_4          installed
  - xorg-libxau          1.0.9  h7f98852_0          installed
  - xorg-libxdmcp        1.1.3  h7f98852_0          installed

  Summary:

  Remove: 35 packages

  Total download: 0  B

────────────────────────────────────────────────────────────────────────


[FR] new node "Delay Until"

Delays each message passing through the node until a configurable time is reached.
(similar to node-red-contrib-chronos node)

implemented in latest beta


Bundle uploaded to NPM didn't go through packaging process?

The packaging process for 0.10.8 didn't seem upload the bundle to NPM the same way it did for 0.10.7?
It results in code not being able to find the lucid-cardano module.

having same issue tried to uninstall and install v0.10.7 and still have same issue

Thanks for letting me know guys. Published indeed the wrong parts accidentally... 0.10.9 should fix this again, let me know if it works for you.

It does work. Thank you!


invalid version: malformed tag

The current tag v0.13 is malformed.
It should be v0.13.0.
https://github.com/daixiang0/gci/tags
# go install<EMAIL_ADDRESS>go<EMAIL_ADDRESS>no matching versions for query "v0.13"
# go install<EMAIL_ADDRESS>go<EMAIL_ADDRESS><EMAIL_ADDRESS>invalid version: unknown revision v0.13.0

Thanks for report, update it, sorry for mistake.