Refactore: using add-attributes as typeStr

As discussed here

@MohamedElqdusy I think you also need to fix the processor name https://github.com/open-telemetry/opentelemetry-service/blob/master/defaults/defaults_test.go

This implements https://github.com/open-telemetry/opentelemetry-service/issues/164
Please mention in commit message.

I suggest that commit message instead of
Refactore: using add-attributes as typeStr

is
Use "add-attributes" as the name for addattributeprocessor

(Inspired by: https://chris.beams.io/posts/git-commit/)

Please rebase to fix the build issue.


Hide Greeting Note, if not set

Drawing this shape is not necessary, if there is no note-text to render:

I will look into that. I already do it with the system greeting. The idea was, that every greeting is shown, (even when it's not configured) as somebody which is not a teams admin might not know that it's possible to insert a greeting at these specific points in the call flow. It's also helpful for troubleshooting purposes. (E.g. should play greeting but was not configured etc...)
As the code is now fairly robust, I have to check how difficult it would be to not draw these nodes, because many times the greeting is the first node of a subsequent call flow. If I just remove it, and the previous link points to a nonexistent node, the diagram will break.

Implemented in V 2.5.3


How can I uninstall it when I have macOS 13

 When I got macOS 13, the plugin dose not work well with the mail app and cause this every time. I try to uninstall the plugin but it says the plugin is  uninstalled. How can I do?

Wow, fast on that 13 beta. Have you tried the manual uninstallation instructions?
Will have to investigate the new macOS 13 at some point

It works, thanks!


[pugixml] Build error on x64-windows

Copied issue body from C:/Dev/vcpkg/installed/vcpkg/issue_body.md
Package<EMAIL_ADDRESS>Host Environment

Host: x64-windows
Compiler: MSVC 19.29.30154.0
vcpkg-tool version: 2024-08-01-fd884a0d390d12783076341bd43d77c3a6a15658
vcpkg-scripts version: 6af584dd5 2024-08-06 (15 hours ago)

To Reproduce
vcpkg install pugixml
Failure logs
-- Using cached zeux-pugixml-v1.14.tar.gz.
-- Cleaning sources at C:/Dev/vcpkg/buildtrees/pugixml/src/v1.14-3215fd4dab.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/Dev/vcpkg/downloads/zeux-pugixml-v1.14.tar.gz
-- Using source at C:/Dev/vcpkg/buildtrees/pugixml/src/v1.14-3215fd4dab.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
CMake Error at ports/pugixml/portfile.cmake:17 (vcpkg_cmake_config_fixup):
Unknown CMake command "vcpkg_cmake_config_fixup".
Call Stack (most recent call first):
scripts/ports.cmake:192 (include)
steps:
c:\Dev\vcpkg>git pull
Already up to date.

c:\Dev\vcpkg>bootstrap-vcpkg.bat
Downloading https://github.com/microsoft/vcpkg-tool/releases/download/2024-08-01/vcpkg.exe -> C:\Dev\vcpkg\vcpkg.exe... done.
Validating signature... done.

vcpkg package management program version 2024-08-01-fd884a0d390d12783076341bd43d77c3a6a15658

See LICENSE.txt for license information.

c:\Dev\vcpkg>vcpkg install pugixml
Computing installation plan...
The following packages will be built and installed:
<EMAIL_ADDRESS>Detecting compiler hash for triplet x64-windows...
Compiler found: C:/Dev/VS2019/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe
Restored 0 package(s) from C:\Users\TATO\AppData\Local\vcpkg\archives in 225 us. Use --debug to see more details.
Installing 1/1<EMAIL_ADDRESS>Building<EMAIL_ADDRESS>-- Using cached zeux-pugixml-v1.14.tar.gz.
-- Cleaning sources at C:/Dev/vcpkg/buildtrees/pugixml/src/v1.14-3215fd4dab.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/Dev/vcpkg/downloads/zeux-pugixml-v1.14.tar.gz
-- Using source at C:/Dev/vcpkg/buildtrees/pugixml/src/v1.14-3215fd4dab.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
CMake Error at ports/pugixml/portfile.cmake:17 (vcpkg_cmake_config_fixup):
  Unknown CMake command "vcpkg_cmake_config_fixup".
Call Stack (most recent call first):
  scripts/ports.cmake:192 (include)

error: building pugixml:x64-windows failed with: BUILD_FAILED
See https://learn.microsoft.com/vcpkg/troubleshoot/build-failures?WT.mc_id=vcpkg_inproduct_cli for more information.
Elapsed time to handle pugixml:x64-windows: 9.6 s
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+pugixml
You can submit a new issue at:
  https://github.com/microsoft/vcpkg/issues/new?title=[pugixml]+Build+error+on+x64-windows&body=Copy+issue+body+from+C%3A%2FDev%2Fvcpkg%2Finstalled%2Fvcpkg%2Fissue_body.md

c:\Dev\vcpkg>vcpkg list
pkgconf:x64-windows                               2.2.0               pkgconf is a program which helps to configure co...
vcpkg-boost:x64-windows                           2024-05-15
vcpkg-cmake-config:x64-windows                    2024-05-23
vcpkg-cmake-get-vars:x64-windows                  2023-12-31
vcpkg-cmake:x64-windows                           2024-04-23
vcpkg-gn:x64-windows                              2024-02-22          GN is a meta-build system that generates build f...
vcpkg-tool-gn:x64-windows                         2024-02-22          GN build system
vcpkg-tool-meson:x64-windows                      1.5.1               Meson build system

the funny thing is that it worked this week, but something got broken.. not sure what is that

You can try vcpkg install pugixml --cmake-args=--trace-expand
At some point it should load share/vcpkg-cmake-config/vcpkg-port-config.cmake and so on.
Unless you removed the files from installed/<host_triplet>.

Thanks!
the --trace-expand  produces super huge logs....
I guess you are right (there were smth removed from the installed/<host_triplet> dir
anyway, I'd like to find that error log in attached file, and close the ticket
if you happen to pint me into the error line,...
thank you for the time & support
issue_body.md

So it is not loading share/vcpkg-cmake-config/vcpkg-port-config.cmake, and that's why the script doesn't get the maintainer function.
You will have to reinstall vcpkg-cmake-config. Or maybe more.

Excellent root causing
Thanks again
I"ll be more carefull in the future
Closing


Emdobrin patch 2

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Codecov Report

:exclamation: No coverage uploaded for pull request base (test200@0945483). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 0694c0f differs from pull request most recent head 1833b72. Consider uploading reports for the commit 1833b72 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             test200       #5   +/-   ##
==========================================
  Coverage           ?   96.61%
==========================================
  Files              ?       28
  Lines              ?     1650
  Branches           ?        0
==========================================
  Hits               ?     1594
  Misses             ?       56
  Partials           ?        0


TypeError: cannot be converted to pointer

(Snips does not crash and everything continues working)
Triggered by the following callback
@staticmethod
def PickRandomBoardgameCallback(hermes: Hermes, intent_message: IntentMessage):
    return hermes.publish_end_session(intent_message.session_id, "Ok")

snips-skills-server -vvv

Wried issue, I suggest that you can try to reinstall the hermes-python dependency.


[Spark-40974]When the value of quote or escape exists in the content of csv file, the character in the csv file will be misidentified

What changes were proposed in this pull request?

When the value of quote or escape exists in the content of csv file, the character in the csv file will be misidentified
We found that when the value of quote or escape exists in the content of csv file, the character in the csv file will be misidentified.
When this content is being read by Azure Data Factory copy activity and written to CSV, the content is
"test\\" =
test"
we read csv as below:
df = spark.read.csv(path='test.csv'
, sep=','
, header=True
, quote='"'
, escape='\'
, multiLine=True
, lineSep='\n'
)
resulting in the following being written to the CSV:  test\" = and test in the next line ,but what we want  test\\" = test.
Now when the above is being read by Spark:

The first \ is being interpreted as being an escaping of the second \ (so the content looks like a single literal )
The " now appears to be an unescaped quote character, so we're back in the situation where Spark tries to handle this using STOP_AT_DELIMITER.
As before, the rest of the CSV after this point is being parsed incorrectly.

Why are the changes needed?

We could change the "quote,escape..." to avoid it for the scenario above, but the content of their csv file is very large and it may occur any character. the data sources that we have which are affected by this issue are systems outside of our control, so we have no means of controlling what content/characters will be there.When we change the "quote,escape...", it may conflict with the content again, and it still have issues in the following content.
As far as designing the content to avoid certain characters - the data sources that we have which are affected by this issue are systems outside of our control, so we have no means of controlling what content/characters will be there.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Unit test.

@clairezhuang

If the issue exists in the master branch, you need to use master as the code base for development instead of branch-3.3
If the issue only exists in branch-3.3,  you need to base on branch-3.3 and select the push target as branch-3.3 instead of master

Can one of the admins verify this patch?

Sorry for using the batch-3.3 as the mistake. The issue exists in the master branch, and I have no experience to make file change.
I have closed the pull request. You could delete the pull request if it is possible.
I would go to jira: https://issues.apache.org/jira/browse/SPARK-40982?jql=project %3D SPARK .


Feature Request: Add command option to mention backend file

When I place the wslbridge-backend file not in the wslbridge.exe it shows an error. So, can you add a option to mention backend file path?
Example: C:\xyz\wslbridge.exe -p "C:\abc\wslbridge-backend"

Maybe the path to the backend should be a WSL path rather than a Windows path.

How can I mention that path in command line? Do you have any parameter in wslbridge?

How can I add the backend path in wslbridge command as I said above? The path of frontend and backend will  be different. This may help in my project of wsltty appx package.

There isn't currently an option to specify a non-default path to the backend binary.
Your request shows a Windows path to the backend, but the frontend needs a WSL path to invoke the backend. Converting a Windows path to a WSL path has had trouble before (https://github.com/rprichard/wslbridge/issues/22), so I suggested that if wslbridge has an option, then maybe it should use a WSL path rather than a Windows path.
On the other hand, you could ensure that the two binaries are in the same directory.


Create core WRover POST

Rationale
Ensure that core WRover hardware is functional/connected prior to starting the main sequence of WRover code.  Provide meaningful diagnostic messages to operators as to which subsystem is not working, potentially including some root-cause analyses
Anti-Goal
This is NOT to:

Create Unit Tests: POST is run at WRover launch time, unit tests should be run before software is deployed
Perform Actions with the WRover: POST is to make sure that things are connected/operational, which enables subsequent code to actuate the WRover

Required Actions

[ ] Create a software package containing POST tests, including:

Motor communication bus tests
Sensor tests (for sensors that are permanently connected to the chassis of the WRover)
Communication tests (talking to all daughterboards, remote systems)

 Create Core WRover POST


refactor CI pipelines

Description
now that we have a bit more complex CI pipeline, it makes sense to refactor it in a re-usable way.
the solution might look like this:

install (3 OSs)
build (3 OSs), uses install
lint (3 OSs), uses build
test (3 OSs), uses build
e2e (3 OSs, 3 browsers), uses build

need to experiment and see what workflow is best.
Check List

[ ] update CI pipelines for pull-request checks

Additional Comments

https://docs.github.com/en/actions/using-workflows/reusing-workflows
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

for e2e we don't need 3 OSs, just one can do the job

for e2e we don't need 3 OSs, just one can do the job

browsers behave differently in different OSs, also, Safari is only available on macOS.
I'm also starting with some limitations with cypress:

can't test new tabs
have experimental support for Safari.

I think we should also take a look at Playwright as an alternative, it already covers those above points

I think we should also take a look at Playwright as an alternative, it already covers those above points

cypress still needs to fully support Safari indeed, if this playwright has those points covered then we can switch to it


Cannot Add Package via SPM in Xcode 15 Beta 3

Hi! Thanks for the work you've put in to maintaining this library, I know it's going to save me a ton of time.
Summary

Cannot add version of MagicTimer via Swift Package Manager
Error SPM: Failed to resolve dependencies Dependencies could not be resolved because package 'magictimer' is required using a stable-version but 'magictimer' depends on an unstable-version package 'magictimercore' and root depends on 'magictimer' 2.0.1.. <3.0.0.

Environment

Xcode Version 15.0 beta 3 (15A5195k)
Build target iOS 17+

Thank @TheOtherJFK for opening this issue, I will fix it soon.

@TheOtherJFK  To continue your development checkout below link:
https://forums.swift.org/t/dependencies-could-not-be-resolved-because-package-yeelampa-is-required-using-a-stable-version-but-yeelampa-depends-on-an-unstable-version-package-requester-and-root-depends-on-yeelampa-0-1-0/53840
use latest commit hash to reference correctly and I will fix it soon.
commit hash: 9ff923bdea4b4dcfbca2002ff8b71ed7971f04d3


Added GPA Calculator, Word Counter and Lorem Ipsum

if you want I'm making https://www.pwaawards.com/ and would love for you make a pr @amdixon


Some taxon constraints in CL are too tight for ZFA

Two CL terms have taxon constraints that are too tight and cause issues when ZFA is merged with Uberon and CL.
'B cell, CD-19 positive'
'B cell, CD-19 positive' is said to be mammal-specific (in_taxon some Mammalia). It’s actually part of the logical definition.
This makes, in turn, most of the B cells in CL (e.g. 'mature B cell', 'immature B cell', 'transitional stage B cell, etc.) mammal-specific.
But B cells (including mature and immature B cells, transitional stage B cell, etc.) exist beyond mammals, e.g. in zebrafish. Most ZFA terms for B cells are unsatisfiable in Uberon+CL+ZFA because of the restriction of 'B cell, CD-19 positive' to mammals.
'rod bipolar cell'
'rod bipolar cell is said to be mammal-specific (in_taxon some Mammalia).
But those cells apparently also exist in zebrafish, and the ZFA term for them is unsatisfiable in Uberon+CL+ZFA because of that restriction to mammals.

We should probably drop the (in_taxon some Mammalia) for the B cell, CD19-positive.  According to this article, CD19 is found on B cells in Zebrafish, and is thus most like a marker of B cells in most or all vertebrates.
Google Gemini offers up additional articles in support of CD19 on B cells in zebrafish.  I have not had time to verify this information yet:
Scientific Articles Identifying CD19 as a B Cell Marker in Zebrafish
Here are a few scientific articles that have used CD19 as a marker for B cells in zebrafish:

Page et al., 2013: This study characterized the development and behavior of IgM+ B cells in zebrafish. They utilized three fluorescent transgenic lines, including one expressing CD19, to define the existence of pro-B, immature/mature, and mature B cells in the kidney marrow.

Title: "Zebrafish B cells exhibit a distinct developmental pattern and are highly plastic."
Journal: Blood
2. Lu et al., 2016: This research explored the role of B cells in zebrafish tumor immunity. They found that CD19+ B cells can express the death ligand FasL to directly induce cytotoxicity when stimulated by IL-17A.
Title: "CD19+ B cells contribute to anti-tumor immunity in zebrafish through FasL-mediated cytotoxicity."
Journal: Frontiers in Immunology
3. Hu et al., 2010: This study identified IgZ as a novel B cell marker in zebrafish. They also confirmed the expression of CD19 on B cells in different tissues.
Title: "Identification of IgZ as a novel B cell marker and its expression in zebrafish immune tissues."
Journal: Developmental and Comparative Immunology
4. Tao et al., 2017: This research investigated the regulatory role of B cells in zebrafish inflammation. They found that CD19+ B cells can be negatively regulated by IL-10.
Title: "IL-10-producing B cells regulate inflammation in zebrafish."
Journal: Journal of Immunology
These articles provide valuable insights into the use of CD19 as a B cell marker in zebrafish and its role in various immune processes.

Looks like recent work supports rod-bipolar pathway as more ancient than previously thought

So I think OK to relax taxon constraints on this to.


pre-commit hook not working properly

current behavior
the codebase is using grunt-githooks  that runs grunt lint to test any linting errors before letting developer to make a commit,
the thing is grunt lint corrects linting errors but it does not stop commit process,  changes made by linter remain in the working directory!
expected behavior
it must prompt the developer to add the linting changes to the commit as well or should simply terminate the commit process.
Also I would like to work on this issue

@frappelatte28 i agree with you , our pre commit hook system must be more robust , following are some more issues regarding the same!

Currently linter fixes the linting mistakes automatically  in pre-commit hook :-

An easy fix i can think of is run the linter in no-fix mode when used in pre-commit hook, you can make two different task with grunt one for lint fix and other for lint no-fix you can read here about adding tasks to grunt.

Secondly linter fixes linting errors on file other than sraged-files too,

you can fix it by making a template for pre-commit hook that will stash other changes and then run linter and then pop stash chanegs   back to original state ! , here is the great article about it .

As it reflects , you know pretty much about pre-commit hook system, so go ahead.We welcome every contribution.
For any query , you can reach out to us here!
@montoyamoraga  @therewasaguy  @kyle1james  what do you think about it ?

@frappelatte28 i agree with you , our pre commit hook system must be more robust , following are some more issues regarding the same!

Currently linter fixes the linting mistakes automatically  in pre-commit hook :-

An easy fix i can think of is run the linter in no-fix mode when used in pre-commit hook, you can make two different task with grunt one for lint fix and other for lint no-fix you can read here about adding tasks to grunt.

Secondly linter fixes linting errors on file other than sraged-files too,

you can fix it by making a template for pre-commit hook that will stash other changes and then run linter and then pop stash chanegs   back to original state ! , here is the great article about it .

As it reflects , you know pretty much about pre-commit hook system, so go ahead.We welcome every contribution.
For any query , you can reach out to us here!
@montoyamoraga  @therewasaguy  @kyle1james  what do you think about it ?

I think this has been adressed already.
In #574 @frappelatte28
Closing this one .


pre-commit: PR110260

Link: https://github.com/llvm/llvm-project/pull/110260
Requested by: @dtcxzyw

/close


Add window.innerHeight and window.innerWidth to getPageInfo()

Released as v4.1.0.
Thank you for this.


Specify how invalid address conversion is handled for jumps.

For JAL in legacy mode it says:

the target address which is written to the pcc's address field

(the should probably be removed btw)
It says a very similar thing for conditional branches.
It doesn't really specify how invalid address handling should be applied here. Suggestion from Jamie was that the (non-capability) target address undergoes invalid address conversion. PCC is not affected if invalid address conversion changes the target address.

@andresag01 and I had some discussion about this a while back: I think the plan was for the architecture to specify that the bounds-check happens pre-conversion. The conversion in the architecture (with representability check) should only happen on the subsequent fetch when the translation has failed and working out what to put in epc(c).
Happy to PR if we agree this is a sensible approach?

@Timmmm : You are right, the spec is missing a description for pcc handling -- we only have a description for CSRs
@PRugg-Cap: I seemed to remember that it would work like this (e.g.) in the case of JAL:
// Get an XLEN target
targetAddr = pcc.address + imm
// Drop unused bits, then decompress to extend back to XLEN to see whether we lost precision due to invalid address
targetAddr = COMPRESS(DECOMPRESS(targetAddr))
// Check bounds as usual
if inCapBounds(pcc, targetAddr)
    pcc = setCapAddr(pcc, targetAddr)
else
    EXCEPTION

Hmm, I don't think that was ever my idea of how it would work: it would be nice that this didn't pollute the architecture more than it has to. It really should just affect exception reporting, so why would you want to do the transformation before the bounds check?

I might be misremembering though: I'll have a think

It really should just affect exception reporting, so why would you want to do the transformation before the bounds check?

You are suggesting that we just assign the target address to pcc without checking bounds or representability. If so, then we run the risk of manufacturing a capability that breaks the encoding and is still tagged. I do not think we can just wait for the next instruction to check the PCC because the encoding would have been broken by then (assuming that PCC.address only has sufficient bits to hold the valid addresses)

I’m of the same view as Peter, I don’t think you should be mucking with the address. But also if you fail the bounds check then you don’t perform the jump so there is no invalid address to write anywhere, the faulting PC(C) is that if the jump itself.

@andresag01 I'd consider it more as that you jump to the unconverted address. The architecture only tells you that epc(c) doesn't need to have the redundant bits. The microarchitecture still doesn't have to store those bits: the jump goes through then the microarchitecture throws the bits away while noting to itself that the CHERI fetch checks should pass, then the illegal fetch translation happens as it always did.

@andresag01 I'm not suggesting you put some hacky bit of state directly forwarded between the instructions or anything. I'm saying that you "compress" a PC in the microarchitecture to include a bit that says it's been through all the CHERI checks. If you take an interrupt in the meantime, then the architecture is allowed to compress the PCC and it's okay for that bit to get thrown away along with the redundant high address bits.

@arichardson any thoughts?

@tariqkurd-repo This will have some odd implications though, e.g. I can check if a cap is in-bounds, but then get a bounds exception when I jump to it. It sounds the same as saying that we should be allowed to throw an instruction misaligned fault on the jump because the implementation might legalise it to an unaligned address.
I see what you're saying about needing a representability check when compressing the cap into EPCC, though, and it would be sad to insist on that without a good reason. I wonder if the spec should just say the tag gets cleared if the fetch address was invalid, i.e. if the legalisation isn't a nop?

This will have some odd implications though, e.g. I can check if a cap is in-bounds, but then get a bounds exception when I jump to it.

The argument is that the legalization for the invalid address is an architecturally-defined behaviour for all CSRs that hold addresses. Therefore, manually checking the bounds on an XLEN register is naturally going to give a different result from doing the analogous computation on a trimmed down register like ddc, pcc, mtvecc, stvecc, etc.
I agree that its quirky, but it needs to work somehow. At the end of the day, this is an optimization, so spending lots of hardware on additional representability checks for branches/jumps instead to save flops for PC bits would be unfortunate.

I wonder if the spec should just say the tag gets cleared if the fetch address was invalid, i.e. if the legalisation isn't a nop?

We previously considered just clearing the tag when an invalid address occurs (not just in branches/jumps), but discarded the idea because its almost like saying that invalid address exceptions don't exist and we instead get a CHERI tag violation which is not very helpful.

The argument is that the legalization for the invalid address is an architecturally-defined behaviour for all CSRs that hold addresses. Therefore, manually checking the bounds on an XLEN register is naturally going to give a different result from doing the analogous computation on a trimmed down register like ddc, pcc, mtvecc, stvecc, etc.

The issue I have is that something that's supposed to be a slight change to exception reporting has effectively turned into another layer of translation. If we're defining that bounds checks happen on the post-conversion address, why shouldn't that happen to data memory accesses as well? What if the illegal address legalisation isn't continuous, i.e. some of the access is in-bounds and some is not? I'm worried also that an access that is supposed to be out-of-bounds could become in-bounds after the conversion, rather than just the other way around.

I agree that its quirky, but it needs to work somehow. At the end of the day, this is an optimization, so spending lots of hardware on additional representability checks for branches/jumps instead to save flops for PC bits would be unfortunate.

I absolutely agree it has to work. Just trying to think about ways to make it work cheaply without as many quirks.

We previously considered just clearing the tag when an invalid address occurs (not just in branches/jumps), but discarded the idea because its almost like saying that invalid address exceptions don't exist and we instead get a CHERI tag violation which is not very helpful.

Okay, I was just proposing clearing the tag when it got put into EPCC, but I realise that has the problem that a completely CHERI-oblivious software stack could take a tag exception when xRETting after it's been unlucky enough to take an interrupt just after doing one of these dodgy jumps but before the subsequent fetch check. I'll think a little bit more about whether it's possible to avoid a representability check per branch unit, but otherwise I agree with @tariqkurd-repo's summary of what this would mean pragmatically.

I think there a simple solution here.

for legacy mode compatibility we must take the instruction access fault, not a tag fault in these cases, if the cap is infinite. if it isn't then we can clear the tag as we're using a CHERI-aware OS.
clear the tag on invalid addresses detection if the cap isn't infinite

Therefore if the cap isn't infinite we get a tag violation, if it is infinite we get the correct RISC-V behaviour of the instruction access fault.
How does that sound?
I think this is also applicable to load/store. No-one can load/store/fetch from invalid addresses - the only question is which type of fault is taken.
No additional representability checking logic required.

Bit of a shame that the other CSR writes (e.g. mtvecc) use a slightly different algorithm to writing to PCC though.
Maybe a stupid idea but could you use the normal invalid address conversion algorithm (i.e. clear the tag if it is invalid) when writing PCC but then also say that instruction access faults due to invalid addresses are simply higher priority than CHERI tag checks?

The CHERI fault must come first in all cases, so to maintain legacy compatibility we need the tag to be set for invalid addresses, which is easy if the metadata is infinity.

If conversion was required, then A’s tag is cleared if A is sealed or if the new address is not representable — this is equivalent to the semantics of SCADDR

from 3.13.1. Invalid Address Handling
If we changed this from new address is not representable to address changed and the metadata is not infinity then it all fits together. How about that? @PeterRugg ?

@tariqkurd-repo Yes, I was about to suggest something similar. Either define that they're cleared when the bounds are not almighty or make it part of the implementation-defined legalisation that the tag is allowed to be cleared so long as it's never cleared when the bounds are almighty, but is cleared at least in the case where the bounds interpretation would change.
Even if the tag will be clear when the PCC gets written to EPCC, the architecture currently still says that conversion only happens on writing to EPCC, so the CHERI fetch checks immediately after the jump/branch would still have to pass. I think that's handled by the "flag" suggested above: basically the microarchitecture is storing the whole PCC for that stretch but "compressing" it down to a single bit that's enough to say it should pass the checks. Does that make sense, or should we try to simplify things a bit?
@Timmmm It is tempting, but I don't think it avoids the representability check: you still need to ensure the EPCC is tagged if the bounds are almighty, but cleared if the bounds interpretation would change, otherwise you're just delaying the unexpected CHERI fault until the next xRET.

If we changed this from new address is not representable to address changed and the metadata is not infinity then it all fits together.

I think that may be okay: I'll just have a look through to make sure there aren't other cases where we'd regret this.

Conclusion from today's conversation:

Do invalid address conversion before any CHERI checks are performed
The branch/jump throws a tag violation if, after conversion, the address is invalid and PCC is NOT Infinite.
The branch/jump throws  instruction access fault if, after conversion, the address is invalid and PCC is Infinite. This is to ensure that Legacy + Infinite is compatible with standard RISC-V.

@PRugg-Cap @tariqkurd-repo @arichardson @jrtc27 : Do you agree with this behaviour?

And just to be clear, if you are in legacy mode and write a capability with an invalid address and infinite bounds to mtvec, would it clear the tag?
Would it make sense to just change the invalid address conversion procedure so that all invalid address conversions special-case infinity. I.e. instead of
function setCapAddrChecked(c : Capability, addr : CapAddrBits) -> Capability =
  let (representable, newCap) = setCapAddr(c, addr) in
  clearTagIf(newCap, not(representable) | isCapSealed(c))

function convertInvalidAddrCap(cap : Capability) -> Capability = {
  let reducedAddr = convertInvalidAddr(cap.address);
  if reducedAddr != cap.address then setCapAddrChecked(cap, reducedAddr) else cap
}

do
function convertInvalidAddrCap(cap : Capability) -> Capability = {
  let reducedAddr = convertInvalidAddr(cap.address);
  if reducedAddr != cap.address & not(hasInfiniteBounds(cap)) then setCapAddrChecked(cap, reducedAddr) else cap
}

Also hasInfiniteBounds() needs to be specified since IIUI there's more than one possible cap that covers all the address space. Do we mean:
function hasInfiniteBounds(cap : Capability) -> bool =
  cap.E == infinite_cap.E & cap.B == infinite_cap.B & cap.T == infinite_cap.T & cap.internal_exponent == infinite_cap.internal_exponent

or this?
function hasInfiniteBounds(cap : Capability) -> bool = {
  let (base, top) = getCapBounds(cap);
  base == 0 & top >= 2^xlen
}

And just to be clear, if you are in legacy mode and write a capability with an invalid address and infinite bounds to mtvec, would it clear the tag?

It would not clear the tag. Otherwise software can end up getting a tag exception without ever touching capability features.

Would it make sense to just change the invalid address conversion procedure so that all invalid address conversions special-case infinity.

I think so! We should check, but I don't think there's any reason not to make this behaviour universal for invalid address conversions. It should be a lot cheaper. I think the proposal is slightly different to the sail snippet though: it should be more like:
function convertInvalidAddrCap(cap : Capability) -> Capability = {
  let reducedAddr = convertInvalidAddr(cap.address);
  clearTagIf(reducedAddr != cap.address & not(hasInfiniteBounds(cap)), cap)
}

I.e. we're saying the representability check doesn't happen at all and you just blindly clear the tag if you change the address.

Also hasInfiniteBounds() needs to be specified since IIUI there's more than one possible cap that covers all the address space.

Sort of. There's only one set of bounds that should ever be tagged that covers the whole address space, so you shouldn't be able to tell the difference between the two checks you proposed anywhere. For clarity, I'd suggest we go with the base == 0 & top >= 2^xlen definition.

I think we're in agreement - we'd apply the same behaviour everywhere. So if you write an invlaid address to metvec and the metadata isn't infinite then you clear the tag

Agreed that this seems a good way to go. Minor nit, just to check I understand correctly:

The branch/jump throws a new CHERI invalid address fault if, after conversion, the address is invalid and PCC is NOT Infinite.

The "after conversion" is redundant here? Illegal addresses have to convert to illegal addresses?


Revert the adoption of typed throws in the Result type

We've found a compiler crash and a potential miscompile due to this change, so revert it while we address the underlying issue.

@swift-ci please smoke test

Leaving this as a draft. If I can fix the source-compatibility issue and the potential miscompile, I'll close this.

All issues with this have been addressed; closing.


Typography - Overline does not conform w/ material spec

Overline is currently set to 400 font-weight, it should be 500 font-weight.
Here's the spec: https://material-components.github.io/material-components-web-catalog/#/component/typography. You'll notice its 500 font weight. Which all matches the material.io images of Overline text.
Would you mind changing the default theme's 'overline' weight from 400 to 500?
That'll conform w/ the design spec

@NawarA Thanks for the report but it contradicts: https://material.io/design/typography/the-type-system.html#type-scale

Goes in the same direction: https://vuetifyjs.com/en/styles/typography#typography. I think that we can close it for now, at least, until the material design spec is consistent (to minimize changes here).

Even though Google's other design tools show overline as 500. You're right, the spec calls for regular. Regular = 400 and medium = 500.
Thanks dude 🙏


Talib-macd not working in UI

xxx POST /api/backtest 500 103ms -
Error: non-error thrown: Child process has died.
    at Object.onerror (/gekko-develop-old/node_modules/koa/lib/context.js:107:40)
    at process._tickCallback (internal/process/next_tick.js:103:7)

ah darn, I am working hard on getting a stable web UI going but I am not there yet. Is there anything else in your console?

Nope sorry :/
I wanted to to take a look myself, but nodejs and everything is new to me and i can't debug child process because i get a duplicated address error.

duplicated address

Are you trying to run gekko --ui more than once? Because it can only bind to a port once.

Could you then tell me what dataset you selected for your backtest (and where you got that data from)?

No, i just run "node-debug gekko.js --ui" everything is working fine. But, in the gui when i try the "scan available data" the "server" try to spawn another process with the same debug port.

Could you then tell me what dataset you selected for your backtest (and where you got that data from)?
Wrong browser tab? Btw i have 1 month of btc-e  (not bitchina) data.

No, i just run "node-debug gekko.js --ui" everything is working fine. But, in the gui when i try the "scan available data" the "server" try to spawn another process with the same debug port.

Why are you running it with node-debug? Does it work correctly with node-debug gekko --ui?

Wait wait. Two trouble here. First talib-macd not working with "node gekko.js --ui" and the second one is me unable to launch the ui with node-debug.

A workaround is setting to this problem is setting this property to true:
https://github.com/askmike/gekko/blob/develop/web/routes/baseConfig.js#L16
Will reimplement talib integration, a config flag works great for the commandline version of gekko, but not so much for an UI like this.

This has been fixed, if you have talib installed (npm install talib) Gekko will detect this and correctly use it :)

that talib not suport in windows 7?

I don't think so no, see here for details: https://github.com/oransel/node-talib/issues/8
If you want to run talib right now you probably need to run linux in a VM or so I think.
There is another library that supports similar indicators and is supported on Windows, but it's not integrated into Gekko yet (see #708) - that would work the best.

thanks for the answer..
my ram is to low for open VM... or do you have strategy configuration that no need talib ?

Gekko comes with 7 example strategies, 6 of those do not need talib (which is more meant for users creating their own strategies).
Here is a list, you can use any except for the bottom one (talib-macd).
https://gekko.wizb.it/docs/strategies/example_strategies.html

If you have more questions please open a new issue instead of commenting here please!

Did you install talib like so (inside the gekko folder):
npm install talib

If gekko still says "TAlib is disabled" after this there is an issue with
your talib installation.
On Wed, Jun 14, 2017 at 12:41 PM, shanehull<EMAIL_ADDRESS>wrote:

Is this currently working on stable? I installed Gekko and TAlib, but
gekko --ui doesn't seem to use it (says: "TAlib is disabled" when i start
gekko --ui.
Everything else works amazingly well, great project! Very excited for the
UI live trader.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/askmike/gekko/issues/525#issuecomment-308406033, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7MD2JZWIhyCv5zNBBtsVxrVzdRHfXwks5sD8b7gaJpZM4LTBoZ
.

--
PGP key at keybase.io/mikevanrossum
https://keybase.io/mikevanrossum/key.asc

You were right, it was the installation. It works fine after a trying again.

Hmm, still getting an error when I try to run a backtest on talib-macd.
Here's what I get:

strange, I'll try to reproduce asap. @shanehull can you provide more information on your OS? And can you tell me what version of talib is installed (you can find that out by running npm list)?

I'm running talib 1.0.3 installed on Ubuntu 16.04.

Could you quickly try talib 1.0.2 (1.0.3 is new and that might be the
problem). You can do that by running:
npm remove talib
npm install<EMAIL_ADDRESS>
On Thu, Jun 22, 2017 at 12:59 PM, shanehull<EMAIL_ADDRESS>wrote:

I'm running talib 1.0.3 installed on Ubuntu 16.04.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/askmike/gekko/issues/525#issuecomment-310359377, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7MD8gB6gJ0CkdJKLAboAQwl1hnWbqCks5sGlc2gaJpZM4LTBoZ
.

--
PGP key at keybase.io/mikevanrossum
https://keybase.io/mikevanrossum/key.asc

I had the same error with talib 1.0.3 on Ubuntu 16.04.
As per @askmike I removed and installed<EMAIL_ADDRESS>and issue resolved.

Great! I will work on integrating the latest version of talib asap.

Great! I'll give that a try. Thank you!


[Event Hubs] Update package.json files to have sideEffects set to false

As per the Typescript guidelines, we need to set sideEffects to false in the package.json files.
Relevant section from the guidelines

DO set sideEffects to false. Side effecting libraries must be explicitly approved during design review. The sideEffects field is used by Webpack and potentially other tools as an indicator of how aggressively the package can be optimized.

Side effects refer to modifications to the runtime environment of the program as a result of including a module. For example, including a polyfill library is a sideEffect as it mutates the global environment and later code depends on its presence. Side effects make it harder for tools to optimize your build and should be avoided
This issue is to track the required update in both EPH and Event Hubs

Closed with #2767

Closed with #2767


Firearms are not about "trust".

In using SSLs as the basis of this proposal, you are taking a system that is about trust - sharing data on a single network - and trying to apply that concept to something that couldn't be less similar.
The legal basis of firearms ownership is distrust. Distrust of the government, distrust of the neighbors. Firearms have always proven to be a leveling tool that removes some of the coercive power of governments, powerful individuals and majority groups against minorities and individuals. Firearms are both the enforcing arm of individual liberty and litmus test: In free societies adults are automatically "trusted" until they have proven otherwise. They are then trusted to vote, trusted to say responsible things and trusted to join and practice whatever faith.
This proposal basically says the liberty is a popularity contest where a type of majority (the network) has to be relied upon to decide to grant rights and freedoms to the minority (individuals). If you believe that a majority establishing which individuals can be trusted with a liberty (in this case a weapon), then it automatically follows that all liberties can and should be viewed the same way: Networks for voter registration, networks the ability to assemble, networks for the ability to make public speech.
The trust in SSL is a service provided that allows the internet to function, so it is okay with everyone that a tiny minority has established a method for producing a commodity: SSL certificates. That commodity is universally used. Gun ownership is not a commodity - the right to use a gun never leaves the individual who has it, and can never benefit anyone else but the individual.
I am saddened that intelligent people can't see the enormous gulf in the use of trust networks for the creation of transferable commodities and one used to act for and against individuals. You might as well establish a gun owning aristocracy - an ancient arms holding trust network - since you want to dispose of individual freedom as the basis for Western civilization.

I think you've fundamentally misunderstood both this proposal and the present political moment.
On the first matter, it's not possible for this to turn into some kind of arms-owning aristocracy, because any group of 5 people of the age of majority who can pass a background check can come together to form a network. That is just not a very high bar, and it's in no way conducive to the development of an arms-owning elite.
To the second point, we are in a moment where lone wolf wackos are taking the fruits of a half-century of American innovation in small arms, and using them to terrorize us in public spaces. The public is just not going to stand for that much longer, and if the tempo of these attacks pick up then you will lose rights.
We had better come up with a regime for vetting firearms ownership that we can all live with, because if we don't then the other side will come up with one that we cannot live with. Gun owners may be riding high right now, but this, too, shall pass. Our 2A rights would not survive a combination of a Dem congress and a string of mass casualty shooting sprees. Wake up, because that's what time it is.
On a final note, I'm from the old-school gun culture, and I can tell you that it absolutely was social. I didn't get my first gun until my dad thought I could handle it. And if you were a dangerous yahoo, you didn't get invited to the deer camp and you were otherwise socially ostracized.
The simple fact is this: nobody wants to be around a loner with a deadly weapon. If that describes you, then I'm sorry. If you don't have some sort of network of trust relations that you're embedded in, then you have no stake in a collective and therefore you have nothing really to lose. An armed individual with nothing to lose is a danger to everyone while simultaneously being not even remotely a danger to the status quo. Only an armed collective is a bulwark against tyranny. If you don't do collectives, then you weren't going to be any help anyway--go back down into your bunker and ride it out.

This clearly ignores the actual current proposal. No honest reviewer would make such conclusions of being limited to a specific network.
So I have to ask what's the actual point of introducing this empty rhetoric? And why do it on a brand new anonymous account? For admitting there's a problem which needs solving and starting a conversation I find Jon admirable. This nonsensical attempt to derail it isn't.
As for its content it's historically ignorant.
In no place but recent American history could one find anyone who posits that individual freedom was the basis of Western civilization. The Magna Carta granted certain rights only to lords, and in no way did it undermine the Crown's authority. The claim is not even reasonable with regards to American civilization. Take another look at the Constitution's preamble- the primary focal point is the common, not the individual. That societal-centered method of framing law is consistent going all the way back to Hellenic Greece.
Distrust doesn't appear anywhere in the constitution or the second amendment.  Equating this as yet unspecified mode of cooperation to authoritarianism is an act of ideological fanaticism.

I don't know how this site works as far as anonymity - I created the account following the instructions. I'm the one who proposed the example of the hated minority that Jon posted.
As far as individuals go in Western culture, that concept has always existed and has just changed who it counted for: Aristocrats, then white males, then all males, then all adults. We don't hold the words of the Constitution to be invalid because they weren't initially applied to women, and we don't believe that Western Civilization ended just because of the Dark Ages.  And speaking more generally, most laws are about defining property ownership - which is also all about individuals.
Statistically, there aren't significantly more "wackos" doing anything that wackos were doing 100 years ago, and the stats for mass spree shootings by capita put the US behind many European countries.
http://www.ijreview.com/2015/12/348197-paris-attack-claim-mass-shootings/
AR15s are less lethal than a 1920 Tommy Gun with 50 round drum mag, so this idea that there is a recent technology watershed at work is also false. What no one seems to be in a hurry to admit is that mass shooters are SO much less effectively than bombers, and maybe we are fortunate that the wackos prefer shooting people one at a time to the Timothy McVeigh way of acting out violently. Bombs don't require background checks to construct.
I don't think it has anything to do with the legality of the proposal, but America was never a land of gun clubs and social shooting. Most of rural America kept and used firearms for solo pursuits like hunting or protection. Gun clubs, shooting ranges and that kind of thing went along with the growth of cities to provide safe  places for shooting. It is like saying that the "normal" way to swim is in a municipal swimming pool. While shooting may be social for you and your family, I have personally known many hunters that taught themselves and always hunt alone. It is not strange.
"No one wants to be around a loner with a deadly weapon." No one wants to be around a loner, is what the core of the statement means. I do not understand licensing prejudice, and words like "loner" is prejudicial, just like words about race or religion. You seek to disenfranchise anyone who doesn't fit into your minimum 5 person litmus test of "socially compatible", and whether that is for guns or something else, I find it monstrous. It reminds me of when promiscuous women were treated as mentally ill.

"No one wants to be around a loner with a deadly weapon." No one wants to be around a loner, is what the core of the statement means. I do not understand licensing prejudice, and words like "loner" is prejudicial, just like words about race or religion. You seek to disenfranchise anyone who doesn't fit into your minimum 5 person litmus test of "socially compatible", and whether that is for guns or something else, I find it monstrous. It reminds me of when promiscuous women were treated as mentally ill.

I just don't buy this analogy or line of argumentation, at all. Nonetheless, I think it's important for anyone interested this proposal (or any variant on it, however watered down) to hear it, because it's probably going to be a common objection.
Also, let me speak to this comment specifically:

You seek to disenfranchise anyone who doesn't fit into your minimum 5 person litmus test of "socially compatible"

I don't seek to "disenfranchise" or disarm anybody. Rather, I'm operating on the assumption that the status quo has a limited shelf life, and at some point something is coming that will disarm everybody. This proposal is my way of trying to preserve gun rights (and, in fact, actually expand them) for people who meet a very minimal threshold of social connectedness. The people who can't meet that threshold are screwed long-term with or without this proposal, because until you can conjure up a way to prevent armed loners from shooting into crowds then it's going to keep happening and the ice under all of us will keep getting thinner.
You may never like the idea of having to rely on other people to vouch for you, but you're going to like the alternatives that the other side proposes way less.

I can get people to vouch for ME all day long. I don't care about what I get out of a new law, but what happens to the least represented people.
You are simply proposing that a right is more palatable if it can be preserved, inequitably or not. That isn't a right, and not worth preserving.
You are also interpreting the current political maneuvering and media coverage as some sort of evidence that the general public is poised for a sea-change. It isn't - more people appreciate the usefulness of firearms now then when the 1994 Assault Weapons ban was imposed. That is why it wasn't renewed, and why in that same period CCLs became normal in the US.
All that has happened is there is another incident for both sides to point at and say - "See what happens when you arm/disarm citizens!" The status quo is preserved due to the polarity of reactions.
I appreciate you putting on your thinking cap, but for the several reasons I posted on Pistol Forum related to personal liability as well as the unconstitutional nature of making citizens their brother's keeper, this can't possibly work. It won't be seriously discussed, voted for, upheld by SCOTUS or be able to administratively function. This is pie in the sky, like a Heinlein's suffrage for veterans idea. It can't be implemented without a fundamental revolution in our government/social structure.
So I'm not worried about the proposal going anywhere - it won't. I'm concerned about people that are so blase about disenfranchisement. You are selling privilege to an egalitarian society. It doesn't matter if you think 99% percent will be able to get that privilege - it is still a violation of equal protection under the law when it is based on relationships and not blind justice.
It actually makes me feel bad for you that you view your citizenship this way.

This proposal is my way of trying to preserve gun rights (and, in fact, actually expand them) for people who meet a very minimal threshold of social connectedness

Which mass murderer wasn't connected to a political group, religious movement or family, BTW? Do you actually have any good reason to believe that "loners" - as defined by your 5 person threshold, are the problem?

I can get people to vouch for ME all day long. I don't care about what I get out of a new law, but what happens to the least represented people.

Ah, now I see where you're coming from. In the original Proposal the organization was government run. Under that regime your arguments are valid because it would violate the 2A and all our individual rights. I'm opposed to such a system as well.
That's why Jon created a new version which is privately run and voluntary. Those who for whatever reason don't choose to join the network would still enjoy their 2A rights. The network is a way for us gun owners to police ourselves and keep gov't OUT of the picture as much as possible. This would require no new laws, no weakening of the 2A, no disenfranchisement, etc.
The hope is that we can weed out or identify possible bad actors by ruling out trusted gun owners. It may not be 100% effective, but it won't hurt or hamper anyone's rights either.

Re: You are also interpreting the current political maneuvering and media coverage as some sort of evidence that the general public is poised for a sea-change. It isn't - more people appreciate the usefulness of firearms now then when the 1994 Assault Weapons ban was imposed.

I have to strongly disagree with your assessment - though I hope to God you are right and I am wrong. The current crop of college aged kids are some very special snowflakes. In 5-10 years they will be out in the wild using the same tactics to agitate for gun control. And a Dem President and Congress seems likely at this point. Those two factors make me pretty pessimistic.

Where is this new version where you can have 2A rights outside the network? I can't find it.

@RX-79G click this link for a description of the new direction/version:
https://github.com/jonstokes/shootercontrol/issues/4#issuecomment-228237613

I just realized that Underwriters Laboratories (UL) is a near perfect analogue for this proposal. It is a private organization and compliance is completely voluntary, yet UL enjoys near complete adoption in the electrical products industry.

UL is just like any organization that private or government organizations decide to trust. The analog to UL would be if your gun background checks went through Experian rather than the FBI. The proposal is that your background check go through 4 of your drinking buddies.
I can't imagine those favoring gun control finding much in this proposal to like.

 Sincerely. The more holes you can poke the better because it forces us to think about things we may not have considered, or flesh out vague ideas. I hope you don't get tired of going round and round with us because it will ultimately make the project stronger or sink it.
OK, back to the grind :)
I actually thought about the structural difference between UL and the proposal. It may be that the monolith approach would be better than a distributed network. I'm not in love with or put off by either approach. Maybe once we get things a bit more fleshed out it would be a good idea to do an opinion poll of the different structures and include both pro and anti gunners.
On your other point about what the gun control crowd would get out of the deal, I've been kicking that around for a couple of days myself. Since the proposal is by gun people for gun people, it will naturally appeal more to gun people. I'm not really sure what gun control folks would find appealing at this point. Maybe later on in the process some things will become apparent.
But I did come up with some things to avoid so as not to poison the well with  gun control folks. For starters there would need to be some distance from the NRA. Their purpose is protecting the 2A, while this proposal is trying to cut down on gun crime. Any organization formed under this proposal would need to be transparent in it's operation, and pro-actively go public whenever bad actors are discovered. "Shooter Web Uncovers Another Terror Plot" is much better than "Shooter Web Involved in Another Terror Plot." (I know I know...MSM are in the tank for gun control, but I can dream)

I have already "sunk" the primary version of this as the sole method of validating a gun purchaser as legal. Now the original is just an add-on for anyone who likes it, and there is no reason that either side is going to like it aside from those that see it as easier than doing a bunch of different paperwork.
The central problem I see is that you guys really like the way trust networks work, and you'd like to solve other problems using it.
The rest of the world does not work much like the strange and wonderful world of computer coding. There is really no analog to something like shareware, and SSL certificates are only similar to things that banks did before there were central exchanges and banks.
Everywhere else business and people use centralized standard setters - like UL, ANSI, Federal Reserve, DOJ, FDA, municple building code, etc. They complain about dealing with these entities - but they trust them in that they are one authority looking after everyone, they answer for their errors and can be appealed to. What you are selling is completely outside the experience and comfort of most people, and it takes too long to explain it to get any average person (voter) to follow and see the complete structure and logic.
I am able to follow the whole thing, and I don't see the logic or benefit. It sounds like an administrative nightmare that would need to be overseen by a group of people that keep saying "trust me" when asked what's going on.
The SSL model is not an appropriate application to govern gun control, and none of the suggestions for how it works would appeal to either side. I really think you're wasting your time. If I came up with 3 major objections in the first 5 minutes of reading the proposal, people who actually do public policy for a living are going to make mulch out of it.

RX - this proposal is trying to cut down on gun crime to a) save lives, and b) take away the most effective tool the gun control folks have - mass shootings.
And yeah, you're starting to persuade me against the distributed trust model. (more on the other thread)


Update  to properly handle background color

This pull request fixes a bug where the method setSelectIndex does not update the background color of the tabBarItem.

thanks


Add autofocus on first char input

Would be great if the app autofocused the first char input so users can start typing right away, and fires the autofocus feature on next/prev actions.
Also this can improve the user experience playing only with the keyboard.

@isaniomoraes Yes! This would be a nice addition. Are you up for a PR?

@ollelauribostrom may I take this if @isaniomoraes hasn't done this already?

@ollelauribostrom nice, thanks!
@thedavidzhao please, go ahead :)
I didn't have a chance to work on this, but I can help testing or something else if you need.


