[BUGFIX] [SCRIPT] Fixed a bug in clean_tok_mono_corpus.py and merged clean_tok_para_corpus.py and clean_tok_mono_corpus.py #1520 #1490

Description
In clean_tok_mono_corpus.py was taking two variables in line 238 but as it was a mono_corpus only one was needed. Another issue of merging two files(clean_tok_para_corpus.py and clean_tok_mono_corpus.py) with similar functions (different types of corpus) was also completed.
Checklist
Essentials

[x] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage
[x] Code is well-documented

cc @dmlc/gluon-nlp-team

Awesome. Thanks for refactoring! Overall it looks reasonable to me. I approved the CI workflow to run

Awesome. Thanks for refactoring! Overall it looks reasonable to me. I approved the CI workflow to run

Than you sir, I guess you can merge this request and also close these two issues as both of them are solved through this pull request .


Server Certificate Expired - How to Renew?

Our server certificate has expired and clients are unable to connect! How do we renew the server certificates? or extend its expiration?
This is for a production VPN so any quick help would be greatly appreciated!

the same problem

@batesenergy I removed previous certificate and create a new one with the same name. Here is a example https://github.com/angristan/openvpn-install/issues/1002#issuecomment-1229525488

Did this work for you?
Patrick Bates
Open IoT Group
207.242.6313
On Sun, Jan 8, 2023, 1:45 PM Nikita Rukavkov @.***>
wrote:

@batesenergy https://github.com/batesenergy I removed previous
certificate and create a new one with the same name. Here is a example angristan/openvpn-install#1002
(comment)
https://github.com/angristan/openvpn-install/issues/1002#issuecomment-1229525488
—
Reply to this email directly, view it on GitHub
https://github.com/kylemanna/docker-openvpn/issues/731#issuecomment-1374901105,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMCAJGPP6BGBXV3E34RYR2DWRMDOJANCNFSM6AAAAAATTSLLUA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@batesenergy yes

For those who run into the same issue. Here are the changes we made to fix this issue:
server_cn= "Server Common Name" mv /etc/openvpn/pki/reqs/$server_cn.req /etc/openvpn/pki/reqs/$server_cn.req.backup mv /etc/openvpn/pki/private/$server_cn.key /etc/openvpn/pki/private/$server_cn.key.backup mv /etc/openvpn/pki/issued/$server_cn.crt /etc/openvpn/pki/issued/$server_cn.crt.backup cd /etc/openvpn easyrsa build-server-full $server_cn nopass
Then reboot the container to take effect.


Does Hystrix 1.4 still support a java 6 runtime environment?

Does Hystrix 1.4.x still support a java 6 runtime environment?

Not as of 1.4.0.  It's now Java 7+

Is there no plan to make available it Java 6 compatible? I'm sure there are many users of Hystrix that are still on Java 6 and could really use the new features such as Semaphore timeout capability as well as any bug fixes. Please strongly consider that.

Given that Java 6 was EOLed 2 years ago, I'd strongly prefer to move forward through Java versions.
Is there anything special about your case that requires Java 6?   Any dependencies which I should be aware of that prevent you from moving forward?

Also, more generally, if anyone has a strong desire for staying on Java 6, it would be very helpful to hear from you about what your reasons for that are.

I'm using Hystrix with an app running on Websphere 8.5 and we've just come across this problem too.  Whilst it is possible to upgrade the Java version to 7, it's an optional feature and we can't use it just yet.  I think with 8.0 it's not even optional, you're stuck with 6.

Our environment is on Websphere 8 with no upgrade planned in the near term.
So we are stuck on java 6. I would not be surprised if many Hystrix users
are in a similar situation where for one reason or another an immediate
java version update is just not feasible.
On Mar 25, 2015 7:45 PM, "Matt Jacobs"<EMAIL_ADDRESS>wrote:

Also, more generally, if anyone has a strong desire for staying on Java 6,
it would be very helpful to hear from you about what your reasons for that
are.
—
Reply to this email directly or view it on GitHub
https://github.com/Netflix/Hystrix/issues/722#issuecomment-86254437.

OK, that sounds reasonable enough.  Thanks for the explanation.
We don't get any real mileage out of JDK 7, though it would make #372 harder to implement, so the downside is fairly small.  I do want to target JDK8 at some point.  Will try and
I'll get to work on targetting Hystrix 1.4.3 to JDK 6.

That's great, thanks!
On Mar 26, 2015 8:08 PM, "Matt Jacobs"<EMAIL_ADDRESS>wrote:

OK, that sounds reasonable enough. Thanks for the explanation.
We don't get any real mileage out of JDK 7, though it would make #372
https://github.com/Netflix/Hystrix/issues/372 harder to implement, so
the downside is fairly small. I do want to target JDK8 at some point. Will
try and
I'll get to work on targetting Hystrix 1.4.3 to JDK 6.
—
Reply to this email directly or view it on GitHub
https://github.com/Netflix/Hystrix/issues/722#issuecomment-86764188.

Code is merged.  Will go through the docs tomorrow to make sure everything is up-to-date with this change and then release 1.4.3.

This is now released in 1.4.3.  Can you give it a try and confirm that I've released it properly?

Awesome, many thanks!
Will take it for a spin soon as poss. Thanks again

Using javap, I see that these classfiles are major:50, minor:0 (JDK6), so this looks done to me.
Classfile /Users/mjacobs/debug/validate-jdk6/com/netflix/hystrix/Hystrix.class
Last modified Mar 27, 2015; size 3471 bytes
MD5 checksum 5585031e2abcc1f6283bfb75372b9c6f
Compiled from "Hystrix.java"
public class com.netflix.hystrix.Hystrix
minor version: 0
major version: 50


htlcswitch: use a spec-compliant fail for intercepted HTLCs

The old message is not spec compliant: all Update reasons must include the
channel details. On the other hand, using a Fail reason is also a
bit harsh since they are considered permanent. That is, a node could
refuse payment attempts to that channel for all time and be spec
compliant while doing so.
TBH I'm not sure if this change is a good default. I chose this error mostly cause it penalizes the channel instead of the routing node. The main motivation for this is that Acinq-based nodes don't react kindly to the current state of affairs.

@roeierez as the the other heavy users of this API, I'd love your feedback on this

Are you referring to this section:

MUST include the appropriate data for that particular error type.
?

For a temporary channel failure, there may not be any new information to communicate. Also, it'll also allow most nodes to safely retry that same link eventually. If a temp chan failure is sent (as is now), then all nodes the led up to that failure will be credited for a "success" for that payment amount, since they were able to transit up to that node. This isn't the case if a unknown peer message is sent.

The main motivation for this is that Acinq-based nodes don't react kindly to the current state of affairs.

Can you elaborate on this? We should also consider the higher order effects of such a change beyond the specific routing implementation of an end user wallet.

I refer to

Please note that the channel_update field is mandatory in messages whose failure_code includes the UPDATE flag.

temporary_channel_failure is UPDATE|7 so it should include the field under this wording.

For a temporary channel failure, there may not be any new information to communicate.

I agree, maybe it's something to revise on the spec? Not sure what the original rationale was.

The main motivation for this is that Acinq-based nodes don't react kindly to the current state of affairs.

Can you elaborate on this?

Acinq expects a channel update and errors out since it can't parse the empty update.

We should also consider the higher order effects of such a change beyond the specific routing implementation of an end user wallet.

