ENH: find_blinks (pupil)

closes https://github.com/mne-tools/mne-python/issues/12808

This PR is currently a draft to discuss an API for a potential find_blinks function that works on eye-tracking data.
Comments welcome -- I would also be happy for pushes to this branch, but if nobody will, then I may eventually get to implementing this, too.
to do

[ ] consensus about API
[ ] add function proper
[ ] add test
[ ] show use in example

@larsoner @britta-wstnr @mscheltienne @sappelhoff @drammock @AlexLepauvre @qian-chu @scott-huberty
what do you think of this suggested API?

Hello everyone, apologies for the radio silence. Myself and @qian-chu got a bit sidetracked over the past few months. I will get back to it next week and follow the recommendation laid out above to bring this PR further :)

Since blink detection is usually based on pupil data, do you also think it makes more sense to put find_blinks() under _pupillometry.py?

would be fine by me, too.


[Android][Espresso] Test runs with @Parameterized tests are marked as failed.

Describe the solution you'd like
AppCenter should be able to properly read parameterized test results.
Additional context
At the moment test runs that contain parameterized tests are marked as failed, altho all tests passed. It looks like the tool is not able to properly read the report, thus it marks the entire run as failed (See the console output below):
...

INSTRUMENTATION_STATUS: numtests=19
INSTRUMENTATION_STATUS: stream=.
INSTRUMENTATION_STATUS: id=AndroidJUnitRunner
INSTRUMENTATION_STATUS: test=someTestFuncName
INSTRUMENTATION_STATUS: class=some.package.name.SomeTestName
INSTRUMENTATION_STATUS: current=19
INSTRUMENTATION_STATUS_CODE: 0
INSTRUMENTATION_RESULT: stream=

Time: 481.489

OK (18 tests)

INSTRUMENTATION_CODE: -1

All tests were running previously on Firebase locally on similar devices and where passing.
Disabling the parameterized tests makes the test run pass, and the report is properly read.

Any news on this issue?

We would like to get a better understanding of your test suite, so can you share a link to a recent test run so we can have a closer look? Alternatively start a support ticket via the blue chat bubble on the bottom left or from the question mark icon on the top right in App Center?

@sejr-lotutovici Did you get help?

@serj-lotutovici did chat help you?

Yes, I did. Sorry for the long reply.


能获取到丢包率吗

能获取到丢包率吗

imcp 不支持
2017-11-29 16:42 GMT+08:00 javavaan<EMAIL_ADDRESS>
能获取到丢包率吗
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dawei101/shadowsocks-android-java/issues/57, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACK1MTUncRB6XuSFwAd60F3rVbRJxYq6ks5s7RjtgaJpZM4QumX1
.


Joining external machine with no docker to Rancher managed network

Rancher Version: v1.2.0-pre3
Docker Version: 1.12.1
OS and where are the hosts located? (cloud, bare metal, etc): Ubuntu 16.04.1 LTS (with KVM)
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node rancher, internal DB
Environment Type: (Cattle/Kubernetes/Swarm/Mesos) Cattle
Hi,
I have Rancher deployed on one of my servers and it manages a set of 4 rancher hosts.
There is also a selenium grid instance (hub + 4 chrome + 4 firefox nodes) deployed to rancher + many temporary short-living instances of my web application (deployed on each commit for this test run only) that are getting tested with this grid. There can be multiple instances of my application deployed that are tested at the same time (when developers do frequent commits).
Hub node is exposed to the public world via port 4444, so I use the url to http://myhost.internal.corp:4444/grid/console to access it and view the list of browsers connected to it.
All selenium nodes, hub node and applications are deployed to the same rancher environment, so they share the same Rancher's managed network and can ping each other.
Thus I do not expose any ports of my web application on the running host, but I use internal rancher's DNS to point selenium nodes to the currently tested web site. So in fact each node opens a browser and types into the url something like that: http://web.test-run-34.rancher.internal/ where 34 is the number of the build (read: commit)
I want to enable testing of my application with Internet Explorer (or any other non-linux/non-rancher compatible environment, android for example).
As I have grid exposed at http://myhost.internal.corp:4444/grid/console I see the possibility to connect additional selenium nodes that run on external hosts (that are not managed via Rancher) to it.
But those nodes will not have access to internal web application instances via the url http://web.test-run-34.rancher.internal/ as they are not joined to the Rancher's internal overlay network.
I see 2 solutions for it:

Adjust the testing procedure to expose web application to the public world and let Rancher choose the port and host for my web application.
It means that instead of using http://web.test-run-34.rancher.internal/ I should wait Rancher to deploy the application for me and query it for the name of the host and the port that it assigns to my application. Then I should use the url of the form: http://some-of-rancher-hosts.internal.corp:54623/
Join external machine (possibly running Windows) to Rancher's internal network for that environment so that it could ping any instance of application using url http://web.test-run-34.rancher.internal/

Before taking the 1st path I want to know if it is possible to follow the 2nd path

solution 1 sounds like the best bet. I'll close this issue out, feel free to reopen if you have further questions.


Cannot build with frameworks: KSCrash/KSCrashAdvanced.h file not found

I'm integrating Bugsnag 5.0.2 via CocoaPods with a Podfile set to use_frameworks! and get a compiler error when compiling Bugsnag:
Pods/Bugsnag/Source/Bugsnag.m:32:9: 'KSCrash/KSCrashAdvanced.h' file not found

The issue does not occur when building static libraries, i.e. with use_frameworks! removed from the Podfile.
It appears that KSCrashAdvanced.h is a private header in KSCrash 1.0.1. Starting with kstenerud/KSCrash@0114ae0, only certain headers are public in KSCrash. This was noticed and fixed in kstenerud/KSCrash#124 by adding a KSCrash/Reporting/Advanced subspec. However, a new version of KSCrash has not yet been published.
I believe to fix this:

A new 1.0.2 version of KSCrash will need to be published
Bugsnag will need to be updated to include a KSCrash/Reporting/Advanced dependency at version 1.0.2

Alternatively, since KSCrashAdvanced.h wasn't private in version 1.0.0 of KSCrash, this could potentially be resolved by downgrading the dependency to allow that version, but I'm not sure if anything was changed in 1.0.1 of KSCrash that Bugsnag depends on.

Okay, version 1.0.2 of KSCrash was tagged, but the changes to its spec in 1.0.2 now have caused it to not build with use_frameworks!. I'll look into that some more.

:tada: wooh with the kstenerud/KSCrash#127 PR I opened I'm finally able to build with frameworks!
Working podfile looks like:
platform :ios, '8.0'
use_frameworks!

target 'PodsTest' do
  pod 'Bugsnag', '5.0.2'
  pod 'KSCrash/RecordingAdvanced', :git => 'git@github.com:SSheldon/KSCrash.git', :branch => 'frameworks_advanced'
end

Awesome work, @SSheldon. Thanks for looking into this. I'm taking a look at fixing #100 and shipping a patch release for this along with it. Hopefully now the subspecs are divided as needed.


WorkGroup

Hi,
in the video you've explained about the domain joined laptop which open portal page and sign-in is not required, excellent.!! :)  i had a question on this, how about the workgroup machines ? will they still be able to access the apps and o365 (forget about single sign on, am considered about services, if any of the user whose identity is in on prem AD and Azure AD, but he's trying to authenticate on portal.office.com with his on prem AD credentials using workgroup PC , will he be able to sign-in ?? )

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

ID: e4e5a986-727e-a83d-568f-304ec86caef3
Version Independent ID: 8d384088-0ae0-d111-a10b-173720a9106b
Content
Content Source
Service: active-directory

Thanks for your feedback. We will investigate and update on it soon.

Thanks for your comment. If you  have a setup on AD Connect and agent installed for Pass Through Authentication, when you access application request will go to AAD and password will get validated from on-premise AD. If the machine is connect to network which can reach AAD, the authentication must work as expected.

@aircelgag -> For the workgroup machines which will not able to communicate the domain controller directly on these type of machines, user's are prompted to enter password.
Process :-
User request will land to login.microsoftonline.com --> The request will be sent to the sync server --> The connector will be listening to these incoming requests and the authentication will be completed.
You can check the below mentioned link to check how this feature works.
https://www.youtube.com/watch?v=kRPExiS4EwI&t=7s

We have sSSO enabled. On a domain connected machine when we try to access the application we still see a prompt to select the user name (not happy) however, it does not ask for a password (happy). Why we are prompted for a username on domain connected machine ? Is that an expected behavior ?


chore: Set permissions for GitHub actions

Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.

Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests
Signed-off-by: naveen<EMAIL_ADDRESS>

Thanks for your contribution! Please have a look at the code contribution workflow that describes how the commit message is expected to be formatted.
Instead of chore:  as prefix, you probably want to use ci:  in the subject of the commit. You should also use your full name and real email address in the Signed-off-by line.

Thanks for your contribution! Please have a look at the code contribution workflow that describes how the commit message is expected to be formatted.
Instead of chore:  as prefix, you probably want to use ci:  in the subject of the commit. You should also use your full name and real email address in the Signed-off-by line.

Thanks, I have changed it to ci and that is my real name  in the signoff. I use github email for signing my commits.

Thanks for the update!
There are 10 files modified, but it seems we have 11... The retest.yml was missed, this workflow checks for the CI status, and leaves a comment in the PR to retest failed jobs. Could you add that one too? (And maybe rename to .yaml instead of .yml.)

Took care of it. Thanks

@naveensrinivasan can you please fix CI failure (commitlint).

It seems the first paragraph and the URLs are a little long... The following should pass commitlint:
https://github.com/nixpanic/ceph-csi/commit/ab9f410377a5e2efc1a970214a658d631984d93d
@naveensrinivasan, if you want me to take car of this, let me know and I'll push an update to this PR (or create a new one).

It seems the first paragraph and the URLs are a little long... The following should pass commitlint:
nixpanic@ab9f410
@naveensrinivasan, if you want me to take car of this, let me know and I'll push an update to this PR (or create a new one).