sharding

Hello!
Proxy how time, integer, keyword sharding。
How do I import Java classes in a configuration file, such as those of the standard sharding strategy。

Please change title more make sense

Closed because title doesn't make sense.


Add 307 as valid response for pulling blobs

Fixes #397

does this affect conformance tests at all, or are redirects simply followed? (i think they are)

Redirects are followed automatically in Go (https://pkg.go.dev/net/http#Client). Does this need to be more generic than just on a blob GET, i.e. a statement at the top indicating http redirect status codes should be supported by clients according to https://www.rfc-editor.org/rfc/rfc7231#section-6.4

Does this need to be more generic than just on a blob GET

That would seem to cover all bases here

hmm.. adding redirects to the spec probably requires further consideration.
Was there any progress on creating a WG for auth?

Was there any progress on creating a WG for auth?

https://github.com/opencontainers/tob/pull/119

Closing this PR for now but will consider bringing up the issue during the call. Currently multiple clients already follow redirects but seems like this is intermingled with auth.


Fix require path in test

npm run dev fails on current master due to invalid casing in filename. This fixes that.

Hm, I don't experience this issue. Can you provide details of your setup like version for npm, node, operating system, etc., so that I might gain some insight?

I don't suppose you're on Windows @gregnb (paths are case-insensitive on Windows but not on Linux/OS X)? There is no Cities.json or Cities.js in the folder.

I can verify this, it doesn't work on OS X or on codesandbox: https://codesandbox.io/s/github/gregnb/mui-datatables
I also added a fix as part of this PR: https://github.com/gregnb/mui-datatables/pull/1087

I don't see the problem on Windows, but I don't see any harm in changing it to lowercase, as that is how it is used elsewhere, and that is the exact filename, so it should be fixed. Thanks for pointing this out @Legogris and thanks for helping to verify @patorjk.

I don't see the problem on Windows, but I don't see any harm in changing it to lowercase, as that is how it is used elsewhere, and that is the exact filename, so it should be fixed. Thanks for pointing this out @Legogris and thanks for helping to verify @patorjk.

Apart from Windows on NTFS/FAT, paths are generally case-sensitive on all filesystems and OS's in mainstream use today.


Posterior object for fast predictions

Summary
GPflow had already been optimised for speed in the training loop. This PR addresses the speed of predictions and resolves #1599. We achieve this by introducing new Posterior objects that can cache the results of a "precompute" stage (everything that's independent of test points) and thereby significantly speeds up repeated predictions.
Description of changes

Posterior classes contain a precompute() and predict_f() that is significantly faster for repeated predictions.
The "old" fused computations from conditionals() are incorporated as _fused_conditional() methods. This means the related code paths are always next to each other.
All the conditionals() implementations now solely construct the corresponding Posterior object and call its fused_predict_f() method, thereby remaining backwards-compatible.

This PR closes #1620, which is a previous iteration (left open for now for the review comments left on there already).
Outstanding tasks:

[ ] code clean-up

[ ] Identify & remove all avoidable transposes!
[ ] Add warnings to conditionals() to use Posterior objects instead (Can we do this even on import? Ideally we’d move the various conditionals() into a single file now that they just construct posteriors…)

[ ] design review of new posterior classes etc.

[ ] Are we happy with the DeltaDist / DiagNormal / MvnNormal classes?

[ ] code review of implementation
[ ] add missing tests

[ ] Numeric consistency check between the two code paths: for all “cached-posterior” predictions (all AbstractPosterior subclasses), we want to compare predict_f against the corresponding (“status-quo”) fused_predict_f (@johnamcleod is working on this)
[ ] Test to confirm it all works within tf.function() and allows swapping out of models without having to retrace/recompile the graph.
[ ] Test to confirm it all works within AOT compilation & gives expected speedup

[ ] add documentation

[ ] API docs?
[ ] We need to explain this to users. Ideally, the VFF notebook could demonstrate the difference between caching and fused predict!

[ ] revert the backwards-incompatible a9d889b before merging.

Co-authored-by<EMAIL_ADDRESS>

Should revert the backwards-incompatible a9d889b before merging.

Note- this change will also allow us to speed up predictions even further by carrying out the post-precompute predictions in float32 rather than float64; to make that easy to use will require further modifications ("posterior.as_dtype(np.float32)") which should go in a different PR.

It is hard to track technical changes/movements in the code. It would be nice to have guidance for a reviewer

To the best of my ability, I simply moved the code one-to-one from a gpflow.conditionals.conditional() implementation into the corresponding Posterior subclass's _fused_conditional() method.

the code moving bit requires careful handling. I do want to trust tests in this situation. However, I don't have full confidence that we actually have tests in GPflow with good coverage for many different failing/successful scenarios.

Yes, that's a concern I share. In the course of working on this PR @johnamcleod discovered #1651 and #1653.

If we're all happy with this PR in-principle, should we change the merge target to develop and close #1620?

Identify & remove all avoidable transposes!

As far as I know we don't have actual benchmarks that transpose make things worse in those (all) cases.

Are we happy with the DeltaDist / DiagNormal / MvnNormal classes?

No :)