Totally agree! It makes sense for Muun (and we'll roll this out for our node) but I have no idea whether this a generally good idea. Since no other error had as ample meaning as this one (they are all quite specific or node level), I felt this one might work. What's your take on this? I think that given that intercepting an htlc should mean no channel actually exists for that htlc this error would be the correct one most of the time.
I also think the API should accept an error message to avoid a "one error for all scenarios". Would this be acceptable? I'd be happy to work on it.

An alternative here would just be to thread through the latest channel update to make ACINQ happy, which lets us retain rewarding all the nodes up to them that forwarded w/ a "success" from the PoV of mission control.

Here's an example where we do this elsewhere in the switch: https://github.com/lightningnetwork/lnd/blob/master/htlcswitch/switch.go#L672

An alternative here would just be to thread through the latest channel update to make ACINQ happy, which lets us retain rewarding all the nodes up to them that forwarded w/ a "success" from the PoV of mission control.

Sounds good! Will look into it next week.

An alternative here would just be to thread through the latest channel update to make ACINQ happy

Seriously? This is not to "make us happy", the spec is 100% non-ambiguous and LND is returning invalid error messages.
If you think this part of the spec isn't good, then the appropriate thing to do is advocate for a change and not break compatibility with other implementations.

@roeierez as the the other heavy users of this API, I'd love your feedback on this

@champo sorry for not being responsive... I think the suggested alternative of fetching latest channel update is a good solution to be spec compliant.

Seriously? This is not to "make us happy", the spec is 100% non-ambiguous and LND is returning invalid error messages.

That was just a colloquial phrase which was short hand for: "fix the issue w/o degrading our path finding and ensure this advanced feature is compliant with the implementations you're having issues with".  I think you're reading into it a bit.

If you think this part of the spec isn't good, then the appropriate thing to do is advocate for a change and not break compatibility with other implementations.

I made no such comment, I was simply gathering more information as I was sure we had began to send error payloads in all the relevant areas. The added API didn't purposefully break compatibility with other implementations, we would never explicitly try to do such a thing. This API was added after we did a sweep to send error payloads where relevant, and the fact that the affected area of the code didn't do so was simply an oversight during review of a contributor's PR.
As you can see from my comment above directing the OP w.r.t how to proceed with a new iteration, I am indeed advocating for a change here to resolve the issue. Also this PR is marked to be packaged with our upcoming release, which shows explicit intent to resolve the issue and deploy the fix.

@champo I'm going to pick this fix up, unless you'd still like to get to it?
iiuc, the fix will be to keep NewTemporaryChannelFailure and add a channel update for this type of failure + a test.
This will leave pathfinding unaffected as per:

If a temp chan failure is sent (as is now), then all nodes the led up to that failure will be credited for a "success" for that payment amount, since they were able to transit up to that node. This isn't the case if a unknown peer message is sent.

@champo I'm going to pick this fix up, unless you'd still like to get to it?

thanks for picking it up! I got swamped and won't be able to look into it soon.


Improve deployment and staging error metrics

#1241

Still looking at more ways to improve this

We should update the common library to do staging using future's the same way the experimental deploy does.  I'd like to serialize all this code as much as possible. We've got node like code soup here which is hard to read.

yes, we indeed have callback hell here. I'll look at this in a different PR.
A common pattern we have with handling deployment/staging exception is something like this:
catch (SomeException se) {
  callback.errorOccured(someLocalizedMessage); // cancels the operation and sends the message to metrics
  logger.error(se); // IDE error and notifies us
}

@patflynn, @joaoandremartins  what are your thoughts on including the localized message in the logger.error and / or including the exception message in the callback errorOccured?
What I'm aiming for is a way to associate the localize message (e.g. "staging failed due to an unknown error") with the actual exception that was thrown. @patflynn I do remember you were against including localized messages in the logging statements.
Note: this will not help for cases where staging/deploy fails due to the process failing unsuccessfully (which is the majority of our failures). These cases still require updating gcloud's error messaging.

@etanshaul why include localized message when you can just add your own more specific message to the error logging statement?

I don't think we have anything more specific to give. But on second thought, I don't think this will be helpful. We can already cross-reference the exception with the reported metric error with my current changes.

@patflynn, before I merge - did you have anything else in mind for this PR?

nope.
On Tue, Feb 14, 2017 at 11:42 AM, Etan Shaul<EMAIL_ADDRESS>wrote:

@patflynn https://github.com/patflynn, before I merge - did you have
anything else in mind for this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1242#issuecomment-279762362,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HVtBJu_ooZrSC4oAlMiZDSJiVTuFks5rcdlqgaJpZM4L_0g9
.


Update to p2 v0.7.1

Hey!
I updated the definition file to v0.7.1 which was just released (though the changes were actually mostly from v0.7.0).

Thank you for this mate.


Replace default  optimization level -O0 by -O3 or -Ofast

Maybe replace the default optimization level with -O0 to reduce execution time?

The default optimization level should already be -O2. Is this not so?

-O0

    Reduce compilation time and make debugging produce the expected results. This is the default.

proof link:  https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Optimize-Options.html#Optimize-Options
Actual for 7.x, 8.x versions.

-O0 is the compiler default, yes, but all autoconf-based projects use -O2 or higher as the build system default. Ruby's build system defaults to -O3. Below is an example of a compiler invocation during a Ruby build:
gcc -I. -I../../.ext/include/x86_64-linux -I../.././include -I../.././ext/openssl -DRUBY_EXTCONF_H="extconf.h" -fPIC -O3 -ggdb3 -Wall -Wextra -Wdeclaration-after-statement -Wdeprecated-declarations -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wrestrict -Wwrite-strings -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Werror=deprecated-declarations -fPIC -o ossl_pkey_ec.o -c ossl_pkey_ec.c

Notice how it uses -O3.


Several improvements.

Hi,
This pull request brings several improvements:

Update assets to version 0.6
Created a Rake task for autoupdating assets
Rework the Readme so that it is more clear
Remove .ruby-version file, as it is not really needed to enforce that.
Create a SimpleForm input

I see that this repository is not keeping up with the changes in the main repo. @HackerWins if you would like to make me a collaborator I can help with that.
Thanks!

:+1: Awesome contribution!

Thanks! I hope it's merged soon. Summernote is pretty awesome, and it is a pity that summernote-rails is not up to date.

Sample application will be added turbolinks. because it's rails default.


Added Unraid Template

Currently, this is hosted within my repository. Once this one is approved onto the Unraid Store, I will delete mine to consolodate maintenance.
Please note; you will have to go through the Unraid Repository application process.

Thank you so much!


Fix image references

Converted image references from img tags to markdown syntax. Previous version looks fine on GitHub but isn't rendered on docs.microsoft.com - just shows escaped HTML.

Thanks, Jon! You should see your fixes later this afternoon.


Bulletproof metadata parsing

Prevents the container from crashing if the metadata doesn't parse as valid JSON or the resulting JSON object doesn't contain the key 'enabled'.

Argh as usual I need to rebase this...

Merging on behalf of @Cynocracy.


ENH: Added functionality to format signal groups and trigger scaler

@dchabot, @klauer
This is a suggested enhancement to run_engine and signal groups. Here we set the signal names in the group to have the base signal name and a postfix for the type of signal (for example '_s1' for S1 of the scaler).
This then also adds signal groups to the event descriptors and events such that the signals are all added. I think this makes more intuitive sense to "bundle" up signals into groups which are then added. For example all the signals for a temperature controller could be bundled in a signal group.
Thoughts.... I tested this and it works OK with the scaler.
I also added the sclr.count as the trigger so this can be triggered in the scan.

Closed this after seeing @dchabot's comment, I will use this for testing at the moment in my branch then nuke the changes.


SQL Squirrel error

C*: JDBC Driver class not found
class java.lang.NoClassDefFoundError: Could not initialize class com.github.cassandra.jdbc.CassandraConfiguration
I followed the README and got the following error message.
I'm using the shaded jar in the README.

cassandra-jdbc-driver-0.6.4-shaded worked for me


Set motors to 0 voltage when brakes are locked (no motor fighting the brake, one controls at a time)

Climber issue

look into voltage control mode

I believe this is addressed by our climber code calling setNeutralOutput(). @LandonBayer can you confirm and if so feel free to mark this issue as done and close it.

Yup it does, this can go


Hugo 0.16 hanging on Travis

I am running Hugo 0.16 on Travis and when I try to generate the site on Travis and Hugo hangs.  Eventually Travis times out and things terminate.
Hugo Version:
hugo version
Hugo Static Site Generator v0.16-DEV BuildDate: 2016-01-28T15:10:26Z

Output from running hugo -v.
hugo -v
INFO: 2016/01/28 15:10:27 hugo.go:385: Using config file: /home/travis/gopath/src/ghe/org/project/config.toml
INFO: 2016/01/28 15:10:27 hugo.go:501: syncing static files to /home/travis/gopath/src/ghe/org/project/public/

Relevant pieces from .travis.yml
language: go
go:
- '1.5'
sudo: true
dist: precise
group: edge

Tested this out with v0.14, 0.15, both work fine.

We build the docs site on Travis as part of the CI, and that is currently green. Hmmm.... Could you try to update to the latest Go 1.5.3 (matching what we use on Travis)?
If it hangs on the "syncing ..." a suspect is one of @spf13 s latest commits.

@bep just ran with with Go 1.5.3 and got the same hang...  I will note this is running on an on-prem instance of Travis not travis-ci.org.

@jsloyer: I was able to get hugo to hang right after a hugo site new run, i.e. a site where the content/ directory is empty, on my Debian laptop.  Is that the case for you too?

@anthonyfok yep!

Thanks @jsloyer!  I have changed the title of the issue accordingly.  :-)
Cheers,
Anthony

According to git bisect, this problem seems to be introduced at bcc42c0. I can reproduce the issue in the way @anthonyfok mentioned from the commit.

I think the root cause of the problem is the line https://github.com/spf13/hugo/blob/master/hugolib/site.go#L880 in Site.ReadPagesFromSource() method.
The receiver in Site.CreatePages expects values from a channel but at the above line, it only returns nil and a channel value is never sent so Hugo hangs here.

This should be fixed in 68e2e63.

This needs a test case, reopen.

I added a test to this issue in 2b3b90a


Added Myself to Developer List

@ahmadmardeni1 I added my areas of expertise. Can you review this and merge it, please?

Great, thank you @john-amiscaray


Make "Object Metadata" available in Cloud

Hi all,
I have a particular case when I need to access Object Metadata while building solution for Cloud BC: I need to read a SubPageLink parameters and parse it for further processing. I was able to achieve that in NAV 2018, but, while moving functionality to BC SaaS, I realised that all Metadata tables which contain metadata BLOBs are marked as Scope = OnPrem.
Can you please make Object Metadata available for SaaS or create something similar that can be used to read metadata from SaaS?
Best regards,
Oleksandr

Thanks for the suggestion. Since this is an improvement and not a bug, you can post this to our Ideas forum at https://aka.ms/BusinessCentralideas, or vote up the idea if its already there. We're constantly monitoring top Ideas and will consider them for a future release.


Mob Programming

Good job so far, but we have some suggestions we think you can implement.

[ ] Kindly replace the following commands with your commands

Usage
ruby main.rb
Run tests
rspec , For running the app

Thank you for these Alice


Fix linking idyntree-model target deprecation

This could be useful if we bump the iDynTree required version, although I am not able to find for which version of iDynTree this change was introduced, going through it's CHANGELOG.

This could be useful if we bump the iDynTree required version, although I am not able to find for which version of iDynTree this change was introduced, going through it's CHANGELOG.

I think it is iDynTree 5 the first with the new target.

Done in https://github.com/ami-iit/bipedal-locomotion-framework/pull/588 .


Getting started data prepper

Description
Merged content from Data Prepper repo documentation into existing page on OpenSearch documentation website.
Issues Resolved
Fixes #1457
Checklist