I have fixed the commit message length. Thanks

TBH this is a lot more work than the actual PR.

Yeah... it usually is not such a problem. I'm sorry you have to spend such a lot of retries on this. We appreciate your contribution a lot!

TBH this is a lot more work than the actual PR.

Yeah... it usually is not such a problem. I'm sorry you have to spend such a lot of retries on this. We appreciate your contribution a lot!

👍

@mergifyio requeue

@mergifyio rebase

hey @naveensrinivasan,
Can you click on the following to allow mergifyio access to rebase the pr on top of devel?
We use mergifyio extensively and only rebase and merge  prs with on top of latest devel changes.
Please call @mergifyio rebase after doing so, thanks

@mergifyio rebase

It seems the first paragraph and the URLs are a little long... The following should pass commitlint:
nixpanic@ab9f410
@naveensrinivasan, if you want me to take car of this, let me know and I'll push an update to this PR (or create a new one).

I have fixed the commit message length. Thanks

@nixpanic  Ther mergify is having issues. Could you please do the same as you did to the other PR? Thank you! 🙏

@Mergifyio rebase

@Mergifyio rebase

I guess you would have to pull my commit into another PR similar to the other one! AFAIK. Thank you!

I guess you would have to pull my commit into another PR similar to the other one! AFAIK. Thank you!

Yes, maybe. I'll keep an eye on this and will get to it later today. Thanks for your patience!

PR #3096 is a replacement for this, please review that one :)


Is it possible to use fractional numbers on rarity?

Hi!
Is it possible to use fractional numbers on rarity?
For example: Item#2.8

No It's not possible unfortenuly but i think i'm going to implement a weighted rarity system. I don't know when i will do that because currently i'm a lot busy with the University


Fix frequency plot

Description

Details
URL to issue
https://biomage.atlassian.net/browse/BIOMAGE-1812
Link to staging deployment URL (or set N/A)
https://ui-martinfosco-ui687.scp-staging.biomage.net/
Links to any PRs or resources related to this PR
Integration test branch
master

Merge checklist
Your changes will be ready for merging after all of the steps below have been completed.

Code updates
Have best practices and ongoing refactors being observed in this PR

[ ] Migrated any selector / reducer used to the new format.

Manual/unit testing

[ ] Tested changes using InfraMock locally or no tests required for change, e.g. Kubernetes chart updates.
[ ] Validated that current unit tests for code work as expected and are sufficient for code coverage or no unit tests required for change, e.g. documentation update.
[ ] Unit tests written or no unit tests required for change, e.g. documentation update.

Integration testing
You must check the box below to run integration tests on the latest commit on your PR branch.
Integration tests have to pass before the PR can be merged. Without checking the box, your PR
will not pass the required status checks for merging.

[ ] Started end-to-end tests on the latest commit.

Documentation updates

[ ] Relevant Github READMEs updated or no GitHub README updates required.
[ ] Relevant Wiki pages created/updated or no Wiki updates required.

Optional

[ ] Staging environment is unstaged before merging.
[ ] Photo of a cute animal attached to this PR.

Have you checked if this issue happens in other plots as well?


FastReport base path is not correct in iis.

I have my .net core 3.1 project published on IIS.
However, the report doesn't work correctly.
I have errors like 404 not found. (but it works perfectly both on another VM and my local machine.)
The only difference is that the error one is published under Subfolder.
However, the base path seems wrong which not target the right folder.
e.g.
it should be something like   www.abc.com/[webName]/_fr/reference....
but it shows   www.abc.com/_fr/reference  ....
I tried to use  app.UseFastReport(options => options.RouteBasePath = "/[webName]/_fr");
but it didn't work....
I need your help on this.

Hi, I'm working with net core 3.1 and the report works fine in my local visual studio. But, when I publish the project on my web site I get the error "404 not found" when WebReport.Render() is triggered. Could you solve this error?
Thanks and regards

Duplicate #186 . We will increase the priority of this task

Duplicate #186 . We will increase the priority of this task

thanks


Workflow - New Objects Missing Oid

I have a ChangedWorkflow setup. For an existing object it works wonderfully, but for a new object, I get an entry in the [ObjectChangedXpoStartWorkflowRequest] table, but the TargetObjectKey is [Guid]'00000000-0000-0000-0000-000000000000'
Because of this, my workflow does not know which object to work on. Is this the intended behavior?
Thanks.

did you tried to init the guid?
some thing like
BaseObject.OidInitializationMode=OidInitializationMode.AfterConstruction ??

Yes, OidInitializationMode.AfterConstruction is the setting in my Module constructor.

I am not sure whats going on but you can init the field manually
youobject.SetMemberValue("oid",Guid.NewGuid())

That worked great. Thanks.


Enable 'Unsafe Mode' in CLI

Etcher version: 1.0
Operating system and architecture: Windows 10 x64
Image flashed: ext4 image written to mSATA drive via USB enclosure
Do you see any meaningful error information in the DevTools? As I am using the CLI, the DevTools are not an option. But I can say that since the mSATA drive is not considered a removable device inside Windows, it does not show up as an available drive in the CLI. I can write to it fine via the GUI if I enable Unsafe Mode.

The ability to pass in a flag to enable Unsafe mode would resolve this issue. The GUI does not fit into our workflow, which is why we would like to see this feature in the CLI.
Thanks!

Hi @Stuka87,
Thanks a lot for reaching out. Looks like the interactive drive selector widget doesn't allow us (we'll fix it soon!), but you should be able to use --device just fine.
Let us know how it goes!

I guess if the device passed with --drive is detected as a system device, maybe we should also ask the user for a confirmation (after displaying a bit of info about the drive), unless the --yes flag was passed?
Also, @Stuka87 suggested in gitter that it'd be useful for the examples output by --help to be tailored to the OS on which the Etcher CLI is actually running.

As an update, specifying the drive directly does work with the CLI in its current form. Although it should be noted etcher.exe must be run from cmd. If it is run from a PowerShell prompt it will error out, this is mostly likely due to an encoding difference with PowerShell and the drive path that gets passed in. I did not spend too much time digging into a fix, as running from cmd is fine for this use case.
For the time being, I am using the standalone drivelist node module to grab the current list of drives, and then parse that to find the drive I want to write the image too.


Bad HDH Markets To Go Menu Link

The menuWebsite url being fetched for Village and John's market is bad.
Comparing to other to go menu urls it isn't super wrong.
Bad: http://hdh.ucsd.edu/DiningMenus/MarketsToGo.pdf (This just goes to hdh menu website)
Good: https://hdh.ucsd.edu/DiningMenus/MarketsToGo.pdf (This actually goes to the pdf)
Fixing on gitlab

@a6wu Lambda for dining-service needs to be updated

Completed


Is qy_graph correct?

Hi Rui, I was reading your blog and found it very helpful to my understanding of the CVAE paper. Related to the GMVAE you experimented in the end, I found the implementation might have some issues. To be more specific:
the qy_graph (code copied and pasted below)
def qy_graph(x, k=10):
    reuse = len(tf.get_collection(tf.GraphKeys.VARIABLES, scope='qy')) > 0
    # -- q(y)
    with tf.variable_scope('qy'):
        h1 = Dense(x, 512, 'layer1', tf.nn.relu, reuse=reuse)
        h2 = Dense(h1, 512, 'layer2', tf.nn.relu, reuse=reuse)
        qy_logit = Dense(h2, k, 'logit', reuse=reuse)
        qy = tf.nn.softmax(qy_logit, name='prob')
    return qy_logit, qy

returns the distribution parameter of p(y) qy which is the mean of p(y). Following this graph, the generative process of the model becomes
y = E[p(y)]
z ~ N(mu_z(y), var_z(y))
x ~ Ber(mu_x(z))

instead of what is stated in the blog:
y ~ p(y)
z ~ N(mu_z(y), var_z(y))
x ~ Ber(mu_x(z))

.
Is my understanding correct?

Closed after seeing your reply here.


leveldb library added

The Leveldb library and wrapper functions are added.
The leveldb_wrapper can be applicable for other lsm-tree based storage engine.
Please see the comments in  wrappers/leveldb/CMakeLists.txt

It seems tests are failing - any ideas?

It seems tests are failing - any ideas?

The snappy and numa library are not prepared,
It should check library existence first, and link those libraries to wrapper function.

Thanks for the contribution, I started reviewing the changes, but since there are some commits that undo initial changes, it will be confusing to read my comments.
Could you make a new Pull Request with a single commit with all changes?
Then I will make my comments on the new PR and we can work together to fix the build errors.
For the future, you can use git commit --amend to edit the last commit and avoid creating new ones. Keeping a single commit per Pull Request makes it easier to review :)

@llersch sorry for duplicate commit request, I will make a new PR.


chore: zeebe-operator to 0.0.40

chore: Promote zeebe-operator to version 0.0.40

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Feature: Add separate damage for same AOE and multiple target damage. And maybe support for half-damage

For example when a burning hands hits 3 target with for full 10 damage make it log 30 damage instead of 10. If its 2 fail and 1 save then 25 damage instead of 10.
Maybe possible solution sugestion 1: Instead of loging damage from chat rolls loging changes in HP for all tokens after aoe or mulitple target damage rolled and then using it as damage for the attack.
Maybe possible solution sugestion 2: Adding promt button to chat after AOE or multiplte target spell where only DM can access to enter saves counts (full damage, half damage, no damage).

Thanks for this suggestion, its ace. Out of interest, do you use midi-qol? I am trying to support as many integrations as possible while maintaining feature parity hence the chat message log. I think your suggestion of monitoring the tokens damage may be the way forward for users who dont use midi-qol for targeting, etc


Temp/file_01.tmp problem