Test to confirm it all works within tf.function() and allows swapping out of models without having to retrace/recompile the graph.

Either I don't understand what you mean or the answer is that it is not possible (you can't replace parts of a computational graph with another parts, a user have to recompile all the time)

Test to confirm it all works within AOT compilation & gives expected speedup

AOT is simply a compilation step from a graph representation to a native code, why would you test it?

Are we happy with the DeltaDist / DiagNormal / MvnNormal classes?

No :)

To clarify (following discussion) - it's not ideal as it is, but good enough to get the PR merged in. Let's rename them to _DeltaDist etc to ensure they're not seen as part of the public API.

Identify & remove all avoidable transposes!

As far as I know we don't have actual benchmarks that transpose make things worse in those (all) cases.

This does have a measurable effect, but it's not crucial - this already speeds things up much more. Let's keep track of it in an issue for potential future work. Though ideally this issue will be solved by smarter linear algebra compilers @awav is working on separately.

Most likely not perfect yet, but let's merge it and see what happens. :-)


v2.1.2 Grafana stopped working

Grafana stopped working for me with the new update, could be an issue with prometheus. Any ideas?

Can you see whether Prometheus is running correctly?
There have been quite a few changes recently to Prometheus. Knowing your full COMPOSE_FILE may help. I've just tried it on a fresh install with Teku and Besu and I am getting metrics.
Working through this on ethstaker Discord will be faster than a Github issue