[ x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dlvenable This is ready for your review.


no such name A netbird.selfhosted

I can ping & telnet peer device; but browser visit peer device's http service not work; I capture the network by wireshark.

I use another vpn for global proxy to make this problem.


feat: Get component from default protocol if not exist

What this PR does / why we need it:
Get component from default protocol if not exist
Which issue(s) this PR fixes:
Fixes #
Specified Reivewers:
/assign @sfwn

test it using rendering in yaml.

/approve


chore: Delete redundant test file that doesn't do anything.

Issue #

https://github.com/awslabs/aws-sdk-swift/issues/1194
Description of changes

The PR https://github.com/awslabs/aws-sdk-swift/pull/1327 takes care of this TODO item.
New/existing dependencies impact assessment, if applicable

Conventional Commits

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

STSWedIdentityCredentialsProviderTests.swift
   ^^^

what about the other days of the week???

🤣


download: set custom User-Agent header

Codecov Report

Merging #251 into master will decrease coverage by 1.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #251      +/-   ##
==========================================
- Coverage   68.91%   67.72%   -1.20%
==========================================
  Files          33       33
  Lines        3018     3018
==========================================
- Hits         2080     2044      -36
- Misses        735      778      +43
+ Partials      203      196       -7


CHAZ-01/01 supported?

I have connected one CRCA-00/04 thermostat and one CHAZ-01/01 actuator (connected to a Dimplex oven) for testing. The thermostat works great, but for the CHAZ-01/01 I'm only getting signal strength and the following errors in the Xcomfort log:
At initial loading from ECI:

unknown status 0 for unsupported device 55
(device 55 refers to CHAZ-01/xx)
Device 5939337 (channel 0-'Varme trimrom (Settpunktsinnstilling)') sent message (battery mains-powered, signal weak, cyclic false) unknown

Repeating:
-Unknown channel 0 for device E-Radiator Actuator (CHAZ-01/xx)
Is the CHAZ-01/01 supported?

Currently unsupported, but I can take a look at it.

That is very much appreciated!

Attempted fix in 0.45, please try. There is scant information about the workings of this device and it seems to have been discontinued a while ago, so I am having a very hard time finding out how this device really works.
Turn on verbose and send me logs, so that I can verify that things are working. You will have to follow the instructions in https://github.com/karloygard/hassio-addons/blob/master/xcomfort/DOCS.md to send the current temperature to the actuator. I don't know if the actuator needs updated values every 30 minutes, the documentation I found said nothing about it. Other than that, the actuator will show up as a climate device in Home Assistant, and should be trivially controllable.

Thanks a lot, updated to 0.45 and get the log below. I understand I need to add the following code
description: Update current temp on change or every 30 min
trigger:

platform: state
entity_id: sensor.{name of the sensor}
platform: time_pattern
minutes: '/30'
condition: []
action:
service: number.set_value
target:
entity_id: number.{name of the heating actuator}_current
data_template:
value: '{{ states(''sensor.{name of the sensor}'') }}'

Should this be in the main configuration file?
Log:
2021/11/12 08:11:11 EPROM: [d1115a0001800a002032313a31303a323920]
2021/11/12 08:11:11 EXTENDED: [d110640001800a00]
2021/11/12 08:11:11 EPROM: [d111640001800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d1106e0001800a00]
2021/11/12 08:11:11 EPROM: [d1116e0001800a000000bd00486a656d6d65]
2021/11/12 08:11:11 EXTENDED: [d110780001800a00]
2021/11/12 08:11:11 EPROM: [d111780001800a00204d5246206d69677261]
2021/11/12 08:11:11 EXTENDED: [d110820001800a00]
2021/11/12 08:11:11 EPROM: [d111820001800a0074652076650044da7500]
2021/11/12 08:11:11 EXTENDED: [d1108c0001800a00]
2021/11/12 08:11:11 EPROM: [d1118c0001800a0045746865726e65742d43]
2021/11/12 08:11:11 EXTENDED: [d110960001800a00]
2021/11/12 08:11:11 EPROM: [d111960001800a0049000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d110a00001800a00]
2021/11/12 08:11:11 EPROM: [d111a00001800a00000000409dba83d1fd88]
2021/11/12 08:11:11 EXTENDED: [d110aa0001800a00]
2021/11/12 08:11:11 EPROM: [d111aa0001800a008d0d632ad85500000000]
2021/11/12 08:11:11 EXTENDED: [d110b40001800a00]
2021/11/12 08:11:11 EPROM: [d111b40001800a0000000030c0a801bd0000]
2021/11/12 08:11:11 EXTENDED: [d110be0001800a00]
2021/11/12 08:11:11 EPROM: [d111be0001800a000c0000002200f8010180]
2021/11/12 08:11:11 EXTENDED: [d110f80101800a00]
2021/11/12 08:11:11 EPROM: [d111f80101800a0002200c3120657461736a]
2021/11/12 08:11:11 EXTENDED: [d110020201800a00]
2021/11/12 08:11:11 EPROM: [d111020201800a00650001200b4b6a656c6c]
2021/11/12 08:11:11 EXTENDED: [d1100c0201800a00]
2021/11/12 08:11:11 EPROM: [d1110c0201800a0065720002400b5472696d]
2021/11/12 08:11:11 EXTENDED: [d110160201800a00]
2021/11/12 08:11:11 EPROM: [d111160201800400726f6d00]
2021/11/12 08:11:11 EXTENDED: [d110c80001800a00]
2021/11/12 08:11:11 EPROM: [d111c80001800a005661726d65207472696d]
2021/11/12 08:11:11 EXTENDED: [d110d20001800a00]
2021/11/12 08:11:11 EPROM: [d111d20001800a00726f6d20285365747470]
2021/11/12 08:11:11 EXTENDED: [d110dc0001800a00]
2021/11/12 08:11:11 EPROM: [d111dc0001800a00756e6b7473696e6e7374]
2021/11/12 08:11:11 EXTENDED: [d110e60001800a00]
2021/11/12 08:11:11 EPROM: [d111e60001800a00696c6c696e6729000000]
2021/11/12 08:11:11 EXTENDED: [d110f00001800a00]
2021/11/12 08:11:11 EPROM: [d111f00001800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d110fa0001800a00]
2021/11/12 08:11:11 EPROM: [d111fa0001800a0000000008000101200202]
2021/11/12 08:11:11 EXTENDED: [d110040101800a00]
2021/11/12 08:11:11 EPROM: [d111040101800a00400000004c656b6b6173]
2021/11/12 08:11:11 Datapoint 2: device E-Radiator Actuator (CHAZ-01/xx), serial 5939337, channel 0, mode 0, 'Varme trimrom (Settpunktsinnstilling)'
2021/11/12 08:11:11 Level: 1.2.0, location [Kjeller, Trimrom, ]
2021/11/12 08:11:11 EXTENDED: [d110080101800a00]
2021/11/12 08:11:11 EPROM: [d111080101800a004c656b6b61736a652062]
2021/11/12 08:11:11 EXTENDED: [d110120101800a00]
2021/11/12 08:11:11 EPROM: [d111120101800a0061642068616c6c202028]
2021/11/12 08:11:11 EXTENDED: [d1101c0101800a00]
2021/11/12 08:11:11 EPROM: [d1111c0101800a004b616e616c2041290000]
2021/11/12 08:11:11 EXTENDED: [d110260101800a00]
2021/11/12 08:11:11 EPROM: [d111260101800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d110300101800a00]
2021/11/12 08:11:11 EPROM: [d111300101800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d1103a0101800a00]
2021/11/12 08:11:11 EPROM: [d1113a0101800a0000000005060202200000]
2021/11/12 08:11:11 EXTENDED: [d110440101800a00]
2021/11/12 08:11:11 EPROM: [d111440101800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d1104e0101800a00]
2021/11/12 08:11:11 EPROM: [d1114e0101800a0000000000030000000000]
2021/11/12 08:11:11 Datapoint 1: device Binary Input, Battery (CBEU-02/02), serial 6491427, channel 0, mode 1, 'Lekkasje bad hall (Kanal A)'
2021/11/12 08:11:11 Level: 2.0.0, location [1 etasje, , ]
2021/11/12 08:11:11 EXTENDED: [d110580101800a00]
2021/11/12 08:11:11 EPROM: [d111580101800a00526f6d6b6f6e74726f6c]
2021/11/12 08:11:11 EXTENDED: [d110620101800a00]
2021/11/12 08:11:11 EPROM: [d111620101800a006c207472696d726f6d20]
2021/11/12 08:11:11 EXTENDED: [d1106c0101800a00]
2021/11/12 08:11:11 EPROM: [d1116c0101800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d110760101800a00]
2021/11/12 08:11:11 EPROM: [d111760101800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d110800101800a00]
2021/11/12 08:11:11 EPROM: [d111800101800a0000000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d1108a0101800a00]
2021/11/12 08:11:11 EPROM: [d1118a0101800a000000000c020101200202]
2021/11/12 08:11:11 EXTENDED: [d110940101800a00]
2021/11/12 08:11:11 EPROM: [d111940101800a0040000000000000000000]
2021/11/12 08:11:11 EXTENDED: [d1109e0101800a00]
2021/11/12 08:11:11 EPROM: [d1119e0101800a0000000000030000000000]
2021/11/12 08:11:11 Datapoint 3: device Room Controller (with Switch) (CRCA-00/01..04), serial 6129618, channel 0, mode 1, 'Romkontroll trimrom'
2021/11/12 08:11:11 Level: 1.2.0, location [Kjeller, Trimrom, ]
2021/11/12 08:11:11 EXTENDED: [d110a80101800a00]
2021/11/12 08:11:11 EPROM: [d111a80101800a0044f8722067617261736a]
2021/11/12 08:11:11 EXTENDED: [d110b20101800a00]
2021/11/12 08:11:11 EPROM: [d111b20101800a0065202829000000000000]
2021/11/12 08:11:11 EXTENDED: [d110bc0101800a00]
2021/11/12 08:11:12 EPROM: [d111bc0101800a0000000000000000000000]
2021/11/12 08:11:12 EXTENDED: [d110c60101800a00]
2021/11/12 08:11:12 EPROM: [d111c60101800a0000000000000000000000]
2021/11/12 08:11:12 EXTENDED: [d110d00101800a00]
2021/11/12 08:11:12 EPROM: [d111d00101800a0000000000000000000000]
2021/11/12 08:11:12 EXTENDED: [d110da0101800a00]
2021/11/12 08:11:12 EPROM: [d111da0101800a0000000001040000000000]
2021/11/12 08:11:12 EXTENDED: [d110e40101800a00]
2021/11/12 08:11:12 EPROM: [d111e40101800a0000000000000000000000]
2021/11/12 08:11:12 EXTENDED: [d110ee0101800a00]
2021/11/12 08:11:12 EPROM: [d111ee0101800a0000000000030000000000]
2021/11/12 08:11:12 Datapoint 4: device Door/window sensor (CDWA-01/3x), serial 7581257, channel 0, mode 0, 'Dør garasje ()'
2021/11/12 08:11:12 Read datapoint list from eprom in 552.410683ms
2021/11/12 08:11:12 Sent MQTT autodiscover add for 4 devices and 4 datapoints

Did you substitute {name of the sensor}and {name of the heating actuator} in the automation?
You seem to already have a room controller, is that controlling the heating actuator?

Did you substitute {name of the sensor}and {name of the heating actuator} in the automation?
You seem to already have a room controller, is that controlling the heating actuator?

Yes, here is the full automation in the automations.yaml:
description: Update current temp on change or every 30 min
trigger:

platform: state
entity_id: sensor.romkontroll_trimrom
platform: time_pattern
minutes: '/30'
condition: []
action:
service: number.set_value
target:
entity_id: number.varme_trimrom_settpunktsinnstilling_current
data_template:
value: '{{ states(''sensor.romkontroll_trimrom'') }}'

I have a sensor (CRCA 00/04) named romkontroll_trimrom which should switch the CHAZ on/off. These are not connected in MRF, both are only connected to the ECI.
I tried to create a thermostat with the romkontroll_trimrom sensor and the CHAZ heating actuator. This did not work. I have not figured out how to turn the CHAZ on/off yet. New to Home Assistant.

Don't worry about setting the operation, it should be updated by the actuator itself.
The MRF log is useful, it clearly states that the setpoint is sent to the actuator and acked. If you manually set number.varme_trimrom_settpunktsinnstilling_current, that temperature should be sent to the actuator, and it should attempt to reach that temperature. Can you use MRF to verify that the value is sent to the actuator?

Don't worry about setting the operation, it should be updated by the actuator itself.
The MRF log is useful, it clearly states that the setpoint is sent to the actuator and acked. If you manually set number.varme_trimrom_settpunktsinnstilling_current, that temperature should be sent to the actuator, and it should attempt to reach that temperature. Can you use MRF to verify that the value is sent to the actuator?

Perhaps I got this backwards. I thought number.varme_trimrom_settpunktsinnstilling_current is the current temperature, which is sent to the actuator from the sensor through the automation script?
I have made a thermostat in HA with the entity climate.varme_trimrom_settpunktsinnstilling.

When a target temperature is set, this is sent to the actuator with the MRF log below:

You were correct, number.varme_trimrom_settpunktsinnstilling_current is the current room temperature, climate.varme_trimrom_settpunktsinnstilling is the desired temperature.
The MRF log looks somewhat strange, although it could be showing the actual routing of the messages. Have you double checked that all actuators are updated with correct data and that the DPL has been updated in the ECI?
If everything else is in order, you can use MRF to route the room controller directly to the CHAZ and log the messages that they are sending between them. That way we can verify the operation of the heating actuator and see that we are sending the correct messages to it. (The room controller we already know works.)

You were correct, number.varme_trimrom_settpunktsinnstilling_current is the current room temperature, climate.varme_trimrom_settpunktsinnstilling is the desired temperature.
The MRF log looks somewhat strange, although it could be showing the actual routing of the messages. Have you double checked that all actuators are updated with correct data and that the DPL has been updated in the ECI?
If everything else is in order, you can use MRF to route the room controller directly to the CHAZ and log the messages that they are sending between them. That way we can verify the operation of the heating actuator and see that we are sending the correct messages to it. (The room controller we already know works.)

I have gone through the MRF set-up, replaced the heating actuator (in case it was fault), set up a seperate MRF project with only sensor, ECI and heating actuator (to eliminate any conflict with SHC and routing). Still same effect, see log below:

I have a number of CHAZ 01/01 connected to SHC, and looking at the log I see the following differences:

SHC never uses "Office-Mode", mainly Comfort and Eco
In line 3 in the log above, the sensor send current temperature to ECI, followed by "1308.8K". Not sure what this means, but in with SHC this is always "0.0K".

I tried to connect the sensor directly to the CHAZ in MRF. This is not possible with this thermostat (CRCA 00/04). I think CRCA 00/06 or 07 is needed for this operation.
Everything seems to work good except that I'm unable to turn heating on/off in the HA thermostat.

If it works with SHC, that helps a lot. Can you capture some more of the traffic from SHC?

Tweaked the messages in 0.46, test it and report back. In particular interested in whether the messages in MRF now are the same as from the SHC.

Thanks again for your help on this. I have updated to version 0.46. Still not turning on heat, here are logs from HA and MRF:
Sending a temperature in HA to CHAZ:

Sending a temperature in MRF to CHAZ:

Logs from other CHAZ-01/01 in the system connected to SHC and working properly:
Sending temperature from SHC to CHAZ (comfort mode changing temp to 22 degrees):

Sending Economy mode (19.5 degrees) from SHC to CHAZ:

Turning off heating in the zone (through SHC app):

Turning on heating in the zone /through SHC app):