In scanning screen when I connect to a device, push to another page, "lose connection"(not manually disconnect), detect it via  "connectionStreamOf" push back(or pop)to scanning screen I get this error. Actually, many scenarios leads to this error.
Restarting the app (manually or programatically) solves the problem.
 Unhandled Exception: PathAccessException: Cannot open file, path = 'C:\Users\xyzuser\AppData\Local\Temp/file_01.tmp' (OS Error: The process cannot access the file because it is being used by another process.

 Unhandled Exception: PathAccessException: Cannot open file, path = 'C:\Users\xyzuser\AppData\Local\Temp/file_01.tmp' (OS Error: The process cannot access the file because it is being used by another process.

are you on older version ?
new version of library have ble_server.exe instead of file_01.tmp

I think I'm on 1.0.1

I think I'm on 1.0.1

please try with 1.0.2


Flakiness in CentOS 7 Linux package repository, encountered >5 times per day

Ok so I am running into this over five times a day, each time it seems to work if I try again in a few minutes. It's turning out to be a major productivity problem when we have multiple image builds per day on cluster - each one has to be manually checked and rerun when they fail. I am just wondering if the RPM repo will ever be reliable:
Downloading packages:
https://packages.microsoft.com/centos/7/prod/netstandard-targeting-pack-2.1.0-x64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=packages-microsoft-com-prod clean metadata
Trying other mirror.

Error downloading packages:
  netstandard-targeting-pack-2.1-2.1.0-1.x86_64: [Errno 256] No more mirrors to try.

Originally posted by @yoshiya8 in https://github.com/dotnet/core/issues/4280#issuecomment-589175267

I wonder if you are possibly getting routed to a broken/unhealthy mirror vs. a healthy one. We recently discovered that the package repos can have per-mirror problems and the repo owners don't have a way to find the issues by themselves yet. (https://github.com/dotnet/core/issues/4236, very scary. We're following up the best we can with the service owners as part of the general push for reliability tracked at https://github.com/dotnet/core/issues/4167.)
@yoshiya8 do you have IP addresses packages.microsoft.com is being resolved to in your logs? That could be used to tell which mirror cluster you're using and help the repo owners narrow down their search, if this is indeed the problem.

$ping packages.microsoft.com
PING apt-eus-d.cloudapp.net (<IP_ADDRESS>) 56(84) bytes of data.

Then hangs

Interesting, thanks for the details. Yeah, it's actually easy to repro even outside the region using the IP:
$ while :; do wget --no-check-certificate https://<IP_ADDRESS>/centos/7/prod/netstandard-targeting-pack-2.1.0-x64.rpm; done
...
$ for x in net*; do echo "$(md5sum $x | cut -d' ' -f1 ) $(wc -c $x)"; done
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm
8214edb8e45e49e909fcf4def15bd110 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.1
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.10
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.2
8214edb8e45e49e909fcf4def15bd110 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.3
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.4
8214edb8e45e49e909fcf4def15bd110 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.5
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.6
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.7
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.8
403fff7fe128c636d71c082086fe6a3b 2201944 netstandard-targeting-pack-2.1.0-x64.rpm.9

@NikolaMilosavljevic is passing this along to the linux repo owners to get fixed, we'll update here once they've tried something. They were able to manually fix up the mirroring last time.

This issue was fixed yesterday, by repo owners - all mirrors have correct files now.
@yoshiya8 , have you experienced any more instances of this issue?

Closing the issue as there has been no more reported instances.


Bumped Django version

Pull Request Test Coverage Report for Build 59

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 57:
0.0%

Covered Lines:
640

Relevant Lines:
640

💛  - Coveralls


add support for fedora39 installer

https://packages.adoptium.net/artifactory/rpm/fedora/39/ is missing

Please add support for Fedora 39. I updated my machine since it is the current Fedora release but then I realized that there is no repository for it.

You could try https://packages.adoptium.net/artifactory/rpm/fedora/38/  in the meantime while they add support

I believe there is now SELinux
https://guix.gnu.org/en/manual/devel/en/html_node/SELinux-Support.html.
The binary installer implements the approach which, admittedly, has some
drawbacks per the manual page I linked.
My intention is to remove Guix from my Fedora machine and try this new
updated installer.
Cheers! afm
On Tue, Dec 12, 2023 at 2:28 PM GalaxyVOID @.***> wrote:

You could try https://packages.adoptium.net/artifactory/rpm/fedora/38/ in
the meantime while they add support
—
Reply to this email directly, view it on GitHub
https://github.com/adoptium/installer/issues/739#issuecomment-1852913691,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOVVOOIKXVSHNPSCFLTAGTYJDLA3AVCNFSM6AAAAAA5DRWPQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJSHEYTGNRZGE
.
You are receiving this because you commented.Message ID:
@.***>


Fix Off By One Error To Trigger PoS Consensus

Current dependencies on/for this PR:

feature/pos-syncing-and-steady-state

PR #924   👈

This stack of pull requests is managed by Graphite.


Update dandevri.json with CTA

Joining the Eleventy Super Professional Business Network!
https://www.11ty.dev/news/espbn/

Thanks!


Use AttachThreadInput to be able to workaround the SetForegroundWindow bug (Issue 1039 #2)

Summary of the Pull Request

Use AttachThreadInput to be able to workaround the SetForegroundWindow bug. More info is in the issue. The same fix could be also applied to ImageResizer and other context menu tools.
Do not kill explorer for MSIX (separate commit)

PR Checklist

[x] Applies to #1039

Validation Steps Performed
As described by Raymond Chen, the main issue with attaching the input queue of another application, is that our thread could hang with the application we've attached to. To aid testing, I've developed a small test application which works in tandem with PowerRenameExt:

it locks a named mutex when launched
PowerRenameExt waits for this mutex to be unlocked until I've pressed a button in small application window: it stops the message pump loop (now we've "stopped responding") and unlocks the mutex. Pressing the button also brings the test app to the foreground.
PowerRenameExt attaches itself to the foreground thread from a different thread, which is killed after 10 seconds in case of hanging.

Actually, I've observed that even though I didn't process intentionally any messages in the test app, PowerRename didn't hang. Even though, we create a separate thread just in case. In the worst case scenario, we'll just remain in the background.

Talking with @enricogior, we should think about how we keep deal with the scenario someone doesn't have the OS patch.  Thought was after like 1 second, we detect if we're not in the foreground and if we aren't, we do the hack after the patch has been serviced.  We also talked about maybe making this into a setting.  Just something in the back of our heads we should think about when we have to migrate this out.

I've tested the new workaround and it works as expected.
When selecting a large folder tree, since the dialog may take some time to show up, switching to another window will then make the dialog steal the focus and get to the foreground. This is not a recommended behavior but in the context of this temporarily workaround it should be acceptable.


LoRa driver sending opcode of commands without parameters

Hi all,
I'm testing the LoRa drivers included in Zephyr and through a logic analyzer I realized that the driver for the SX1261 is transmitting the opcode of the commands over SPI but without any parameters.
The image below depicts the problem when the driver sends the command with opcode 0x98 (CalibrateImage), which requires two bytes for the parameters 'freq1' & 'freq2':

According to the log in debug mode, two bytes of data should have been sent together with this opcode:
[00:00:15.406,188]  sx126x.SX126xWriteCommand: Issuing opcode 0x98 w. 2 bytes of data
This problem occurs with all commands, except with:
0xC0 - GetStatus: for this command, the opcode and an additional byte are sent (for reading the status byte).
0x1D - ReadRegister: for this command, the opcode and three additional bytes are sent (two for the address and one for reading the register value).
For the WriteRegister command (opcode 0x0D), the opcode and the two bytes for the address are sent, but no bytes for the data to be written.
I'm currently using the 'lora_send' and 'lora_recv' code from the samples folder and a Hifive1 Rev. B board with the following overlay:
&{/soc/spi@10024000/} {
    status = "okay";
    cs-gpios = <&arduino_header 13 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;

    lora: sx1261@0 {
        compatible = "semtech,sx1261";
        reg = <0>;
        label = "sx1261";
        dio2-tx-enable;
        reset-gpios = <&arduino_header 14 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
        dio1-gpios = <&arduino_header 10 0>;
        busy-gpios = <&arduino_header 8 0>;
        spi-max-frequency = <1000000>;
    };
};

/ {
    aliases {
        lora0 = &lora;
    };
};

The project configuration is as follows:
CONFIG_SPI=y
CONFIG_GPIO=y
CONFIG_LORA=y
CONFIG_LORA_SX12XX=y
CONFIG_PRINTK=y
CONFIG_SPI_SIFIVE=y
CONFIG_MAIN_STACK_SIZE=4096

CONFIG_LOG=y
CONFIG_LORA_LOG_LEVEL_DBG=y

Have you encountered similar issues while using the LoRa drivers? or do you have an idea why would the parameters not be transmitted over SPI but only the opcode?
Thanks in advance!
--
Information regarding the build environment:

OS: Ubuntu 20.04
Toolchain: zephyr-sdk-0.12.2
Zephyr version (displayed while building with west): 2.4.99
Build command: west build -p -b hifive1_revb

Update:
The problem could be related to the function for transmitting data over SPI (located in /drivers/lora/sx126x.c):
static int sx126x_spi_transceive(uint8_t *req_tx, uint8_t *req_rx, size_t req_len, void *data_tx, void *data_rx, size_t data_len)
The contents of 'req_tx' (opcode + dummy bytes for read operations) are being correctly transmitted, but the contents of 'data_tx' (command parameters) are not being sent at all.
Is it possible that this problem is related to the SPI drivers for this specific chip?
--
Here is the function for sending commands (also located in /drivers/lora/sx126x.c):
void SX126xWriteCommand(RadioCommands_t opcode, uint8_t *buffer, uint16_t size)
{
	uint8_t req[] = {
		opcode,
	};

	LOG_DBG("Issuing opcode 0x%x w. %" PRIu16 " bytes of data",
		opcode, size);
	sx126x_spi_transceive(req, NULL, sizeof(req), buffer, NULL, size);
}

I guess the pointer to buffer is either empty (although 'size' is not zero) or simply being ignored by the transceive function, as only the contents of 'req' are sent.

Update:
In order to confirm the root of the problem, I modified the sx126x_spi_transceive() function in /drivers/lora/sx126x.c so that it combines 'req_tx' and 'data_tx' into a single array, which is then transmitted over SPI. Thus avoiding the use of an array of buffers (i.e. spi_buf_set.count = 1).
And after doing this modification, the transmission of data over SPI works properly and I'm able to correctly receive the messages on a separated LoRa unit.
This would mean that the issue is in the transmission of the second buffer in the buffer array (i.e. 'data_tx').
Is there any specific configuration needed for enabling the transmission of multiple buffers?

The root of the issue results to be not in the LoRa drivers but in the SPI srivers for Sifive's MCUs, which appear to not handle multiple buffers. That's why I'm closing this issue, and continue in #34308.


Organization labels missing

Gitea version (or commit ref): 1.11.4
Git version: 2.25.0
Operating system: Windows Server 2008
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Description
I have no Labels option in my Organisation setting. In https://try.gitea.io this option is available.
Screenshots

#110814 is the PR to introduce this, it won't be available until 1.12.0

Hello, I think maybe we can do  some extend for this feature, that means we can allow users to define their own labels which can be used in all repos owned by them like an org. Thanks


Bluetooth: Mesh: Fixes wrong prov process

When link close, Wrong clear pointer, resulting
in illegal pointer access.
Signed-off-by: Lingao Meng<EMAIL_ADDRESS>

Sorry, github was only showing me the strdup change, I need to take a second look


How to reset the speed-scheduler?

I am currently writing a replay-feature for my game. Therefore I save the seed and all the player inputs. This works fine in the first level and I get a nice replay to watch.
However there is a problem in level 2. I get the same level layout and all starting positions also match. But by whatever reason it seems that some monsters do their turn a little later in the replay compared to the original game. It seems like the speed scheduler still remembers some events from the previous level.
Is there a way to reset the speed-scheduler to its initial state (as if it was newly created)?

Fortunately I could solve my problem! :-)
My guess that it was the scheduler was wrong.


Unable to exploit kernel. This is not an error. Reboot and try again.

Describe the bug
I’ve been trying to jailbreak my iPhone X but everytime I do try, I get a message saying “ Unable to exploit kernel. This is not an error. Reboot and try again.” Any fix for this? I’ve tried to Restore RootFS, hard reset my phone, and cleared diagnostics data and still get the same message.
To Reproduce
Screenshots

Device (please complete the following information):

iOS Version: 13.2
iOS Device: iPhone X
unc0ver Version: 4.3.1

Place an "x" between the brackets if true:

[ ] this is a bug others will be able to reproduce
[x] this issue is present with all tweaks uninstalled(except for default packages) or disabled
[x] this issue is present after a rootfs restore
[x] this issue is present on the latest version of unc0ver

Logs

Duplicate of #1844


Documentation update

Several parts of the documentation are out-of-date and incorrect.
Correct them.
There is also some missing information, such as the default username and
password to document,

LGTM


Update lambda

Update lambda to latest code

esp since we do not have tests, let's re-make these changes in small chunks we can be confident aren't breaking anythign.


Add a label on each policy with their control number

In reviewing a blog post, @sftim wrote:

kind: ValidatingAdmissionPolicy
metadata:
  name: "kubescape-c-0017-deny-resources-with-mutable-container-filesystem"

I'd expect to see a label here where the value was "C-0017". Maybe an annotation with a link to the Kubescape page about that control.
This is more feedback on the library itself, and not on the article.

We should add labels like so.

@craigbox could you confirm once if the field names are appropriate enough? I've used controlId and controlUrl respectively.


EventLog target only writes to Application log

Hi! Thanks for reporting this feature/bug/question!
Please keep / fill in the relevant info from this template so that we can help you as best as possible.
For .NET Core users, please check the platform support: https://github.com/NLog/NLog/wiki/platform-support
Type (choose one):

Bug

NLog version: 4.4.12
Platform: .Net 4.6.1
Current NLog config (xml or C#, if relevant)
<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="false"
      internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log">

  <targets>
    <target xsi:type="EventLog" name="eventlog" log="GatewayAPI" source="GatewayAPI" layout="${message}${newline}${exception:format=ToString}" />
    <target xsi:type="File" name="logfile" fileName="errors.txt" />
  </targets>

  <rules>
    <logger name="*" minlevel="Info" writeTo="eventlog" />
    <logger name="*" minlevel="Error" writeTo="logfile" />
  </rules>
</nlog>

In case of a BUG:

What is the current result?
EventLog target writes to the Application log even when a custom log (or System) has been defined.
What is the expected result?
EventLog target should write to the specified log when provided.
Did you checked the Internal log?
Yes, it states it sets the Log name to the custom one defined in the XML, but NLog still writes to Application log.
Please post full exception details (message, stacktrace, inner exceptions)
No exceptions.
Are there any work arrounds?
no
Is there a version in which it did worked?
Unsure, first version used/installed.
Can you help us by writing an unit test?
Unsure how to unit test this.

Duplicate of https://github.com/NLog/NLog/issues/950
Please continue the discussion there. As far as I remember we don't know how to solve this.


Fix crash caused by versionCode methods returning an int rather than …

…a string

Thanks for merging - any chance of a new release with this change in?

Hi, I'll first have to test it. That's also the reason I didn't comment here yet. Will do it soon!

Released with 1.4.4. Thanks!


PackageId:CPython39.Exe.x64;PackageAction:Install;ReturnCode:1603;

This issue has been moved from a ticket on Developer Community.

[regression]
Describe your issue here
===DO NOT EDIT BELOW THIS LINE===
PackageId:CPython39.Exe.x64;PackageAction:Install;ReturnCode:1603;

Original Comments
Feedback Bot on 10/25/2022, 06:08 PM:
(private comment, text removed)

Original Solutions
(no solutions)

duplicate of #7197


Age guards are needed?

The age of the applicant should be 18 yr of age or older?
If that is a requirement it is not being enforced.

As a note, this needs to be implemented at the UI level. The primary and secondary applicants must be 18+, but dependents can be <18 and are also stored in the People table.

Distinguishing dependents has been identified as an MVP-2 feature. Adding the MVP-2 label to this ticket, as it also requires a mechanism to distinguish dependents.


Using DGS Platform and DGS Codegen in Gradle project causes issue with api scope

I tried to use the DGS Platform/BOM adding below to my Gradle project as documented here:
dependencies {
    // DGS BOM/platform dependency. This is the only place you set version of DGS
    api(platform('com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:3.10.2'))
    ..

If I understand correctly to use the api I need to change the java plugin to the java-platform plugin in my Gradle build file as otherwise I get a:
Could not find method api() for arguments [DefaultExternalModuleDependency{group='com.netflix.graphql.dgs', name='graphql-dgs-platform-dependencies', version='3.11.0', configuration='default'}] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

But when I do that, ~`id "java"~, id "java-platform" I get:
The "java-platform" plugin cannot be applied together with the "java" (or "java-library") plugin. A project is either a platform or a library but cannot be both at the same time.

So it seems some other plugin is adding it?
Looking further I found out it is the DGS Codegen plugin causing the issue as it is applying the Java plugin :dizzy_face::wink:
https://github.com/Netflix/dgs-codegen/blob/master/graphql-dgs-codegen-gradle/src/main/kotlin/com/netflix/graphql/dgs/codegen/gradle/CodegenPlugin.kt#L29
I reverted back to the Java plugin and changed:
dependencies {
    // DGS BOM/platform dependency. This is the only place you set version of DGS
    api(platform('com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:3.10.2'))
    ..

to
dependencies {
    // DGS BOM/platform dependency. This is the only place you set version of DGS
    implementation(platform('com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:3.10.2'))
    ..

and that seems to work as well. I have no experience so far using the Java Platform plugin or usingapi so I'm not sure using implementation instead could have side effects?
Probably good to mentions this in the docs?
And maybe avoid applying the Java plugin automatically in the DGS Codegen plugin if the Java Platform plugin is already applied?

Btw looking at the Spring documentation regarding their Platform/BOM support for Gradle they use this example:
dependencies {
	implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
}

Note they use implementation.

I played a bit with the codegen adding the Java plugin conditionally like:
class CodegenPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        if (!project.getPluginManager().hasPlugin("java-platform")) {
            project.plugins.apply(JavaPlugin::class.java)
        }
        val taskProvider = project.tasks.register("generateJava", GenerateJavaTask::class.java)
        project.getTasksByName("compileJava", false).forEach {
            it.dependsOn(taskProvider.get())
        }

        project.getTasksByName("compileKotlin", false).forEach {
            it.dependsOn(taskProvider.get())
        }

        val javaConvention = project.convention.getPlugin(JavaPluginConvention::class.java)
        val sourceSets = javaConvention.sourceSets
        val mainSourceSet = sourceSets.getByName(SourceSet.MAIN_SOURCE_SET_NAME)
        val outputDir = taskProvider.get().getOutputDir()

        mainSourceSet.java.srcDirs(outputDir)
    }
}

That works for not applying the Java plugin, but then it will fail on:
val javaConvention = project.convention.getPlugin(JavaPluginConvention::class.java)

as when having the java-platform plugin there is no JavaPluginConvention. The java-platform plugin does not seem to have a similar convention, so I'm wondering if my assumption to use the java-platform plugin is correct?

@marceloverdijk using the api scope for the platform is not required. You can use compile or implementation as well. I'll add this to the docs to make it clear. You also don't need to use the java-platform plugin because you are only consuming the BOM, and not producing one.

Indeed. So probably docs could best mention implementation, as api in most cases doesn't make send or either won't work.

Fixed in this PR https://github.com/Netflix/dgs/pull/32


Add Leap Year Calculator:

Is your feature request related to a problem? Please describe.
I would like to add a calculator which will tell us if a year enter is leap year or not .
I agree to follow this project's Code of Conduct
I'm a GSSoC'24 contributor
I want to work on this issue

Currently not accepting sample projects. Kindly raise new Issues


Repo sync for protected CLA branch

The pull request is created from main637883173802846154 to main to fix git push error for protected CLA branch

@opbld15 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


[8.x] Add Clean and Mask to String Helper

Ok - This one I think doesn't have the formatting changes - hopefully this one checks out better!
Intro
First pull request so if I'm missing anything just let me know and I will totally understand if it's not approved.  I believe I've read all the important details in the contribution guide, but I feel like I heard/read somewhere that you weren't looking to add to the string/array helper functions anymore, but I couldn't find where I read that - so hopefully this is a welcome PR, and not an annoyance.
This is a minor feature - and should be backwards compatible to versions prior to php 5.6.
At the moment there weren't any function definitions for mask or clean in the string helper so I don't think it should break any existing features.
It should also have good longevity/stability, the code itself uses pretty base level php functions like strpos, preg_replace, substr etc.
The problem I am trying to solve
I build primarily B2B software, usually a lot of forms, and profile pages etc.
There are always a few things that need to happen when I work on these forms

When you store data, you want to store it in a standardized format so it's easily searchable/filterable
When displaying data, you want to appear it in an easy-to-read format

Common use cases that I have are

Phone numbers
Zip/postal codes
Employee IDs, or any other formatted identification numbers

So these 2 functions help developers do this. Their use-cases are

the clean function strips away all the formatting characters eg.<PHONE_NUMBER> turns into<PHONE_NUMBER>
the mask function adds the formatting to the string eg<PHONE_NUMBER> turns into<PHONE_NUMBER>

As a side note, these functions also work great with Livewire - so you can make real-time masks.
Str::clean - a wrapper around preg_replace with easy to remember options
this takes a target string, and an array of options - the options include numbers, letters, space, comma,period, colon, and has a few aliases as well (eg. ' ' = 'space')
Str::clean('y7Av58R/NW/Qep6vP@W/vvn;2ucp)KMzt6<D', ['numbers','letters']);
//Returns: 'y7Av58RNWQep6vPWvvn2ucpKMzt6D';

Str::clean('y7Av58R/NW/Qep6vP@W/vvn;2ucp)KMzt6<D', ['numbers']);
//Returns: '758626';

Str::mask - takes a string and forces it into an easily definable format
//US Social Security Number
Str::mask('987654321', '###-##-####'); //returns "987-65-4321"

//US & Canada Phone Numbers
Str::mask('(800) 800.8000', '###-###-####'); //returns '800-800-8000'
Str::mask('8008008000 x 123', '###-###-#### ext. ######'); //returns '800-800-8000 ext. 123'
Str::mask('8008008000', '###-###-#### ext. ######'); //returns '800-800-8000'

//US Zip-code
Str::mask("The zip code for the whitehouse is: 20500", "#####"); //returns "20500"

//Canada Postal Code
Str::mask("A1B2C3", "$#$ #$#");  // returns 'A1B 2C3'

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Thanks so much for the consideration!
I had a feeling it wouldn't go in but I thought I'd give it a try.  It was actually a really good experience just making the PR and going through the review process.  Laravel has made my life so much easier so I wanted to contribute back to core - I'll definitely give it another go when ever I think of something else that may be valuable to the framework.
Thanks for all your hard work guys!

Thanks so much for the consideration!
I had a feeling it wouldn't go in but I thought I'd give it a try.  It was actually a really good experience just making the PR and going through the review process.  Laravel has made my life so much easier so I wanted to contribute back to core - I'll definitely give it another go when ever I think of something else that may be valuable to the framework.
Thanks for all your hard work guys!


(Feature) New token icons for RSK

RSK updated the tokens list and their icons:

testnet: https://github.com/rsksmart/rsk-testnet-contract-metadata
mainnet: https://github.com/rsksmart/rsk-contract-metadata

It would be nice to see the icons of those contracts on nifty wallet as well

Great, updated. Will be published in 5.0.3


Finalize GNOS helm chart

Helm Chart for Geonetwork OpenSource
Prerequisites

Install custom resource definitions for elasticsearch

kubectl create -f https://download.elastic.co/downloads/eck/2.9.0/crds.yaml

Install the elasticsearch operator with its RBAC rules:

kubectl apply -f https://download.elastic.co/downloads/eck/2.9.0/operator.yaml

see here https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-deploy-eck.html#k8s-deploy-eck
Configuration
This directory contains a helm chart using the official Geonetwork OpenSource (GNOS) docker image for Kubernetes cluster deployments.
Since GNOS requires a running instance of ElasticSearch (and Kibana) this is included using custom resources and corresponding configuration files.
The GNOS version can be defined in the Chart.yaml file by setting appVersion.
The following parameters can be configured in (a custom) values.yaml, including the version of ElasticSearch (currently only successfully tested with version 7.1.1):

elk.version: The version of the ELK-stack (currently 7.1.1)
elk.name: The base name of the elk-services - default: gnos-elk
javaHeapSizeDefinition: The Java heap size definitions - default -Xms512M -Xss512M -Xmx2G; Other environment variables can be placed here as well
persistence.enabled: A default pvc (persistent volume claim) is used for persistent geoserver data
persistence.size: Size of pvc (persistent volume claim)
persistence.useExisting: Should an existing pvc (persistent volume claim) be used, default: false
persistence.existingPvcName: The name of an existing pvc (persistent volume claim) that should be used to store geoserver data
persistence.storageClassName: The name of the storage class to use. Leave empty if the cluster default should be used

By default, it is assumed that a PostgreSQL database (name: gnos) exists and can be accessed by the cluster. It can be configured in values.yaml by:
db:
  name: gnos
  username: postgres
  password: postgres
  host: postgres
  port: 5432

Thx for review @hwbllmnn


Determine and maintain a random per-RRDP-repository fallback time.

Currently, fallback from RRDP to rsync happens a constant time after the last successful update via RRDP. It has been suggested to instead fall back after a random time to spread out load on the rsync servers.
So, after each RRDP update, not only store the time of update but also a random fallback time with the RRDP repository state and use that to determine whether to fall back to rsync.

As a repository operator, that would be perfect!
My initial proposal (and I have a mail ready about this) would be to pick a delay from the "uniform distribution" between [now + rrdp_update_interval, now + rsync interval]. That would ensure that in the worst case delay an RP sees is the same delay as they would have if they switched to rsync manually directly after the last succesfull update.
Meanwhile, for the rsync servers, the clients would be spaced out (a lot).
For the rsync servers it would be better if the fallback would happen [now + rrdp_update_interval, now + rrdp_update_interval rsync_interval] after the last succesfull update: That would space clients out over the full hour.


Add documentation on Typing DNA to IS 7.0.0 docs

Is your suggestion related to a missing or misleading document? Please describe.
The documentation related to Typing DNA is missing from the IS 7.0.0 section. The related doc link in 6.1.0 is given below [1].
[1] - https://is.docs.wso2.com/en/latest/guides/adaptive-auth/typingdna-based-adaptive-auth/#set-up-typingdna-in-wso2-is

Closing since going forward, the connector documentations will only be managed in Github


Docker tests

docker container to run local tests in.

Codecov Report

Merging #71 into master will decrease coverage by 0.21%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
- Coverage   88.19%   87.97%   -0.22%
==========================================
  Files          29       29
  Lines        1575     1580       +5
  Branches      209      211       +2
==========================================
+ Hits         1389     1390       +1
- Misses        165      167       +2
- Partials       21       23       +2

Impacted Files
Coverage Δ

testci/test_keras_load_model.py
66.66% <42.85%> (-33.34%)
:arrow_down:

pelops/datasets/str.py
100% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


IDEA separate scanner and reporting

what about splitting this to 2 parts? One for crazy fast scanning (possibly with more accounts) and one for map(s) and reports.

What exactly do you mean by "reporting"? Do you mean the map you get when visiting <IP_ADDRESS>:5000 and the /stats endpoint?

yup. Just anything related to displaying collected data. Be it live map, spawns map, heat map, statistics, ... It can be slow, because the scanner will still run fast.

I want it to be configurable from the web in the future. And the status labels wouldn't work.
So no.


test: [Hacbs 650]/failure missing release strategy

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Issue ticket number and link
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation

Jira: https://issues.redhat.com/browse/HACBS-650

/retest

/retest

/cc @davidmogar
Hi David
Can you please review my PR?

/assign @psturc

/assign @flacatus

/approve

/retest

/retest

can u merge main branch?

ci/prow/redhat-appstudio-e2e - job failed
Don't know why

/retest

/retest

/retest


support for dynamic tablenames for multi-tenancy #318

This is a pull request to implement dynamic table names as described in issue #318

Coverage decreased (-60.9%) to 0.0% when pulling 35e31ad6cf4b2fb0234750be2405b5442ec6894b on bkali:master into 6a3c8a87d0457cf700e57046c41e19b7cf3c44fa on go-gorp:master.

I see that the test coverage % has not passed. I can fix that. Please let me know if you have any other feedback. Thanks,
Biju

I added some more test code to increase test coverage.  When I build on my dev machine I see 71% test coverage.  Coveralls is reporting 60.9% test coverage..  I am not sure which one to believe.. :-)
PASS
coverage: 71.4% of statements
ok      github.com/bkali/gorp   103.338s

Coverage decreased (-60.9%) to 0.0% when pulling eddd970430fc5423d1902f00fa5c86850b91ee08 on bkali:master into 6a3c8a87d0457cf700e57046c41e19b7cf3c44fa on go-gorp:master.

Coverage increased (+5.5%) to 66.407% when pulling c44bca114fa9ba39ede961014e3fb082f57af75f on bkali:master into 6a3c8a87d0457cf700e57046c41e19b7cf3c44fa on go-gorp:master.

Coverage increased (+5.8%) to 66.731% when pulling 86fb555b65ac6e11ae7bfdff584b2fd4ada22a12 on bkali:master into 6a3c8a87d0457cf700e57046c41e19b7cf3c44fa on go-gorp:master.

Coverage increased (+5.8%) to 66.731% when pulling bd2d2ba9227cddd48ebd052bb0a9b9365d596d11 on bkali:master into 6a3c8a87d0457cf700e57046c41e19b7cf3c44fa on go-gorp:master.

Sorry about the long delay; I'm going to start going through pull requests gradually and hopefully get things moving toward v2 again.  The only thing I saw that I would prefer changed is the GetTableName method, looks good to merge otherwise.

Coverage increased (+5.8%) to 66.731% when pulling 6c13097f2322a8c4ad78cd959208f76cd34b1231 on bkali:master into 6a3c8a87d0457cf700e57046c41e19b7cf3c44fa on go-gorp:master.

Weird style for "if" checks. It's the opposite of how standard Go and Gorp uses them, except when you check errors, then it's standard.
if nil != foo {
...
}

if foo != nil {
...
}

@stxml  : good catch :+1: It is an old habit of mine from C++ days (constants on the left of equality operator to avoid accidental assignment).

I'll just swap the order post-merge :)
I'm going over this one last time and am going to run tests locally.

Thank you very much @nelsam !


Better entity type suggestions when encountering unexpected entity types

Category
Cedar validation features
Describe the feature you'd like to request
This feature request comes out of a discussion on #360.  Currently (before or after #360), when encountering an unexpected/undeclared entity type, the validator uses Levenshtein distance to make suggestions, while Core's entity-schema-conformance checks instead try to suggest entity types with the same basename in different namespaces (as a direct response to #73).  These should probably use the same algorithm to make suggestions, and ideally share code.  It would probably be best for both the validator and Core to use both algorithms to make suggestions -- looking for entity types with close Levenshtein distance as well as entity types with the same basename but different namespace.
Describe alternatives you've considered
We could use only Levenshtein (despite #73), or we could use only the same-basename suggestions.  Both of these are almost certainly worse than the behavior suggested above.
Additional context
No response
Is this something that you'd be interested in working on?

[ ] 👋 I may be able to implement this feature request
[ ] ⚠ This feature might incur a breaking change

Related to #166

Do you have any suggestions on how to combine the two algorithms to this end? At present, they are slightly different in that the validator's algorithm looks for an optimal candidate (IDs within the same entity type), while the core's algorithm suggests multiple candidates ("zero-distance" IDs from other entity types). Because of that, it doesn't make sense to put all entity IDs in the same bag and compute Levenshtein's distance, as this might yield different results depending on how users name entities in their applications.
I've also thought about backing off from one to the other. For example, back off from core's algorithm to the validator's if the same entity ID is not used in other entity types. But that means we'd prioritize suggestions from other entity types, which doesn't sound great if there are good candidates within the same entity type. It's also hard to define what "close" is (for Levenshtein's distance) since once again it depends on how entities are named by users.

Spitballing here, what if we took the top 3 candidates from each algorithm (if they exist of course)?  So then we'd report up to 6 suggested candidates, some with "small" Levenshtein distance and same entity type, and others with zero Levenshtein distance and different entity type.  (We could prioritize entity types that are a short Levenshtein distance away as well.)

Spitballing here, what if we took the top 3 candidates from each algorithm (if they exist of course)? So then we'd report up to 6 suggested candidates, some with "small" Levenshtein distance and same entity type, and others with zero Levenshtein distance and different entity type. (We could prioritize entity types that are a short Levenshtein distance away as well.)

Thank you, @cdisselkoen ! The suggested approach sounds good to me, and I really like the idea of prioritizing entity types based on Levenshtein's distance because of the symmetry. I don't know if 6 candidates will be too many, but we can adjust those numbers later depending on how it looks.


404 errors and missing JSAPI dependencies

I created a vanilla app (just a basemap) with WAB Dev Edition 2.11 and built it using esri-wab-build 1.1.  There was an earlier issue (404 Errors when loading the built app) related to this and it looks to be persisting. I can get around the errors by manually uncommenting the following line in buildOutput\app\env.js:
//apiUrl = './arcgis-js-api';
Should this already be taken care of by esri-wab-build, or at least documented on the readme?
There are additional errors once env.js is modified:
dojo.js:22 GET https://localhost/esri-wab-build/arcgis-js-api/esri/geometry/support/pe-wasm.js?wab_dv=2.11 net::ERR_ABORTED 404
AbsolutePositionLayoutManager.js?wab_dv=2.11:4 Load widgetOnScreen:<PHONE_NUMBER>5625ms
worker-init.js:29 failed to load resource (https://localhost/esri-wab-build/arcgis-js-api/esri/config.js)
worker-init.js:29 DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'https://localhost/esri-wab-build/arcgis-js-api/esri/config.js' failed to load.
The build process didn't include the geometry or config packages in ..\buildOutput\app\arcgis-js-api.

I had the same initial error like you and for me it worked to just replace apiUrl = null at the beginning of env.js with the link to the api version (for example apiUrl = 'https://js.arcgis.com/3.27/'). I did not uncomment //apiUrl = './arcgis-js-api';

I can also add that the esri/geometry is not copied over
\app\arcgis-js-api\esri\geometry - is missing.
Work Around - Manually copy it from the build-src folder.


do not merge - this is a concept - feat: acquisition checkpoint

Please ensure your pull request adheres to the following guidelines:

[ ] make sure to link the related issues in this description
[ ] when merging / squashing, make sure the fixed issue references are visible in the commits, for easy compilation of release notes

Related Issues
Thanks for contributing!

Also, this should go against main – no new features in 1.x we said.


CF9 Compatibility fix

There was some issues with Relax on CF9 even though it states its supported.

+1 Solves my CF9 problems -- thanks, @gratzc.

@lmajano What needs to happen for this fix to be part of the stable build?

this is in the latest build I believe

How is that possible @lmajano, I just merged it earlier today?


Flatgeobuf: use geo-traits for parsing geometry

Closed by https://github.com/geoarrow/geoarrow-rs/pull/728


Do not panic when daprd receives unknown CLI flags

Changes how CLI flags are parsed in daprd to avoid panicking when a flag that is undefined is passed.
This is needed to allow smoother upgrades in the future. For reference, see conversation here where we would need to add new CLI flags passed by the injector, but which would cause older versions of the sidecar to crash: https://github.com/dapr/dapr/pull/6761#discussion_r1282581479
Although this change is applied to master only and it's not retroactive, so the problem highlighted in the conversation above can't be solved (at least not for 2 more Dapr releases), it will allow making these changes safer in the future.
Flags that are unknown will cause a warning to be printed, but will not cause a panic.
This change is possible by switching the CLI flag parser to spf13/pflag, which also comes with some additional benefits such as being able to hide deprecated flags from the help message (we have 2 at the moment), or having built-in support for multiple flags (like for --config and --resources-path).
This PR includes unit tests for the added feature and for other "tricky" parts of the package.

This change is applied to daprd only. I don't think it's necessary to apply it to sentry, operator, injector, placement. This is because these are all deployed via Helm and flags are controlled by the Helm chart for the given version.

As mentioned in my comment, I don't think not exiting on error is a good idea. It's not standard and is going to causing UX issues. An operator must know that the CLI flags passed to a program are actually being picked up.
We can use environment variables for introducing new options until all supported versions implement the flag.

As mentioned in my comment, I don't think not exiting on error is a good idea. It's not standard and is going to causing UX issues. An operator must know that the CLI flags passed to a program are actually being picked up.
We can use environment variables for introducing new options until all supported versions implement the flag.

You're right on the fact that panicking makes it easier to see typos. This PR shows a large warning at the beginning however which should help a bit.
But if the alternative is to use env vars, that's a much bigger evil:

They are in the environment so users set them with export in the shell, forget about them, and then see the app behaving incorrectly. Env vars are like global vars in code, and developers are taught to avoid them :)
There's no way to detect typos at all; at least with CLI flags we can show a warning.
There's no autocompletion in the shell.
Env vars do not appear in the --help page and are less discoverable.
Users will be confused by what is set via env vars and what is set via CLI flags
Our docs will be more confusing. The table already has many columns: dapr run flags, daprd flags, annotation. Adding a 4th column will not help.

They are in the environment so users set them with export in the shell, forget about them, and then see the app behaving incorrectly. Env vars are like global vars in code, and developers are taught to avoid them :)

These are only meant to be used in kube where we need to support new flags for backwards compat. We are already using environment variable extensively.

There's no way to detect typos at all; at least with CLI flags we can show a warning.

Warning do not give immediate signals in large deployments and are effectively silent until an outage happens and logs are investigated.

There's no autocompletion in the shell.

We still have auto-completion of the flags. The point here is to have both the environment variable and flags be available.

Env vars do not appear in the --help page and are less discoverable.

^ flags do as above.

Users will be confused by what is set via env vars and what is set via CLI flags

Flags take precedence over environment variables. This is typical  behavior of all programs.

These are only meant to be used in kube where we need to support new flags for backwards compat. We are already using environment variable extensively.

There's standalone mode too for Daprd.

Users will be confused by what is set via env vars and what is set via CLI flags

Flags take precedence over environment variables. This is typical behavior of all programs.

What I meant was, users will need to remember which option can be set via env vars and which via flags. That is confusing.

This is currently blocked due to some weird stuff done by the Kubernetes components in components-contrib. See: https://github.com/dapr/components-contrib/pull/2992#issuecomment-1638552086

Can we discuss this in the next maintainer's call? This is a breaking change.

Can we discuss this in the next maintainer's call?

Yes.

This is a breaking change.

How so?

Using pflags as a library is an ok change. @berndverst you're correct in assessing the question is about how Dapr behaves with unknown flags. My opinion is that allowing unknown flags to pass without validation is an anti pattern in most software and just an overall bad user experience for Dapr, which is why I don't think we should accept this change as-is. The tooling around Dapr is diverse - CLI, multi app run, Docker Compose, the sidecar injector and any form of way to run Dapr processes. When users provide a wrongly configured flag today, they would immediately receive feedback before Dapr starts. This lends itself  naturally to most testing validations, including the ones we use for the sidecar injector. With this change, users are left to encounter errors during runtime, or even worse - Dapr continues to operate without the desired behavior silently and never informs the user that something is wrong. In addition, this opens the door to many injector bugs related to malformed flag names, that cannot be caught with e2e, leading to greater chances of a hotfixes.

I agree with Yaron here. Every cmd tool I use fails with invalid commands, moving that to a runtime issue is a problem. You are just moving the problem down the road. So, people running Dapr will have the illusion a given flag is being considered while it is not. I think the problem of upgrading and handling new params is a legit concern but we can fix it in other ways. One is to have ENV variables for the optional params.

Most users don't run daprd directly, but use the Dapr CLI or the injector. So they don't risk making typos.
Env vars have literally the same issues you've described above, such as inability to catch typos etc, with the additional ones of being global, defined in the environment, and undocumented when running --help. And usually defined in places scattered all over the codebase. See: https://github.com/dapr/dapr/pull/6766#issuecomment-1665714022
The reason for this change is not because pflag is nicer (albeit it is), but because this boxes us adding required flags in the future.

Anyways, you two will decide what you want as usual.
Closing

I don't think daprd is really a command line tool - yes it can be used that way, but the command line tool is the Dapr CLI. daprd is only called by CLI, of course our sidecar injector, and by a few select very advanced users. In the CLI I would agree with erroring with unknown flags. In daprd I do not agree erroring is necessary, and it makes things harder.
I will also state that ENV vars are a much more error prone pattern.
Fortunately as I am not a runtime or CLI maintainer I do not have to deal with the CLI / runtime upgrade downgrade mess. I just advocated for a change that I believe to be good for the project and evaluate its merit without ganging up on the contributor.


MissingPluginException with webview_flutter

I'm using the "webview_flutter" plugin in my app. Most of the time it works, but sometimes I have this error:
[ERROR:flutter/lib/ui/ui_dart_state.cc(148)] Unhandled Exception: MissingPluginException(No implementation found for method loadUrl on channel plugins.flutter.io/webview_0)
#0      MethodChannel.invokeMethod (package:flutter/src/services/platform_channel.dart:314:7)
<asynchronous suspension>
#1      MethodChannelWebViewPlatform.loadUrl (package:webview_flutter/src/webview_method_channel.dart:52:21)
<asynchronous suspension>
#2      WebViewController.loadUrl (package:webview_flutter/webview_flutter.dart:446:39)
<asynchronous suspension>
#3      Engine.load (package:test_flutter/bug_webview.dart:152:24)
<asynchronous suspension>
#4      CustomList.build.<anonymous closure> (package:test_flutter/bug_webview.dart:94:16)
#5      GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:182:24)
#6      TapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:365:11)
#7      TapGestureRecognizer.handlePrimaryPointer (package:flutter/src/gestures/tap.dart:275:7)
#8      PrimaryPointerGestureRecognizer.handleEvent (package:flutter/src/gestures/recognizer.dart:455:9)
#9      PointerRouter._dispatch (package:flutter/src/gestures/pointer_router.dart:75:13)
#10     PointerRouter.route (package:flutter/src/gestures/pointer_router.dart:102:11)
#11     _WidgetsFlutterBinding&BindingBase&GestureBinding.handleEvent (package:flutter/src/gestures/binding.dart:218:19)
#12     _WidgetsFlutterBinding&BindingBase&GestureBinding.dispatchEvent (package:flutter/src/gestures/binding.dart:198:22)
#13     _WidgetsFlutterBinding&BindingBase&GestureBinding._handlePointerEvent (package:flutter/src/gestures/binding.dart:156:7)
#14     _WidgetsFlutterBinding&BindingBase&GestureBinding._flushPointerEventQueue (package:flutter/src/gestures/binding.dart:102:7)
#15     _WidgetsFlutterBinding&BindingBase&GestureBinding._handlePointerDataPacket (package:flutter/src/gestures/binding.dart:86:7)
#16     _rootRunUnary (dart:async/zone.dart:1136:13)
#17     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#18     _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
#19     _invoke1 (dart:ui/hooks.dart:250:10)
#20     _dispatchPointerDataPacket (dart:ui/hooks.dart:159:5)

$ flutter doctor -v
[✓] Flutter (Channel stable, v1.7.8+hotfix.3, on Linux, locale fr_FR.UTF-8)
    • Flutter version 1.7.8+hotfix.3 at /opt/flutter
    • Framework revision b712a172f9 (il y a 2 jours), 2019-07-09 13:14:38 -0700
    • Engine revision 54ad777fd2
    • Dart version 2.4.0

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /home/*/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-Q, build-tools 28.0.3
    • ANDROID_HOME = /home/*/Android/Sdk
    • Java binary at: /opt/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_152-release-1343-b16-5323222)
    • All Android licenses accepted.

[✓] Android Studio (version 3.4)
    • Android Studio at /opt/android-studio
    • Flutter plugin version 35.3.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build
      1.8.0_152-release-1343-b16-5323222)

[✓] IntelliJ IDEA Ultimate Edition (version 2019.1)
    • IntelliJ at /opt/idea-IU-181.5281.24
    • Flutter plugin version 36.1.4
    • Dart plugin version 191.7830

[✓] Connected device (1 available)
    • Nokia 7 plus • * • android-arm64 • Android 8.1.0 (API 27)

• No issues found!

Make sure to stop and rerun your app after you have run flutter packages get

@kush3107 Yes I did but it still crashes every time.

@kush3107 the same error still exists even when hot restarted the application. Any fix?

@Z6P0 Can you please try it with current flutter stable v1.9.1+hotfix.2 and latest webview_flutter?

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.

I think the issue is caused by webview being not visible, I wrap webview in a visibility widget and showing error state on onWebResourceError, webview throws exception when I call any of it's methods.

I think the issue is caused by webview being not visible, I wrap webview in a visibility widget and showing error state on onWebResourceError, webview throws exception when I call any of it's methods.

@javad-vovin
this issue was closed more than a year ago and it's not actively worked on
if you are experiencing this error please file a new issue
providing your flutter doctor -v your flutter run -v and a minimal reproducible code sample

@javad-vovin
this issue was closed more than a year ago and it's not actively worked on
if you are experiencing this error please file a new issue
providing your flutter doctor -v your flutter run -v and a minimal reproducible code sample

Yes I know it's closed, Someone else created new issue, #70655
I wanted to provide more information if someone else encountered with this.
Thanks

Yes I know it's closed, Someone else created new issue, #70655
I wanted to provide more information if someone else encountered with this.
Thanks


Frequent compactions and write/read delays

Bug report
System info: Fedora release 22, InfluxDB version v1.0.0-beta1
Steps to reproduce:

Drop database
Start inserting points (we range at around 30k-100k points per second, in a couple hundred thousand series)

Expected behavior: Points are inserted with acceptable latency
Actual behavior: We have two machines configured near identically, a canary and a production database. In the dev machine (16 CPUs) we see no issues and InfluxDB seems to handle the throughput just fine. In the production machine, under a near identical workload (99% identical points being added), we get long write delays constantly. The logs in prod also show a large number of compaction events. The database is extremely unresponsive to writes (block for up to a full minute), and HTTP queries during these slow periods. The database is in this slow, unresponsive state for perhaps the majority of the time while inserting.
Additional info: Compaction logs and inserter wait logs (>250ms wait counts bucketed by minute) for each box are attached. We're inserting batches of size up to 4k at most every 400ms. There's ~20 inserters. We tried dropping the database and re-creating it once the drop database command returned, to no avail. We've also tried restarting InfluxDB and temporarily stopping the inserters. Unclear why this only affects the production box. Let me know if I can help with more details.
compactionLogsProd.txt
inserterWaitsProd.txt
compactionLogsDev.txt
inserterWaitsDev.txt

I've attached the config file we're using for both the dev (working) and prod (problematic) machines.
config.toml.zip

After trying a bunch of potential solutions, we found that those slow periods seem to be triggered by out-of-order writes. For the dev machine with less CPUs it seems that the insert rate was low enough not to get into the pathologic slow behavior very often.
We have a set up for monitoring system where we allow users to insert new time series into the database. The datapoints for these new series come from individual files broken up by day. We'd like to be able to backtest alerts so we backfill old data, up to a couple months. Backfilling all of those daily files can take time, so we also allow continuous insertion of new points added in real time so we can start monitoring right away.
It looks like the database is sharded in weekly increments. We also have these settings:
cache-snapshot-write-cold-duration = "1h0m0s"
compact-full-write-cold-duration = "24h0m0s"
Is it possible that if we end up inserting a point at time T-X, then a point at time T (now) then a point at T-X+1 a compaction would be triggered after the second point was inserted due to the first point being considered a "cold" write by now? X here could be anywhere between a few minutes to several weeks.
Given our use case, are there any tips on avoiding this issue, e.g. by somehow having shards with smaller time increments (e.g. <24hrs) so that the continuous processing and backfilling can take place at the same time? Or perhaps some way to avoid compactions during backfilling for some particular measurement (which should only take a couple of hours at most).
Thanks.

Hi @lpalm,
How long after the DB is restarted before continuous full compactions are seen?
In our setup, we see full compactions and heavy write throughput and IOPS exactly 24hrs after DB is restarted. Unlike in your use case, we do not do any backfill, new data is always for current time.
However, the exact 24hr period before deterioration happens is suspect and to test whether the cold duration full compaction period is the trigger have raised that to 48h.
This is the behaviour we see:

Is the same behaviour seen in your case or do full compactions start immediately after the DB is restarted?
Log output is similar to yours, frequent full compactions, per below attachment.
influxdb_write_logs.txt

We start seeing issues easily within an hour of restarting. But we get through several day's worth of data per hour when backfilling. Our previous backfill policy was to start from yesterday and go back in time so we can backtest alerts with the most recent data first. Changing it to fill from the oldest file first seems to have reduced the incidence of the massive slowdowns, despite continuous inserting of real-time data while backfilling takes place.
Still, it would be desirable to be able to backfill somewhat recent data (say, the past 1-2 weeks) quickly but still be able to later fill in historical data if needed without crushing the database. Advice on workarounds (Assuming this is intended behavior in first place) would be much appreciated.

There is at least one issue with compactions run after compact-full-write-cold-duration as per  #6885
In your case, compactions causing issues are also triggered by out of order inserts but are limited to duration of inserts.
It may be the actual cause for these two compactions issues is the same, cannot say without debugging the code though.
Workarounds for cold duration compactions:

Restart DB within cold compaction interval
Increase cold compaction interval to a very high number to effectively turn it off

For your case, yes, it would be best to backfill from oldest date to newest. Backfilling in reverse time order is a bad idea with influxdb in general, regardless of any compaction issues - it will never perform well in that use case. Perhaps limit backfilling to maintenance periods when the DB is not serving requests.
Will still need one of the two workarounds above for cold duration compactions issue.

"Backfilling in reverse time order is a bad idea with influxdb in general, regardless of any compaction issues - it will never perform well in that use case"
To clarify, for each day getting backfilled, points are in order, starting from 00:00 all the way through to 23:59. It's just that we were inserting each day in reverse chronological order. Given that, is it possible to configure Influx or insertions such that this won't be a problem? We don't experience issues when backfilling data from a few days ago while simultaneously inserting real-time data for the same series, so there's at least some amount of tolerance for out-of-order insertions already.
What does cold compaction buy us? Is data completely uncompressed until it is compacted? Do queries run faster on compacted data?

Let me clarify, backfilling in descending date and/or time order is ill advised :)
There is no configuration settings that I know of that can be adjusted to change this, it's part of the DB's design
What might be worth trying, however, is setting up a new retention period and backfilling only into that retention period. Your queries will also have to use that retention period for backfilled data while real time queries have to go to default retention as normal. This should in theory, haven't tried it myself, force backfill data to not live in the same files as real time data.
Compacted data takes less space (better compression), queries faster from disk (less files to read from) and uses fewer disk I/O.
Conversely, disk space use, IOPS use and query performance from disk will suffer without cold compactions. How much so depends on your particular work loads.

Splitting backfilled and real time data into different retention periods would be messy, since we'd like to visualize and backtest alerts on time ranges that may straddle the split between real time and backfilled. And the split point would be different for each measurement as they are being continuously added over time.
Ideally, disabling compaction for a given measurement while we backfill might avoid killing the database for everybody else. We could then trigger/enable compaction once backfilling is completed 1-2 hours later to reap the benefits of compaction. Doesn't seem like it, but is it possible to control compaction behavior while running and/or on a per-measurement basis?

During backfilling it is possible in some cases that some data points for the current day get overwritten. We start the real-time inserter from the start of the day to ensure we don't have gaps.
Could this be related to the various issues reported RE: overwriting points?

Is this still occurring w/ 1.0.1?

Confirmed to be resolved since 1.0.0.

Thank you for confirming.


added goreleaser

added goreleaser

Hi,
we need an external reference to goreleaser which is ok but in for an development cycle it would be to set the default target to a go only thingy. And add a release target to use goreleaser.
all:
go.....
release
goreleaser

You mean the github workflow? The release/upload should happen here (and only for tags, hence the if): https://github.com/mabels/eimer-kette/blob/main/.github/workflows/go.yml#L24 .

docker build might be broken now, since the path has changed. Haven't tried that one yet.


Remove app.example.ini

Users aren't reading the disclaimer at the beginning of this file which is more harmful than helpful.
A future PR could be to generate the docs.gitea.io page from go structs, but this is a starting point.

@jolheiser thanks for that catch. I've updated.

I think there are dozens of options that are only documented in that file. I'm happy to have one documentation source in the future but care should be taken that no documentation is lost.

Another option is just to have the whole damned thing commented out.

I'm for removing, but we have to make sure, to migrate any extra info int the docs from that example ini ...

As a regular user, I depend on the config file being provided. Whenever I upgrade, I diff the new example against my current file to find new and deleted options. The Gitea config is pretty overwhelming but it's still the best chance I have of keeping up. I won't digest all of the release notes with the same scrutiny. There's a bit of momentum here already but if there was a chance to reconsider...


When bundling with Rollup.js resulting bundle does not work under Node.js

I ran into a problem when trying to bundle a package that depends on chalk using Rollup. I don't know if this is considered a bug but I think a small change could make chalk more portable by supporting the default config.
To reproduce
yarn add rollup @rollup/plugin-node-resolve chalk

// rollup.config.mjs
import nodeResolver from "@rollup/plugin-node-resolve";

export default {
  input: "./chalk-test.mjs",
  output: [
    {
      file: "dist/chalk-test.mjs",
      format: "es",
    },
  ],
  plugins: [
    nodeResolver({
      //   exportConditions: ["node"],
    }),
  ],
};

// chalk-test.mjs
import chalk from "chalk";

console.log(chalk.blue("Hello world!"));

Now after bundling and running the resulting bundle we get an error:
$ yarn rollup -c rollup.config.mjs
$ yarn node dist/chalk-test.mjs
/dist/chalk-test.mjs:225
const isBlinkBasedBrowser = navigator.userAgentData
                            ^

ReferenceError: navigator is not defined
    at file:///media/index/Dev/js/worms/packages/chalk-test/dist/chalk-test.mjs:225:29
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

Node.js v19.1.0

The cause of this problem is the conditional import in package.json. Rollup by default selects the default version, which will includes the code that results in an error in a non-browser environment.
"imports": {
		"#ansi-styles": "./source/vendor/ansi-styles/index.js",
		"#supports-color": {
			"node": "./source/vendor/supports-color/index.js",
			"default": "./source/vendor/supports-color/browser.js"
		}
	},

This can be solved by manually adding node to exportConditions in the nodeResolver config (see https://www.npmjs.com/package/@rollup/plugin-node-resolve)
  plugins: [
    nodeResolver({
      exportConditions: ["node"],
    }),
  ],

This is not ideal because it is confusing and requires Rollup users to alter their config for all dependencies. I think ideally, the default version should not depend on the presence of the global navigator variable.

This is a problem with Rollup or your Rollup config. You should take this up on the Rollup issue tracker, not here. Node.js recommends using node for Node.js and default as fallback for browsers, and this is what most isomorphic packages use.

Hi, thank you for your reply! As I said, I already found a workaround  for my build (setting exportConditions: ["node"] to get my bundle to work in Node.js), the reason I decided to create this issue is that it might save others from encountering the same headache.
I do not think this is the fault of Rollup, which tries to make an environment-agnostic bundle for my library unless I tell it I want a node-specific or browser-specific version by configuring the export conditions accordingly (though their docs could be clearer). In his case, I was actally trying to create a portable bundle that can be used in both Node and browser environments. I understand that it is impossible to get full functionality of your package in this scenario because the Node code in https://github.com/chalk/supports-color/blob/main/index.js depends on node-specific APIs and should only be included when the node export condition is set. However, it would still be nice if the default export could degrade gracefully when it ends up in a non-browser environment instead of crashing, for example by defaulting to basic color support. I checked the Node.js docs again and also came across these related issues: https://github.com/chalk/supports-color/issues/113 , https://github.com/chalk/chalk/issues/557 https://github.com/SBoudrias/Inquirer.js/issues/1153
As per the Node.js documentation, if I understand it correctly, the default condition should offer an universal implementation that does not make assumptions about the environment.

When using environment branches, always include a "default" condition where possible. Providing a "default" condition ensures that any unknown JS environments are able to use this universal implementation, which helps avoid these JS environments from having to pretend to be existing environments in order to support packages with conditional exports. For this reason, using "node" and "default" condition branches is usually preferable to using "node" and "browser" condition branches.

In your package, this is not the case (the default version assumes that the browser-only navigator field is defined, which is not the case for all javascript environments). This means I have to pretend to be a node environment (which is my current solution) and give up the goal of building one bundle that can work across environments. In the end, creating a single bundle for multiple environments might be a rather niche goal, so I can also understand if you think it is not worth the trouble to support this.


Remove EVM commands

The EVM commands near evm-view, near evm-call, and near evm-init-dev have been obsoleted by the Aurora Engine CLI and should be removed at some point.
@artob

Can I help out here, @thisisjoshford ?

I think we'll need to sweep the docs to make sure we don't say "yeah you can use NEAR CLI with the EVM"


Add names to character colliders, for better collision or intersection indication

I was recently using a cuboidCollider with onIntersectionEnter and exit. I found the character to trigger the event more than once on each enter/exit. Because it has colliders on the model, and on the Ecctrl component itself. By adding a name property to each one, especially the Ecctrl one, we can now detect or differentiate exactly which one caused the event to fire. So if we want to detect a single event, we can exclude those that don't have the character-body-capsule-collider name, for example.
These names would show up in onIntersectionEnter > event.colliderObject.name

Thanks for your contribution @Seanmclem ! However, the default ecctrl collider is just one capsule, and it only triggers enter event once I believe. For specific models or collider use cases, users can name their own colliders to indicate the desired event.

Thanks for your contribution @Seanmclem ! However, the default ecctrl collider is just one capsule, and it only triggers enter event once I believe. For specific models or collider use cases, users can name their own colliders to indicate the desired event.

Right, but the included capsule collider of the library should be able to identify itself. Instead of me, only being able to identify additional colliders added through models. Because, in that case, the included capsule collider would always be nameless.

Emm.. make sense. So you need a way to only identify the ecctrl collider, right?
If you could only include name for the capsule collider, I will proceed with merging it into the main 👍

@ErdongChen-Andrew ok done


feat(bridge-ui): release token button

@shadab-taiko

I'm having trouble looking at the bridge ui, not sure why