We went through this on Discord. Prometheus is collecting metrics and Grafana sees them.


Prepare v1.1.0 release

fixed the version number in lerna.json
released new packages using lerna version

Saucelabs is failing if branch names include dots or slashes: https://phabricator.wikimedia.org/T262270
Closed this and created a new PR with a new branch name (tag-1-1-0 instead of tag-1.1.0)


Relational Query: Unify CASE generation

After PR #13469, we generate SQL CASE expressions in multiple places. We should consider going through the same codepath for both of them.

In new query pipeline we removed using ConditionalExpression in sql tree. Everything is case expression now.


Add watch towers to game state

Add positions of xelnaga watch towers to the game state object

Solved in #267


Badge' cannot be used as a JSX component

I'm getting this error while trying to use this on a typescript project. This error exists in the current project demo in the read me so I think something in the spec changed sometime over the last couple of months.
Badge' cannot be used as a JSX component.
  Its return type 'Promise<Element>' is not a valid JSX element.
    Type 'Promise<Element>' is missing the following properties from type 'ReactElement<any, any>': type, props, keyts(2786)

Hey @Kyle772, thanks for making an issue, this is essentially an issue with the current types in react. This module uses the new React Server Components feature that only some environments like Next.js app dir, maybe remix i'm not sure and some other react servers. You can read about them here https://beta.nextjs.org/docs/rendering/server-and-client-components#why-server-components, https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html  and https://remix.run/blog/react-server-components. Additionally Theo did a video on it a couple months ago https://www.youtube.com/watch?v=h_9Vx6kio2s. If you are using an environment that can run them, this type issue should be just ignored. You can either disable typechecking, but i don't recommend that, or add {/* @ts-expect-error Server Component */} above the component until the react types get updated. If you're not using a ssr environment your free to experiment with using an older version of this module, they should have the majority of the badges you could need.