The last log from turning on heating in the zone is interesting. SHC initially sends temperature 0,0 and the the set temperature (21,5). Here is the enture log turning on heat for 3 CHAZ-01/01 in kitchen (1) and living room (2):

Hope this helps :-)

Looks fine so far, the setpoint commands are at least the same as the SHC commands. Can you do the same test with sending the current temperature?

The HA sensor in MRF log:

The same type sensor (CRCA 00/04) sending temperature to SHC:

This also looks fine, "Romkontroll trimrom" is sending 16.6C + wheel is turned down to -3C. We presently just drop the wheel position on the ground, but that's under control.
I need to see a message where ECI is sending a temperature command to the CHAZ. Formerly, this had the 1305.8K wheel position, which seemed completely broken.

It looks OK now (temp sent to CHAZ when the automation is executed):

Yeah, you can't turn the actuator on and off with the flame button, only by setting the current temperature.
Awesome that you got it to work! I'm a little confused by the 0.4 value, I'm sending zero, but if it works...

Dear @kstormhansen can you tell how you made it work? I am not able to get the multiheat channel status in HA, so it is always unkown.
flame is always off.
thank you.
@karloygard thank you for your great work.


Gnosis chain deployment

Website
http://gnosis.io/
ChainId
100

Deployed on https://gnosisscan.io/address/0x914d7fec6aac8cd542e72bca78b30650d45643d7


About.Cshtml page is missing

I have followed the same procedure as shown above but I don't see any About.CShtml and Content.Cshtml pages. How can I get that pages?

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

ID: 2ab4333f-c992-f580-5a1f-cfc60bcfb650
Version Independent ID: e354bcf5-e277-8d35-9850-e5accfb8ace8
Content: Create an ASP.NET Core web app in C# - Visual Studio
Content Source: docs/ide/quickstart-aspnet-core.md
Product: visual-studio-windows
Technology: vs-ide-general
GitHub Login: @TerryGLee
Microsoft Alias: tglee

@vij9218 Thanks for letting us know; I'll investigate and report back.

@vij9218 Thanks again for your feedback; with the recent integration of .NET Core 3.0 in to Visual Studio 2019, the About page became obsolete. We've changed the quickstart to use a page that is available in the new version of .NET Core 3.0. Thanks for helping us improve the documentation!


Adding helpers to get selected ProjectItem and selected ProjectItem…

Adding helpers to get selected ProjectItem and selected ProjectItem…'s Project.
This also fixes error when invoking "Managing client side libraries" Project menu option and there are no projects selected.
Adding check to delete files only if exists.

Closing and opening a new one


disable copy construction for homestore superblock

with copy construction, superblock will be easy to cause duplicated metablk when call write() function if it is not carefully enough. we can avoid this by disable copy construction and only allow move construction.

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (87b40b0) 70.27% compared to head (52e7f76) 70.37%.

Files
Patch %
Lines

src/include/homestore/index_service.hpp
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #246      +/-   ##
==========================================
+ Coverage   70.27%   70.37%   +0.09%
==========================================
  Files          97       97
  Lines        7944     7953       +9
  Branches     1017     1018       +1
==========================================
+ Hits         5583     5597      +14
+ Misses       1870     1866       -4
+ Partials      491      490       -1

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

Can you bump homstore patch version assuming it compiles successfully with homeobj?

yes, I can bump homestore patch version for this.  but homeobject need make little changes to build successfully because indextable interface is changed.


Implement batched query support

Only Dense queries are accelerated currently
Certain features are awaiting on GATs/generic const expressions

Objective
Fixes #1990
Solution

Implement a batch-oriented view of the Bevy ECS suitable for SIMD acceleration, with overalignment as a compile-time guarantee

Changelog

