[Docs] some 6 to 7 breaking changes hidden in the Detailed change list (or missing)

The main docs page for RxJS, https://rxjs.dev/, currently has two main headers related to changes related to the 6 to 7 updates. One is called "Deprecations and Breaking Changes" and one is called "Detailed Change List". However, some actual breaking changes are included only in the Detailed Change List.
Specifically, debounce and the duration option for groupBy require an observable that emits a next, not just one that completes, to end the duration. The documentation for the change to debounce is in the "Detailed Change List", while it appears that there is no documentation for the change to groupBy.
Missing these issues broke our app in two places, where we were using (with some other logic) EMPTY.delay(time) to trigger debounce or groupBy durations.
One simple thing that might help, for at least the debounce issue, would be to pull the "Detailed Change List" under "Deprecations and Breaking Change" in the menu. My incorrect assumption was that the detailed list was just informational, for those interested in how RxJS had been improved under the hood.
Sorry this is coming up so late--the recent update of NgRX to support RxJS 7 allowed us to finally update our own application, so I'm just coming across these issues now.

Ran into this today with a debounce operator which returned of() in some scenarios. Switching to of(true) fixes.


Error inserting large values into varbinary(max) on SQL Server 2008.

What steps will reproduce the problem?

When I try to insert a large value into a varbinary(max) column on SQL Server
2008 it is producing an error "The text, ntext, or image pointer value
conflicts with the column name specified. (7125)"  Based on this MSDN article
http://msdn.microsoft.com/en-us/library/ms130896.aspx this problem seems to be
tied to the data bindings that the ODBC driver is invoking.

Here is a sample DDL:
use TestDb
Go

create table blobTest (
    id int identity primary key,
    dataDesc varchar(200),
    imageData varbinary(max)
    )

And sample code that generates the error:
import pyodbc, pickle
from PIL import Image
from StringIO import StringIO

#Create the SQL connection
sqlConnStr = ('DRIVER={SQL Server};Server=(local);Database=TestDb;'+
            'Trusted_Connection=YES')

sqlConn = pyodbc.connect(sqlConnStr)

#Create a image to store and prepare it for starge
img = Image.new('RGB', #mode
                (1024, 768), #size
                (0, 0, 255) #color, this is dark blue
                )
imgBuffer = StringIO()
img.save(imgBuffer, "BMP")
img.save('testblue.bmp')

#Store the image in the database
curs = sqlConn.cursor()
sql = """
    insert into blobTest (dataDesc, imageData)
    values (?, ?)"""
curs.execute(sql, ('Blue Image', pyodbc.Binary(imgBuffer.getvalue())))
sqlConn.commit()

This code works quite nicely if the image is made smaller before trying to
insert it.

What is the expected output? What do you see instead?

Receiving a "The text, ntext, or image pointer value conflicts with the column
name specified. (7125)"   error.

What version of the product are you using? On what operating system?
This is version 3.0.2 on Python 2.7.1 running on Windows 7

Please provide any additional information below.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 17 Jul 2012 at 9:54

this helped me inserting huge json inside a nvarchar(max) column type. thanks!


chore(deps): update module github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper to v1.2.13

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.2.12 -> v1.2.13

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper
v1.2.13
Compare Source
Bug Fixes