Thank you for the info!
I am running this in Next 13 and I think my problem is stemming from me wrapping a Badge with additional elements in a more generic component which I am rendering on a page. I think I need to look more deeply into next's implementation of server components.

Okay so I've gone ahead and developed my implementation further with success but I'm constantly running into issues stemming from this component now that it's been converted to a server component. For example, if I have a list of technologies on a project and I only want to show 3 until someone clicks on it to show the full list that is no longer possible (as far as I can tell) since the client needs to be able to conditionally render them. It doesn't make sense to me to drill these components all the way down from the server component layout level and that seems to be the only way to get anything beyond basic rendering now.
That said I really feel like this library doesn't NEED to be a server component. It really limits where and how this is implemented. I'm likely going to downgrade in the meantime but I think you should reconsider setting this to server only.
Looking through the React server components docs my interpretation of the reasoning for server components is to save on performance wherever possible. Since these components are served as images your browser can just cache and reuse them. Maybe a second version should be added to the library to allow for client-side usage? Just some food for thought.

I'm not trying to defend RSC, they seem to have shortcomings and are still very beta. But the reason I decided to use them is fairly simple, as part of this package I needed to know the primary / accent / branding colour of every icon / brand. This project runs a script to grab it from some other source that has done all the work (I don't claim to have done it at all) and compiles it in to one massive json file.