Added a `WorldQueryBatch`` trait to support batched queries
Added a MAX_SIMD_ALIGNMENT constant that table columns are aligned to
BlobVecs are now aligned to MAX_SIMD_ALIGNMENT to support batching
SimdAlignedVec type was added to provide MAX_SIMD_ALIGNMENT on the inner buffer, providing Vec-like semantics
Tests have been added for the new functionality
Docs too (with runnable examples)
Benchmarks

A detailed discussion can be found in #1990 , including benchmarks justifying why batched queries are worth implementing.
Benchmarks can be found here: https://github.com/inbetweennames/bevy-simd-bench
Migration Guide
No breaking changes.
Fixes #6161

Wow, you're fast!!  I will see about getting these finished in the coming days, thanks for your patience :)

Happy Thanksgiving!
Hah, I'm glad I wrote tests.  Found a few soundness issues thanks to the Miri CI we have here.  You bet I'll be running that locally now too :) fortunately the issues weren't fundamental.
Currently working on the remaining documentation related problems now that the soundness issues have been resolved.
There's a few ways of using the API and the current example only shows the more "advanced" way with repr(transparent).  It's now possible to more easily use batches with a non-"transparent" API using the map and as_array functions of the AlignedBatch trait.  The tradeoff is that it seems to optimize worse -- the Rust docs seem to indicate that the performance situation is a little finicky with array maps.  In a quick test I did, I saw loads and stores that could have been easily optimized out appearing in the assembly.  The docs recommend using the iter() API instead -- maybe I'll play around with that later this week after I clean up the docs a bit more.

Thanks very much for your comments @BoxyUwU -- this is a learning experience in Rust for me and I'll work at addressing yours (and the rest of @alice-i-cecile 's ) comments over the next few weeks.  I think delaying until GATs are stable makes sense and I can actually start readying the code for that in the meantime.  Thank you for your patience :)

Next up on my list is to get one of the Bevy examples going with batched queries (in a very limited way) to demonstrate batched queries a bit better.  Thanks for your comments and your patience everyone.

Not a problem! It's been great to see this slowly progress.

@InBetweenNames can you please mark in the PR description that this Fixes #6161 so that it gets auto-closed when this is merged?

@InBetweenNames can you please mark in the PR description that this Fixes #6161 so that it gets auto-closed when this is merged? I'll give this a review soon. This has been quite the API hole compared to what Unity's ECS has that Bevy sorely needs.

Not a problem!  I have some more changes coming down the pipeline when I get the energy to make the API a little friendlier.  With the stabilization of GATs being imminent, I'd like to clean up the code with those (not a big change), and also restructure for_each_mut_batched to work similar to the following:
    for_each_mut_batched::<4>( |((mut a, Align16), (b, Align32))| {

        println!("a: {:?} b: {:?}", a, b);

    } );

That is, the Align parameter now becomes per-component, which is way more flexible.  As a bonus, I can provide a for_each_mut_batched variant that doesn't care about alignment -- with the usual caveats that would imply in terms of codegen.
For the above example, such a variant would be equivalent to:
    for_each_mut_batched::<4>( |((mut a, Unaligned), (b, Unaligned))| {

        println!("a: {:?} b: {:?}", a, b);

    } );

Simple, safe, effective :)
Can't promise any timelines for that (hopefully this month), but I am working on it in the evenings here.  Bevy is in a very unique position to provide HPC primitives like this :)  Down the pipeline, we can look at avoiding false-sharing in a type-safe and compile time checked manner when doing batching across multiple threads, too.  That's my dream toolkit for simulations right there :)

Alright, managed to get this ported over to the new GAT way of doing things and simplified a lot in the process.  However, the per-component alignment feature isn't implemented yet.  I'm going to try seeing if I can use typenum to automatically compute it, which would keep things still relatively simple while still not relying on generic const expressions (which seem to have some foundational problems).  I've moved the PR over to "draft" status as I don't think it should be merged before alignments can be manually set per component or they can be automatically computed.  Still, it's worth reviewing the changes so far as what is committed shouldn't change drastically after those "feature complete" changes are in.

I took a little detour to try out what this would look like if generic_const_exprs were stable, and it's actually really nice:

q.for_each_mut_batched::<4>(
                |(mut position, velocity)| {
                    //Scalar path
                },
                |(mut position, velocity)| {
                    //Batched path
                });

Code provided here: https://github.com/inbetweennames/bevy/tree/generic_const_exprs
All alignments automatically computed, absolutely zero work needs to be done by the user to do anything, and the autovectorizer loves it.  The type is very simple to understand too: AlignedBatch<T, N> automatically has the correct batch alignment computed using the gcd!  Literally all the user needs to do is select the batch size N, provide a scalar and vector path, and the rest is taken care of for you.  It really is that nice.
(One can dream!)
Obviously I can't propose that for merging, but it does serve as an important design validation point that you really can make some trivial changes to the code once it is possible to evaluate const expressions in generics and just have this for free.  I suppose this could be hacked in with typenum too, maybe... might be worth a shot.

Bad news :( ... even with the typenum hackery, it seems this can't be done on stable as it's not possible to get the size of a type T as a typenum without using generic_const_exprs.  Therefore, it seems the best we can do (for now, on stable) is implement the per-component manual alignments as described previously.  That's okay, because the "unaligned" variant can then be promoted to "alignments automatically derived" without code changes once generic_const_exprs are stable, and the manual aligned version can easily migrated off.  I'll go ahead and start working on that.  The API is still very usable this way :)

I was wrong!
It is indeed possible to do this with typenum, but it makes the code a giant mess, and likes to cause internal compiler errors in rustc.  It requires a patched typenum that supports const generics (a U<N> = UN type) and a new trait, SizeOfAsTypenum, which can be conveniently hacked into the derive macro for Component.  SizeOfAsTypenum defines a type Output that is set by the implementor to be the size of the type as a typenum.  Since this is not a generic context, it is indeed possible to use sizeof here :) (it looks like type Output = U< { sizeof::<T>() }>, hence the dependency on the patched typenum).  SizeOfAsTypenum needs to be manually implemented for other, non-component types, which isn't great (and attempting to provide an implementation generically will, of course, require generic_const_exprs).
However, even without the ICEs, this is still a gigantic hack and (I expect) unlikely to be accepted.  I think given the options of pushing a little bit of complexity onto the user versus putting a lot of complexity in Bevy to automatically derive the minimum alignments (on stable Rust), it makes sense to prefer the former path.  This still provides for a clean upgrade path when generic_const_exprs are stable that reduces both user and implementation complexity compared to the manual alignment approach.

I agree with that assessment!

iamthetypesystem.jpg

Small update -- I was unable to get to the proposed implementation without (again) hitting the limits of the type system in Rust as it currently exists.  So the proposed:

    for_each_mut_batched::<4>( |((mut a, Align16), (b, Align32))| {

        println!("a: {:?} b: {:?}", a, b);

    } );

isn't implementable without generic_const_exprs, which if those were stable, we'd just use the automatic approach that already has been proven to work in the branch I discussed earlier.  I'll discuss the exact limitation of Rust's type system in a moment that gets us in trouble, but first I want to discuss what I think is a suitable compromise:

            //Align32, Align16, etc, are just type synonyms for Align<N> from the `elain` crate
            //type Unaligned = Align<1>;
            q.for_each_mut_batched::<4, (Align32, Align8, Align16, Unaligned)>(
                |(mut a, b, c, d)| {
                    //scalar
                },
                |(mut a, b, c, d)| {
                    //batched
                });

The above works just fine and is what I'm going to propose for merging after I clean it up a bit and move the definitions to a new file.  The main difference is that the alignments can't be passed inline with the arguments as before -- they must be passed as a generic parameter.  Unfortunately, Rust's type system again strikes here, where it is not possible to default this to "Unaligned" (i.e. Align<1>).  The reason for this is discussed in this thread (most recent comment linked):
https://github.com/rust-lang/rust/issues/36887#issuecomment-1041515594
However, another approach is easily worked around for this: we provide a new function where this is defaulted using another associated type, for the unaligned case.  That machinery is pretty unobtrusive, even if it is a bit of a hack.  Unfortunately, that machinery is more verbose than it needs to be due to associated_type_defaults again not being stable lol.  Still, it's not too bad.
If you want the power of stipulating manual alignments because you need that, it is in your hands -- otherwise, no need to worry about it.  This should help discoverability of batching and vectorization in general.
On the topic of discoverability, what I propose is to make the "Unaligned" interface the default for simplicity, as there's only a handful of architectures that really care about alignment hints, or have instruction opcodes that demand aligned operands.
For example, x86-64-generic" targets SSE2, and a good chunk of SSE2 instructions demand naturally aligned operands.  Therefore, without being able to prove natural alignment, the compiler must emit more movup*instructions for the generic x86-64 target and do work in registers, which will hurt performance.  So,Align<16>clearly helps here.  Even though newer processors don't make a distinction between "aligned" and "unaligned" variants of instructions (the "unaligned" variant performs as fast as "aligned" so long as the data is actually well aligned), you still pay a price.  Older processors will of course pay a much steeper price.   As another example,armv7a` with NEON also accepts alignment hints (which are free to be ignored by the implementation).
Truly modern architectures (things made in the last 10 years)
Of course, truly modern x86 (AVX support and above) makes the full instruction set available for unaligned operands thanks to VEX/EVEX encodings.  AArch64 in a similar vein has no "aligned" variants of instructions at all.  In both cases, full performance is achieved if the memory operands are naturally aligned, but the instructions don't need to encode that alignment themselves -- meaning there is nothing for your compiler to really do here.  We could simply ignore alignment and follow suit, simplifying this PR, but I want to stress that AVX is not in the default enabled instruction sets for  x86-64.  Even if we move the x86-64-v2, that only enables SSE4_2.  It takes x86_64-v3 and above to enable AVX support in the compiler, and so far, I've only seen discussion about moving the default x86-64 target to v2.  Also, if Bevy were to ever run on embedded platforms, you'd really want this to eek out every last drop of performance possible.  Or, maybe running Bevy systems someday as GPU kernels?
Type madness
I saved this part for the end to not have to inflict it on poor souls casually passing by.  You've been warned!
The exact limitation I ran into when trying to implement the former interface is that Rust GATs unfortunately only mirror Haskell's "type families" (which represent "injective" relationships) and there is no way to assert that the combination of alignment specifiers is "unique" with respect to a trait.  In formal language terms, you say there is a possibility of "ambiguity" here.  The other side of higher kinded types is the ability to model bijective relationships, where you can indeed make that assertion and "work backwards".  At the call site, when we say, for example, |Batch16(mut a), Batch8(b), Batch4(c), Batch32(d)|, without that kind of functional dependency (sometimes called fundep in Haskell space), there is no way to assert to Rust that there is exactly one appropriate derivation for that sequence of arguments.  Things get even more complicated when you consider weird queries like Query<(&A, (&B, (&C, &D)))>, which are nested.  Even if you enforce a flat hierarchy by introducing a new trait (say, WorldQueryBatchBase) to exclude this possibility, having WorldQueryBatch impls for the query tuples depend on those , without generic_const_exprs you can't have WorldQueryBatchBase::fetch_batched return some kind of BatchT<Self::MIN_ALIGN, Self::FullBatchType>, as MIN_ALIGN would have to be chosen by the implementor 🙃...
Conclusion
So... I'm fairly confident that on stable rust, the new proposed interface at the start of this post is the best we can do, with an "unaligned" and a separate "manually aligned" interface for the use cases outlined above.  When generic_const_exprs are stable someday, we can eliminate the "manually aligned" variant and automatically upgrade users of the "unaligned" variant to the "automatically aligned" version without breaking any backwards compatibility as the interface is the exact same.
Until next time!

Small update; code has been reworked, but I'm trying to find a way to recommend using batches without using the array map function, which optimizes horribly for some reason.  TransparentWrapper from bytemuck may be the way to go, but I'll be exploring options over the coming days.  If anyone has ideas on how to do this, your advice would be most welcome.   It may be that we just recommend people to unroll their batches manually such as let [Position(p1), Position(p2), ..., Position(pn)] = batch to handle these kinds of cases.

So it seems array::map can be fixed, and there is work upstream on doing that: here and here.  It is also possible to provide a new trait to use the proposed implementations that fix these problems, e.g. ArrayMap.  I found in my own tests, taking the array by reference instead of by value (move) was sufficient for the compiler to generate sane code for a map function.  Of course, this is solely to work around the poor performance of array::map.  Since it seems like the upstream implementation is likely to be fixed in the next 6 months, I'm going to go forward and recommend users unroll their batches manually as mentioned before.  There's no sense in introducing a new trait due to an upstream bug IMO, which would be obsolete as soon as it's fixed.
It's curious that the upstream API takes the array by move -- it seems there's no real benefit to doing that and it makes the function harder to optimize.  I should try to dig up some of the discussion around array_map and figure out what's going on there.
With that said, all that's left to do is update the examples and docs and satisfy the CI here.  At which point, I'll mark this again for review.  Shouldn't be too long now :)

I have an idea for a new example to showcase this PR, but I haven't had time to get it implemented with benchmarks and everything.   However, I think the actual code itself is ready for review.
A universal "batching is always better" example is very hard to write, because hardware isn't universal.  The best I've been able to come up with, in stable rust at least, is using x86 AVX intrinsics directly to perform a layout transform and doing some math that way.  AVX intrinsics are not beginner friendly though, and I'm concerned about putting those into an example that is intended to be beginner friendly.  std::simd helps here, but it isn't available in stable Rust unfortunately -- and has it's own problems (that appear to be being worked on).
I think some properties for a good enough example would be:

Has to be realistic, not contrived in any way: e.g., collision detection, some kind of physics, etc
If it uses core::arch intrinsics, has to be relatively portable, and can't use anything "too deep"

If it doesn't, and it relies on autovectorization, then it must be very obvious, because rustc/LLVM is fickle between versions on what it will autovectorize and what it won't.

It can't be too complicated: ideally it shouldn't define a bunch of types, etc, and should be short
It shouldn't be worse than letting rustc autovectorize everything.

So far, I have a contrived example involving explosions and damage calculations, but I fear it's not super realistic with what you might actually see in a game.  I was thinking maybe a collision detection off a solid plane would make more sense to implement, and might not be too much longer.
For now, I took out the old example because it wasn't very good -- on recent rustcs, it got unrolled and autovectorized optimally, making batching actually perform worse as rustc couldn't optimize the batched version as easily.
From this point onwards I'll focus on the documentation and seeing what we can do for a cool "intro example" for vectorized queries.

Hey all, just lettying you know I haven't forgotten about this.  I've found a suitable example using collision detection that is easy to explain and directly benefits from batched queries.  It's simply doing an inside/outside test of a convex polygon with respect to a set of entities.  So we've got some dot products, comparisons, etc, but nothing crazy, and it's something you might expect to see in an actual game.  Currently working on getting that written up in a non-ugly way for inclusion.  Unfortunately, due to std::simd being unstable, I have to write it using core::arch intrinsics.  I hope that's not a dealbreaker!
On a side note, Rust seriously needs some kind of copy elision baked into the standard:

What you're seeing here is literally the following:

"copy this crap to my stack, then load the stuff i just copied into my stack into registers"

This seems to be a similar problem as we've seen with array::map, where copies aren't elided when they could be.  In C++, we have guaranteed copy elision which helps in some cases as this gets enforced in the language frontend.  In Rust, it seems that the lower levels of the stack are relied upon to get rid of extraneous copies, but it's a little flakey.
Otherwise, even with that shortcoming, the code still outperforms its scalar and autovectorized counterparts.
On the topic of benchmarks, it's my hope that I can move the ones out of my bevy_simd_bench repo into the main tree without much fuss.

On the topic of benchmarks, it's my hope that I can move the ones out of my bevy_simd_bench repo into the main tree without much fuss.

Excellent: these will be much easier to merge in their own PR.

The new example and associated benchmark are up.  Results look good!

This benchmark has been included in the main Bevy benchmark suite.  To run it, ensure you have AVX enabled -- the suite will exclude it it isn't enabled.