deps: update terraform null to >= 3.2.1 (#217) (b1fe9e5)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fix Order of precedence for Consul Distributed Configurations (#361)

Have the correct order precedence between shared-application, shared-application by environment, application-specific and application-specific by environment configurations

Hello, the static analysis build is failing with error message

Task :sonarqube
Failed to check if project 'micronaut-projects_micronaut-discovery-client' is bound
Failed to prepare download of the sensor cache
org.sonar.api.utils.MessageException: Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator

Any idea why this happens, and if/how I can fix it ?

Don't worry, it's a known issue


RECOVER LOST OR SCAMMED CRYPTO/BTC/USDT/ CYBERTECH WIZARD

I've been working in sales for over a decade, building a successful business empire along the way. Wanting to expand my horizons, I decided to dive into the world of cryptocurrency, with a particular focus on Bitcoin. Using the wealth of knowledge available on the internet, I began my journey into this exciting and volatile market. Initially, my investment of $500,000 quickly grew, yielding a profit of over $700,000 in less than a year. Encouraged by this success, I deposited my earnings into a Bitcoin wallet. However, disaster struck when I lost my phone. After replacing it, I realized I could no longer access my wallet, triggering a frantic search for a solution. That's when a trusted trading colleague recommended CYBER TECH WIZARD. They promised to help me regain access to my account within 72 hours. With hope and skepticism, I reached out to them. From the very first interaction, the team at CYBER TECH WIZARD displayed remarkable professionalism. They patiently listened to my predicament and reassured me that they had the expertise to resolve it. Their clear and concise communication about the steps they would take helped put my mind at ease. They kept me informed throughout the process, providing regular updates on their progress. Their transparency and dedication were truly commendable. True to their word, within 72 hours, I received confirmation that my wallet access had been restored. Seeing my balance intact was an enormous relief. But CYBER TECH WIZARD  didn't just stop at recovering my account. They went the extra mile to help me secure it against future mishaps. They guided me through implementing enhanced security measures, such as two-factor authentication and better backup protocols. Their proactive approach ensured that I was better protected moving forward. In summary, my experience with CYBER TECH WIZARD was outstanding. Their professionalism, expertise, and commitment to client satisfaction were evident at every step. They not only restored my access to my Bitcoin wallet but also helped safeguard my account against future issues. I highly recommend their services to anyone facing similar challenges in the cryptocurrency space. Thanks to their swift and effective intervention, I can now continue my trading journey with confidence, knowing my assets are secure
EXPERTISE INFORMATIONS
SEND EMAIL: cybertechwizard(@)cyberservices(.)com
WHATSAPP INFO:+185-9743-5022

I dropped out of college four years ago to fully concentrate on day trading. I saw Bitcoin as a gold mine after my close friend, who was successful in the field, mentored me for over a year. I started off with a $15,000 investment just to test the waters. To my delight, I made over $60,000 in a span of six months. Encouraged by this success, I invested an even more substantial amount—up to $390,000.For the first two years, things went well. I decided to switch brokers due to constant changes in rates. The new broker’s rates were attractive to any trader, and I thought it would be a good move.  The new broker turned out to be a scam. When I tried to withdraw my profits, I was met with delays and poor communication. My emails were ignored, and my calls went unanswered. Panic set in as I realized that my substantial investment was at risk. The trading site eventually went offline, and I was left in the dark. Feeling desperate, I shared my experience with a fellow trader who had faced a similar situation. He recommended Daniel Meuli Web Recovery, a team that had helped him recover his account. I reached out to them, hoping for a miracle. Daniel Meuli Web Recovery proved to be a beacon of hope. Their team was relentless in tracking down the scammers and recovering my account. They provided me with the support and guidance I desperately needed during this crisis. Without their help, I might have never recovered my losses. Switching brokers turned out to be the worst decision I ever made, but reaching out to Daniel Meuli Web Recovery was the best. They acted quickly and professionally, helping me through a very dark time. My experience is a cautionary tale. Be vigilant and skeptical with online investments. Trust must be earned, and it’s crucial to safeguard your financial well-being. If you ever find yourself in a similar situation, remember that there are experts like Daniel Meuli Web Recovery who can help you find a way out.   Email         hireus (@) danielmeulirecoverywizard (.) online    Telegram    (@) Danielmeuli

In the perilous realm of cryptocurrency investment, the promise of lucrative returns often conceals a darker reality—a breeding ground for heartless scammers preying on unsuspecting victims. My journey into this began with the allure of financial prosperity, only to culminate in devastation at the hands of deceitful traders. Like many others, I was lured into the world of cryptocurrency investment by promises of substantial gains. With eager anticipation, I deposited 97,345 Euros into what seemed like a promising venture on February 10th. The initial thrill of seeing my investment grow to 127,871 Euros, including a payout bonus, fueled my optimism for the future. However, tragedy struck when a car accident left me in dire need of funds to cover my insurance fees. Desperate and vulnerable, I turned to the very entity that had once promised financial security, only to be met with callous indifference and outright hostility. Live chats were abruptly terminated, and my pleas for assistance were met with disdainful dismissal. It was in this moment of despair that I realized the cruel reality of my situation—I had fallen victim to a heartless scam. My hard-earned money, once a source of hope and possibility, had become a distant dream, forever out of reach. It was then that I resolved to seek justice and reclaim what was rightfully mine. Guided by the counsel of a trusted friend, I turned to Digital Web Recovery—a beacon of hope amidst the darkness of digital fraud. Their reputation preceded them, with a multitude of positive reviews attesting to their prowess in recovering lost cryptocurrency assets for victims like myself. With a sense of cautious optimism, I entrusted my case to their capable hands. The response was nothing short of miraculous. In less than a day, Digital Web Recovery's team of experts meticulously navigated the labyrinth of blockchain technology to reclaim every cent of my stolen funds. Their dedication and efficiency were unmatched, providing me with a newfound relief and gratitude. I am eternally indebted to Digital Web Recovery and its team of professionals for their unwavering commitment to justice. Their swift action and relentless pursuit of truth served as a beacon of hope in my darkest hour, restoring my financial stability and my faith in humanity. To anyone who finds themselves ensnared in the web of cryptocurrency fraud, I implore you to exercise caution and vigilance. But should you find yourself in need of assistance, look no further than Digital Web Recovery. Website https://digitalwebrecovery.com Their expertise, integrity, and unwavering dedication to their clients are unmatched, offering a glimmer of hope in an otherwise unforgiving landscape. Get in touch with them via;
Email<EMAIL_ADDRESS>WhatsApp +14033060588


Update on TLS 1.0/1.1 retirement?

The "latest" update states: "We have already disabled TLS 1.0 and 1.1 for most Microsoft 365 services in the world wide environment. Rollout will continue over the following weeks and months."
But there is no context for "when this started" or more importantly, when it is expected to be completed...
A different page https://learn.microsoft.com/en-us/microsoft-365/compliance/technical-reference-details-about-encryption?view=o365-worldwide#support-for-tls-10-and-11-deprecation states  "We began disabling TLS 1.0 and 1.1 for Worldwide and GCC environments beginning on October 15, 2020 and will continue with roll-out over the next weeks and months."
But it's been 25 months now...
It would be useful for this information to be current, and if this isn't complete yet, be clear about when its expected to be complete for the remaining environments.

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

ID: 9ec089a7-8f7b-d4d9-a763-e8abd73fb2c9
Version Independent ID: 41ba8999-f0ea-5847-afad-8620dd83492a
Content: Disabling TLS 1.0 and 1.1 for Microsoft 365 - Microsoft Purview (compliance)
Content Source: microsoft-365/compliance/tls-1.0-and-1.1-deprecation-for-office-365.md
Service: o365-seccomp
GitHub Login: @WorkShay
Microsoft Alias: fasqiu

@manderson97 Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/10208
Once the author approves, the changes will be live.
Thanks
Sri


added my example

wrote it in p5.js on the web editor.
Managed to make it run faster as a Bubblesort, doesn't look like Selection sort anymore.

nice one!


Uncaught ReferenceError: $ is not defined

Hi !
I have a problem to display the widget, the console return an error : Uncaught ReferenceError: $ is not defined.
At 816
 $(document).ready(function () {
        var limit  = 3,
            layout = 'horizontal';

        ns.TwitchMonitor.init(limit, layout, '.widget-twitch-monitor');
    });

In settings api twitch in uri i have put juste the domain.
I restarted nodebb but is not better.
Thx

What version of NodeBB do you use? There is a high probability that plugin is not compatible with your NodeBB.
Starting from 1.6 there were big breaking changes for plugins.


Bug of dupilaction !!

When you drop the portal gun and you switch the slot, he will replace de slot in a portal gun and you will still have the portal gun from before

Oh yes, I'm already fixing it! Thanks a lot for the report!

The portal gun you can't drop it in inventory panel :(
here is the video (sorry for the quality of the video)
https://drive.google.com/file/d/1nnwHHbr6R_LdWdEzF9VtYEChcRjL29nb/view?usp=sharing

Oh yes, I'm already fixing it! Thanks a lot for the report!

Ah okay thanks a lot because i love this plugin

You can use the switch button the f key (he switch the item in the other hand) when you have the portal gun in hand you can prevent the action before executated is beter than drop it
sorry for my english

https://www.spigotmc.org/resources/fkeycommand.62655/
there is a exemple and this feature work in 1.8/1.18.1

Yes I thought about the possibility of using the F key but I still want to make a system for picking up and transporting entities and blocks in the future.
With this bug I'm coming across other bugs related to the drop, I'll see what I can do to make the system fully functional. Thanks again for your report.
Don't worry about translations! I do not speak English too 😄

Done! It's now available on Spigot! Please if you can leave a review on Spigot's page I would be very grateful! Thanks again for the report.


Update manifests/l/LLVM/LLVM/12.0.0/LLVM.LLVM.locale.en-US.yaml

Fixes an issue where this package has multiple different monikers
Microsoft Reviewers: Open in CodeFlow

[Policy] Reset Labels


Python console takes some action to sync with binaryview

Version 2.1.2269-dev Personal (Build ID 26eb7189), Windows 10
Repro steps:

Open a binja python console
Open a binary, get some address of something in .data, in my case that is 0x403098
Close the binaryview
Open the binary again, don't navigate anywhere
In the console, attempt to navigate via here = <your address>, e.g. here = 0x403098. You should see the following error:
Address 0x403098 is not valid for the current view
Hit 'g' and paste your address. The address is clearly valid.
Now here = 0x403098 works

>>> here = 0x403098
Address 0x403098 is not valid for the current view
>>> here = 0x403098
>>> here
0x403098

It seems if you navigate around a bit without going to the address directly it will also cause it to sync up and start working.

This appears to be fixed. Tested on 2.2.2614-dev.

This appears to be fixed. Tested on 2.2.2614-dev.


Fix errors on line plots

When a plot only has one data point, the code will make it go out of bounds (at index one). Test this by going to the example and setting
p0.Data = [][]float64{[]float64{5}}

And it will crash.
Now it checks the ith element instead of one, and starts reading the data from 0 instead of 1.

Honestly I may need to look at this again... Every time I think I fixed it, it crashes again. Every single time it's just bad indexing in the plot function, I need to look closer.


log is defined in math and developer packages and has a completely different purpose, we should avoid name collision in the standard library when it make sense

Change Intent
Use case
log is defined in math and developer packages and has a completely different purpose. not the best development experience.
let's say you have:
import developer;

foo() {
int i = 0;
log(i)
}

then you need the math package for bar, you see the collision and do change your import too
import developer as developer; import math then you add developer. when the compiler is complaining
you add up with the following code
import developer as developer;

foo() {
int i = 0;
log(i) // BOOM!
}

bar() {
// my math function
}

Proposal
I think the standard library should avoid collision as much as possible. devLog could be an acceptable name
the math library and the need to log thing is quite commun
Justification
Developper experience

remember to always alias the math
library is not the best developer experience.

Please don't use breaking-change-request template if you are just making a feature request or filing a bug. This template is used for team specific process.

@mraleph From my understanding, changing a function name is a breaking change because it changes the public API of the package but I'm maybe missing something.
What I propose more globally is to reduce the need for show, hide, and as when using the standard library.
I see these features as something to avoid conflicting names but not something you use everywhere in your project

@stephane-archer it is indeed a breaking change (and the one we are rather unlikely to decide to do), but that does not mean you have to file a breaking change request - breaking change requests are used when we are executing the process of rolling out actual breaking changes and I usually filed by the person who owns the change.

Would have been nice to avoid the name clash, if we had been aware of it from the start.
The best change would have been to change the log in dart:math to ln, or maybe to loge (so we could have log2 and log10 as well).
Changing anything today is very unlikely to be worth the effort.
Renaming log to ln would likely mean keeping the alias log around for a long time (until Dart 4.0 or so), which means that it doesn't actually do anything in the short term.
The problem is limited, and has an easy workaround.
If the same library uses both dart:developer and dart:math, and uses the log from both (if it only used one, it could just hide the log from the other), then it's annoying. But nothing more, the author will have to import one of the libraries with a prefix (instead or as well, with a hide on the non-prefixed one).
This is standard name clash handling, something a Dart author is expected to be able to do, and name clashes can just as easily happen with third party libraries, so this isn't something special to know for dart: libraries. The workaround is always the same.
So, no current plan to rename anything. Unless it becomes a much larger problem, I don't see it being worth even the beginning effort of renaming log to ln in dart:math, and adding:
@Deprecated("Use ln instead")
double log(num value) => ln(value);

Even if it's better, it's still a huge impact on everybody who has ever used the name log.
If we want to do this, we should also create a fix that rewrites log to ln. Then at least the impact on users will be limited to running dart fix when they get deprecation warnings, and eventually, maybe, we can remove log in Dart 4.0 or 5.0.

@stephane-archer it is indeed a breaking change (and the one we are rather unlikely to decide to do), but that does not mean you have to file a breaking change request - breaking change requests are used when we are executing the process of rolling out actual breaking changes and are usually filed by the person who owns the change.

This was unclear to me when opening the issue, maybe the description should be updated

Agree on the template documentation.
Templates that are only intended for internal use should be documented clearly as such. Even if it means starting their name with you [Internal use only] or something.
(Unless we can differentiate the templates proposed to team members and to other users in GitHub.)

The deprecation does look small when written like that. My main worry is the number of people who would suddenly get a deprecation warning, and would need to address it.
If we can dart fix it, is not even a bad idea.
I don't expect a lot of users to have internalized the name to the point where they'll keep writing log instead of ln forever, and curse us every time it happens.
That said, other languages that we generally try to be somewhat consistent with use log for the natural logarithm: Java, C#, and JavaScript. (JavaScript copied Java, so no surprise there.)
Those languages also have log2 and log10 functions for listings with other bases, which we do not. We have ln2 and ln10 contestants that you can multiply or divide by instead, which means that if we switch to ln for the natural logarithm, we're locked out of having accompanying ln2 and ln10 functions. (Not that the constant names are consistent to begin with.)
All in all, it's probably better to keep what we have. Even the opportunity cost of implementing a dart fix for it isn't really worth it, the issue is too rare and too early worked around.
And if we want to add log2 and log10 functions in the future, we still can with the current names.

My workaround:
import 'dart:developer' as dev;

foo() {
  int i = 0;
  dev.log(i)
}

Is that standard?


✅ Fix test error in Windows for jsonable_encoder

Fixes issue in this comment: https://github.com/tiangolo/fastapi/pull/9816#discussion_r1257415632

Question here is, can we make other tests also follow the same pattern of using str(Path)? I feel we don't have to hardcode the output of str(Path) in our tests.

Can this also be merged? I don’t think this needs a release 🤔

Great, thank you @iudeen! 🚀


Benchling API v2 Support

v1 of the API is deprecated and is no longer supported by Benchling. Are there plans to update the repo so it supports v2?
https://docs.benchling.com/v2/

I haven't actively maintained this project for awhile and wasn't aware of the new API version. Please do make a PR @zdk123!

see #21


Issue with NDK and com.android.tools.build:gradle:3.6.0(3.6.1)

Your support team told me to write here.
I use ndk in the project and after updating android studio and com.android.tools.build:gradle to 3.6.0 I can’t build the project in appcenter, but I can on the local computer.
What went wrong:
Execution failed for task ':app:generateJsonModelDev'.

Expected NDK STL shared object file at /Users/runner/Library/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_shared.so
BUILD FAILED in 1m 20s
24 actionable tasks: 23 executed, 1 up-to-date
Error: /Users/runner/runners/2.165.0/work/1/s/gradlew failed with return code: 1
at ChildProcess. (/Users/runner/runners/2.165.0/work/_tasks/Gradle_8d8eebd8-2b94-4c97-85af-839254cc6da4/1.128.0/node_modules/vsts-task-lib/toolrunner.js:569:30)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Socket. (internal/child_process.js:351:11)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at Pipe._handle.close [as _onclose] (net.js:509:12)
##[error]Error: /Users/runner/runners/2.165.0/work/1/s/gradlew failed with return code: 1

When I specify the ndk version explicitly I get this:
A problem occurred configuring project ':app'.

No version of NDK matched the requested version 21.0.6113669. Versions available locally: 18.1.5063045, 18.1.5063045

When I downgrade the ndkVesrion I receive such message in android studio:
Requested NDK version 18.1.5063045 did not match the version 21.0.6113669 requested by ndk.dir at ...
Downgrading com.android.tools.build:gradle version solves the problem, but I want to use the latest one.

Also experiencing the same issue after updating android (3.6.1) and gradle (3.6.1).
`* What went wrong:
Execution failed for task ':app:generateJsonModelCdxDebug'.

Expected NDK STL shared object file at /Users/runner/Library/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_shared.so

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 1m 9s
11 actionable tasks: 11 executed
Error: /Users/runner/runners/2.165.0/work/1/s/Pulsewave/gradlew failed with return code: 1
at ChildProcess. (/Users/runner/runners/2.165.0/work/_tasks/Gradle_8d8eebd8-2b94-4c97-85af-839254cc6da4/1.128.0/node_modules/vsts-task-lib/toolrunner.js:569:30)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Socket. (internal/child_process.js:351:11)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at Pipe._handle.close [as _onclose] (net.js:509:12)
##[error]Error: /Users/runner/runners/2.165.0/work/1/s/Pulsewave/gradlew failed with return code: 1`
Thanks for your help.

raises hand
ditto, same issue here!

Same!

Adding @elamalani to provide an update on timeline. Looks similar to #1740 .

Same issue here.
After updating to Gradle tools 3.6.1, apparently Azure Devops (where we do CI) fails because it only has version 21.0.6113669. So in order to support Azure Devops, we set ndkVersion to 21.0.6113669 in our build.gradle. (Without specifying ndkVersion, app is looking for version 20.x)
However, because of that, AppCenter fails to build because AppCenter only has 18.1.5063045 or 18.1.5063045. 🤷♂

@elamalani any updates on this? timeline? we have to react base on your status
Thanks

@D3laru3 This is a new feature request in App Center. We don't plan to support it at the moment but we'll keep this issue open for visibility and would let you know once we decide to support it in the product.

18.1.5063045 version is now deprecated, 20 version minium is recommended, please  upgrade your NDK version. @elamalani

https://github.com/microsoft/appcenter/issues/1740

@MaxenceMax Let me talk to the team and see how we could prioritize this issue.

Any news on this @elamalani ?

@bogdantmm92 We are working on it currently and will have an update soon. I will keep this thread posted once the changes are live.

I've an update on this issue - we have updated Android NDK version in App Center Build. Can you please give it a try and let me know if it works for you?

I have specified ndkVersion '21.0.6113669' in our build.gradle and AppCenter is able to build now. Thanks @elamalani !

Closing it as the issue has been resolved.

Hey @elamalani , in the build env is there any way to provide backwards compatibility for 1 version back as well as the most recent version of the NDK?
For instance, just yesterday the version for the NDK was 21.1.6352462 and today it's bumped up to 21.2.6472646 so our builds are failing again. Is there a chance the team could keep up to 2 versions back? For instance, here's the error message I'm receiving from the console output: No version of NDK matched the requested version 21.1.6352462. Versions available locally: 18.1.5063045, 21.2.6472646, 21.2.6472646, notice that the last 2 versions "available locally" are the exact same.
My suggestion is to support 18.1.5063045, support 1 version behind which is 21.2.6472646, and then support the latest 21.2.6472646.
Is this a feasible request? I'm sure others will also run into this problem today.

I faced this exact same issue when AppCenter went from 21.0.6113669 to 21.1.6352462. Was communicating with James from AppCenter support.
Because now we have to specify which NDK to use in the gradle, if a slightly-older version is abruptly removed locally on the VM, all our builds fail until we update.

Hi @elamalani, it happened again. AppCenter's ndk version has been bumped to 21.3.6528147 and our builds are failing as previously mentioned. I'm sure others will run into this problem again. We love your distribution system on AppCenter but these constants changed to the build environment is quite disheartening.
Can we please get some input from you or a team member?

Hi @MoeHamoud,
Keeping two versions back is possible but they will still be updated when the new latest one is released, so I believe this won't solve the initial issue with versions being unexpectedly updated.
If you need to use the exact hardcoded version of NDK I would suggest to use a pre-build script (guide reference) that will be executed automatically after installing dependencies. In this script you can install any version you need with the following code:
#!/usr/bin/env bash

SDKMANAGER=$ANDROID_HOME/tools/bin/sdkmanager
echo y | $SDKMANAGER "ndk;<major.minor.build>"

Also, you can track our image updates on a weekly cadence on this page to be aware of new software https://docs.microsoft.com/en-us/appcenter/build/software
Please, let me know if you have any questions.

Morning @AlenaSviridenko,
Thanks for getting back to us and providing that script. I do realize that at the end of the day we would still need to update our ndk versions, however, what some of us are proposing in this thread is to allow up to 2 versions back of the latest last 2 ndk releases in the build environment. This way when a new ndk version is released and it's applied to the build environment, our builds will still work until the next version release of the ndk - this way we have a bit of a grace period to apply the changes on our end.
As an error msg we see (pulled from above as an ex.): "No version of NDK matched the requested version 21.1.6352462. Versions available locally: 18.1.5063045, 21.2.6472646, 21.2.6472646"
So for example the available ones in the env are: [18.1.5063045, 21.2.6472646, 21.2.6472646]
Notice the last two are the exact same? So say you update ndkVersion[2] from above, is it not possible to keep ndkVersion[0] and ndkVersion[1] until the next ndk version is released? This way, on a new ndk version release; ndkVersion[2] from above would become ndkVersion[1] and the latest would take its place at ndkVersion[2].
Thanks again!

Hi @MoeHamoud,
I got you idea, but keeping 3 versions of NDK (r18 is always presented for compatibility with old Xamarin.Android apps) requires a significant amount of space and a complex support, and still new release could break someone who didn't notice the update, so we currently don't have plans to make this change. Probably we will revisit this strategy later.
Usage of pre-build script will help you to detect when NDK version is bumped up without breaking the build: if your hard-coded version in build.gradle matches the version on image - script won't install anything, but if version is bumped up - script will download your version and you will notice the increased build time (~1.5 min) because of it, your build won't fail, and still you will know that the version on image was updated.
Thank you.

@AlenaSviridenko Ok great, thanks for getting involved in the discussion and for the clear explanation!

Adding an appcenter-pre-build.sh file with the content given by @AlenaSviridenko (thanks!) was for me the beginning of the solution since I also needed an older NDK... BUT it failed with the following error:
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema

This is because I need Java 11 for React Native, so I have JAVA_HOME=$(JAVA_HOME_11_X64) setup in my app env build settings
So I just specified the Java version to use for the SDK manager:
#!/usr/bin/env bash

SDKMANAGER=$ANDROID_HOME/tools/bin/sdkmanager
echo y | JAVA_HOME=$JAVA_HOME_8_X64 $SDKMANAGER "ndk;21.4.7075529"

(replace 21.4.7075529 with whatever NDK version you need or course, probably the same as your ndkVersion in your build.gradle)
The available Java versions in the AppCenter build image are given at the beginning of the logs output: look for "Included Software", e.g. https://github.com/actions/runner-images/blob/macOS-11/20231117.2/images/macos/macos-11-Readme.md#java


OpenVINO inference redesign

Description

Bbox detection using batch operations. For loops are removed as their ranges become constant when exported to onnx.

Known limitations

Currently, torch and openvino inferencers support only single image in a batch.
Since connected_components is added to the onnx graph, loading the model takes quite some time.
Code is a bit messy but I'll wait for the discussions before starting the refactor.

Note: Introduces breaking changes

Closing this as OpenVINO inference will be addressed later


Railties dependencies

I tried to add filepicker-rails and the carrierwave-filepickerio gem to my project, but I'm unable to resolve dependencies bc it looks like one of the two is only allowing railties in the 3.x release. Rails 4.2 depends on the same version of railties, so I can't use this gem in my project.
doki_core (>= 0) ruby depends on
  carrierwave-filepickerio (>= 0) ruby depends on
    filepickerio_rails (~> 0.0.2) ruby depends on
      railties (~> 3.1) ruby

From the looks of it, that 0.02 is from the old fork of carrierwave-filepickerio gem. I'm not sure how to install the latest from the Ink github.

Closing in favor of https://github.com/Ink/carrierwave-filepickerio/issues/3


Add a skip link to the form builder

Summary | Résumé
Adding a skip link to the form builder that skips our 3 levels of navigation and shoots you down straight into the normal page content. SkipLink is a super basic component that takes no properties and expects an id of "#content" to be on the page somewhere.
Note: there is a black outline on the divs when we focus them. Is this good/bad? Happy to remove them if we want, or maybe it's good to show people where they are focused. The border lasts for 1 second and then goes away.
Note: I didn't use the translate function (t) here on purpose because I figure the SkipLink might get used elsewhere and I  didn't want to introduce the whole namespace problem. I'm easy on the approach though.

On the one hand, it is also totally self contained right now and the copy is taken from Canada.ca, so it should be pretty reliable
On the other hand, it's just not how we do things normally.

Used this tutorial for the basic approach:

https://levelup.gitconnected.com/build-an-accessible-skip-to-content-anchor-link-with-react-140903f3bd7e

gif

Just a heads up that a SkipLink component already exists in the app for all other screens and can be found under components/globals.  Can this existing component meet your needs for form-builder?

Ah good point, Bryan. I'll have a look.

Closing in favour of #1254


Send packet only with POST method.

Closes #468

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

Comparison is base (a6a7260) 87.12% compared to head (72de688) 86.99%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #470      +/-   ##
============================================
- Coverage     87.12%   86.99%   -0.14%
+ Complexity      364      358       -6
============================================
  Files            32       32
  Lines          1429     1422       -7
  Branches        165      162       -3
============================================
- Hits           1245     1237       -8
- Misses          115      116       +1
  Partials         69       69

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@nostromoo
Please test it first
implementation 'com.github.nostromoo:matomo-sdk-android:remove_get_packet-SNAPSHOT'
if it comes now with desired behavior. If yes, I'll merge it.
Please keep me informed

Now I see the linked #468.
Did something change on the server-side? According to docs (the last time I checked) the server should accept both GET and POST. :shrug:
This could warrant further debugging to find out why GET is not working. Broken in the SDK? Or an issue with the server config?
If it's the later, changing the SDK seems like the wrong way to fix it :grin:.

Now I see the linked #468.

I did it

If it's the later, changing the SDK seems like the wrong way to fix it 😁.

Any suggestion what's the right way

If it's the later, changing the SDK seems like the wrong way to fix it 😁.

Any suggestion what's the right way

Check if single GET requests are reaching the server, and if they are, check why the server is not processing them. Removing the GET and only using POST is fine, but shouldn't be done as a "guess" without understanding why GET is not working.
@mattab Did the server's behavior for GET change?


CI: make faster/more actionable

Current CI runs as a single job on Travis. This single job is quite slow. Need to investigate:

splitting whole CI process into more smaller jobs (e.g. "fast" check and "the rest", so that the fast one provides feedback quickly, ideally within few minutes)
using github actions more (it seems they run faster, better integrated and maybe we can get more parallelism this way)
Providing more comments on the code on github, rather than on a separate CI page (e.g. description errors, linter warnings can be attributed directly to lines of code). Here is a prototype.

Also fixed 2 cases of non-deterministic test coverage:
https://github.com/google/syzkaller/commit/4053862c2605da2c3cfdf9f866f8588cf5716ebd
https://github.com/google/syzkaller/commit/d06aafeef69b6ffb906d7015fe5b24432766a579
I think this can be considered fixed. CI is now useful again. Separate additional improvements should go into new issues.


for manual document upserting

$sMongoID = md5('555' . 'www.apple.com');
$doc = new Document($collection);
$doc->setId($sMongoID);
$doc->set('manufacturer', 'apple.com');
$doc->set('name', 'iPad');
$doc->set('cap', '32GB');
// document created
$doc->save();
unset($doc);
$sMongoID = md5('555' . 'www.apple.com');
$doc = new Document($collection);
// creating document wit SAME id
$doc->setId($sMongoID);
// set color
$doc->set('color','white');
$doc->save() ; // it will update document, set color

I don't understand why you are trying to create document twice. In ORM document is an object representation of some data in database. So to update document you need to load document from database. But you are trying to upsert document instead of update.
Connect use case is:
<?php

// Create document
$sMongoID = md5('555' . 'www.apple.com');
$doc = $collection->createDocument()
    ->setId($sMongoID)
    ->set('manufacturer', 'apple.com')
    ->set('name', 'iPad')
    ->set('cap', '32GB')
    ->save();

unset($doc);

// update document
$doc = $collection
    ->getDocument($sMongoID);
    ->set('color','white')
    ->save();

Document::setId() marks field as changed, and document became unstored with defined id:
<?php
class Document
{
    public function isStored()
    {
        return $this->get('_id') && !$this->isModified('_id');
    }
}

And unstored document with defined id will be inserted, and of course fails with duplicale key. So if you really want to update document in your strange way, you need to define _id, but without mark it as modified. There is method for that: `Document::defineId()`. So you can update document in that way:

```php
<?php
// Create document
$sMongoID = md5('555' . 'www.apple.com');
$doc = $collection->createDocument()
    ->defineId($sMongoID)
    ->set('color','white')
    ->save();

But it's weird.
PS. Your pull request is not PSR compatible, and it broke tests for php 5.3. Also thank you for idea about events in unit of work, i'v forget about them. They will be added soon

Because when you parse 30+ sites with python crawlers, why do you need to do additional Select from DB while you can just do upsert?
I'v made fork from your repo, there is many changes above your project, you can check it. For example, documentEvents in Persist (with upsert too)

So why you dont use directly $collection->update() with upsert? If you really need upsert in entity, use defineId. But imho this can add data inconsisted state, because some busines logic inside Document may require all fields.
For example you can add beforeSave event which set one field relatively to value of another field.
But at last i understand want you want  and i will think how to do that in more clear way than setting upsert flag. i'm trying to hide all mongo options by clean interface.
By the way doctrine's mongo add upsert when id set, maybe it is better solution than setId/defineId in this lib:
http://doctrine-mongodb-odm.readthedocs.org/en/latest/reference/upserting-documents.html

https://github.com/sokil/php-mongo/issues/107
https://github.com/sokil/php-mongo/issues/108

$collection->update() with upsert
Because I need it in batch.

Impelmented batch processing of operations instad of documents:
<?php
$collection
    ->createBatchUpdate()
    ->update(
        array('a' => 1),
        array('$set' => array('b' => 'updated1')),
        $multiple,
        $upsert
    )
    ->execute('majority');


Appstudio update test-component-pac-bfbz

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI/test-component-pac-bfbz-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
35 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
1 minute
sast-snyk-check

✅ Succeeded
23 seconds
deprecated-base-image-check

✅ Succeeded
25 seconds
inspect-image

✅ Succeeded
3 minutes
clair-scan

✅ Succeeded
53 seconds
clamav-scan

✅ Succeeded
16 seconds
sbom-json-check

✅ Succeeded
14 seconds
show-sbom

✅ Succeeded
12 seconds
show-summary

Pipelines as Code CI/test-component-pac-bfbz-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
20 seconds
clone-repository

✅ Succeeded
25 seconds
build-container

✅ Succeeded
7 seconds
sast-snyk-check

✅ Succeeded
27 seconds
inspect-image

✅ Succeeded
27 seconds
deprecated-base-image-check

✅ Succeeded
35 seconds
clair-scan

✅ Succeeded
36 seconds
clamav-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
5 seconds
show-sbom

✅ Succeeded
6 seconds
show-summary


Optimized condition for accepting credit lines

Save gas by restructuring the check on sender while accepting credit line requests.
Fixes https://github.com/code-423n4/2021-12-sublime-findings/issues/77
Changelog

require condition to check sender while accepting credit line requests in accept(_id) function is updated

Codecov Report

Merging #208 (1415a13) into master (6aaf59a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #208   +/-   ##
=======================================
  Coverage   15.95%   15.95%
=======================================
  Files          16       16
  Lines        1736     1736
  Branches      321      321
=======================================
  Hits          277      277
  Misses       1459     1459

Impacted Files
Coverage Δ

contracts/CreditLine/CreditLine.sol
9.82% <ø> (ø)

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 6aaf59a...1415a13. Read the comment docs.


storage capacity: beta

After the promotion to beta in 1.21, enabling the feature is easier
and mostly just depends on the CSI driver deployment.

/hold
The actual promotion hasn't happened yet. See kubernetes/kubernetes#99641 for that.

cc: @reylejano

/milestone 1.21
/assign @tengqm
/sig storage
hold until kubernetes/kubernetes#99641 merges

Please make sure /docs/reference/command-line-tools-reference/feature-gates.md is properly updated when the upstream promotion is done. Thanks.

Please make sure /docs/reference/command-line-tools-reference/feature-gates.md is properly updated when the upstream promotion is done.

Thanks for pointing it out. I have added it to https://github.com/kubernetes/website/pull/26801

/lgtm


Add regression tests for handling of HTML errors

closes https://github.com/TryGhost/Ghost/issues/8203

rename version-mismatch-test.js to the more generic error-handling-test.js
add tests to simulate receiving HTML errors (eg, the type of error received from CloudFlare for a gateway timeout)

Coverage increased (+0.06%) to 73.451% when pulling 9c9ab282887ad326f5429efd5a2aaf004066e516 on kevinansfield:add-tests-for-html-alerts into 868d62bea370ad8eb41804bd92306f1523404b2d on TryGhost:master.


r

Is it International Talk Like a Pirate Day?

Ha(r) I think it was last week! I had the focus on the wrong window, was trying to clear my terminal and sounded like a pirate by mistake :)
Michael Brett

On 25 Sep 2015, at 20:59, kenny-evitt<EMAIL_ADDRESS>wrote:
Is it International Talk Like a Pirate Day?
—
Reply to this email directly or view it on GitHub.


urllib.unquote error exposed by Python 3 runtime when extracting zip file or compressing file in File Browser

Is the issue already present in https://github.com/cloudera/hue/issues or discussed in the forum https://discourse.gethue.com? No
Describe the bug:
User attempts to extract a zip file in the File Browser, or attempts to compress a file in the File Browser.  User is presented with error:
"Exception occurred while extracting archive: module 'urllib' has no attribute 'unquote'"
Steps to reproduce it?
2 ways:

Attempt to extract a zip file in the File Browser
Attempt to compress a file in the File Browser

Hue version or source? (e.g. open source 4.5, CDH 5.16, CDP 1.0...). System info (e.g. OS, Browser...).
Hue 4.7+

Added fix as part of PR for #1799 fix as well.  urllib.unquote needs to be converted to urllib_unquote in Filebrowser views.py.
https://github.com/cloudera/hue/pull/1810

Nice, thanks Rick! Just could we do it in a separate PR? (to avoid mix&matching apples and oranges ;))

@romainr , fixed that here:
https://github.com/cloudera/hue/pull/1841

Excellent, thank you Rick!


Add support for a KMS configuration that uses Vault Tokens

Initial implementation (still a work-in-progress) for VaultTokensKMS support as described in #1743.
Posting for early review.

Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

/retest ci/centos/<job-name>: retest the <job-name> after unrelated
failure (please report the failure too!)
/retest all: run this in case the CentOS CI failed to start/report any test
progress or results

@nixpanic  - is this meant as a replacement for PR #1559 and fix for issue #1500 ?

@nixpanic - is this meant as a replacement for PR #1559 and fix for issue #1500 ?

Yes, that is correct.

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

Job 420 failed:
STEP: create a PVC and bind it to an app with encrypted RBD volume
...
Dec 10 12:31:55.890: FAIL: failed to validate encrypted pvc with error timed out waiting for the condition
...
ProvisioningFailed: failed to provision volume with StorageClass "csi-rbd-sc": rpc error: code = InvalidArgument desc = invalid encryption kms configuration: missing encryption passphrase in secrets

This is not an issue introduced by this PR, but something that started to happen sporadically.


[FR] Grid Zoom: Smallest images still too large

Hi, I am using fiftyone via Python in its Jupyter environment to display images that are 64x64 pixels in size. Setting the grid zoom slider to its leftmost value, renders images that are still too large for me.
Is there a possibility to make the grid of images even smaller?
I saw that I can pass grid_zoom=0 to the app, but this does not really help me as this only programmatically sets the slider to its leftmost position.
Thank you.

Hi @r0f1. I hear you. I will try increase the limit a little. There are practical limits, of course. We don't want to offer a lower bound that leads to a poor experience.
Generally speaking, App optimization is an ongoing effort and the limit will be increased accordingly.

Range increased by #4281 in 0.25.0


Avoid subnets that don't have available IP Addresses

Description
What problem are you trying to solve?
When a subnet is almost out of IPs, Karpenter will continue to launch nodes in it, leading to the VPC CNI failing to become ready, and the node becoming unready as well. In many cases, there's nothing we can do, but if another subnet has IP addresses, and the workload does not have scheduling constraints that prevent it from running in those zones, we should launch in the subnets with available IPs.
How important is this feature to you?
Managing the ipv4 space is hard, and anything we can do to alleviate these pains would help customers on their path to ipv6.

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

@ellistarn if we have multiple available subnets available for a zone, will karpenter choose the least full subnet like it says in here https://karpenter.sh/v0.32/concepts/nodeclasses/#specsubnetselectorterms ?

Correct. This is a good point. We don't do this for subnets in different zones
.

Would be really good if we could do this, as this would/could also naturally balance instances across zones which would be a nice HA feature. We have seen that unless there is a topology spread in our deployments, multiple instances get spun up in the same zone.

This is one of the burning issue that we are currently facing with Karpenter, we discussed about this in reinvent. Checking available IPs across the subnets using AWS endpoint and scheduling next instances to the subnet with most IPs seems straight forward. Any approximate release timeline for when we can expect this feature to be added?

Are you finding that there are 0 remaining IPs and the launch fails, or just a few IPs? Can you provide logs that occur when this happens? Is the failure at the node level? Pod level?

Are you finding that there are 0 remaining IPs and the launch fails, or just a few IPs?

No we were seeing that without pod anti affiinity to force them to be spread across zones we'd often end up with multiple nodes in the 1 zone and none in the other 2 zones, then all the pods trying to spin up and exhaust the subnet. Note that this is using lots of small pods and relatively small subnets (/26). We weren't seeing node launches fail.
We're not seeing this issue as we moved to larger subnets and added the anti affinity which means the nodes are spread across the zones/subnets more evenly.
Am happy to recreate this and send some logs if that would be helpful @ellistarn ?

@martinsmatthews , have you completely exhausted the ipv4 space? Is it possible to add another subnet with more IPs? Why are you so constrained?
I'm working on an idea for EKS networking and I'd love to chat more over slack.

Coming back to the use of topologySpreadConstraints to solve this issue and stripe pods over AZs (and thus over subnets) this doesn't work perfectly. I spun up 10 deployments with 3 replicas and with a topologySpreadConstraints like (plus a large enough resource ask to end up with only one pod per node) with a nodepool that had 3 subnets defined, 1 in each of 3 AZs:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: topology-test-{{ count }}

and this gave me 30 nodes, 10 in each AZ - bingo. But... then I dropped the replica count to 2 and spun up 15 deployments and this gave me a very uneven spread of nodes:

us-west-2a: 19
us-west-2b: 7
us-west-2c: 14

Obviously this is artificial, but this does again highlight a need for an option to balance nodes across AZs even if this is not the default. And not just for subnet usage reasons, there is an HA risk here for when we lose a zone - it doesn't happen often, but when it does and we were skewed like this in a production cluster, it wouldn't be pretty.

Has anyone come up with a solution to work around this?  We have twice run into a situation where Karpenter overloads a single AZ (with two /20 subnets) and both subnets run out of IP's.  The skew was quite extreme (200 nodes in 1 AZ, 50 in the other 3) and it seems like a burst of spot requests may have put them all on the same AZ, but it still seems odd that Karpenter doesn't attempt to do any kind of load balancing across the AZ's.  Our current work around is to define a nodepool per AZ and use the cpu/memory limits to faux-limit the number of nodes to prevent IP exhaust, but this results in a lot of nodepools and ec2nodeclass's.  This only works because we currently use a fairly strict set of instance types so we know what their max pod count would be.  If anyone has come up with a better solution please share!

We have twice run into a situation where Karpenter overloads a single AZ (with two /20 subnets) and both subnets run out of IP's.
Same issue here.

After migrating to karpenter, it started favoring one zone (eu-west-1c), despite having over 1000 addresses available in other subnets, which ended up with us running out of addresses in eu-west-1c.
╰─❯ kubectl get nodes -L  worker-type,group,topology.kubernetes.io/zone --sort-by=.metadata.creationTimestamp --no-headers   -l group=default | awk '{print $8}'  |sort | uniq -c
   7 eu-west-1a
   7 eu-west-1b
  25 eu-west-1c

different cluster but still running on cluster-autoscaler:
  18 eu-west-1a
17 eu-west-1b
18 eu-west-1c


use signal-hook instead of ctrlc

Fixes #1264

bors r+

This change is not functionally equivalent to using Ctrlc with termination feature. You're now handling SIGINT only, where previously you were handling SIGTERM and SIGHUP also.

@Detegr noted, I wonder if that would be an issue.

It depends whether you want to have for example kill cross run the handler or not. I'm not sure if cross can be used on Windows, but on Windows killing a process from a task manager or closing the command line window will trigger CTRL_CLOSE_EVENT and that won't be handled either.
For just exiting the process with Ctrl-C will work with this solution in unixes and Windows.

@Detegr I see that you've reverted the behaviour in ctrlc to how it used to be and introduced try_set_handler instead. Does that mean this pr could be reverted with that update?

Yes, I brought the previous overwriting behavior back as it broke more things than I anticipated (should've been a major number change, I guess).


[feature request] cloudflare pages

Be super dope to also support CloudFlare pages locally 🕺🏻

Moving to wrangler 2 is such a pain. It's far from ready, and such a big shift for us to move to it from miniflare! 😅
There's no way I can entice you to consider this for miniflare than to suggest moving to wrangler?


⚠ Bofrost.at has degraded performance

In ca02749, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1607 ms

Resolved: Bofrost.at performance has improved in 5723498.


pre-release: generate changelog

Capturing the original discussion from https://github.com/nix-rust/nix/issues/595.
As one of the last steps in a release process, there is often the need of semi-automatically generating a changelog.
I'd be better personally happy in having some field to specify a custom binary/script, and some calling convention to follow (e.g. to know about previous and new version, etc.). That way I could extend the process with further logic without making cargo-release too opinionated, and even introduce some interactive action in the middle for a final cosmetic pass.

/cc @Susurrus @kamalmarhubi

Yes I agree having a pre-release hook script is a good approach at the moment. Will add this to my backlog.

Just added a quick and simple implementation of pre-release hook.

Could you provide some documentation for it? I'd like to test it out but I'm not clear on how to use it just from looking at your commit.

For now, just add this to your Cargo.toml:
[package.metadata.release]
pre-release-hook = "your-command-or-script"

It will be executed when you call cargo release. There will be two arguments provided to this script: the new version and current version.

And I assume that script will also be run during a dry run for easy testing?

No. I just print out the command during dry run, like:
Update to version 0.8.1 and commit
Calling pre-release hook: my-script 0.8.1 0.8.1-pre
my-script 0.8.1 0.8.1-pre
cd .
git commit -S -am (cargo-release) version 0.8.1
cd -
Running cargo publish
cargo publish
Creating git tag 0.8.1
git tag -a 0.8.1 -m (cargo-release)  version 0.8.1 -s
Starting next development iteration 0.8.2-pre
cd .
git commit -S -am (cargo-release) start next development iteration 0.8.2-pre
cd -
Pushing to git remote
git push origin --follow-tags
Finished


Provide delegate based acceleration

There are mutliple available options:

Use Eigen backend - supports TIZEN and Android but not available on both, needs to be packaged for both
Use NNAPI backend - natively available for Android, forwarding can be natively done, backwarding would use multiple basic operations from NNAPI
Use cblas - this is currently what we do

This also needs API to allow user to set this.

:octocat: cibot: Thank you for posting issue #659. The person in charge will reply soon.

Now we have a configuration header. Now the issue is who should have that configuration object and how configuration be used to generate the appropriate layer.
Let's say choosing between fc_layer.h, fc_layer_nnapi.h
We will have a backend nnapi from ini file (or from a model setup, or layer property...)
One way would be AppContext to have generate from a mangled layer type name, eg) fullyConnected_nnapi and we mangle name to call a layer.
AppContext::createObject<Layer>("fullyConnected_nnapi")
Because it is hard to maintain, we can choose an option to make a Backend as an argument to the AppContext<Layer>::createObject like
AppContext<Layer>::createObject(name, props, backend)
This is fine but it will be a mess inside AppContext<>::createObject with a lot of switch cases.
To resolve this problem. I came out with the following design below.
Design
First, we create a factory manager class.
Factory manager will register factories and create object
Each supported backend will have exactly one factory manager.
/* factory_manager.h */
/// this factory manager will be created for each supported backend
class FactoryManager {

  int registerFactory (args...) {
    /// moved from appcontext
  }
  Obj createObject(layertype, properties) {
    /// moved from appcontext
  }
};

Now, app_context will have std::unordered_map<BackendEnum , FactoryManager *>, and we can register a factory manager, sets property for the factory manager, and unregister a factory manager.
/*  app_context.h */
class AppContext {
registerBackend(backendEnum key, FactoryManager backendSpecificFactoryManager) {
 /// now app context saves backend, available backend for the context.
}

unregisterBackend(backendEnum key) {
 /// disable certain backend.
}

setBackendProperty(backendEnum key, props) {
 /// delegates to setting a backend Property
}

createObject<ml::train::Layer>(layer_type, backendEnum, properties, ) {

}
};

Now we can initiate the supported backends as below
/* appcontext.cpp */

static void init_global_context_nntrainer __attribute__((constructor)) {
  auto &ac = AppContext::Global();

  std::shared_ptr<FactoryManager> BaseFactoryManager = make_shared...
  BaseFactoryManager->registerFactory(createLayer<FullyConnected>, FullyConnected::type);
 ac.registerBackend(Backend::Base, BaseFactoryManager)

#ifdef android
  std::shared_ptr<FactoryManager> NNAPIFactoryManager = make_shared...
  NNAPIFactoryManager->registerFactory(createNNAPILayer<FullyConnectedNNAPI>, FullyConnected::type);
  ac.registerBackend(Backend::NNAPI, NNAPIFactoryManager);
#endif
}

The above code implies that we do not have to make a hierarchy of  ->  but we can stick to a flattened layer hierarchy.
+) user side code would look like this..
// in ModelLoader or user's code
{
auto &ac = AppContext::Global();

ac->createObject<Layer>("fullyconnected", Backend::BASE, {/*properties */});
ac->createObject<Layer>("fullyconnected", Backend::NNAPI, {/*properties */});

ac->registerBackend(Backend::custom, UserFactoryManager);
ac->unregisterBackend(Backend::base);
}

considering serialization support, we should use string instead of enum, but big picture remains the same.

The design is good. However, I am concerned about a few points -

With FactoryManager for different backends combined for all layers, the default backend for each layer becomes restricted. For example, suppose the default backed for FC and Conv can be NPU/GPU but for RNN/softmax should be CPU. Such a setup would not be possible with this design. This is a very common scenario as some backends might not support a layer or different backends have different performance for different layers (this does not add any memory overhead as with ARM architecture, DRAM is shared)

In my opinion, the factory manager can be at a lower level (layer level).

Such requirements is possible.

createObject<ml::train::Layer>(layer_type, backendEnum, properties, ) {
if (backendEnum == 'auto') {
  op =  resolveBackend(layer_type);
}
}

backend is a configuration that will be owned by its object. AppContext just owns bunch of factories to create the object.
eg) fc layer with armcl backend) (let's say class name is FcArmCL

register (as an object to use for this context)

  ac.register_object('arm_cl', createObject<FcArmCL>)

creating from an ini

 [fclayer]
 backend=armcl

//model_loader.cpp
std::string backend = iniparser_getstring(ini, 'fclayer:backend', unknown);
app_context.createObject<ml::train::Layer>(layer_type, str_to_enum(backend), properties);

saving to an ini

FcArmCL::save {
if(save_backend)
 file.write(layer.getBackend());
}

From the offline discussion, I am gonna add op =  resolveBackend(layer_type);. And not implement setBackendProperty as this should be probably inside model

resolveBackend(layerType) looks good. Lets go with it.
I think you misunderstood my point. Clarified offline. Backend/Delegate configuration object will be owned by model.


[Feature]: Add support for other Mastodon instances

Prerequisites

[X] I have verified that this issue is not a duplicate. (Search here  to find out.)

Is your feature request related to a problem? Please describe.
Many folks do not use mastodon.social. Support for other instances would make this more useful.
Describe the solution you'd like
A text entry box for a user-specified Mastodon instance.
Describe alternatives you've considered
No response
Additional context
No response
Do you want to implement this feature yourself?

[ ] Yes, I will implement this by myself and send a pull request

Thank you for your feature request!
I am considering adding a feature that allows users to specify their Mastodon or Misskey instances.


Task with no return value cannot be declared

1、The regenerated code cannot be overwritten
2、Method has no return value ，but it can not use "Task" directly.

Looks like this affects Hystrix enabled bindings only... unless I'm missing something.  I've added a couple unit tests and will be committing the update once this is fixed.

Added unit tests to recreate the error.  A return type of void is perfectly fine, but a return type of Task is not.
The bug is related to mistaking the Task as a convertible type, which it is not.  The generated code looks something like this:
        public async System.Threading.Tasks.Task<System.Threading.Tasks.Task> PingAsync()
        {
            var 仮variables = new System.Collections.Generic.Dictionary<string,object>();
            var 仮reqParams = new System.Collections.Generic.Dictionary<string,string>();
            var 仮request = CreateRequest(System.Net.Http.HttpMethod.Post, "", 仮variables, 仮reqParams);
            var 仮response = await InvokeAsync(仮request);
            return await DHaven.Faux.HttpSupport.DiscoveryAwareBase.ConvertToObjectAsync<System.Threading.Tasks.Task>(仮response);
        }

Will fix.


Hotfix support

It would be nice if this module could also support the installation of hotfixes/packages during startup/installation by putting copying the hotfix zip files into the /crx-quickstart/install folder.
The list of files to copy into that folder could be provided in the aem::instance { 'aem' : } declaration.
What do you think?

I am all for this! Currently I'm working on supporting OSGi configurations as part of the pre-initialization process (putting the properties file in the ./install folder. I will look into this next.
However instead of providing the files as a list, i am thinking a custom defines/resource type, that way you can manage where the files come from. For example sourcing the file, you can supply:

file() type resource
packageshare keyword which requires Adobe ID Username/Password to lookup and d/l the file

Thoughts?

That sounds good to me. How is your progress on this?
Maybe the issue name should be changed to something like 'pre-initialization instal support'?

I'm wrapping up two other features. I think i'll have this done in the next week or two. I'm going to add it to the next release feature set though.

Hi,
We need this functionality.
Do you have any code done for this?
Maybe a base we can build onto...?

No work has been done on this yet.

I suppose i can start coding on this using the existing types/providers as examples and using rest endpoint /crx/packmgr/service.jsp, /crx/packmgr/service/.json and /crx/packmgr/service/console.html

This will come out with 3.0, but i do not have a project timeline on that at the moment.

Your comment suggests you have something near completion...
Should i just wait for that?
If you have nothing yet, do you object to accepting PR's?

I'll accept PRs, but the design for 3.0 will differ significantly from the current implementation; so it may not mesh with the planned changes. Hate for there to be wasted work.
Re: near completion? No, unfortunately not.

In wat way 'different'?
If you let me know, my work may not be 'wasted'.

I'm adding support for this for 2.4; the architectural changes for 3.0 will start to take effect with this feature. Those changes are to extract API calls from the providers into gems. To that end i have started the work on those gems. The one for this feature is here.


Doesn't work on Mac OS

./run.sh -stp
./run.sh: line 146: -8: substring expression < 0

when running ./run.sh -stp

I put update to resolve this problem.


Team page issue on mobile

tanzu.vmware.com/developer/team/whitney-lee endpoint does not render on mobile
Steps to reproduce the behavior:

Go to 'https://tanzu.vmware.com/developer/team/whitney-lee'
See error/page will not load

Smartphone:

Device: iPhone
Browser: multiple

@bryanfriedman Any thoughts? I'm stumped on this one. Can't recreate the issue. Makes it hard to pinpoint.


Add stem-plot

I would love a feature for creating stem-plots in Makie, as it is just the right visual for signals that are discrete in x-values (IMO). Could something like this be added? Possibly it would return two plot-object, one for the lines and one for the scatters (in addition to an axis and/or figure) - or one could bundle them together in a single object that has attributes of both a line and a scatter.
Examples of what I am talking about:
https://goropikari.github.io/PlotsGallery.jl/src/stem.html
https://se.mathworks.com/help/matlab/ref/stem.html
https://matplotlib.org/stable/gallery/lines_bars_and_markers/stem_plot.html
https://github.com/GiovineItalia/Gadfly.jl/pull/1076

Duplicate of #818. I think it would be fairly easy to make a pr for it if you or @Uroc327 want to try. You can check the docs for how to create recipes and compare to others in AbstractPlotting src/basic_recipes.

I tried to create a general (supporting 2D, 3D, all those attributes, sane default attributes and styles) recipe for a short while. As I had a really hard time to find documentation and examples that are existing and up-to-date and correct for this, I kind of stopped trying.
My last approach was someting like
# those are not strictly necessayr, but they allow to plot complex data as well.. yay
convert_arguments(::Type{<:Scatter}, coords::AbstractVector{<:Complex}) = (map(x -> Point(float(real(x)), float(imag(x))), coords),)
convert_arguments(::Type{<:Scatter}, coords::AbstractVector{<:Complex}, heights::AbstractVector{<:Real}) = (map((x, z) -> Point(float(real(x)), float(imag(x)), float(z)), coords, heights),)

@recipe(Stem, positions) do scene
	merge(default_theme(scene, Scatter), default_theme(scene, LineSegments))
end

function plot!(plot::Stem{<:NTuple{N, Any}}) where N
	y = p[N]
	lines = [Point(x..., (0, y)[i]) for (x..., y) in zip(p[1:N-1]..., p[N]) for i in 1:2]

	plot!(plot, Scatter, attributes_from(Scatter, plot), p[1:N]...)
	plot!(plot, LineSegments, attributes_from(LineSegments, plot), lines)
end

This is probably a good reference, since arrows do something similar.
https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/basic_recipes/arrows.jl

https://github.com/JuliaPlots/AbstractPlotting.jl/pull/643

does this look ok in terms of functionality (link should start working soon) http://makie.juliaplots.org/previews/PR643/plotting_functions.html#stemplot

does this look ok in terms of functionality (link should start working soon) http://makie.juliaplots.org/previews/PR643/plotting_functions.html#stemplot
or maybe this temp link https://refined-github-html-preview.kidonng.workers.dev/JuliaPlots/MakieDocumentation/raw/gh-pages/previews/PR643/plotting_functions.html#stemplot

That looks AMAZING! The offset kwarg is not something I have seen before, but it is super-cool. And the 3D stuff is very nice, good job!
Maybie one of the plots could be with everything default? That is the only thing I am feeling uncertain about in terms of looks.
I would also prefer to command to be stem as opposed to stemplot, as the commends don't typically end with "plot" in Makie (e.g. scatterplot or lineplot). I feel like it would be more consistent.
But for any more discussion, tag me over at the PR. I concider this issue closed. Thanks so much ❤

I just wanted to add the following quote from my homework this morning:
"Again, note that each sample amplitude is plotted using a vertical bar with a solid dot. This notation is well accepted in the DSP literatures."
Thanks again for the fast response and action <3

see that's why it's important to have different perspectives for this kind of thing. I've never needed a stem plot in neuroscience / psychology but it seems quite important in your field, so I'm glad to add it


Unhandled Promise

Issue Type

[X] Bug (https://github.com/ethjs/ethjs-contract/blob/master/.github/CONTRIBUTING.md#bug-reports)

Description
The method called here returns a promise, but that promise is then dropped on the floor.  When a failure occurs in the method, this results in an unhandled rejection error in node with a threat to crash the application in future versions of node.  I have argued with the node/chrome maintainers at length that this is an incorrect behavior and inappropriate usage of promises but ultimately they decided to prefer making node "easy for bad programmers" rather than "powerful for advanced users" and it doesn't look like they plan on changing this.  Because of this, all promises in a library should either return up the stack to the end-user or should be capped with a catch(...) before they are dropped.
Steps to reproduce

Instantiate a contract.
Call a method on that contract.
Have your Ethereum node return a failure like {"id":6604108303907,"jsonrpc":"2.0","result":"0x6864f52eba193e1b7d1b2eafddcf454dfb1568d756c5782d40efbc8c8857efbc","error":{"message":"VM Exception while processing transaction: invalid opcode","code":-32000}}

In my case, the error I get back looks like (though the error specifics shouldn't matter):
Error: [ethjs-provider-http] Invalid JSON RPC response from provider
    host: http://localhost:64891
    response:  ""
    responseURL: undefined
    status: 0
    statusText:

Versions

Node/NPM: v8.5.0/5.3.0

Peanut Gallery
This whole problem would go away if the library used promises all the way down rather than just faking it half of the time and using callbacks the other half of the time.  Also, if written in ES2017 you could use async/await which would make the code much easier to read.

Error: [ethjs-provider-http] Invalid JSON RPC response from provider
host: https://rinkeby.infura.io/
response:  ""
responseURL: undefined
status: 405
statusText: Method Not Allowed
how do i solve this ?


Fix draw polygons for mouse events on devices with touch screens - 2

I created this pull request but it included a change that didn't want to be merged into the original project. https://github.com/Leaflet/Leaflet.draw/pull/636
Undoing the change would have broken my repo and the github.io page liked to it which is useful for testing the fix. Thus I have created a new branch and a new PR.
This PR addresses a few different bugs.
https://github.com/Leaflet/Leaflet.draw/issues/631
https://github.com/Leaflet/Leaflet.draw/issues/637
https://github.com/Leaflet/Leaflet.draw/issues/624
This is my github.io page that shows the fix working. https://b3ncr.github.io/docs/examples/full.html

If this is getting merged to master do I need to add the build output to this commit?

Consider this comment my approval and +1 for what it's worth.

Here's another fix for the same problem we implemented in addVertex - also works in cases where the user accidentally adds two points in the same location:
addVertex: function (latlng) {
var markersLength = this._markers.length;
// If the last point clicked is identical to the this point, ignore it.
// This works around a bug where we get an onClicked and an OnTouch event (IE11, touch screens) when adding a vertex.
if (markersLength > 1) {
if (latlng.equals(this._markers[this._markers.length - 1].getLatLng()))
return;
}

this is not fixed for me in the current master/0.4.7 branches. I think possibly a regression has occurred, because the original fork of @B3nCr's branch did fix many issues for me, and the polyline file looks significantly different (particularly the _onTouch function). :\

There was another PR merged that fixed the same issue. I never tested their fix, I wonder if it overwrote my changes

@B3nCr yeah idk. i tried looking for your changes in the codebase and even the commit history for the polyline file, and was unable to, although it's possible I have a misconception of how github's interface works.

This was merged 4 days after my change. https://github.com/Leaflet/Leaflet.draw/pull/632/files
To be fair I always thought my change was a workaround and I've not tested that PR so I'm not 100% certain this was the issue but it's in the same area

Yeah, I'm pretty sure that regresses your fix, workaround or no, which basically renders IE/Android/iOS unusable for the respectively bugged draw shapes. I'll see if I can take a look at working on a PR this week as I'd like to continue using the main repo, but we'll see. @B3nCr

I guess this really needs more tests in that case as I assume both PRs passed all the existing tests. Could you write a test that fails?


Setting values

It would be nice to have an API that also allowed mutation.  Any interest?
Would you accept a pull request with such functionality?

Hm, I've been thinking a little about this but haven't been entirely sure how I would want it to work :)
Do you have any thoughts regarding an API design for it?

Mainly I was thinking about implementing Set... methods on Object.
I think it might be useful as well to define another type, Array which is basically an alias for []*Value.  That way, you have both Array and Object as distinct subtypes of Value.  I think Array would be useful in a writable context because then you could manipulate the array.  But you could, of course, always work with the existing []*Value type to accomplish the same thing.  The type alias would be mainly to define some "helper" methods on it.
Note that if you wanted to manipulate []*Values, you'd probably need some basic functions like NewValueFromString and NewValueFromInt64, etc. in order to have stuff to put into a []*Value.
Is that consistent with your thinking?

Okay, adding Set-methods on Object would probably be pretty straightforward. It could be a good start.
I think there is no great need for an Array type since I believe []*Value should cover most of the use cases, and it's simpler too.
Yes, the NewValueFromString, etc methods are probably needed.
I'd be happy to see you give it a go, hopefully it will turn and well, and we'll discuss around the new API methods before making them part of the the library. Remember not to break any of the existing API methods though :)

Here is an implementation of the NewValueFrom... functions.  Let me know if this is what you had in mind and I can finish up the Set... methods as well.

Thanks. Yes, it seems like a good start. Feel free to continue with the Set methods :)
I'm just a little curious why the NewValueArray method is needed. What's the use case?

I think with the current design this isn't possible actually (correct me if I'm wrong).
The issue is that no instance of Object is ever actually part of the real set of Value instances.  Said another way, whenever you have an Object, what you have is a "projection" of the Value onto a new value.  The result is that even if you do a SetString operation on an Object, the change is just in this temporary projection.  It doesn't propagate back to the original value.
I suppose you could keep some kind of pointer back to the original value and change it as well.  But that seems a) very complicated and b) quite risky.
The irony is that I actually implemented all the functionality and then only realized this issue when I started writing the tests.

Hm, the object contains both the original value (data) and a copy in a map (m). I don't remember exactly why values are copied from the original value to the map, but it may have something to with not avoiding a lot of later typecasting, although that may not even be true.
Try setting the value to both the data and m and see if that works better?
https://github.com/antonholmquist/jason/blob/master/jason.go#L714-725

The problem is here:
https://github.com/antonholmquist/jason/blob/master/jason.go#L711
You are just creating a new Object and returning it.  Yes, you can change the values of obj.data and obj.m.  That isn't the problem.  The problem is there is no connection back to v.  If you change obj, you are only changing the value of a temporary that is used only by the consumer.  You have no way to change the original data structure (v).

Not sure whether this is proper github etiquette, but I wrote a library very similar to jason about a year ago which has support for this: https://github.com/Jeffail/gabs

Closing this due to inactivity


Add jsonapi rb benchmark test

As mentioned in https://github.com/Netflix/fast_jsonapi/issues/12 and https://github.com/Netflix/fast_jsonapi/issues/44, added benchmark test with jsonapi-rb
It's hard to make direct comparison, because jsonapi-rb renders relationships only when we include.
e.g.) AMS / fast_jsonapi render movie class without including =>
  {
    ...,
    "relationships" : {
      "actors" : {"data":[{"id":"1","type":"actor"} .... ]},
  }

jsonapi-rb render movie class without including =>
{
  ...,
  "relationships" : {
    "actors" : { "meta" : { "included" : false } .... ]},
}

Benchmark results x 1000

Serialize to JSON string 1000 records
Serializer      Records    Time
AMS serializer  1000       369.62 ms
jsonapi-rb serializer 1000       32.99 ms
Fast serializer 1000       10.31 ms

Serialize to JSON string 1000 with includes and meta
Serializer      Records    Time
AMS serializer  1000       509.1 ms
jsonapi-rb serializer 1000       91.17 ms
Fast serializer 1000       20.82 ms

Can you share benchmarks results here? 😊

would it make sense to have additional comparisons?
with / without includes?
with / without sparse fieldsets?
with / without relationships (specifically belongs to / has many / both) ?

I think it'd also be interesting to see how this interacts with ActiveRecord. Looking at the has_one 'extension', it looks like it's doing object.relationship.id, which may or may not cause a DB hit, which wouldn't be required if the foreign key is already on object, ya know/

@grossadamm fwiw, I did some goofy shell comparison of serializations (jq and diff) in https://github.com/rails-api/active_model_serializers/blob/benchmarks/benchmarks/serialization_libraries/compare.sh

The shell comparison are super valuable. When I initially did a jsonapi-rb vs AMS comparison, I didn't take into consideration the different default outputs.
A true comparison should have as-equal-as-possible json outputs.

@minsikzzang Thank you this is super helpful.


⚠ GitLab Server has degraded performance

In a3a00d3, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11493 ms

Resolved: GitLab Server performance has improved in 981336c.


bib2fastread.py should filter by entry type

bib2fastread.py should filter by entry type. For instance, you may want to export only @inproceedings and @article entries, ignoring everything else (such as @proceedings and @journal). This will avoid creating a .CSV with entries that are not useful for FastRead.

I have just added an option to filter the entry types to be considered when importing data.


Refactored the generatePassword function

This PR refactors the password generator function.
The changes are directly backwards compatible with the existing version, but is (in my opinion) easier to read and understand, it should also not produce any errors unless someone tries to have it generate a password that is literally impossible.
This code is capable of generating a 4 character password that includes an uppercase, a lowercase, a number, and a special character within the allowed 100 iterations so we should never have that limit be hit in a real world application unless the provided params are impossible (requiring a special character with only a 3 character length).
Closes #2130.

Nice work - much cleaner! 👍

Agreed, I think it's far more readable now even if it's still not perfect


Adding a --sheetindex parameter

By default, the utility shows the 0th page. Would be much more flexible with a --sheetindex option to show an arbitrary page. The question remains whether to tell the user to count from zero or one.

Solved, among other issues, by @digital-steez in https://github.com/digital-steez/x_x/commit/c4b7036477d378c00a8c8eefb522d82ee4d33d88


dont know how to use

download checkpoints,but dont now how to use to get the performance in the introduct

Can you get the performance in the introduction now? I tried to use 'options/test/EDSR/test_EDSR_Mx4.yml'，but it seems not the correct yaml file.

Just load the model using the model class defined in span_arch.py. No yml needed.
When I use their codes, I normalize the image as in their codes, but don't do de-normalization and just clip the output to [0, 1]. By doing so, the output looks good to me.


Cards for support pages - https://www.octoral.com/en/support/

Already taken care via https://github.com/aemsites/octoral/pull/89


Use directed graph in block merging criteria

Description
Replaces has_disallowed_write_after_read_in with has_write_after_read_with_offset and has_cycle_with_parallel_axis_offset that use a rudimentary field dependency graph. This PR does not attempt to replace the "info" infrastructure that has been put into place, since effort should be focused instead on the GTC backends.
The limitation of the current system is that they work on the block level, so they do not capture the finer-grained statement-level dependencies that a field dependency graph can, and are used in conjunction with checking stage extents, which does not always work with horizontal regions.
We found this when creating the new horizontal-regions branch, where the existing logic actually causes this stencil to generate a single multistage, causing the GT backends to generate invalid code (triggering a static assert in GridTools C++).
def example(field: Field[float]):
    with computation(PARALLEL), interval(...):
        tmp = field[0, 0, 0]
        with horizontal(region[I[0], :]):
            field = tmp[1, 0, 0] + 1

It does this because the horizontal region did not trigger a stage extent, so target.has_extended_domain evaluated to False, though if with horizontal(region[I[0], :]) were replaced by a traditional control flow statement like if field < 0.0 (or similar) this would have worked correctly. So, this change in the algorithm is critical when adding horizontal regions.
This change flips an existing test from creating two to one multistage, so it has already proven to be more aggressive, which should help performance (and correctness) of the GT backends.

Tox tests should pass after merging #369

After thinking about this today for a while, I realized that due to a few misunderstandings about how the merging works, I was actually able to re-use the existing infrastructure very well. In fact, there is only one more check necessary, and this PR adds it.
This adds a check there is no read with offset on a parallel axis after writing to an API field (note that for temporaries this check does not apply). Before this, there was only a check on all fields that there was no read with sequential axis offset after write.
Does this sound correct?

After thinking about this today for a while, I realized that due to a few misunderstandings about how the merging works, I was actually able to re-use the existing infrastructure very well. In fact, there is only one more check necessary, and this PR adds it.
This adds a check there is no read with offset on a parallel axis after writing to an API field (note that for temporaries this check does not apply). Before this, there was only a check on all fields that there was no read with sequential axis offset after write.
Does this sound correct?

Sounds good. One open PR in the parallel model description actually addresses exactly this issue: https://github.com/GridTools/concepts/pull/39

I just pushed one more change that expands things and cleans it up, but the commit is failing on some tests, so it still needs work. Perhaps if one of you has a chance to look today you can catch my mistake.

I'm happy with how this looks and it seems to be passing all tests (here and in our dynamical core) so it's ready for another review when you have time.

bors try

bors try

bors try-
bors try


[stable/prometheus-operator] Readme update of kube-proxy metrics bind address, pointing to multiple possible cm locations.

Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
Pointing out the possibility that kube-proxy config.yaml might be in a different configmap. Related to https://github.com/coreos/prometheus-operator/issues/2757
Which issue this PR fixes

fixes #

Special notes for your reviewer:
Just a minor docs update. Hopefully saves people some time (outweighing the review effort).
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

The tests will keep failing until one of these can be done:

https://github.com/helm/charts/pull/18271
https://github.com/helm/charts/issues/18310

/lgtm
Could you please bump the chart version?

Done. Tagged from 8.1.2 to 8.1.3.

/lgtm


Create discord-rare-drop-notificater

Plugin for automatically posting detailed loot notifications and screenshots to Discord using webhooks when receiving a rare/unique drop. Configurable rarity/value threshold. Activities (Barrows, CoX etc.) and pets supported.

This does not compile.
/tmp/external-plugin.s4QhGWEJ/repo/src/main/java/com/masterkenth/RarityTables.java:31: error: cannot find symbol
import static java.util.Map.entry;
^
  symbol:   static entry
  location: interface
  where K,V are type-variables:
    K extends Object declared in interface Map
    V extends Object declared in interface Map
/tmp/external-plugin.s4QhGWEJ/repo/src/main/java/com/masterkenth/RarityChecker.java:61: error: cannot find symbol
      log.warn("No event table for '" + eventName + "'");
      ^
  symbol:   variable log
  location: class RarityChecker

You need to pin your dependencies.

You need to pin your dependencies.

I've followed those steps and there is a gradle/verification-metadata.xml in the repo, unless I'm missing something else? Re-running the command gives me no file changes to commit.

Apparently i missed it, sorry about that. That's correct then.


Remove unused psr/log and stop allowing EOL dependencies.

psr/log seems to be unused. I also dropped support for versions of Symfony that are EOL.

I can confirm that everything still works fine after introducing this change into our project.


Suggested README update

Might I suggest to mention in the ReadMe something along the lines of:
Suggested README change:
The value for "YOURSERVICEID" must be between 1-15 chars.
The regex in MethodChannelNsdPlatform only allows only 1 to 15 characters between the underscore (_) and the period (.).
Also the value you choose for "YOURSERVICEID" must only contain (a-z A-Z 0-9) that is alphabetical chars lower or uppercase and 0-9, no special chars or anything fancy like that.

Reason for change:
I just spent a fair amount of time trying to figure out why I was getting:
E/flutter (32229): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: NsdError (message: "Service type must be in format _<Service>._<Proto>: _MT_TEST._tcp", cause: illegalArgument)

It ended up being that the ServiceID I had arbitrarily chosen was 17 chars, 2 chars over the hidden limit.

Also it was a bit unclear on how the info.plist should be used. Likely because of my inexperience with tcp permissions in iOS but it might help to clear it up.
Suggested README change:
Add the following permissions to your Info.plist:
Note: Remember to replace YOURSERVICEID with your own following the rules about creating YOURSERVICEID found in this README.
<key>NSLocalNetworkUsageDescription</key>
<string>Required to discover local network devices</string>
<key>NSBonjourServices</key>
<array>
    <string>_YOURSERVICEID._tcp</string>
</array>

Hi!  Sorry; I just figured out how to see a list of issues raised on any of my repos.
I've added a YOURSERVICEID section to the Readme - would that have been sufficient to save you the trouble, in your case?
Re: info.plist, it looks like I already made an associated correction at some point after you opened this issue (which I don't think I saw, sorry).
Are these changes sufficient, do you suppose?

Yes those changes look great to me, hopefully will help the next person!
Very thankful for your work putting this repo out there!
I am putting together a little utility app for my DnD DMing and this was just the thing I needed.


Fix variable name

Should fix #12

Looks good more me. I'm merging this.

Awesome, thanks! :)

a 0.1.9 version is pushed to rubygem, i will tag the project later today