The issue is the file size of that json file, with over 1500 icons its very large, not something I thought we would want to put on to the client. But that was my first implementation which worked ok.
So to combat this I built an api, very simply it would hold the json object in memory, and you could request the hex for a brand, very simple. Issue being to display any badge now required two network requests, plus I would potentially have to pay for the hosting but eh.
The next option I explored was using scripts to generate a new component for every single badge, taking advantage of tree splitting so people could use just the badges they want. Issue here was generating 1500 component .tsx files and compiling that to javascript files.
Lastly I rebuilt it using RSC, nextjs, remix, etc is responsible for the json object in memory and only sends the relevant data for the requested components to the client. So far this solves all the above issues, small client bundles, no double request, easy to build and distribute

On to the issues your facing, I totally see where your coming from, so all I can do is offer some solutions. Firstly with the app dir, you should aim to have pretty much everything server components, except for about 3 things: context, buttons and forms. those buttons and forms should be in seperate files with the "use client" at the top. Pretty much everything else should be server rendered. When it comes to holding state, you should put the state in the url, cookies, or hold them server-side.
I totally see that this isn't optimal for every project, all i'm offering is the knowledge i've gained working with the app dir and how it seems nextjs is pushing.
With client side conditional rendering, I don't love how its supposed to be done now, but its not terrible.
      <SummaryTabs
        paragraph={
          <Suspense fallback={<TextSkeleton title="Summary" />}>
            {/* @ts-expect-error RSC Yay */}
            <Summary topic={params.topic} />
          </Suspense>
        }
        dotPoints={
          <Suspense fallback={<TextSkeleton title="Summary" />}>
            {/* @ts-expect-error RSC Yay */}
            <DotPointSummary topic={params.topic} />
          </Suspense>
        }
      />