@alice-i-cecile @james7132  @BoxyUwU @TheRawMeatball I think this is now fully ready for review!
For example usage, see this benchmark 😄

Awesome :D I'll aim to do a full review by the end of next Monday: there's a ton of ECS work in the air right now.

Sounds good, no rush! :)

No changes in the latest commit; just rebased.  I see some new verbiage in main about "BatchedStrategies" for parallel queries.  That's cool -- just wondering if maybe a different name should be given to this different concept introduced in this PR to avoid confusion.  While similar, the intent is different: the batching introduced in this PR is about processing batches of N components at a time using SIMD, whereas parallel batch sizes appear to be more about managing overhead and synchronization costs when executing a query across multiple threads.  I'm open to suggestions here :)

When #6773 is merged, I'll port this over to using the new style of iteration.

FYI: did a little reading into the naming convention behind this concept.  EnTT refers to it as "chunked iteration": https://github.com/skypjack/entt/issues/462
How do we feel about using the name "chunk" instead of "batch" for this PR, to set it apart from other uses of "batch" in Bevy?  Is there a better name we could use instead?

[7:27 AM] james7132: On closer inspection, I don't think the batched queries is going to be ready for 0.11 (or even 0.13 at this rate), it's reliance on unstable rust features is probably a non-starter for it.

From @james7132 on Discord. If you can find a way to make it work without this, or convince us that the assessment is wrong / it's worth making an exception, let us know.
Similarly, if you need us to make changes to the internals to allow 3rd party crates that need unstable Rust features to implement this externally, we're also generally very open to that!

Hey Alice, this was an old comment that was addressed already. This code
does not rely on any unstable rust features. Thank you!
On Tue, Feb 28, 2023, 8:22 a.m. Alice Cecile @.***>
wrote:

[7:27 AM] james7132: On closer inspection, I don't think the batched
queries is going to be ready for 0.11 (or even 0.13 at this rate), it's
reliance on unstable rust features is probably a non-starter for it.
From @james7132 https://github.com/james7132 on Discord
https://discord.com/channels/691052431525675048/749335865876021248/1080103960943267911.
If you can find a way to make it work without this, or convince us that the
assessment is wrong / it's worth making an exception, let us know.
Similarly, if you need us to make changes to the internals to allow 3rd
party crates that need unstable Rust features to implement this externally,
we're also generally very open to that!
—
Reply to this email directly, view it on GitHub
https://github.com/bevyengine/bevy/pull/6161#issuecomment-1448173367,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3VLDEEHERTHWTCNL26MULWZX32LANCNFSM6AAAAAAQ4QFHE4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Sorry about that, must have been reading an old version of the PR. Really shouldn't be doing this stuff at 4AM, haha.