Heres an example of what I just implemented in a project. This jsx is inside a server component, but SummaryTabs is a client component, with Summary and DotPointSummary being server components. So with SummaryTabs holding state client side, users can click on the tabs to switch between the two server components. In practice it works pretty well. You could even build this in to something more dynamic, taking an array of objects of tab name and component. But really should store the state of the tabs in the url.
In the case of expanding a view to the user on click, a client component that takes the server component as children or a prop would probably work well.
On to your last point, I definitely see the possibility of two components and helper functions / hooks. A base level client component that requires the hex as a prop, then server component that wraps it to supply it, and other functions or hooks to grab the value from the api or you could load it yourself from the json file if thats the way people want to use it. When i've got some free time I'll look in to it.
Of course your completely free in the meantime to go to an older version of the module, they should still work fine. But if you want any help with specifics I'm more than happy to help out.


fix issue 2674 - enable towhee to work with pydantic 2.5.x

pydantic                 2.5.1
pydantic_core            2.14.3

Fix issue https://github.com/towhee-io/towhee/issues/2674
Fix issue https://github.com/towhee-io/towhee/issues/2676

Very tks for this pr, however, this change does not work in environments with pydantic<2. If you want to modify it, you need to make sure it works in both pydantic 1.x and 2.x.


Backwards compatible protocol / scheme

Hey,
One problem of deterministic schemes is that it can't store variable data. This especially becomes an issue when you need do deprecate or refactor the scheme used for password generation. A change means losing access to existing logins.
I would suggest versioning the hashing schemes, and creating a way of communicating the scheme version between the requesting and signing party. SL will always incrementally add hashing schemes while maintaining support for older ones. When a requesting party requests a deprecated hashing scheme; the password is hashed according to this scheme; but a update of the password is also sent to the requesting party along with the new version number.
This way requesting and signing parties maintain backwards compatibility and granular upgrading.
A point of concern with this would be requesting known weak schemes to attempt cracking the result. This could be solved through TTL (expiration dates) of older schemes in favour of the latest schemes. If an older scheme is requested past the TTL time frame, SL can either refuse hashing or display a warning to the user that the website is using an outdated scheme.

I'm not sure I understand what is requesting party here. Websites cannot request much from the app. They only offer provider and scope.
The hashing algo will be changed indeed, and there will be list like Weak, Medium, Recommended etc but it's only alg that will be applied to email+pw, and will never be exposed to websites. Users may migrate from email1+pw1+alg1 to email1+pw2+alg2 using Change Password page.

If you're talking about how verify method is implemented on the server side (signature verification, not hashing): https://github.com/andrewda/node-securelogin/blob/master/index.js#L53 then there's no planned versions in this direction. NaCl is a solid choice of primitives and if the industry chooses something else we will manually migrate to it. It doesn't happen often so far.

The requesting party is the website the user wants to login to. To maintain backwards compatibility incase of hashing scheme changes, you need to be able to specify which hashing scheme to use.
Lets say SL has hashing scheme "SLv1", and a user registers like so:
{
    email<EMAIL_ADDRESS>    password: md5(email + password),
    scheme: 'SLv1'
}

Now SL is updated, the hashing scheme is udpated to "SLv2":
{
    email<EMAIL_ADDRESS>    password: sha1(email + password),
    scheme: 'SLv2'
}

We will lose access to all websites, because of the new password result.
md5(email+password) !== sha1(email+password)
To solve this issue, we want the requesting party to be able to specify the hashing scheme.
Lets say we have a user stored as:
{user<EMAIL_ADDRESS>password: 'hashV1', scheme: 'SLv1'}
In the browser, we let the user enter their email. We use this email to request a hashing scheme:
>><EMAIL_ADDRESS>// Request the active hashing scheme for registered user<EMAIL_ADDRESS><< SLv1 // user exists with scheme SLv1

With the returned hashing scheme, we open the secure login app.
>> securelogin://?scheme=SLv1
<< {
    user: email, password: md5(email + password), scheme: 'SLv1',  // Login result matching requested hashing scheme
    update: {user: email, password: sha1(email + password), scheme: 'SLv2'} // Latest hashing scheme.
    }

Update database:
if(result.update)
    {user<EMAIL_ADDRESS>password: result.update.password, scheme: result.update.scheme}

When the user attempts to sign in again:
Request scheme:
>><EMAIL_ADDRESS>// Request the active hashing scheme for registered user<EMAIL_ADDRESS><< SLv2 // user exists with scheme SLv2

Login user:
>> securelogin://?scheme=SLv2
<< {
    user: email, password: sha1(email + password), scheme: 'SLv2',  // Login result matching requested hashing scheme
    }

@menzow There're two alternatives with your approach:

Rehash later. The app cannot rehash the password with an older algorithm later if needed because it doesn't know the password.
Hash with all protocols at profile creation time. Then what's the point of using the newer, more secure algorithms if the older ones are also stored?

I'm with @homakov on this one.

... it's only alg that will be applied to email+pw, and will never be exposed to websites. Users may migrate from email1+pw1+alg1 to email1+pw2+alg2 using Change Password page.

We neither use sha or md5, only crypto box of nacl:
https://github.com/sakurity/securelogin/blob/master/js/main.js#L275
There's also nothing like a "password" that's ever returned, only sltoken. Have a look at node lib above to see how it's parsed: no hashing again. if there would be a need to change from crypto box to something else (e.g. flaw in curve) that would be a different and unlikely scenario to add version to it. Now no need to bloat it with &ver=1
Websites cannot command what kind of derivation users should have used when they created their profiles. This is stored for future use https://github.com/sakurity/securelogin/blob/master/js/main.js#L412

Hey @homakov, the examples I gave are Psuedo code. They're meant to show backwards compatibility in a general sense, without diving into exact implementation.
I'll try to reiterate tomorrow.

Yeah I can't follow, so it's better if you can give direct links so i see what you mean

Not heard back yet @menzow , and from what I understood, at this point, there's no versioning. It might be added in the future and no need to bloat with v=1 requests right now.


ADBDEV-1357 ADB 6.14.1 sync

There is one more good fix in a current release - https://github.com/arenadata/gpdb/pull/163/commits/11baf067a511c140d6d7299929e39871c33f4c4b (fixes a problem from telegram chat).


config: Add new tests for default values.

Add tests to ensure default and overriden values are correct for
hypervisor, proxy, shim and agent.
Signed-off-by: James O. D. Hunt<EMAIL_ADDRESS>

Coverage increased (+1.02%) to 39.271% when pulling 8655c06c74924a248039f49b5c9c412fb7c8d541 on jodh-intel:add-hypervisor-defaults-tests into 8e2f96e4def6fa273fe661c15b2c64f6952123d9 on clearcontainers:master.

LGTM

lgtm


Remove token from hub_utils.tests.common.py and move to secrets

We should remove the token from the repo and move it to secrets, but we should make sure it works on PRs from forks.

@BenjaminBossan would you be up for this one?

I would be up but I have no idea yet how to actually solve the problem.

It's possible to have this work in PRs by doing some magic in GH actions, but then running the tests for users would require them to give a token. On the other hand, it's already the case that users would need to pass their token to create the docs. So maybe that's not a big issue?

On the other hand, it's already the case that users would need to pass their token to create the docs

They could still use the checked in token for that.

running the tests for users would require them to give a token

I don't really see a good solution for that. We could mark all tests that require a valid token (which amounts to the network tests I guess) and if users don't provide a token, skip them. If they make changes that don't require those tests, then we're fine, else they have to provide their own token . At the end of the day, all tests will be run on CI.

yeah I guess that works.

Just noticed we also haven the token here. This one could really be replaced by a GH secret, though I guess we would also need to invalidate it since it's already public, and as long as we still use the same token for tests, nothing is gained.

@BenjaminBossan AFAIK once you remove it on 🤗Hub it's invalidated. I think I don't have the user access to add tokens (I don't see the settings tab) maybe @adrinjalali can do it (and then we can replace the token with the secret).

yeah that one is the same as the one used by tests to create the repos. So changing it doesn't gain us anything.


Update SonosService.java

Prevent NPE on items with null type (occurs with .url files at least, which exist in OneDrive as shortcuts to OneNote notebooks).

Thanks for the PR


Consider rethinking the module structure

Currently everything in the windows crate gets exported at the top level. This certainly makes usage easy as the developer just needs to add windows::* to any module and all windows types are available to them. This, however, isn't the most idiomatic API approach.
One downside is that documentation will become harder to navigate as more features are added to the windows crate. Right now, everything is on one page which can make it hard to understand what's going on.

Possible other approach
Another approach would be to use the "prelude" pattern where items that are useful in almost any use of windows (e.g., Abi, Interface, ErrorCode, etc.) are in the prelude module. Users normally only import this module use windows::prelude::*;. Other items that are only useful in more specialized cases would be in submodules and users would individually import them. For instance, HString is only used in certain APIs. We could make the strings module public and users would import that type with use windows::strings::HString;
Which types go in prelude?
I would propose the following types live in prelude with all other types living in their various submodules:

ErrorCode, Error, Result
IUnknown, Object
Abi, Interface, RuntimeName, RuntimeType`
Array

Additionally Error and Result would be re-exported from the top level module and used like so windows::Result.

 The only thing worse than an endless list of declarations (windows atm isn't that bad actually, it could be libc after all) is one module for every declaration that's impossible to navigate because you have to go two steps into a documentation just to read any item.

I seem to have an opposite problem. For every symbol I want to add to build.rs I need to search the documentation  first to see in which module it belongs.

Going to close this issue as the Windows crate's documentation surface is not expected to get much larger. The public types are mostly limited to those that straddle both WinRT and Win32 and must thus be defined by the Windows crate. Most everything else should be included in the generated bindings as needed.


Struggling to install HSR game

Describe the bug
Currently having a hard time trying to install HSR using the Yaagl launcher- Keeps saying I change the download path other than those listed below in the screenshots, then whenever I try to lead it to a different path other than the ones it doesn't allow, it says this error.
Screenshots

System Information (please complete the following information):

macOS: Sequoia 15.0.1
Device: Retina 4K, 21.4-inch, 2019
CPU: 3 GHz 6-Core Intel Core i5
Dedicated GPU (if any): Radeon Prop 560X 4 GB
RAM: 8GB

Permission issues, Give Yaagl full disc access in system settings

Permission issues, Give Yaagl full disc access in system settings

I've already done it, still says the same thing

Fully uninstall and reinstall yaagl
Go to discord for any further problem support.


RFC: allow uint8 array parsed as string

Context: https://github.com/iovisor/bpftrace/issues/2248#issuecomment-1144512575
I'm looking for ways to compare two char array in bpftrace, some idea:

use str() convert two char array to string, and do strncmp() on them, it works, but seems cumbersome
implement char array binop comparison
parse char array as string, and compare them directly by == or strncmp()

This PR is a try of the 3rd idea, not sure if this is appropriate, please leave your comments. :)
In the following example, the daddr_v6 is defined as __u8 daddr_v6[16] in the tracepoint format.
tracepoint:tcp:tcp_retransmit_skb {
  $addr = args->daddr_v6;
}

When clang_parser parses this field, it firstly recognize this daddr_v6[16] field as CXType_ConstantArray, then its element type is CXType_UChar, a similar but different type from CXType_Char_U.
https://github.com/iovisor/bpftrace/blob/master/src/clang_parser.cpp#L333-L338
To achieve my goal with the 3rd idea, I added the CXType_UChar and CXType_SChar to the if-statement before CreateString(). Now the args->daddr_v6 can be recognized as a Type:string.
I don't think there is much difference between CXType_UChar and CXType_Char_U, how do you think?
Some info found: https://lists.llvm.org/pipermail/cfe-dev/2012-February/019902.html
Side effect
This pr may cause some of the existing char array becoming strings, as the changes in the test files shown.
There are other cases may fail, e.g., c_array_indexing https://github.com/iovisor/bpftrace/blob/master/tests/runtime/regression#L26
Checklist

[-] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[-] User-visible and non-trivial changes updated in CHANGELOG.md
[*] The new behaviour is covered by tests

Hi @viktormalik , I've include the potential side effects in addition to our prior discussion. Could you please comment on this? Thanks!

At first, this seemed to me like a good way to go, but now that I'm looking at it more, I'm not sure if treating any byte array as a string is good. Strings get some special handling in bpftrace and so this change, e.g., introduces unnecessary operations in codegen and breaks existing regression tests.
Maybe implementing a specialized operation for comparing fixed-size arrays (MACs, IPs, etc.) would be a better approach.

@viktormalik Yeah, I was worried about the breaking changes as well. Let me close this.


Trait to add right_or(Left) to Option<Right>.

To replace ok_or(Err).

Given that there is already fn right_or(self: Either<L, R>, val: R) -> R; (etc.) I think it may be confusing to add fn right_or(self: Option<R>, val: L) -> Either<L, R>; (etc.). However, these same-named functions are never on the same type, which would reduce confusion. (If Either::right_or were not already part of the public API, I might suggest changing that to unwrap_right_or if this feature is added, but that is not an option here.) Also, there is somewhat of precedence for this in std, with Result::unwrap_or vs Option::ok_or analogous to these, although those are not named the same.
Given that opt.right_or(left) would be equivalent to opt.map(Either::Right).unwrap_or(Either::Left(left)), I'm not sure that this feature would be particularly useful.
If this is added, I would also expect corresponding left_* and *_or_else methods e.g.

pub trait OptionExt {
    type T;
    fn right_or<L>(self, val: L) -> Either<L, Self::T>;
    fn right_or_else<L, F: FnOnce() -> L>(self, func: F) -> Either<L, Self::T>;
    fn left_or<R>(self, val: R) -> Either<Self::T, R>;
    fn left_or_else<R, F: FnOnce() -> R>(self, func: F) -> Either<Self::T, R>;
}

impl<T> OptionExt for Option<T> {
    type T = T;
    fn right_or<L>(self, val: L) -> Either<L, T> {
        self.map(Right).unwrap_or(Left(val))
    }
    fn right_or_else<L, F: FnOnce() -> L>(self, func: F) -> Either<L, T> {
        self.map(Right).unwrap_or_else(move || Left(func()))
    }
    fn left_or<R>(self, val: R) -> Either<T, R> {
        self.map(Left).unwrap_or(Right(val))
    }
    fn left_or_else<R, F: FnOnce() -> R>(self, func: F) -> Either<T, R> {
        self.map(Left).unwrap_or_else(move || Right(func()))
    }
}

You can also write those with Option::map_or and map_or_else:
impl OptionExt for Option {
type T = T;
fn right_or(self, val: L) -> Either<L, T> {
self.map_or(Left(val), Right)
}
fn right_or_else<L, F: FnOnce() -> L>(self, func: F) -> Either<L, T> {
self.map_or_else(|| Left(func()), Right)
}
fn left_or(self, val: R) -> Either<T, R> {
self.map_or(Right(val), Left)
}
fn left_or_else<R, F: FnOnce() -> R>(self, func: F) -> Either<T, R> {
self.map_or_else(|| Right(func()), Left)
}
}

... and then I think you might as well write that directly instead of having the extensions.


Coverage plugin fails when fails to load covered module

fixes #440

Coverage decreased (-0.05%) to 73.456% when pulling 3bb52943e4e78dc316525f6facd2231bc956f5c1 on arcivanov:issue_440 into 224567f188bf26c09d31013feef7a11cc6a0ef58 on pybuilder:master.


The pagination on the contacts page doesn't work

all the relative links (including those with the letter filter) point to the api urls ("/api/...")

I have fixed this here luca@4c89405a9d29ff371ff290767637da9d94889e37 by moving the API routes to the bottom of the routes.rb file (thus being the lowest priority)


refactor: use pydantic

What I did
Refactor to the Pydantic structured data and serialization library
fixes: #126
How I did it
Lots of pain
How to verify it
All tests pass + manual testing
Checklist

[ ] Passes all linting checks (pre-commit and CI jobs)
[ ] New test cases have been added and are passing
[ ] Documentation has been updated
[ ] PR title follows Conventional Commit standard (will be automatically included in the changelog)

This change affects all the plugins, as there are now a couple more (magic) methods to implement.
For example
class AccountContainer(AccountContainerAPI):

could now be
class AccountContainer(AccountContainerAPI, ABC):

else it should implement __get_item__ and __set_item__

closing in favor of #445 et al


TODO: CPadControl

This additional level of indirection concerns me. Not only is it forcing a bunch of locking but also we now have two levels of map lookups that could probably just be optimized to one.

Suggestion: rather than limit yourself to the design decisions of a 20 year old game with this CPadControl interface (which you've modified the behavior of anyway). Why no just modify the pad/host interface to do what you want?


why ClickHouseBatchExecutor#addToBatch() deal with UPDATE_AFTER ?

in my opinion, ClickHouseBatchExecutor is used in append-only scenario, but in fact, it also deal with update event

in my opinion, ClickHouseBatchExecutor is used in append-only scenario, but in fact, it also deal with update event

Yes, you are right.
ClickHouseBatchExecutor is only used in the append-only scenario.
In the current code, the update event won't enter ClickHouseBatchExecutor.addToBatch; the code will run normally.
The current code causes misunderstanding; I will fix it.


Alternating line fill behind reference examples is slightly off

Actual Behaviour
The gray and white alternating lines behind reference examples is slightly off. This seems to build up with consecutive lines.
Expected Behaviour
The gray and white lines alternate with the same height as the text in the example code.
Steps to reproduce it
It can be seen easiest for me in a long example such as the one for createShader.
I am running Chrome 74.0.3729.169 on Windows 10. I have a 4k screen so this could be related to pixel density. Though I tried using the chrome mobile design tool to try other things out to see if this changed and it was not.
Screenshots of the issue

Would you like to work on the issue?
I can but it would be a long time before I was able to get to it. If someone has time to do it sooner that would be preferable to waiting until I finish the other tasks on my plate. I just wanted to document it, and I didn't see an existing issue.

This doesn't show up on my side. macOS 10.14.4, Firefox 66.0.4, Chrome 74.0.3729.157, Safari 12.1
As you mentioned very possibly a pixel density issue or even a OS/browser issue.

I tried on another Windows 10 computer that has a 1080p display and still see the lines displaying as they do in the screenshot above in the same version of Chrome.
Those same lines display correctly in Firefox 66.0.5 and Edge 42.17134.1.0 on both computers.
So my guess is that it isn't the pixel density. It might be as simple as the 'line-height' css value or maybe the font metrics in the font being used in the code. I am a novice in this area so this is just speculation based on a quick search. Either way it is a minor problem that impacts a small subset of users. Though it seems probable that those alternating colors help low-vision people see the code more easily so I thought it worth documenting.

thanks @stalgiag I think I can track this one down. I seem to recall that the line spacing for text in the editor and the row colors are actually two different elements with their own css. I'll see what I can find.


Add plugin Facebook search API

Refer to

https://developers.facebook.com/docs/fort-pages-api/guides/posts

you must be an approved Facebook Research Partner. We are not accepting new partner applications at this time.


Feature/issue 1 docker config

Not quite sure how to expose telnet and if the transports are being started correctly. @justinvdm @hodgestar

@munsanje The go-app.js changes seem unrelated to this PR. I'm guessing they're just left over automated updates from another PR. If I'm correct, could you commit them separately? Either in a new PR or just ask me for an over-the-shoulder review before committing to develop.

@hodgestar There shouldn't actually have been any changes because I haven't changed the app.js or utils.js files... I suppose it was just rebuilt when I ran npm test.

Left a few comments, otherwise looks good.

:+1:


Theme sniffer is not supported by PHP 5.6?

When trying to activate this plugin on wordpress which is on PHP5.6 I get a fatal error :
syntax error, unexpected ':', expecting ';' or '{' in C:\xampp5.6\htdocs\GitHub\NativeSimple\wp-content\plugins\theme-sniffer\src\class-plugin.php on line 159

No it isn't. As noted in the readme, and on the plugin page, you need to have PHP 7.0 or higher to be able to run it.