Backlog cleanup: this one has a long history of attempts to get it across the finish line! Closing for now due to inactivity, leaving in place the original tracking issue (#1990) and perhaps it could be adopted from there if still needed.


Information Outdated

I am making the assumption that this information is outdated and that Azure is not built on EOS operating systems.
"The OS that runs on all nodes is a customized version of Windows Server 2008 or Windows Server 2012."

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

ID: 2ef67581-8a74-70d9-b0d0-a2a1182dfd32
Version Independent ID: d6bbc00c-1ad5-b1be-1a55-0ac2bdaad261
Content: Azure infrastructure integrity
Content Source: articles/security/fundamentals/infrastructure-integrity.md
Service: security
Sub-service: security-fundamentals
GitHub Login: @TerryLanfear
Microsoft Alias: terrylan

Hi @matthansen0 , thanks for bringing this to our attention. I have assigned the issue to the content author to evaluate and update this doc as appropriate

@Grace-MacJones-MSFT - Thank you for this feedback. This issue has been fixed. Sorry we didn't notify you earlier.
#please-close


Small visual changes

Hi,
It is my first collaboration on gitHub. I am excited about Kanboard, because I think it is a very good system. My intention is to help you on Issues, if it is ok.
This was a very small change, just to see how it all works.
Thank you for your time.
Emerson

Unfortunately, I cannot merge your pull-request, your fork is too old, your are 55 commits behind the current master.
The Brazilian translation is almost up to date, check here:  https://github.com/fguillot/kanboard/blob/master/app/Locale/pt_BR/translations.php
If you want to add a shadow and rounded corner around the card you are better to use the custom stylesheet, that doesn't require any code modification. By the way, don't modify directly the app.css this file is auto-generated, see http://kanboard.net/documentation/assets.
Thanks.


Acquisition speed problem

I set the sensor to continuous mode, and then collected data. I found that the speed of the sensor is very slow, and it can only collect 30 times per second，How to improve the acquisition speed? For example, collect data 100 times per second?

Hi @hupozhao ,
I was able to achieve almost 2000 SPS. I have described it in the tutorial:
https://wolles-elektronikkiste.de/en/4-channel-24-bit-adc-ads1220
Did you use Serial.println() to display the values? Then this is the bottleneck, because it is very slow.

Thank you for reading
Serial port output is really slow, and level 6 SPS has been set.
I now directly read ADS1220 data and write it into SPIFFS.
Currently, only 30 values can be written per second.
I am trying to use different settings to improve the reading speed.
Do you have any good suggestions?
thank you!

Level 6 is good. Moreover you should use the continuous mode and the turbo mode. I have described this in my tutorial. You need to find the bottleneck. First you could try to just read let's say 2000 values without saving them. You can measure the time needed to get the values using millis(). You may need to do something with the values like adding them or so - otherwise the compiler might eliminate the sampling. As I wrote before I was able to get 2000 values in 1034 ms which is what it should deliver.
In a next step I would try to save 2000 float values on the SPIFFS. So no measured values, but just any values.
Then you see what is the bottleneck. If both processes should be fast then it's something with the the combination of these processes. That's how I would analyse the issue.
You could also publish your code here or send it to me (wolfgang.ewald@wolles-elektronikkiste.de). Then I can have a look in the evening.

Hi @hupozhao ,
I have taken your code snippets and have made the small program below out of it:
#include <ADS1220_WE.h>
#include <SPI.h>

#define ADS1220_CS_PIN 5
#define ADS1220_DRDY_PIN 21

ADS1220_WE ads = ADS1220_WE(ADS1220_CS_PIN, ADS1220_DRDY_PIN);

void setup()
{
  ads_Begin();
  Serial.begin(115200);
  ads.setConversionMode(ADS1220_CONTINUOUS);
  ads.setOperatingMode(ADS1220_TURBO_MODE );
  ads.setDataRate(ADS1220_DR_LVL_6);
  ads.bypassPGA(true);
  delay(1000);

  String result = "";
  unsigned long startingTime = millis();
  for(int i=0; i<1000;i++)
  {
    result = ads_Data();
  }
  unsigned long durationTime = millis() - startingTime;
  Serial.println(durationTime);
  Serial.println(result); // just to check
}

void loop(){}

void ads_Begin()
{
  if (!ads.init())
  {
    Serial.println("ADS1220 is not connected!");
    while (1) ;
  }
}

String ads_Data()
{
  ads.setCompareChannels(ADS1220_MUX_0_1);
  float adata = ads.getVoltage_mV();

  ads.setCompareChannels(ADS1220_MUX_2_3);
  float bdata = ads.getVoltage_mV();

  return String(adata, 5) + "," + String(bdata, 5);
}

The only relevant parts I changed were:

I chose GPIO5  as CS, because my ESP32 did not like it when I took the GPIO12
I changed to level 6
I added code to measure the time needed for 1000 times performing ads_Data() which equals 2000 measurements.

The time needed (durationTime) was 1290 milliseconds. This is only a bit slower than the maximum data rate, which would be 1000 milliseconds for 2000 measurements. The reason is the time needed for changing channels and all SPI communication.
However, this is much faster than the 30 measurements per seconds that you have found. The bottleneck must be somewhere else in the rest of your code. At least it's not related with the ADS1220 or the library. I recommend to do similar measurements for the other processes in your code. You said you write the results to the SPIFFS. I don't have much experience with SPIFFS, but I know from writing to SD cards that it slows down very much if you open and close the file every time when you write to it . Could it be something like that?

Thank you for reading @wollewald
The chip I used is ESP32S3. I tested ADS1220 and ADXL355 respectively with the code you gave me. Here is the result:
ADS1220_durationTime:28749
ADS1220_result:-0.10425,0.03394
Failed to obtain time
Device found
ADXL355Started
ADXL355_durationTime:2062
ADXL355_result:0.01313,0.00010,1.00263
I just used the pin：
#define ADS1220_CS_PIN 12
#define ADS1220_DRDY_PIN 21
#define MISO 13
#define MOSI 14
#define SCLK 11
#define SS 12
My hardware has been designed, is my problem with GPIO?

Hi @hupozhao ,
I had problems using GPIO12 as chip select pin and used GPIO5. Maybe you want to try that?

My hardware has been made, so I can't adjust GPIO.I try to add ADS1220_ CS_ PIN, always set to low level.

@wollewald I'll try flying line test GPIO5

Exactly - and good idea to try it at least provisionally. Unfortunately I do not have an ESP32 S3 board available,  otherwise I would test it. Good luck!

Since there was no further feedback I close the issue.


requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://html.duckduckgo.com/html

error:requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://html.duckduckgo.com/html
when i use this code:
ddgs_text_gen = ddgs.text(keywords, region='wt-wt', safesearch='Off', timelimit='y')

There is not enough information in the issue


[ConstraintSystem] Diagnose extraneous arguments via fixes

If there are more arguments than parameters, let's fix this by
ignoring (if possible) or removing extraneous arguments. Ignored
arguments could default to Any if they don't get any other
contextual type.

This is still a draft, apparently I need to diagnose shadowing and destructuring first, otherwise this is going to be too greedy.

Too much is changed since March, I'm going to open a new PR which continues this work.


[BUG] Could not find com.azure:azure-storage-blob:12.4.0.

Describe the bug
Could not find com.azure:azure-storage-blob:12.4.0.
To Reproduce

Generate the project using
https://start.spring.io/#!type=gradle-project&language=kotlin&platformVersion=2.5.3&packaging=jar&jvmVersion=11&groupId=com.example&artifactId=demo&name=demo&description=Demo project for Spring Boot&packageName=com.example.demo
clear local gradle and maven cache
add dependency

implementation("com.azure:azure-storage-blob:12.4.0")

observe error

This also happens on Azure Devops CI, so it's not a local cache issue.
The artifacts still seem to be available on Maven Central.
The builds have worked fine before (last successful on 18th July)
I can't update the dependency as it's a transitive dependency
it also happens with e.g. 12.6.0

We also experienced the same problem with our build.
It seems that for all versions prior to 12.7.0 only the metadata remains in Maven Central. The actual artifacts (pom, jar, javadoc.jar, sources.jar etc) are all gone.
This can be seen by browsing the contents of https://repo1.maven.org/maven2/com/azure/azure-storage-blob. The maven-metadata.xml and folder hierarchy in the repo still contain the older versions, however, the folders corresponding to all versions prior to 12.7.0 are empty.

Hi, all. I am closing as this is a duplicate of #23562 Please see that other issue for information as it comes out. We are aware of this and will have more complete guidance soon.
In the meantime, we recommend upgrading to latest. Please feel free to reopen this issue or create another one if you need assistance there


ci: repo templates for issues, automatic labeling, etc.

We need to define contribution guidelines, create issue templates and automatically label based on key words, etc.

is there any documents on what we would want on these guidelines? i think that adding .probot.js config would help this endeavor. https://github.com/bkeepers/PRobot

I agree with probot.  That's actually next on my list.  I've been playing around with a fork lately and trying to figure out exactly what functionality we're looking for.

probot is the way to go for labels being added automatically based on some matched items in issues/pr's.
we still need guidelines and headings in each of the Chart.yaml, GUIDELINES and OWNERS to match what Kubernetes is doing in their repos.

are there any templates on how we want the issues or PR to look.

The issue and PR templates have been merged in already. I should have the owners file in review here soon


TextInput textContentType='oneTimeCode' not working in React Native 0.62.2 and iOS 13.5

Description
TextInput's textContentType='oneTimeCode' showing OTP above the keyboard but not passing data into TextInput in React Native 0.62.2 and iOS 13.5.1.
React Native version:
System:
    OS: macOS 10.15.5
    CPU: (4) x64 Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
    Memory: 940.63 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.15.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.5, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      API Levels: 25, 28, 29
      Build Tools: 28.0.3, 29.0.1
      System Images: android-25 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.0 AI-193.69<IP_ADDRESS>14223
    Xcode: 11.5/11E608c - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_192 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: ^16.11.0 => 16.13.1
    react-native: ^0.62.2 => 0.62.2

Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

Keyboard pop up
OTP showing above keyboard
When press on the OTP, it doesn't pass value to text input

Expected Results
Passing value into textinput when press the OTP above the keyboard, and clear OTP above keyboard.
code example:
<TextInput
        maxLength={6}
	keyboardType='number-pad'
	textContentType='oneTimeCode'
	onChangeText={onOTPValueChange}
	value={otpValue}
	style={styles.otpInput}
	autoFocus={true}
/>

Videos
Here is error on iOS 13.5.1: https://streamable.com/sj5emu
No error on iOS 13.6: https://streamable.com/wy01io

Interesting, @rratanak is this only affect you on iOS 13? , i will try to replicate this issue on my end.

@gedeagas Yes, only on iOS 13 with rn 0.62.2. I tested on iOS 12 working as expected.

This a bit tricky to reproduce because it requires a OTC service.
@gedeagas were you able to reproduce this?
@rratanak could you provide a video that displays this issue?

@rratanak @safaiyeh just finished debuging this both on my iOS 14 Testing Device and iOS 13 Testing Device. .
Using the same code and react-native 62.2 i can't replicate the problem that @safaiyeh having. The oneTimeCode works perfectly.
Demo
RN 62.2 on iOS 13.
https://streamable.com/4tay7c

@gedeagas  I test again and the problem somehow happens only on iOS 13.5. I have added two videos above to replicate the problem I'm having.
@safaiyeh I have edited and added videos to replicate the problem I'm having. About OTP service, I think you can test by send message to yourself, no need to subscribe to any services.

@rratanak Thank you for the videos! Also, what is the behavior with the latest RN version?

https://github.com/facebook/react-native/issues/22578#issuecomment-510284853

https://medium.com/@shankarmadeshvaran/how-to-implement-automatic-otp-verification-in-ios-7813c6116a1d

Hi, is there any update on the issue yet? I'm facing the same issue on iOS 14, RN 0.70.6 (iOS 16 works fine).
onKeyPress event receives "Backspace" when user taps the OTP suggestion.

It is working for me in iOS. Is there a way to achieve the same functionality in android? I tried with autoComplete="sms-otp" but it didn't work


Updated Packages

Needs to be tested

Fixes keystonejs/keystone#3589

As an aside, using underscore feels duplicative.   lodash is already in package.json and has a template function.  Why not use that?

Thanks @brianjd! @noviny went through a separate update prepping for 4.0 which has been tested, inadvertently merging most of these.

@TaylorAckley good point re: lodash/underscore, it's a small change so we'll include that in the rest of the cleanup we're doing. Thanks for pointing it out!


fix: apply filters to course dashboard datasets (FC-0051)

This change ensures that charts display the expected behavior for various filters applied in the course dashboard. This includes:

all video charts responding to section and subsection filters
the page view engagement chart applies section and subsection filters
the partial and full video views chart uses the correct dataset in addition to using the appropriate filters

This change also includes edits made by running sqlfmt on changed SQL files.

Thanks for the pull request, @SoryRawyer! Please note that it may take us up to several weeks or months to complete a review and merge your PR.
Feel free to add as much of the following information to the ticket as you can:

supporting documentation
Open edX discussion forum threads
timeline information ("this must be merged by XX date", and why that is)
partner information ("this is a course on edx.org")
any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.
Please let us know once your PR is ready for our review and all tests are green.

@SoryRawyer 🎉 Your pull request was merged!  Please take a moment  to answer a two question survey so we can improve your experience in the future.


feat(widget-recents): add toUserEmail to event data

I've created a build from this PR. Should we go through the full release process or point it at develop?

@bzang good call, will do


-m flag always shows modified files from git root

Running gitree -m inside a folder in a Git repository will still list all files from the repository's root.

We can scope git status to the current directory by simply providing . (current dir). This can hook in to #7 later too as we can pass an explicit directory.
The issue here is that --porcelain still returns paths relative to the git repository's root. We could perhaps scoot around this by running a third command, git rev-parse --show-toplevel, which will give us the repository's root. Seems a bit extreme though.


Updates to scripts

Made the scripts for downloading more command-line friendly
removed redundant warnings for the notebooks
added some utils

@nkasmanoff If possible, can you run the refactored SDO downloader and see if it works on your end?  I still get the 408 errors which I still think is something server-side (or perhaps my VPN).

Will take a look and get back to you

Will take a look and get back to you

Ran 0.1_data_download.ipynb, no 408 errors on my side so the issue might be connection related

@jejjohnson left some comments with minor changes that may reduce duplicate code. Imo not a blocker to merging, I can branch off of the spaceml version of this and update later on


some output is not processed correctly

I ran by test with default go test ./... command and it output like this:
...
ok      github.com/bangumi/server/pkg/wiki      (cached)
ok      github.com/bangumi/server/revision      (cached)
ok      github.com/bangumi/server/subject       (cached)
ok      github.com/bangumi/server/user  (cached)
?       github.com/bangumi/server/web   [no test files]
?       github.com/bangumi/server/web/captcha   [no test files]
?       github.com/bangumi/server/web/captcha/hcaptcha  [no test files]
...

Then I add -json flags and pipe to gotestfmt with command go test -json ./... 2>&1 | tee test.log | .bin/gotestfmt -hide empty-packages,successful-tests
sometimes there are extra output shows:
...

📦 github.com/bangumi/server/person
ok      github.com/bangumi/server/person        (cached)
  🚧 TestGet (0s)
  🚧 TestMysqlRepo_GetByIDs (0s)
  🚧 TestMysqlRepo_GetSubjectRelated (0s)

📦 github.com/bangumi/server/pkg/duration

📦 github.com/bangumi/server/web/session
ok      github.com/bangumi/server/web/session   (cached)
  🚧 TestManager_Get_notfound (0s)
  🚧 TestMysqlRepo_Create (0s)
  🚧 TestMysqlRepo_Create_conflict (0s)
  🚧 TestMysqlRepo_Get_ok (0s)
  🚧 TestMysqlRepo_Revoke (0s)
...

these lines ok      github.com/bangumi/server/web/rate      (cached) will show randomly on random packages. I have no idea why they show up.
and you can always re-produce this with certain test output.
I check the raw test output, these lines are included in all packages but only some of them are not processed as expected.
complete output as test cases are attached here.
log.zip
My gotestfmt binary is build from version v2.3.1 with go build -o .bin/gotestfmt github.com/haveyoudebuggedit/gotestfmt/v2/cmd/gotestfmt, which is the latest version currently.

Hey @Trim21 thank you very much for your report, I'll try to fix this in the next few days.

Hello again @Trim21 the bug has now been fixed and is being released as version 2.3.2. The updated version will be available in a few minutes. Please let us know if this doesn't fix the issue with your test runs.

Thanks!


Refactor/schedule

refactor Schedule (list & editing page)

fix flights map widget render error in share page
fix quill bundle error
add .png module typescript typing
add custom hook for table pagination simple or not

由于重构前 Schedule 勾选的 portal 数据存储有错误 id 数据，新版重构后，修改老 Schedule 可能会出现界面勾选不上的问题，这时候可以通过界面删除老数据后，重新勾选解决，如下图：

issue: #1240
It has been resolved after Schedule refactoring.

issue: #1240
It has been resolved after Schedule refactoring.


Blackened Seasoning

https://www.chilipeppermadness.com/recipes/blackening-seasoning/

From NYT Cooking:

2 Parts Smoked Paprika
2 Parts Kosher Salt
2 Parts Onion Powder
2 Parts Garlic Powder
1 Part Red Pepper Flakes
1 Part Dried Thyme
1 Part Black Pepper
1 Part Sumac


Android: Touch and hold delay

Description
Building any UI that has a custom long-press gesture (not the standard system on) should use this setting to determine the proper length to wait to be considered pressed.
React Native version:
v0.63

Google doesn't provide an API for this, so while it's technically possible to query using something like reflection, I don't think it's worth adding the hacky code required to the codebase, especially given its relatively limited use cases.
Closing out.


[Discuss] Supporting bcs::from_bytes(..) in std::bcs

As only primitive or object types are supported for parameters of an entry function, serialization and deserialization may be useful in some cases.
I found that the bcs lib supports encoding and decoding.
And we can serialize user-defined data structures through the TypeScript '@mysten/bcs'.
So I'm wondering if @MystenLabs has the plan to support bcs::from_bytes(...) in std::bcs of Sui Move?

sui::bcs supports some of the use cases you are after

sui::bcs supports some of the use cases you are after

Cool~ This test really makes sense~


No Response from JSON RPC

Using curl commands to reach out to JSON RPC of local-validator node but not receiving any response:
`curl --location --request POST 'http://x.x.x.x:8080/rpc'  --header 'Content-Type: application/json'  --header 'Authorization: Bearer '"$SIWE_TOKEN"''  --data-raw '{
"jsonrpc": "2.0",
"method": "tableland_validateCreateTable",
"params": [{
"create_statement": "CREATE TABLE rpc_counter_6 (id int, name text)"     }]
}' -v
Note: Unnecessary use of -X or --request, POST is already inferred.

Trying x.x.x.x:8080...
TCP_NODELAY set
Connected to x.x.x.x (x.x.x.x) port 8080 (#0)

POST /rpc HTTP/1.1
Host: x.x.x.x:8080
User-Agent: curl/7.68.0
Accept: /
Content-Type: application/json
Authorization: Bearer eyJtZXNzYWdlIjoiVGFibGVsYW5kIHdhbnRzIHlvdSB0byBzaWduIGluIHdpdGggeW91ciBFdGhlcmV1bSBhY2NvdW50OlxuMHhmMzlGZDZlNTFhYWQ4OEY2RjRjZTZhQjg4MjcyNzljZmZGYjkyMjY2XG5cbk9mZmljaWFsIFRhYmxlbGFuZCBTREtcblxuVVJJOiBodHRwczovL3RhYmxlbGFuZC54eXpcblZlcnNpb246IDFcbkNoYWluIElEOiA4MDAwMVxuTm9uY2U6IFV4VTJ2cktHYXR6OEpCMzdGXG5Jc3N1ZWQgQXQ6IDIwMjMtMDEtMDRUMDk6NDY6MzEuMzkyWlxuRXhwaXJhdGlvbiBUaW1lOiAyMDIzLTAxLTA0VDE5OjQ2OjMxLjM5MloiLCJzaWduYXR1cmUiOiIweDhmNTg4NTUyMDE4NmMzMmU3YzhhOTVhOTlhYTkwYjNjNTg3ZThhNDRjNmY5MDFhN2E3Nzg2ZTQwMDM5MDEwYWE1MWE1MzM4NTljY2QzMGM3NzdjZmFkZDM4MDQ0MDEwNGVhY2NjODMyNDIxOGQzZDNlMTc0MzlkNzA0N2RmMzI2MWIifQ==
Content-Length: 177

upload completely sent off: 177 out of 177 bytes
Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: Accept, Accept-Language, Content-Type, Authorization
< Access-Control-Allow-Methods: GET, POST, OPTIONS
< Access-Control-Allow-Origin: *
< Content-Type: application/json
< Trace-Id: 7c004e65-2c0a-45fd-8abe-e459151d7b8a
< X-Ratelimit-Limit: 10
< X-Ratelimit-Remaining: 9
< X-Ratelimit-Reset: Wed, 04 Jan 2023 10:10:29 UTC
< Date: Wed, 04 Jan 2023 10:10:29 GMT
< Content-Length: 0
<
Connection #0 to host x.x.x.x left intact
`
@joewagner any idea about issue resolution?
Can you also provide me a link to the slack channel?

Hey @Keerthana-Bidarakoppa I can definitely try to help get things figured out.
A few questions:
What commands are you using to start local-tableland?
What version of local-tableland, and node.js are you using?
Lastly, you have the url http:x.x.x.x:8080/rpc in your curl command.  Are those xs place holders, or is that the actual command you're running?  If they are placeholders what is the actual url you're using?
re: slack
We don't have a slack channel anymore.  You can find us on discord here: https://discord.gg/dc8EBEhGbg

I use
create a new empty directory and cd into it,
1. mkdir test-local && cd test-local 2. run npm install @tableland/local 3. run npx local-tableland
Local Tableland version - 0.0.5- pre.2
Node.js version - v18.7.0
http:x.x.x.x:8080/rpc using x as placeholder for server IP-> http://:8080/rpc.
Thanks for the Discord link.

@Keerthana-Bidarakoppa I have a couple more questions:

When you start a local network, does the console output look like everything has started correctly? Or are there any error messages?  If things are running correctly you should see the message "Tableland is running!" followed by some ascii art of the tableland logo.
Can you give the actual url you are using?  It should be either http://localhost:8080, or http://<IP_ADDRESS>:8080.  If it's not one of those that might be the root of problem you're seeing.  Can you try starting the network and then navigating to http://localhost:8080/query?s=select * from healthbot_31337_1 in a browser?

Yes, Console output shows everything has started locally and there are no error messages. I can see this - "Tableland is running!" followed by some ascii art of the tableland logo. I can also do SQL operations using tableland cli. But not getting response using JSON RPC.
I am using http://localhost:8080. I navigated to the browser for the URL provided and see the below details

[{"counter":1}]
`Access-Control-Allow-Headers: Accept, Accept-Language, Content-Type, Authorization
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 15
Content-Type: application/json
Date: Mon, 16 Jan 2023 09:23:51 GMT
Trace-Id: cccc178a-a016-4ea0-aae8-d8c81cb09814
X-Ratelimit-Limit: 10
X-Ratelimit-Remaining: 9
X-Ratelimit-Reset: Mon, 16 Jan 2023 09:23:52 UTC
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Host: localhost:8080
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0
`

@Keerthana-Bidarakoppa
In your issue description you say "No Response from JSON RPC".  Are you getting no response, or a status 200 response without any content in the body?
The RPC method you are calling might not be returning a body.  If status is less than 300 then it sounds like everything is working correctly.

@joewagner I am receiving a response status 200 without any content in the body.
I am following the documentation here to run RPC curl commands https://docs.tableland.xyz/json-rpc-api.
I run create table query, the command returns 200 but I cannot see a table being created on local-tableland.
Local-tableland list returns empty.

@Keerthana-Bidarakoppa The example you provided has "method": "tableland_validateCreateTable",, which does not create a table.  tableland_validateCreateTable validates the create statement, so if it returns a 200 status that means the create statement is valid.
With all that said, Tableland is going to be depreciating the RPC endpoint at the end of this week.  If you are working on a new project its highly recommended the you build with the new API.
There are details here: https://dev.tableland.xyz/blog/launch-week-tableland-upgrades-more

@Keerthana-Bidarakoppa Are you still having issues with this?

@joewagner I followed the documentation for the validator API https://docs.tableland.xyz/validator-api. I can now receive response content with body.
However, I can only see examples of GET i.e to retrieve information from the already created tables. Does the API also provide support for POST i.e creating new tables?

@Keerthana-Bidarakoppa This is a great question.  To answer this, it's best to first think about the way Tableland works. You can think of Tableland as having two main parts.

The Validator that provides the API and materializes data as tables.  source
A registry contract that is deployed on each of the Tableland supported blockchains. source

With that in mind, the way you create a table is by submitting a transaction with a SQL create statement to the registry contract.  Within that transaction the create statement is emitted by the registry contract.  The Validators are listening to the events being emitted and they use the data in those events to create tables that can be read from.
Back to your question. No, there is not a validator api to create tables.  To create a table you will need to submit a transaction to the chain you want your table created on.

@joewagner Thanks for the prompt response. I will take it from here. No more questions.


regression with v0.15.0: lncli closedchannels gives "unable to fetch chan info: unexpected EOF" and "unable to fetch chan info: invalid public key: unsupported format: c7"

Background
I've been experimenting on testnet and used several versions of the master branch to run my two nodes. I think I started with v0.14.3, but I can't remember - I can dig in deeper, if that helps.
On both nodes I can't run lncli closedchannels (same issue via gRPC). Note that everything else seems to work fine!
On the first node I get:
unable to fetch chan info: unexpected EOF

On the second node I get:
unable to fetch chan info: invalid public key: unsupported format: c7

(where I think the public key is related to gRPC / TLS / ...)
Your environment

version of lnd: recent master up to v0.15.0-beta.rc-1
which operating system (uname -a on *Nix): Linux Linux home 5.16.2 #1 SMP PREEMPT Thu Jan 20 21:00:54 CET 2022 x86_64 GNU/Linux
version of btcd, bitcoind, or other backend: bitcoind v23
any other relevant environment details: testnet, Go 1.18beta1

Steps to reproduce
Start lnd on testnet, update from v0.14.3 (I think) to several master commits from the past couple of days. Run lncli closedchannels.
Expected behaviour
Closed channels are shown.
Actual behaviour
Error messages, see above.

Updated an older testnet node, it was able to start up properly, but hit an issue when running lncli closedchannels, I get a similar error:
[lncli] rpc error: code = Unknown desc = unable to fetch chan info: invalid public key: unsupported format: 10

Likely error source: https://github.com/lightningnetwork/lnd/blob/0ec88b534678f713bcdc06c87610b9184df64207/channeldb/channel.go#L1431, but things don't quite match up since lncli closedchannels doesn't appear to hit that code path.

Tracked things to https://github.com/lightningnetwork/lnd/blob/c647d32cf7d3da17e3f94f937e1e5cf6b29e2b2f/rpcserver.go#L4296, which then attempts to access the historical channel bucket, where this error is sourced from.

Found the culprit: https://github.com/lightningnetwork/lnd/pull/6347/files#r875295125.
So an incomplete migration. Can be resolved my filling in that missing gap, though we may want to also change that field to be a TLV in the process? cc @yyforyongyu

Remedy path: https://github.com/lightningnetwork/lnd/pull/6347/files#r875296783
Any mainnet nodes affected by this should be able to re-run that migration (can add a one off flag). Or we can implement the fix as another migration, which could then also do that LTV thing I mentioned.

Confirmed that this PR fixes the issue: https://github.com/lightningnetwork/lnd/pull/6551

I merged #6551 and it's running fine on my node. Thanks a lot!

Fixed by #6551


Request for parser support for SecurEnvoy

What is the sc4s version ?
3.4
Is there a pcap available?
sample logs
Jan 22 20:01:41 10.x.x.x 22 Jan 2024 20:01:41 host1 Radius<EMAIL_ADDRESS>AD Password Accepted From ClientIP=10.x.x.x RemoteID= Passcode Check Still Required
Jan 22 19:52:51 10.x.x.x 22 Jan 2024 19:52:51 host2 Radius<EMAIL_ADDRESS>Passcode OK Access Accepted with Soft Token From ClientIP=10.x.y.z RemoteID=
What the vendor name?
https://securenvoy.com/
What's the product name?
MFA product - https://securenvoy.com/multi-factor-authentication-mfa/
** Feature Request description: **
** Should it support TCP or UDP?**
UDP
** Do you want to have it for local usage or prepare a github PR? **
both please, local usage to test initially would be greatful

Hello @lakshman237 please ask the customer for a TCP dump for this. I tried writing the parser based on the samples, but the vendor didn't follow syslog standard and this will require a custom regex parser. The format wasn't also described in SecurEnvoy docs, so we will need more input examples.

Thx @mstopa-splunk  I have managed it on-board using
//splunk_metadata.csv
simple_securenvoy,index,test_index
simple_securenvoy,sourcetype,SecurEnvoy
//env_file
SC4S_LISTEN_SIMPLE_SECURENVOY_UDP_PORT=105xx

all right, thank you. please reopen this issue if needed


add bottom dialog

add dialogs from bottom,
just change gravity and dialog animations

I don't intend to have this feature in this library.

Just for curiosity, why you don't want to integrate this feature?

This library's focus is specific, bottom sheet libraries should be used for this kind of thing.

Also, adding a parameter to the Builder constructor is a major breaking change for everyone already using the library.

For the parameter in the builder, you're right, in fact I had moved it as a method in the builder, but I have not yet pushed the change.
For the library's focus I do not quite agree, I think the possibility of having all the customizable material dialog as bottom dialog can be very useful

I have update the fork, if you want you can take a look