MGMT-17148 Add sorting to tables

LGTM! My only comment would be that I personally would extract the sorting functions to the "utils" folder. Basically to avoid having such large code blocks in the main components.

great suggestion, I've extracted the functions.


war-unkdevils_icebox-betarar_7630f56a

Add content:

[UT3 MAP] WAR-=UNK=Devils_IceBox-BETA

Submission log: https://unrealarchive.org/submit/#7630f56a

This is a duplicate.


Minor readme tweaks regarding groupByType usage

The docs have a few inaccuracies around grouping / fetch:

Fetching a collection passing fetch an array of types shows the types pluralized in the result (which they are not).

groupByType requires hidden: true be included in the options to ensure _type is returned, otherwise the items will all be grouped under a single _unknown type.

Thank you for these. Every bit helps. The doc is long and easy to miss things like this. Appreciated.


Cache /ipns/<address> resources

It makes sense to save all visited /ipfs/<address> resources to MFS /ZeroNet/ipfs.
Regarding /ipns/<address> resources, there are two possibilities:

Use /ZeroNet/ipfs, resolving ipns domains/addresses. All versions will be preserved.
Use /ZeroNet/ipns. More accurate MFS, especially in case of frequent updates.

There is an idea to implement second way (more ZeroNet like way), but log all updates (when changed CID).


⚠ St. Lawrence Global Observatory CKAN Sitemap has degraded performance

In b8de26c, St. Lawrence Global Observatory CKAN Sitemap (https://catalogue.ogsl.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 5971 ms

Resolved: St. Lawrence Global Observatory CKAN Sitemap performance has improved in 91b6ce5 after 11 minutes.


Increase item XP issuance

After defeating a beast, the Adventurer receives XP based on the level and tier of the beast. Their equipped gear receives the same amount of XP and uses the same leveling system as the Adventurer, resulting in Adventurers and items generally leveling at the same rate.
With the current settings, it is extremely difficult to get and Adventurer to level 15+. Given that items only receive XP when they are equipped and adventurers may periodically change gear based on beasts, this results in chance of items getting to Greatness 15+ and unlocking extra stat boosts being too small.
Unlocking item stat boosts at greatness 15+ should remain difficult but should be similar to unlocking an extra life in traditional arcade games like Donkey Kong and Galaga. I propose modifications the item XP allocation code to be 3x of the adventurer. For an Adventurer that uses their starter weapon for every battle, this means it'll reach greatness 15 when the adventurer reaches level 5.

Pushed to feat/adventurer via https://github.com/BibliothecaDAO/realms-contracts/commit/be140b3117db551590da8024ae04d54406b48f48


inert=true is not being removed when Lightbox is unmounted

Describe the bug
I am using the <Lightbox> component in to display gallery images. and I'm using a custom slideContainer to add some extra information to the image along with a link to the users profile.
When the user clicks this link the app will change views without closing the lightbox. Unfortunately the lightbox is not removing the inert="true" attribute from the root so the page gets "frozen"
Expected behavior
The lightbox should remove the inert="true" and aria-hidden="true" attributes from the root when unmounted
How to reproduce

Create a simple app that renders the Lightbox component
Open the lightbox
Make the app unmount the lightbox without the user closing it

Screenshots / Logs
No response
Additional context
Thanks for making a react lightbox component that actually works and isn't built on jQuery

What version of the lightbox are you using?

The issue you are describing sounds like #209. Please upgrade the lightbox to the latest version and see if it resolves your issue.

I was using 3.12.1 and tried to upgrade to the latest but was still getting the issue.
I tried it again (this time with removing node_modules / lock file) and the issue seems to be resolved. I guess when I upgraded it did not pull in the latest version
Thanks for responding so quickly and sorry for wasting your time

Thank you for confirming the latest version addresses your issue. That bug actually affected versions 3.15.0 through 3.15.3. I suspect your package.json contained a dependency on ^3.12.1, but your lock file was actually pinned to one of the affected versions.


No Http Client Reuse

In RequestService.cs - CreateHttpClient() gets called every time to create a new HttpClient instance - was there a reason to not create a singleton? Just that the performance improvement isn't worth it?

We will change this with Xamarin Essentials.


#963 Remove Outdated PPL Sort Syntax

Description
Resolves #963.
Related Issues
OpenSearch SQL issue: https://github.com/opensearch-project/sql/issues/3180
Check List

[ ] ~Updated documentation (docs/ppl-lang/README.md)~
[x] Implemented unit tests
[x] Implemented tests for combination with other commands
[ ] ~New added source code should include a copyright header~
[x] Commits are signed per the DCO using --signoff

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

I don't think the sort syntax is outdated. But I agree we should remove this syntax since it is unimplemented. How about change the PR title to Remove unimplemented PPL Sort Syntax?

Thanks @LantaoJin. Agree that "unimplemented" is more accurate. Please also see the discussion on the equivalent SQL issue. The consensus there seems to be to keep this syntax for the time being, update all the documentation to indicate that this method is deprecated, and remove it completely in the next major release.
As such, I will be updating this PR to merely mark the syntax as deprecated in the documentation.

This doesn't resolve #963 - but just deprecates the unimplemented language.
I would link the issues together, but I don't think we should close that issue just because we're deprecating the language.


feature: Add echo-lambda example

Add echo reply bot function to example.
・When checking the connection, "00..." is included in the ReplyToken, so add that verification.
Hope it can help, thanks.

I'm not familiar with AWS Lambda.
The PR deals with '00...' . What about 'ff...' ? Should we return success to context ?

"00..." / "ff..."is a replay token included in the event object that is sent when a connection error occurs when activating the webhook url in the Line Developer API console.

{"events":[
  {
    "replyToken":"00000000000000000000000000000000",
    "type":"message",
    "timestamp":1570728501562,
    "source":{
      "type":"user",
      "userId":"Udeadbeefdeadbeefdeadbeefdeadbeef"
    },
    "message":{
      "id":"100001",
      "type":"text",
      "text":"Hello, world"
    }
  },
  {
    "replyToken":"ffffffffffffffffffffffffffffffff",
    "type":"message",
    "timestamp":1570728501562,
    "source":{
      "type":"user",
      "userId":"Udeadbeefdeadbeefdeadbeefdeadbeef"
    },
    "message":{
      "id":"100002",
      "type":"sticker",
      "packageId":"1",
      "stickerId":"1"
    }
  }
]}

Since this event object will not be generated after the bot server is created and the webhook url is enabled in the Developer console, I think it is unnecessary in the sample code.
Context.success is the second argument that can be passed to AWS lambda, and is the method that will return a response upon success.
Console.log("success",data) is the same, so I removed it.

OK. Cool. Thanks.


Every time the fifth scan, the device will not be scanned

Every time the fifth scan, the device will not be scanned and this error will be reported
BluetoothLeScanner(31703): onScannerRegistered() - status=6 scannerId=-1 mScannerId=0

Hi,
You might scan too frequently ( Android limits the scans to 5 scans/ 30 seconds)
More info : https://blog.classycode.com/undocumented-android-7-ble-behavior-changes-d1a9bd87d983

Hi,
You might scan too frequently ( Android limits the scans to 5 scans/ 30 seconds)
More info : https://blog.classycode.com/undocumented-android-7-ble-behavior-changes-d1a9bd87d983


ForceSync for Table ext. when removing latest physical field causing SQL errors when creating new companies

Describe the bug
Create a new Table Extension with at least one physical field and one FlowField. Publish/Install (F5). Then remove the physical field, keeping the FlowField. Publish/Install (F5). That leaves the extension table with only PK fields, causing SQL errors when creating a new company.
Is this expected for "ForceSync"? When publishing again with "Recreate", then the extension table is removed correctly.
To Reproduce
Steps and to reproduce the behavior:

Set your launch.json to ForceSync.
Create a new Table Extension for any table with a FlowField and a physical field.
Publish/Install from VSCode (F5)
Stop Debugging
Remove the physical field, keep the FlowField.

Actual behavior
The following SQL error was unexpected:
Incorrect syntax near ')'.
SQL statement:
CREATE TABLE dbo."lala$Purchase Line$73577357-7357-7357-7357-735773577357" (CONSTRAINT "lala$Purchase Line$73577357-7357-7357-7357-735773577357$0" PRIMARY KEY CLUSTERED ("Document Type","Document No_","Line No_"))
Versions:
Name: AL Language
Id: ms-dynamics-smb.al
Description: AL development tools for Dynamics 365 Business Central
Version: 3.0.152816
Publisher: Microsoft
Version: Platform 14.0.32600.0 + Application 32615 (DE Dynamics NAV 14.1)

Hi @MODUSCarstenScholling ! I've forwarded the question to our SQL experts.

Thank you for the well written issue! This appears to be a bug in the synchronization engine. I have forwarded the issue to the appropriate team.

Hi @MODUSCarstenScholling
Thank you for the detailed repro steps, I have created a fix to the issue, and it will be released with platform version 14.4.

Thank you!

Looks like I spoke too soon, the complete fix to the issue might not make it for 14.4, but will definitely make it for Oct 2019.

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 35226.
If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo
For more details on code branches and docker images please read:
https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/
https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/


scipy.optimiza.minimize x0 Constraint Validation Uses Strict Inequality

Currently the constraint validation for the initial guess checks against a strict inequality. I would assume we should adhere to the <= or >= for these checks so that the initial guess can be one of the bounds. In particular, I want to freeze one of the variables to a certain value, and this prevents me from doing that.
_constraints.py, line 244:
        if np.any(f0[mask] < lb[mask]) or np.any(f0[mask] > ub[mask]):
            raise ValueError("`x0` is infeasible with respect to some "
                             "inequality constraint with `keep_feasible` "
                             "set to True.")

_numdiff.py, line 361:
    if np.any((x0 < lb) | (x0 > ub)):
        raise ValueError("`x0` violates bound constraints.")

Both of the examples quoted above allow x0 be equal to lb or ub? Did you mean to point to some other part of the code?

Oops, yeah sorry about that.


Separate spice refresh from CFN template

Fix qoute issue
Name fix
Issue #, if available:
Description of changes: Separating spice refresh in it's own CFN template.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Detected a problem when suffix is empty, do not merge yet, I will update the PR soon

This latest commit handles the empty suffix issue tested both use cases, and can be merged safely.


Add to settings the ability to switch seasons

Should reload the picker screen and reset any existing picks made by the user

Successfully switching data, issue of components not rendering with new data though

Comming in next commit


Charts[Gateway] Parameterize Ingress Port Mapping

Feature to Enhance
Various listener port mapping in gateway needs to be parameterized so that user can override the defaults.
Requested Enhancement
Currently Gateway port mappings are hardcoded as below:
GOSSIP: 51XXX
GRPC: 52XXX
GRPCS: 53XXX
etc.
We need to be able to set this in the values.yaml. Values.yaml should have the above port as defaults.
We also need to be able to disable exposing certain port mappings such as GOSSIP or GRPCS ports when required.
Business Need
Allow user to set the ingress port settings as necessary by overriding it in values.yaml file.
Additional Context
No response

:tada: This issue has been resolved in version 0.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


404 Not Found

When I trying to test ChatgptAPI, I've receive 404 error.
Error code from revChatGPT.V1
python3 -m revChatGPT.V1

    ChatGPT - A command-line interface to OpenAI's ChatGPT (https://chat.openai.com/chat)
    Repo: github.com/acheong08/ChatGPT

Type '!help' to show a full list of commands
Press Esc followed by Enter or Alt+Enter to send a message.

You:
hi

Chatbot:
Traceback (most recent call last):
 File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/site-packages/urllib3/connectionpool.py", line 700, in urlopen
self._prepare_proxy(conn)
 File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/site-packages/urllib3/connectionpool.py", line 996, in _prepare_proxy
   conn.connect()
 File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/site-packages/urllib3/connection.py", line 369, in connect
self._tunnel()
 File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/http/client.py", line 924, in _tunnel
raise OSError(f"Tunnel connection failed: {code} {message.strip()}")
  OSError: Tunnel connection failed: 404 Not Found

I guess, I have issue to setting proxy server. Please share some information to setting the proxy.

yes，I have similar question too,and my opint similar with you.
| |
@.***
|
|
@.***
|
---- Replied Message ----
| From | @.> |
| Date | 03/29/2023 01:30 |
| To | @.> |
| Cc | @.***> |
| Subject | [acheong08/ChatGPT-Proxy-V4] 404 Not Found (Issue #22) |
When I trying to test ChatgptAPI, I've receive 404 error.
Error code from revChatGPT.V1
python3 -m revChatGPT.V1
ChatGPT - A command-line interface to OpenAI's ChatGPT (https://chat.openai.com/chat)
Repo: github.com/acheong08/ChatGPT

Type '!help' to show a full list of commands
Press Esc followed by Enter or Alt+Enter to send a message.
You:
hi
Chatbot:
Traceback (most recent call last):
File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/site-packages/urllib3/connectionpool.py", line 700, in urlopen
self._prepare_proxy(conn)
File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/site-packages/urllib3/connectionpool.py", line 996, in _prepare_proxy
conn.connect()
File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/site-packages/urllib3/connection.py", line 369, in connect
self._tunnel()
File "/Users/noirmist/opt/anaconda3/envs/gpt/lib/python3.11/http/client.py", line 924, in _tunnel
raise OSError(f"Tunnel connection failed: {code} {message.strip()}")
OSError: Tunnel connection failed: 404 Not Found
I guess, I have issue to setting proxy server. Please share some information to setting the proxy.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Set as environment variable: CHATGPT_BASE_URL. Not proxy in config. That's different

yes,ok
| |
@.***
|
|
@.***
|
---- Replied Message ----
| From | Antonio @.> |
| Date | 03/29/2023 16:35 |
| To | @.> |
| Cc |<EMAIL_ADDRESS>|
| Subject | Re: [acheong08/ChatGPT-Proxy-V4] 404 Not Found (Issue #22) |
Set as environment variable: CHATGPT_BASE_URL. Not proxy in config. That's different
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

Set as environment variable: CHATGPT_BASE_URL. Not proxy in config. That's different

Hello, can you maybe elaborate a bit? I also get Error 404 and wasn't able to solve the issue because I don't understand what you meant by that :(


add new rule require-nullable-fields-with-oneof

fixes https://github.com/B2o5T/graphql-eslint/issues/1138

@dotansimha I will merge it but happy to hear your review!


.github: add issue templates

You can view a functional test version of this PR here: https://github.com/bmizerany/ollama-test-issues-tempates/issues/new/choose

I've updated with review comments.
The order in which these appear have been reorder so that 'Bug Report' is sandwiched so that its less likely to be clicked in a knee-jerk fashion when "Feature Request" or "Model Request" was the better choice.

P.S. You can view a functional test version of this PR here: https://github.com/bmizerany/ollama-test-issues-tempates/issues/new/choose

LGTM after @mxyng's comments are addressed, this is awesome!


Fix consistency

Change "organisation 3" to "organisation RC". This is so that the whole text is consistent in its naming convention of the organisation names.

Thanks for the contribution! this is a read-only mirror. please read the contribution guide.
Thanks for the contribution! However, this is a read-only mirror. please read the contribution guide. Also, feel free to join us on chat!


HARVESTER: cover access credentials edge case

Linked Issues

https://github.com/harvester/harvester/issues/1967

@WuJun2016 Regex: ^[0-9a-zA-Z]+$
Username which is included symbol is not allowed to add.


rebase: rebasing master (PROJQUAY-2358)

This PR rebases branch redhat-3.6 to include fixes present in master branch

@harishsurf @jonathankingfc can I have an approve on this one. It is just a rebase on master.


Added future weather details

Added weather details for future weather forecasts in weatherDetails.js

Merge from Richard branch


feat: adjust default cache size for arity

Any update on testing?

@dignifiedquire Made a minor update to your changes and also added a tree size/arity validity check.

tested, much better performance


Black screen after logging in

Black screen with blinking underscope after logging in on Fedora 32(both proprietary and open-source NVidia driver)

I found the error and used audit2allow and sepolicy to generate a policy for ly to be useable with SELinux. Maybe we can add a step to the Makefile to generate and install the SELinux policies? Or go further and add a spec file so we can build rpms of ly on the Fedora Copr buildsystem.
ly-selinux-policies.tar.gz.zip

I found the error and used audit2allow and sepolicy to generate a policy for ly to be useable with SELinux. Maybe we can add a step to the Makefile to generate and install the SELinux policies? Or go further and add a spec file so we can build rpms of ly on the Fedora Copr buildsystem.
Here the policy I generated. You need to run the ly.sh as root to install it.
ly.tar.gz

Here is a first WIP for the spec file. We would need to add the .te file from above to the repo so I can actually write a make entry that compiles the module.
Name:       ly
Version:    0.5
Release:    2
Summary:    A TUI display manager
License:    WTFPL
BuildRequires: libxcb-devel
BuildRequires: pam-devel
Requires: libxcb
Requires: pam

%description
Ly is a lightweight TUI (ncurses-like) display manager for Linux and BSD.

%prep
rm -rf $RPM_BUILD_DIR/ly
rm -rf $RPM_BUILD_DIR/src
git clone https://github.com/nullgemm/ly.git src
cd $RPM_BUILD_DIR/src
make github

%build
cd src
make

%install
cd src
mkdir -p %{buildroot}/etc/
mkdir -p %{buildroot}/usr/bin/
mkdir -p %{buildroot}/usr/lib/systemd/system/
mkdir -p %{buildroot}/etc/pam.d/
DESTDIR="%{buildroot}" make install

%files
/usr/bin/ly
/usr/lib/systemd/system/ly.service
/etc/ly/lang/es.ini
/etc/ly/lang/pt.ini
/etc/ly/lang/ru.ini
/etc/ly/lang/en.ini
/etc/ly/lang/fr.ini
/etc/ly/lang/ro.ini
/etc/ly/xsetup.sh
/etc/ly/wsetup.sh
/etc/ly/config.ini
/etc/pam.d/ly

%changelog

I made a WIP Copr for ly
https://copr.fedorainfracloud.org/coprs/dhalucario/ly/

The WIP seems to work now properly.
You still need to enable the service and disable getty@tty2 by hand (and make sure that your systemd target is set to graphical sudo systemctl set-default graphical.target). Then it should work just fine.

The WIP seems to work now properly.
You still need to enable the service and disable getty@tty2 by hand (and make sure that your systemd target is set to graphical sudo systemctl set-default graphical.target). Then it should work just fine.

thanks for putting this together @dhalucario ! i was able to login with ly using your COPR build, however i had some other issues creep up: 1) being prompted for a password when starting firefox, 2) not being able to 'reboot' without sudo, and 3) not being able to launch dmenu on one of my wms. when I removed your build of ly everything went back to normal. is there anything in your ly policy, or any other packaged files, that would cause these changes? thanks

I know that the display manager usually does a lot of initialization when it comes to permissions for specific tasks which I haven't completely figured out myself. I use awesome WM and I can use Firefox just fine. Maybe you could tell us more about your system so we can try to debug stuff.

How did you install Fedora? Did you use Fedora Workstation or Fedora Everything?
Also which desktop environment are you using?

I remember some DE's wanting the password for Firefox because its trying to access the keychain.

#310 I created a pull request for the files. It would be cool if we could add this to the repo.

@nullgemm

This is awesome  @dhalucario, let's discuss it on the PR thread: #310

I tried using the copr repo in Fedora 36 (KDE) and it didn't even want to download the package. Also, the selinux permission script provided above returns an error message (I am not in my computer rn but when I get home I'll qoute it). How can I give Ly a selinux permission manually? I am dying to use it as my display manager over sddm.

This issue is now tracked on #494.


new term: gastrulation (sensu vertebrata)

I would like to request the new term 'gastrulation
(sensu Vertebrata).
This could be placed as a daughter of GO:0001702
'gastrulation (sensu Deuterostoma)' and parent of
GO:0010003 'gastrulation (sensu Mammalia)'.  Such a
term would allow curators of non-mammalian vertebrates
(such as zebrafish) to make annotations to gastrulation
at a finer granularity than sensu Deuterostoma.
Definition:  The process of gastrulation as is
characteristic in vertebrates
Database Ref: ZFIN:dh
-Doug
Reported by: doughowe
Original Ticket: "geneontology/ontology-requests/1430":https://sourceforge.net/p/geneontology/ontology-requests/1430

thanks www.movied.org


Validation of arguments pass to the function of MayaInterval class

Fix for https://github.com/kennethreitz/maya/issues/66
Added decorator to validate arguments passed to the class' function. Added test-cases to validate the invalid argument scenarios.

rebase needed!

@kennethreitz Rebase Done!
✨🍰✨

Thanks so much!


Add input to harmony validators

The generic parameters would get too many. There are other ways to achieve this


Workaround for Icache tests from Ibex Core

Hey!
In this pull request I changed assign on variable declaration. This is needed for run Icache tests from Ibex Core on Riviera-PRO
Signed-off-by: Dawid Zimonczyk<EMAIL_ADDRESS>

Hmm, this is odd. Was the previous code incorrect according to the SystemVerilog spec? I would have thought that this is just an example of a "Variable declaration assignment" as described in section 10.5.

Agree with @rswarbrick
perhaps explain why the tool doesn't support it, so that we can change our coding style to avoid this.

@rswarbrick You are right, this code is allowed by LRM. Simulator have problem with assign extern function with class type to variable at declaration, that's why I separate this, to declaration and then assign to this variable

@rswarbrick You are right, this code is allowed by LRM. Simulator have problem with assign extern function with class type to variable at declaration, that's why I separate this, to declaration and then assign to this variable

@dawidzim do you plan to fix this issue in the tool soon? I'm OK with the current fix, but I feel we don't want to force this rule in our code guide, so we may see it later and you may need to fix it again.

This PR appears to have been abandoned (and we're not really open to taking workarounds for bugs in tools we don't use). Closing.


Frequency reporting from the runtime is broken after stopping run

Describe the bug
I tried to use the GEOPM Runtime to profile my MPI application and I expected frequency reporting to work instead no frequency data was present in the reports.
GEOPM version
v3.1
Expected behavior
All reports always contain frequency data:
$ cat sgemm_1_cpu_sweep_3500000000_report.yaml
GEOPM Version: 3.1.1.dev47+g6e066589d
Start Time: Tue Aug 06 16:04:12 2024
Profile: "sgemm_1_cpu_sweep_3500000000"
Agent: monitor
Policy: {}

Hosts:
  x1001c3s2b0n0:
    Application Totals:
...
      frequency (%): 171.956
      frequency (Hz): 3.43911e+09
...

Actual behavior
$ cat sgemm_1_cpu_sweep_3500000000_report.yaml
GEOPM Version: 3.1.1.dev47+g6e066589d
Start Time: Tue Aug 06 16:27:44 2024
Profile: "sgemm_1_cpu_sweep_3500000000"
Agent: monitor
Policy: {}

Hosts:
  x1001c1s6b0n0:
    Application Totals:
...
      frequency (%): 0
      frequency (Hz): 0
...

Error messages produced
None
Additional context
This was encountered during the third run of a CPU frequency sweep.  On the first run, the frequency reporting worked as expected.  The second run was started, then CTRL-C'd to stop it during the first frequency trial.  Then the third run exhibited the problem with 0's reported for the CPU frequency fields.
Once in this state, re-running will always produce 0's in the reports for the CPU frequency fields.  I was able to restore the proper frequency reporting by issuing sudo systemctl restart geopm.
The current suspicions around why this is occurring center around our use of the fixed performance counters.  We program them here:
https://github.com/geopm/geopm/blob/6e066589d961f72055ca32bcd2bed3e062885ed7/libgeopmd/src/MSRIOGroup.cpp#L1056
That programming occurs the first time any signal is pushed.  The control writes that happen in MSRIOGroup::enable_fixed_counters() occur outside the regular save/restore mechanisms because this code executes under the context of the root user, thus bypassing the save/restore file that is created in geopmdpy.
The only way for the fixed counters to be restored to their initial state is for the Controller to call m_platform_io.restore_control() as it does at the end of Controller::run().  There is another call to m_platform_io.restore_control() in the Controller destructor, but it seems there may be a race that prevents that from resolving this issue as it is gated by m_do_restore.  m_do_restore is only set true part way through Controller::run().
It seems if the run was killed before that line was reached, the restore never occurs.
A few potential solutions:

Move the save_control() call to either be directly after IOGroup initialization, or make it a part of IOGroup initialization.  Also, enable_fixed_counters() would also have to be called during MSRIOGroup construction, and not later like it is now.
Ensure restore_control() is always called as long as save_control() has completed.
Evaluate the need for using the fixed counters at all.  See if we can avoid their use entirely.

Current alias mappings to fixed counters:

CPU_INSTRUCTIONS_RETIRED -> MSR::FIXED_CTR0:INST_RETIRED_ANY
CPU_CYCLES_THREAD -> MSR::FIXED_CTR1:CPU_CLK_UNHALTED_THREAD
CPU_CYCLES_REFERENCE -> MSR::FIXED_CTR2:CPU_CLK_UNHALTED_REF_TSC

THREAD and REFERENCE could be mapped to APERF and MPERF.  Experiments are needed to ensure this would capture the same data as before re: when the counter is actually counting - through sleep states or not.
Unclear if there is another way to get INSTRUCTIONS_RETIRED.

I saw another instance of this bug today, but it manifested differently.  Instead of reporting 0 for the frequency fields, a seemingly valid number was in place.
Expected results:
$ grep "frequency (%)" *report*
sgemm_1_cpu_frequency_sweep_1400000000_report.yaml:      frequency (%): 69.9064
sgemm_1_cpu_frequency_sweep_1500000000_report.yaml:      frequency (%): 74.8983
sgemm_1_cpu_frequency_sweep_1600000000_report.yaml:      frequency (%): 79.8956
sgemm_1_cpu_frequency_sweep_1700000000_report.yaml:      frequency (%): 84.8837
sgemm_1_cpu_frequency_sweep_1800000000_report.yaml:      frequency (%): 89.882
sgemm_1_cpu_frequency_sweep_1900000000_report.yaml:      frequency (%): 94.8654
sgemm_1_cpu_frequency_sweep_2000000000_report.yaml:      frequency (%): 99.8389
sgemm_1_cpu_frequency_sweep_3500000000_report.yaml:      frequency (%): 171.852

Actual results:
sgemm_1_cpu_frequency_sweep_1400000000_report.yaml:      frequency (%): 144.934
sgemm_1_cpu_frequency_sweep_1500000000_report.yaml:      frequency (%): 128.873
sgemm_1_cpu_frequency_sweep_1600000000_report.yaml:      frequency (%): 129.664
sgemm_1_cpu_frequency_sweep_1700000000_report.yaml:      frequency (%): 137.239
sgemm_1_cpu_frequency_sweep_1800000000_report.yaml:      frequency (%): 112.498
sgemm_1_cpu_frequency_sweep_1900000000_report.yaml:      frequency (%): 146.176
sgemm_1_cpu_frequency_sweep_2000000000_report.yaml:      frequency (%): 127.741
sgemm_1_cpu_frequency_sweep_3500000000_report.yaml:      frequency (%): 168.677

The node where this started to happen was reporting normally.  As before, CTRL-C'ing a run down brought about this behavior.

At today's architecture meeting, the following was proposed:
Fixed counter usage:

Map APERF and MPERF to INSTRUCTIONS_THREAD and INSTRUCTIONS_REFERENCE.  Perform frequency sweep experiment to verify data is the same as was being gathered with the previous fixed counters.

For CPU_INSTRUCTIONS_RETIRED if the user calls: read_signal() or tries to push_signal() without first writing “ENABLE_CPU_INSTRUCTIONS_RETIRED_CONTROL” then an error will be presented.

“ENABLE_CPU_INSTRUCTIONS_RETIRED_CONTROL” will be a new control that must be written for any code that leverages CPU_INSTRUCTIONS_RETIRED (e.g. the Tracer).

In short, use APERF/MPERF for frequency reporting.  For CPU_INSTRUCTIONS_RETIRED, a new ENABLE control will be created that is leveraged by all callers that need this signal.  There are no callers that require this signal today (i.e. it is not used in either the reports or traces).


Update README.md

Adding in the Bower install command so devs know: 1) that the repo uses Bower and 2) what the name of the package is on the Bower registry.

Thanks, added ;)


dictation not working on recent commits

Commits after b26bf15ee1fb0b5feb6846d6e8077d8ee6cc9028 on the main branch cause all dictation (say command, formatters and dictation mode) to not work for me using Talon 0.3.0 on a Mac M1. The talon.log file shows the following error when talon starts up. Checking out commit b26bf15ee1fb0b5feb6846d6e8077d8ee6cc9028 directly makes dictation work and does not show the error on startup but the (currently) three commits after that on main do not work for me.
Note that another user has also reported seeing this on the Talon Slack chat (https://talonvoice.slack.com/archives/C7ENXA7C4/p1658075312159609?thread_ts=1658061197.879179&cid=C7ENXA7C4).
2022-07-17 16:58:13 ERROR user.knausj_talon.code.vocabulary: action dictate.replace_words() failed type check
   20:  lib/python3.9/threading.py:937* # loader thread
   19:  lib/python3.9/threading.py:980*
   18:  lib/python3.9/threading.py:917*
   17:     app/resources/loader.py:827|
   16:     app/resources/loader.py:771|
   15: talon/scripting/registry.py:193|
   14: talon/scripting/registry.py:204|
   13: talon/scripting/dispatch.py:105|
   12: talon/scripting/dispatch.py:144|
   11: talon/scripting/dispatch.py:135|
   10:     talon/scripting/rctx.py:233| # 'update_decls' main:update_decls()
    9:    talon/scripting/scope.py:150|
    8:    talon/scripting/scope.py:131|
    7: talon/scripting/dispatch.py:105|
    6: talon/scripting/dispatch.py:144|
    5: talon/scripting/dispatch.py:135|
    4:     talon/scripting/rctx.py:233| # 'change' main:_registry_update_contexts()
    3:    talon/scripting/scope.py:55 |
    2: talon/scripting/registry.py:455| # [stack splice]
    1:    talon/scripting/types.py:196|
talon.scripting.types.ActionImplError: Function 'dictate.replace_words' incompatible with prototype 'dictate.replace_words'
  Signature: (words: collections.abc.Sequence[str]) -> collections.abc.Sequence[str]
  Expected:  (words: Sequence[str]) -> Sequence[str]
  - Parameter 'words' type annotation does not match prototype. Found 'collections.abc.Sequence[str]', expected 'Sequence[str]' (or no annotation)
  - Return type mismatch. Found 'collections.abc.Sequence[str]', expected 'Sequence[str]' (or no annotation)
2022-07-17 16:58:15  INFO (SpeechSystem) Activating speech engine: W2lEngine(fast Conformer b108 (2021-09-15))
2022-07-17 16:58:15 DEBUG Dispatched launch events at 1.4764s, done at 2.7376s
2022-07-17 16:58:15 ERROR [!] 2 error(s) during startup (shown earlier in log)

It seems that this commit (2bafd31d) might be the cause since it seems to add the collections.abc.Sequence that the talon error above mentions

Reverting the commit mentioned above locally also solved the issue. Not that I'm suggesting that should be the fix here, only that this indicates that particular commit seems to be the cause.

https://github.com/knausj85/knausj_talon/issues/816
https://github.com/knausj85/knausj_talon/pull/918#discussion_r920003088
Please remove pyupgrade from the knausj_talon process and revert any typing changes for now until I have official advice on this.
In general, pyupgrade seems like it's a bad idea to run automatically on talon repos. Any syntax upgrades should be intentional and measured.

This  should be fixed now. If you could confirm it works for you that would be great.

Thanks for the super quick fix. I can confirm that the latest main commit works for me.


customization for write model filters

this PR addresses #26. this first basic implementation addresses a use case reported by @adamarla from runtitle.

@adamarla thx for reporting back that the feature works as expected. would be great if you can take some time and read through the simple documentation section about this which I added https://github.com/hpgrahsl/kafka-connect-mongodb/pull/27/commits/546a2d268e15a334a696fe20b52967a76f75265a  does it make sense to you?

@adamarla do you think it's worth to allow for user-defined strategies and let people specify other classes to use their own write model strategies (cf. IdStrategy)? Currently I cannot think different needs but then again you guys came up with yours ;-)

Can't think of a down-side to doing that at the moment. Entirely possible that someone or the other might want to write their own strategy. Can always control it at your end and decide if it is a generic enough case to be made part of the repo.


Refs #28643 -- Added Ltrim, Rtrim, Trim database functions.

https://code.djangoproject.com/ticket/28643

[ ] Documentation.

MySQL, PostgreSQL and Oracle support:

trim([LEADING| TRAILING | BOTH] [characters] from string).

On the other hand SQLite, PostgreSQL and Oracle support:

trim(string, characters),
ltrim(string, characters),
rtrim(string, characters).

I decided to use trim / ltrim / rtrim and patch them on MySQL.

It seems that TRIM on MySQL removes string not all characters from [characters], e.g.: TRIM('xyz' FROM 'zxyzxAAAyzx') returns 'zxyzxAAAyzx' instead of 'AAA', therefore I think we should return to basic implementation without [characters].

buildbot, test on oracle.

buildvot, test on oracle.

buildbot, test on oracle.

buildbot, test on oracle.

buildbot, test on oracle.

I rebased from master.

buildbot, test on oracle.

@timgraham Thanks for the review. I updated PR.

buildbot, test on oracle.

buildbot, test on oracle.

@timgraham Thanks for reviews.


egressgw: change special values for gatewayIP

Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request

[x] All code is covered by unit and/or runtime tests where feasible.

[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.

[ ] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.

[x] All commits are signed off. See the section Developer’s Certificate of Origin

[ ] Provide a title or release-note blurb suitable for the release notes.

[ ] Are you a user of Cilium? Please add yourself to the Users doc

[ ] Thanks for contributing!

Change excluded CIDR "special" value of gatewayIP from <IP_ADDRESS> -> <IP_ADDRESS>

Drop traffic that should be redirected to <IP_ADDRESS> with Host unreachable

Egress Gateway now drop traffic that doesn't match any node

I know this needs further polishing on test and possibly documentation, but I opened this to get initial feedback if this look like the right way to do this and whether or not traffic on egressgw that does not match any node should be dropped by default or not (or maybe this behavior should be guarded under a non default option?). I assumed this was the default behavior and had a bad surprise on my home setup.

Thanks for the PR @MrFreezeex! Couple of comments below.
First I think 2158822 warrants its own PR as that's a separate bug fix.

Sure I will do that.

One way to work around this would be to introduce the change over a couple of releases:
* `1.x.y` release: teach the datapath about `<IP_ADDRESS>` being an excluded CIDR while keeping also the existing `<IP_ADDRESS>` case and make the agent use `<IP_ADDRESS>` as well for excluded CIDRs

* `1.x.y+1` release: switch the `<IP_ADDRESS>` case in the datapath to a drop

but I need to think a bit more here (as that could still cause some drops for example when downgrading from 1.x.y) so perhaps we can start with getting the first commit in?

Migration is a very good point that I indeed didn't have in mind! I am thinking about an alternative solution though, we could just say that <IP_ADDRESS> would be  the blocking special value and keep <IP_ADDRESS> as the current excluded cidr case. It kinda makes less sense in terms of what the value means but at least this will help getting a smoother upgrade. WDYT?

Thanks for the PR @MrFreezeex! Couple of comments below.
First I think 2158822 warrants its own PR as that's a separate bug fix.

Sure I will do that.

Here is the separated PR for the first commit: https://github.com/cilium/cilium/pull/24646

I am thinking about an alternative solution though, we could just say that <IP_ADDRESS> would be the blocking special value and keep <IP_ADDRESS> as the current excluded cidr case. It kinda makes less sense in terms of what the value means but at least this will help getting a smoother upgrade. WDYT?

I thought about that as well, but as you pointed out it makes things less clear, so not 100% sure we want to go this way :thinking:

I am thinking about an alternative solution though, we could just say that <IP_ADDRESS> would be the blocking special value and keep <IP_ADDRESS> as the current excluded cidr case. It kinda makes less sense in terms of what the value means but at least this will help getting a smoother upgrade. WDYT?

I thought about that as well, but as you pointed out it makes things less clear, so not 100% sure we want to go this way thinking

Aren't those values implementation details? We dump them in the CLI commands, but maybe that's our mistake and we should convert them to e.g. block and excluded when showing the map content?

Ok actually I might have another idea. We could add an optional settings disabled by default to block traffic if egressgw doesn't match anything (disabled by default for now). If enabled it will block <IP_ADDRESS> and if disabled ignore both <IP_ADDRESS> and <IP_ADDRESS>. And then in a future release you could decide to either keep this option disabled as is so it won't be a breaking change from the current behavior whatsoever or enable it/drop the option.

Doing the opposite is not a problem for the user it's more a maintainability/readability issue I guess. Like it's easier to conceptualize that 0/no ip (for <IP_ADDRESS>)
would mean block and "1"/broadcast (for <IP_ADDRESS>) would mean excluded/route traffic without egressgw than the opposite.

Honestly, if it's just a matter of code readability, then I think that's a job for clear constant names (e.g., const specialExcludedValue = "<IP_ADDRESS>") and code comments. I agree ideally the other way around would be better, but I'm not sure it's worth the additional complexity of special upgrade/downgrade handling or new settings.

I added a test for the new behavior, no idea if it really works though :sweat_smile:... I believe It's not run by default and I cannot trigger it by myself :see_no_evil:?

Hey @MrFreezeex :wave: sorry for the delay :pray:
After discussion this a bit more we decided to go for the 2 stages approach. We should split this change in 2 part:

first add support for the new encoding of excluded CIDRs to the datapath and to the agent while keeping datapath support for the old one
then in a subsequent PR get rid of the old encoding format for excluded CIDRs (<IP_ADDRESS>) in the datapath and use it to express "no gateway" (and drop this traffic)

From a release perspective:

part 1 should target master and v1.13.2
part 2 should target master and v1.13.3, so at the time of the 1.14 release we'll have already fully migrated to the new format

Moreover I'd like to suggest to switch to the software reserved IP range (<IP_ADDRESS>/8), so:

<IP_ADDRESS> means no gateway
<IP_ADDRESS> is an excluded CIDR

this should make it easier in the future to further overload this gateway IP field in case we need that.
What do you think?

Hi @jibi :wave:, no worries, this approach looks good to me. I just implemented the "part 1" step, let me know what you think. Also added a test case that should hopefully works but no idea if it really does :sweat_smile:.

/test

test-runtime failure is legit:
[2023-04-07T13:30:07.260Z] 	 [13:26:19] FAIL: manager_privileged_test.go:149: EgressGatewayTestSuite.TestEgressGatewayManager
[2023-04-07T13:30:07.260Z] 	 [13:26:19]
[2023-04-07T13:30:07.260Z] 	 [13:26:19] manager_privileged_test.go:246:
[2023-04-07T13:30:07.260Z] 	 [13:26:19]     assertEgressRules(c, []egressRule{
[2023-04-07T13:30:07.260Z] 	 [13:26:19]         {ep1IP, destCIDR, egressIP1, node1IP},
[2023-04-07T13:30:07.260Z] 	 [13:26:19]         {ep1IP, excludedCIDR1, egressIP1, zeroIP4},
[2023-04-07T13:30:07.260Z] 	 [13:26:19]         {ep2IP, destCIDR, zeroIP4, node2IP},
[2023-04-07T13:30:07.260Z] 	 [13:26:19]     })
[2023-04-07T13:30:07.260Z] 	 [13:26:19] manager_privileged_test.go:609:
[2023-04-07T13:30:07.260Z] 	 [13:26:19]     c.Assert(policyVal.GetGatewayIP().Equal(r.gatewayIP), Equals, true)
[2023-04-07T13:30:07.260Z] 	 [13:26:19] ... obtained bool = false
[2023-04-07T13:30:07.260Z] 	 [13:26:19] ... expected bool = true
[2023-04-07T13:30:07.260Z] 	 [13:26:19]
[2023-04-07T13:30:07.260Z] 	 [13:26:19] OOPS: 0 passed, 1 FAILED
[2023-04-07T13:30:07.260Z] 	 [13:26:19] --- FAIL: Test (0.08s)
[2023-04-07T13:30:07.260Z] 	 [13:26:19] FAIL
[2023-04-07T13:30:07.260Z] 	 [13:26:19] 	github.com/cilium/cilium/pkg/egressgateway	coverage: 68.2% of statements
[2023-04-07T13:30:07.260Z] 	 [13:26:19] FAIL	github.com/cilium/cilium/pkg/egressgateway	0.105s
[2023-04-07T13:30:07.260Z] 	 [13:26:19] ?   	github.com/cilium/cilium/pkg/endpoint/regeneration	[no test files]

we forgot to bring the egressgw manager unit tests up to date with the new gatewayIP format

/test

Let's see if those tests works first but meanwhile I added locally a small test case in manager_privileged_test.go for the gateway not found case.

Let's see if those tests works first but meanwhile I added locally a small test case in manager_privileged_test.go for the gateway not found case.

All good with the unit tests :+1:
➜  egressgateway git:(51a6760da3) sudo go test .
ok  	github.com/cilium/cilium/pkg/egressgateway	0.021s

/test

Uh I tried testing it locally and it showed me that it succeeds, but in the CI it did fail :man_shrugging:
	 [15:20:22] ----------------------------------------------------------------------
	 [15:20:22] FAIL: manager_privileged_test.go:155: EgressGatewayTestSuite.TestEgressGatewayManager
	 [15:20:22]
	 [15:20:22] manager_privileged_test.go:366:
	 [15:20:22]     assertEgressRules(c, []egressRule{
	 [15:20:22]         {ep1IP, destCIDR, egressIP1, gatewayNotFoundValue},
	 [15:20:22]         {ep2IP, destCIDR, zeroIP4, node2IP},
	 [15:20:22]     })
	 [15:20:22] manager_privileged_test.go:627:
	 [15:20:22]     c.Assert(policyVal.GetEgressIP().Equal(r.egressIP), Equals, true)
	 [15:20:22] ... obtained bool = false
	 [15:20:22] ... expected bool = true
	 [15:20:22]

I tried a fix let's see...

Uh I tried testing it locally and it showed me that it succeeds, but in the CI it did fail man_shrugging

Sorry, I gave you the wrong command :man_facepalming:
You should pass also PRIVILEGED_TESTS=true: sudo PRIVILEGED_TESTS=true go test .
This should fix the tests:
diff --git a/pkg/egressgateway/manager_privileged_test.go b/pkg/egressgateway/manager_privileged_test.go
index 26f58413b6..bbd5ade3e1 100644
--- a/pkg/egressgateway/manager_privileged_test.go
+++ b/pkg/egressgateway/manager_privileged_test.go
@@ -364,13 +364,11 @@ func (k *EgressGatewayTestSuite) TestEgressGatewayManager(c *C) {
        egressGatewayManager.OnAddEgressPolicy(policy1)

        assertEgressRules(c, []egressRule{
-               {ep1IP, destCIDR, egressIP1, gatewayNotFoundValue},
+               {ep1IP, destCIDR, zeroIP4, gatewayNotFoundValue},
                {ep2IP, destCIDR, zeroIP4, node2IP},
        })

-       assertIPRules(c, []ipRule{
-               {ep1IP, destCIDR, egressCIDR1, testInterface1Idx},
-       })
+       assertIPRules(c, []ipRule{})

        // Update the endpoint labels in order for it to not be a match
        _ = updateEndpointAndIdentity(&ep1, id1, map[string]string{})

/test

Sorry, I gave you the wrong command man_facepalming
You should pass also PRIVILEGED_TESTS=true: sudo PRIVILEGED_TESTS=true go test .
This should fix the tests:
diff --git a/pkg/egressgateway/manager_privileged_test.go b/pkg/egressgateway/manager_privileged_test.go
index 26f58413b6..bbd5ade3e1 100644
--- a/pkg/egressgateway/manager_privileged_test.go
+++ b/pkg/egressgateway/manager_privileged_test.go
@@ -364,13 +364,11 @@ func (k *EgressGatewayTestSuite) TestEgressGatewayManager(c *C) {
        egressGatewayManager.OnAddEgressPolicy(policy1)

        assertEgressRules(c, []egressRule{
-               {ep1IP, destCIDR, egressIP1, gatewayNotFoundValue},
+               {ep1IP, destCIDR, zeroIP4, gatewayNotFoundValue},
                {ep2IP, destCIDR, zeroIP4, node2IP},
        })

-       assertIPRules(c, []ipRule{
-               {ep1IP, destCIDR, egressCIDR1, testInterface1Idx},
-       })
+       assertIPRules(c, []ipRule{})

        // Update the endpoint labels in order for it to not be a match
        _ = updateEndpointAndIdentity(&ep1, id1, map[string]string{})

No worries :D. Thanks for the fix (obviously it was that simple, I should have read this more carefully :man_facepalming:). Let's hope that it succeeds now  :crossed_fingers:.

/test

/test

/test-1.16-4.19

/test

apologies for the notifications, we had to relaunch some test infra

/test

That worked to fix most of the failures, the only one left is for the new end to end test:
[2023-04-11T12:53:02.290Z] FAIL: Failed waiting for egress policy map entries
[2023-04-11T12:53:02.290Z] Expected
[2023-04-11T12:53:02.291Z]     <*errors.errorString | 0xc00060dc00>: {
[2023-04-11T12:53:02.291Z]         s: "could not ensure egress policy entries count is equal to 2: 4m0s timeout expired",
[2023-04-11T12:53:02.291Z]     }
[2023-04-11T12:53:02.291Z] to be nil
[2023-04-11T12:53:02.291Z] ===================== TEST FAILED =====================
[2023-04-11T12:53:02.291Z] 12:52:48 STEP: Running AfterFailed block for EntireTestsuite K8sDatapathEgressGatewayTest egress gw policy when the gateway is not found
[..]
[2023-04-11T12:53:02.291Z] Fetching command output from pods [cilium-c9gtp cilium-m5j7k]
[2023-04-11T12:53:02.291Z] cmd: kubectl exec -n kube-system cilium-c9gtp -c cilium-agent -- cilium bpf egress list
[2023-04-11T12:53:02.291Z] Exitcode: 0
[2023-04-11T12:53:02.291Z] Stdout:
[2023-04-11T12:53:02.291Z]

and the reason for that is that the source pods are not deployed (as we are using a separate context for that test).
Moving Context("egress gw policy when the gateway is not found", .. together with the other tests in  the doContext function should ensure that everything we need for that test is deployed (and also the new test will run with all the configurations we are testing)

That worked to fix most of the failures, the only one left is for the new end to end test:
[2023-04-11T12:53:02.290Z] FAIL: Failed waiting for egress policy map entries
[2023-04-11T12:53:02.290Z] Expected
[2023-04-11T12:53:02.291Z]     <*errors.errorString | 0xc00060dc00>: {
[2023-04-11T12:53:02.291Z]         s: "could not ensure egress policy entries count is equal to 2: 4m0s timeout expired",
[2023-04-11T12:53:02.291Z]     }
[2023-04-11T12:53:02.291Z] to be nil
[2023-04-11T12:53:02.291Z] ===================== TEST FAILED =====================
[2023-04-11T12:53:02.291Z] 12:52:48 STEP: Running AfterFailed block for EntireTestsuite K8sDatapathEgressGatewayTest egress gw policy when the gateway is not found
[..]
[2023-04-11T12:53:02.291Z] Fetching command output from pods [cilium-c9gtp cilium-m5j7k]
[2023-04-11T12:53:02.291Z] cmd: kubectl exec -n kube-system cilium-c9gtp -c cilium-agent -- cilium bpf egress list
[2023-04-11T12:53:02.291Z] Exitcode: 0
[2023-04-11T12:53:02.291Z] Stdout:
[2023-04-11T12:53:02.291Z]

and the reason for that is that the source pods are not deployed (as we are using a separate context for that test).
Moving Context("egress gw policy when the gateway is not found", .. together with the other tests in the doContext function should ensure that everything we need for that test is deployed (and also the new test will run with all the configurations we are testing)

Oh yes indeed sorry for that :man_facepalming:, I was struggling to find the root cause for this, thanks!

/test

/test-1.26-net-next

/ci-datapath

Looks good now, thanks for bearing with me through the few iterations and for all the extra tests!
Thanks for bearing with me too and for all your guidance :D.

With regard to part 2: I don't think we need to wait for anything in particular, we can already start getting that into master, and label it for backport only once this PR is backported and released in v1.13

Sure :+1:, I can prepare something for it as soon as this gets merged! :)

/test

@jibi Unfortunately this does not apply cleanly to v1.13. Marking with backport/author, assuming you will be able to do the backport to the v1.13 branch.

https://github.com/cilium/cilium/pull/24849 is merged, updating the label to done.


Invert the default for the default field prefix on deployment dashboards

For apps that didn't have a field_prefix value set do they now need a field_prefix<EMAIL_ADDRESS>value?

If we wanted to keep the same behaviour, then yes. But I checked in Logit, and assuming the query I used was correct, I couldn't find any data using the prefix of @fields., so I think by changing to not using a prefix, this will fix the missing data on the dashboards for some apps (e.g. collections).


Add getElasticSearchView method

Add an getElasticSearchView(id?: string = 'document') method that returns the specific Elastic view (need to manually check if it is an ElasticView in the types) or the default ElasticView if no ID is specified.

blocked by #80


Fix diskann memory problem

Signed-off-by: zh Wang<EMAIL_ADDRESS>issue: #437
This PR fixed the mixed use of malloc/delete and new/free.
It's better to use std::any instead of boost::any, but it turns out that currently diskann doesn't support c++17. Maybe we should upgrade the standard to c++17.

Signed-off-by: zh Wang<EMAIL_ADDRESS>issue: #437
This PR fixed the mixed use of malloc/delete and new/free.
It's better to use std::any instead of boost::any, but it turns out that currently diskann doesn't support c++17. Maybe we should upgrade the standard to c++17.

What do you mean by doesn't support c++17. Knowhere is using C++17 right now.

What do you mean by doesn't support c++17. Knowhere is using C++17 right now.

Knowhere is using C++17 but inside thirdparty/DiskANN it only supports C++14 now https://github.com/milvus-io/knowhere/blob/main/thirdparty/DiskANN/CMakeLists.txt#L26 and it can't compile when I use C++17 feature inside thirdparty/DiskANN

/lgtm
/approve


Create a CONTRIBUTING.md

Can I work on this? @caniszczyk

I also tend to look after a contribution.md in open source repositories, so I already thought about this as well. But there is a contribution guide, so I am not entirely sure if it makes sense to have a contribution.md as well. What do you think @CathPag @seokho-son @JasonMorgan?!

Also @Asmit2952, @caniszczyk thanks for your willingness to help. Make sure to join the #glossary channel of the cncf slack

@iamNoah1 @Asmit2952 Thank you for your support ! :)
@caniszczyk is a maintainer of this repository. It would be better for the contributors to discuss what caniszczyk thinks before they start contributing :)
@caniszczyk
As @iamNoah1 mentioned, there is a there is a contribution guide https://glossary.cncf.io/contribute/ (https://github.com/cncf/glossary/blob/main/content/en/contribute/_index.md).
Is a CONTRIBUTING.md that includes a link to the contribution guide webpage https://glossary.cncf.io/contribute/ enough?
or do we need additional contents regarding contribution ?

Ideally, it'd live on the GitHub code page AND on the glossary website. @cjyabraham, see the conversation above. Can we move things around so the same content is found in both places?

My sense is that a CONTRIBUTING.md file is a standard GitHub file for any repo that should outline rules and guidelines for contributing to the glossary repo as a whole, which includes the core code for running a glossary site. This file will show up in a sidebar link when people create PRs and issues.
The contributing guide that we publish here is directed at those who want to contribute to the contents of the glossary, not its underlying code.
So I feel they both address a different use-case and should be kept distinct. Any thoughts?

@JasonMorgan, @seokho-son, @jihoon-seo, @iamNoah1, let's think about what makes sense. We could discuss during our meeting on Monday.

Hey folks! I'm a bit confused about who's going to be writing this guide. @cjyabraham do you plan on handling this?

I don't know. I wasn't part of the meeting that @CathPag suggested above so don't know what the follow-up items were. I'm happy to help if that was the decision.

We didn't cover it in the meeting but your suggestion above has a thumbs up from the rest of the maintainers. Your suggestion here seems to be appropriate. Please add the CONTRIBUTING.md and include some basic content on working with the repo that includes a link to the contributing guide.

So can I work on this?

I've submitted a PR

Thank you, @cjyabraham !!


Show USD values for Stacks FTs

@alter-eggo @fbwoolf Might one of you want to take this using the ALEX SDK for Stacks FTs and another for BRC-20 ones (e.g. perhaps Best in Slot, UniSat or CoinMarketCap's API)? It seems like a possible quick win ahead of redesigning the tokens UX in general.
Note that in addition to showing the USD values per token, we'd want to incorporate their values in the account total as well.

Yep, sure, I can take it after my UI issues.

@markmhendrickson is it ok just to handle what is returned by the alex-sdk for fiat prices?
{
    "age000-governance-token": 0.44284066666666666,
    "token-wusda": 0,
    "token-wstx": 3.48,
    "token-wban": 0.28039518,
    "token-wbtc": 69583.66666666667,
    "token-wdiko": 0.57905493,
    "token-wslm": 0.02933197,
    "token-wxusd": 0.9995446666666666,
    "token-wmia": 0,
    "token-wnycc": 0,
    "token-wcorgi": 0.00782047,
    "auto-alex-v2": 0.45748425875749976,
    "token-susdt": 1,
    "token-wvibes": 0.003541152750025805,
    "token-abtc": 68266.77159157977,
    "token-slunr": 0.23096300000000003,
    "brc20-chax": 0.00235852843073116,
    "token-wleo": 0.001848988570889095,
    "token-wmega-v2": 0.9843567751715196,
    "token-wgus": 0.00015734427742962597,
    "brc20-ordg": 0.3628395646699813,
    "brc20-ormm": 0.00028785
}

Yep that works

@fabric-8 there are so many tokens being airdropped into wallets that don't have a fiat conversion available, should I just not show anything for now if $0.00?

I think displaying 0$ is ok, people might otherwise wonder wether any given token might actually be worth something and start looking around.
The more fundamental issue which we'll address is to not display spammy tokens in first place or give the user the option to hide those. I think we're planning to do that, @kyranjamie @markmhendrickson discussed this earlier this week

Let's just show blank? It's best not to give the impression that we know the value (or lack thereof) if we simply don't have the data

Ah, is there a difference between an unknown value and 0? I was assuming that we or the service we're using "knows" that the fiat value is 0

ok thanks for clarifying - Agree with Mark then 👍


UserWarning: torch.utils._pytree._register_pytree_node is deprecated.

When running in the console UserWarning: torch.utils._pytree._register_pytree_node is deprecated. Please use torch.utils._pytree.register_pytree_node instead.
_torch_pytree._register_pytree_node(
How can this be fixed?
Thank you!

Hi @Roboxkin , kindly share me pytorch, torchvision, python versions along with OS details.

Closing this issue due to no response. Feel free to reopen the issue if it's still persists.


sed inline style

@sbeaver-netgate
https://forum.pfsense.org/index.php?topic=101865.0
seems ok, did a quick test.

Another nice improvement. Thank you!


no matching manifest for windows/amd64 10.0.18362 in the manifest list entries

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

This error will be shown if you try to either pull/run an image that's only available for Linux on a docker engine that's configured to run Windows native containers, or if the image you're pulling is not available for the kernel version of Windows that you're running (windows native containers must use a base image that's matching the kernel version you're having)
Closing this issue because this is not a bug

windows10에서 cmd창에서 'docker pull ubuntu:latest'를 실행했을때 'no matching manifest for windows/amd64 10.0.18362 in the manifest list entries'와 같은 오류가 발생하면,
1.docker setting 실행
2.Docker Engine에서 "experimental": false라고 되어 있는지 확인하고 false를 true로 변경
3.Apply&Restart
이렇게 하고서 다시 'docker pull ubuntu:latest'를 실행하면 정상적으로 실행된다.

Good ;)

Worked for me too, in my case was pulling node:10 image, thanks @Joys-WhiteKnight

Note that the "experimental" option would enable  LCOW, which will go away in future; if you're only running Linux containers, it may be better to switch Docker to use Linux containers instead; see Switch between Windows and Linux containers

Thanks Joys

Will anyone explain please , I don't understand these letters below.
1.docker setting 실행
2.Docker Engine에서 "experimental": false라고 되어 있는지 확인하고 false를 true로 변경
3.Apply&Restart
이렇게 하고서 다시 'docker pull ubuntu:latest'를 실행하면 정상적으로 실행된다.

Google translate shows this;

docker setting execution
Check if "experimental": false in Docker Engine and change false to true
Apply&Restart

If you run'docker pull ubuntu:latest' again after doing this, it runs normally.

I think that comment may be referring experimental support for "LCOW" (Linux Containers on Windows), which is deprecated, and will be removed soon
But the main issue is https://github.com/docker/kitematic/issues/5511#issuecomment-569276592. If you want Docker Desktop for Windows to run Linux containers, make sure it's switch to running Linux containers (not Windows containers); see "switch between Windows and Linux containers" in the docs; https://docs.docker.com/docker-for-windows/#switch-between-windows-and-linux-containers


fundamentaldata.py ignoring output_format?

Looking at the code of fundamentaldata.py, it seems like other than raising an error in case output_format is set to csv, the constructor is ignoring the output format preferences altogether, and returning the results in tuple format only instead.
Example FundamentalData (not working)
from alpha_vantage.fundamentaldata import FundamentalData
fd = FundamentalData(key='YOUR_API_KEY', output_format='pandas')
data = fd.get_company_overview(symbol='IBM')
print(type(data))

This returns <class 'tuple'> instead of a DataFrame.
Example TimeSeries (working)
In contrast, the TimeSeries object is working fine, and returns the correct data format:
from alpha_vantage.timeseries import TimeSeries
ts = TimeSeries(key='YOUR_API_KEY', output_format='pandas', indexing_type='date')
data, meta_data = ts.get_daily(symbol='IBM', outputsize='full')
print(type(data))

This correctly returns <class 'pandas.core.frame.DataFrame'>.
Is there a way to make FundamentalData respect the output_format preference like TimeSeries does?

This is because all API's actually return tuples with two elements. In some methods (like your first example) the second element will always be None and can safely be ignored. But on the second example you're destructuring the tuple, so Python makes it look like there's no tuple at all!
For the first example you want to do this instead:
>>> data, _ = fd.get_company_overview(symbol='IBM')
>>> print(type(data))
<class 'pandas.core.frame.DataFrame'>

Likewise:
>>> data = fd.get_company_overview(symbol='IBM')
>>> print(type(data[0]))
<class 'pandas.core.frame.DataFrame'>

@ddavness:

In some methods (like your first example) the second element will always be None and can safely be ignored.

This helps for this specific example, thank you! I will use the unnamed throwaway variable name from your first example.

But on the second example you're destructuring the tuple, so Python makes it look like there's no tuple at all!

I think in general this is exactly the point: the developer here is not destructuring anything really, we are just getting a response from the API which has already destructured the tuple. I think the API should be consistent in the response format: you either make the destructuring transparent everywhere, or you just return a tuple everywhere.

Calling get_income_statement_annual() from that module with output_format = 'json' returns a Pandas dataframe.
Running
from alpha_vantage.fundamentaldata import FundamentalData
fd = FundamentalData(key='YOUR_API_KEY', output_format='json')
income_statement, symbol = client.get_income_statement_annual(symbol='IBM')
print(type(income_statement))

prints
<class 'pandas.core.frame.DataFrame'>

On the plus side, I now know that I have accidentally installed Pandas as a dependency of something else.

If I forcibly remove the Pandas package and try again, I get:
  File "/Users/bfoz/.local/share/virtualenvs/project04-bNStgEKY/lib/python3.10/site-packages/alpha_vantage/alphavantage.py", line 250, in _format_wrapper
    data_pandas = pandas.DataFrame(data_array, columns=[
NameError: name 'pandas' is not defined

With the caveat that I'm not familiar with the code, the problem appears to be around line 238 of alphavantage.py
                if output_format == 'json':
                    if isinstance(data, list):
                        # If the call returns a list, then we will append them
                        # in the resulting data frame. If in the future
                        # alphavantage decides to do more with returning arrays
                        # this might become buggy. For now will do the trick.
                        if not data:
                            data_pandas = pandas.DataFrame()
                        else:
                            data_array = []
                            for val in data:
                                data_array.append([v for _, v in val.items()])
                            data_pandas = pandas.DataFrame(data_array, columns=[
                                k for k, _ in data[0].items()])
                        return data_pandas, meta_data
                    else:
                        return data, meta_data

That looks to me like it returns a DataFrame even when output_format is set to json.

I have opened a PR that addresses this at the end of last year - see #329.
It was probably a result of copy-pasting the same thing twice.

I eventually found your PR, but not until after I figured it out myself. I guess I should have looked first.
So, is this project dead then? It hasn't seen any updates in 13 months and your PR is almost 8 months old.

Closing for now. Will reopen if there is further community response. Thanks!


Add configuration for http.Agent

Follow-up on #24
Make parameters for http agent configurable by the end user

Any updates on this?

We could use this feature as well as customers of ours use a HTTPS proxy and we'd like to override the http.Agent to allow us to configure that. Specifically these lines:
https://github.com/databricks/databricks-sql-nodejs/blob/main/lib/connection/connections/HttpConnection.ts#L30-L32


Use correct system property name in PooledByteBufAllocator (io.netty.…

…allocator.cacheTrimIntervalMillis)
Motivation:
We had a typo in the system property name that was used to lookup the cache trime interval. We should ensure we use the correct naming when lookup the property
Modifications:

Support the old and the new (correct) naming of the property when configure the cache trim interval.
Log something if someone uses the old (deprecated) name

Result:
Fixes https://github.com/netty/netty/issues/9981

/cc @LinShunKang


fixed uploadFile type hinting

The correct type of files on post paths is UploadFile. I changed it in the PR.
However, my main issue is that correct file upload requires to set encoding enctype="multipart/form-data" and this is not mentioned anywhere. If you don't set it, the request file will passed as a string and contains [Object file]. Having the documentation show that string is indeed the correct type (when it's not) just makes it a bit more confusing.
I would lvoe to add this information somewhere so other people can see but I'm unsure where it'd be appropriate. This is a minimal example of what needs to be done for correct file uploads. The relevant bit is:
enctype="multipart/form-data" #   <---- without this the file is passed as a string and contains '[Object file]'
from fasthtml.common import *
import os
import uuid

app = FastHTML(hdrs=(picolink))
rt = app.route

@rt("/")
async def get(request):
    add = Form(
        Input(id="new-file", name="file", type="file", required=True),
        Button("Add"),
        hx_post="/",
        hx_swap="beforeend",
        enctype="multipart/form-data" #   <---- without this the file is passed as a string and contains '[Object file]'
    )
    return add

@rt("/")
async def post(request):
    form = await request.form()
    file = form.get('file')
    content = await file.read()
    filename = f"file_{uuid.uuid4()}{os.path.splitext(file.filename)[1]}"
    with open(filename, 'wb') as f:
        f.write(content)

    return "Upload OK"

serve()

Thanks for this fix! Maybe we should make enctype="multipart/form-data" the default actually.


Microphone Face

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes:  #646

Type of change

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

Checklist:

[x] I have made this from my own
[ ] I have taken help from some online resourses and mentioned in PR
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

Just curious, why don't you ever tick this box? 😀
I have taken help from some online resources and mentioned in PR
This means you have made it 100% on your own. I hope you are aware of this

i Request Don't waste all of my work by making everything plagiarized please.
You are targeting me from the start of My Pr. I did tell you how late i stared my gssoc journey. And i understand the frustration you have because of the work i had sleepless night perfecting all the project that your mentor said.
if you still have the problem then okay i will not do any pr but don't waste my work just by doing that
you can check my profile how late i started my gssoc journey. This repo was my hope


Are SNe’s now available to CatSim?

Hey @rbiswas4 - I think you are very close to being able to close this issue, and also #26. Please do so as soon as you can, with the cheers of your grateful colleagues ringing in your ears! :-) :-)

@drphilmarshall
SNe Type Ia are now available in catsim releases.
However, note that those are not the supernovae that we are planning on using in the sprinkler for Twinkles, though much of that architecture will be used. Let me clarify the situation:

Current releases:
SNIaCatalog: This has a basic implementation (there needs to be more input on distributions) SNIa catalog in much the same way I have planned before. This means you have SN whose properties (model parameters) are generated in situ drawing from distribution functions with a random seed specified by the host galaxy.
FrozenSNCat: This is an implementation where the random generation is done by a separate program which outputs the the SN model parameters associated with the hosts of catsim. The database of SN model parameters is then stored on fatboy much the same way the galaxy parameters are stored. So the model parameters are frozen in the database. This is implementation that exists in a branch, but is not yet merged with catsim master.

I believe that there are relative strengths and weaknesses of both implementations and it is possible that we will use both of them for different purposes. For the current Twinkles run, we will use FrozenSNCat.
So, perhaps the question of whether this should be closed yet in a Twinkles issue is unclear.

Excellent! Since the answer to the question in the issue title is now in
the issue thread, I say: close it out. Can you please update the Run 1 plan
file with the Run 1 supernova plan, please? Thanks! :-)
On Thu, Feb 11, 2016 at 8:36 PM, rbiswas4<EMAIL_ADDRESS>wrote:

@drphilmarshall https://github.com/drphilmarshall
SNe Type Ia are now available in catsim releases.
However, note that those are not the supernovae that we are planning on
using in the sprinkler for Twinkles, though much of that architecture will
be used. Let me clarify the situation:

Current releases: SNIaCatalog: This has a basic implementation
(there needs to be more input on distributions) SNIa catalog in much the
same way I have planned before. This means you have SN whose properties
(model parameters) are generated in situ drawing from distribution
functions with a random seed specified by the host galaxy.
FrozenSNCat: This is an implementation where the random generation
is done by a separate program which outputs the the SN model parameters
associated with the hosts of catsim. The database of SN model parameters is
then stored on fatboy much the same way the galaxy parameters are stored.
So the model parameters are frozen in the database. This is implementation
that exists in a branch, but is not yet merged with catsim master.

I believe that there are relative strengths and weaknesses of both
implementations and it is possible that we will use both of them for
different purposes. For the current Twinkles run, we will use FrozenSNCat.
So, perhaps the question of whether this should be closed yet in a
Twinkles issue is unclear.
—
Reply to this email directly or view it on GitHub
https://github.com/DarkEnergyScienceCollaboration/Twinkles/issues/13#issuecomment-183177403
.

ok. thanks. I am closing this then. But I have filled out the Run1 plan

Excellent, thanks Rahul! And thanks for cleaning up the SL part too,
@jbkalmbach . The plan is looking much better! :-)
https://github.com/DarkEnergyScienceCollaboration/Twinkles/blob/master/doc/Run1.md


Implementation IDs should not be in the specification

...as adding new IDs causes churn in the specification revision number. See, for example, https://github.com/riscv/riscv-isa-manual/blob/main/marchid.md.

In addition should the Implementation ID follow the layout of marchid, where the most-significant bit specifies whether the architecture is open-source or not?


Change default log level

Description
Default log level

console: WARN -> INFO
file : INFO -> DEBUG

Type of change
Please insert 'x' one of the type of change.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[x] Refactoring, Maintenance
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

I accept it.


Turn off history

Is there an option where I could turn off history as I don't need to see that on the server? And does having a history folder take up additional disk space?

Also I am getting the following error when mounting with the following flags...

For now, there's no option to turn off the history view. It doesn't take any additional disk space.

That makes sense! Thank you @vtemian
Can you please look into #330 as well? That's stopping me from using this! I am running this as "nobody" user since that's how my webserver serves files under.


Probleme integrate md-subheader in md-list

Bug, feature request, or proposal:
  <md-subheader class="md-no-sticky">3 line item</md-subheader>

Not available for md-list?
What is the expected behavior?
  <md-subheader class="md-no-sticky">3 line item</md-subheader>

What is the current behavior?
No integration for md-subheader
What are the steps to reproduce?
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, browsers are affected?
Is there anything else we should know?

Please reproduce the issue in Plunker so we can investigate further.

@Symfomany It's not really clear what you're reporting / asking for. Feel free to open a new issue with more specifics.


Another installer

https://zero-to-nix.com/start/install

Closed by https://github.com/kachick/dockerfile-ubuntu-nix/commit/8ecb81b4805fc1da3e6cdea7c71ba75560f4cea9


Transaction inputs from accounts

This PR introduces the ability to spend not only from utxos but also from accounts. This is achieved by making TxInput an enum of Utxo | Account.
TODOs:

[x] verify input/output policy with inputs from accounts;
[x] check transferred amounts;
[x] handle transaction fee
[x] revisit timelock checks;
[x] handle nonce in chainstate: verify, provide access from db;
[x] sign tx inputs from accounts; verify signature;
[x] transaction index
[x] track double-spends in mempool via txinput nonce;
[x] revisit tests, add new;

P.S. last commit contains renames in tons of files, I can potentially make it as a separate PR to simplify reviewing process

Looking at the code again I'm starting to doubt whether making TxInput an enum instead of OutPoint itself was a good idea.
It could be like this:
enum Outpoint {
    Utxo(UtxoOutPoint),
    Account(AccountOutPoint),
}

I see that OutPoint is heavily used in mempool and wallet,  so when accounts are integrated there we will have to either use TxInput everywhere or invent an enum for outpoints. Not sure that TxInput is good for use cases outside of Transaction context. Thoughts?

I see that OutPoint is heavily used in mempool and wallet, so when accounts are integrated there we will have to either use TxInput everywhere or invent an enum for outpoints. Not sure that TxInput is good for use cases outside of Transaction context. Thoughts?

I think it's fine and there's no need to change it.


Seemingly random placeholder

"2020-12-31 23:00:00" is a very random and confusing placeholder if none is set. Instead it should say either nothing or "Choose..." or something like that

If it says "Choose...", you wouldn't know what format to type out. It's a text field, not a button, so I think an example is good

Seriously? Your so-called example just confuses folks. People hit me up because they thought the input field's already stuffed with some random date.
It's not even hinting that they still need to pick a date and time. And your argument is that it is a text box?

No need to be rude.  My existence would surely crumble without the sheer joy of using this picker library.


FIX: Aligning frequency bins to y-axis

Reference issue
Fixes #6929
What does this implement/fix?
Adjusting extent using imshow for linear y-scale. Now, frequency bins appear centered to the y-ticks.

now I see the fix ! merge when you're happy. thx

I think there is nothing more to add. Thanks for the correction @larsoner

CIs are not happy @stfnrpplngr.  OK if I wait to review again until you resolve those issues?

Ok, I will check what is going wrong.

@drammock fixed, feel free to review and merge if you're happy, then backport to 0.19

just waiting for Travis at this point.

Travis failure is unrelated (physionet download timeout).

backported

@drammock
I think the merge (#6942) was a bit fast. Yesterday, I was still examining the effect of the changes. The output of test_evoked.py is wrong now.

The ticks are not aligned anymore which is an easy fix. But I am not sure why the data in the upper plot is shifted...
Shall I open a new Issue for that?


Dark mode for Manager

Is your feature request related to a problem? Please describe.
My eyes are burning out when working with tests during nighttime
Describe the solution you'd like

convenient-test-manager to have a dark mode switch. I
It isn't that hard to implement, basically just pass ThemeMode: ThemeMode.system to the MaterialApp() instance and flutter will do the rest.
Currently the background of scaffolds is force-set to white, we should remove that.

Why is that there in the first place? https://github.com/fzyzcjy/flutter_convenient_test/blob/12e774f1ba40410ccec74275b908956780aa74ca/packages/convenient_test_manager/lib/main.dart#LL18C6-L19C10

Additional context
🌃 💻💡    👀👤    ➡➡     😵

Looks reasonable, feel free to PR!


--process-dependency-links

pip remove --process-dependency-links

Please do not remove or incompletely fill in the issue template when opening a new issue.


Move infrastructure code into separate repository

Summary of changes
Changes introduced in this pull request:
Reference issue to close (if applicable)

Closes #1909
Other information and links

Let's discuss in slack before you work more on this.

Resolve the merge conflicts and also submit a new PR to forest-iac with the updated dairly_snapshot.rb code.

@tyshko5 not all files have been ported yet to the forest-iac repo, this should be first addressed before removing the ones here, or am I missing something?

@tyshko5 not all files have been ported yet to the forest-iac repo, this should be first addressed before removing the ones here, or am I missing something?

Made a PR for that https://github.com/ChainSafe/forest-iac/pull/3


cmd/compile: incorrect DWARF location for runtime.throw's in-param

What version of Go are you using (go version)?

$ go version
go version devel go1.17-15a374d5c1 Wed May 19 01:09:20 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?
Yes. This is only on tip.
What operating system and processor architecture are you using (go env)?
linux/amd64
What did you do?
Compile a small program like
https://play.golang.org/p/1wRyGFu3wca
then run it in the debugger. Set a breakpoint in runtime.throw, then run. print "s"
What did you expect to see?
(gdb) p s
$1 = 0x47bfb6 "all goroutines are asleep - deadlock!"
What did you see instead?
(gdb) p s
$2 = 0x0 <error: Cannot access memory at address 0x0>
This is a bug in the Go compiler's debug location analysis phase, being triggered by the register ABI. Things seem to work when the register ABI is disabled, but I think mainly because the incoming locations for "s" are never killed, e.g. the stack location is essentially always available.  When "s" is passed in RAX/RAB, it correctly tracks this fact, but then doesn't record the correct entry location when those registers are overwritten. I am not entirely sure what is going wrong, more analysis needed.

@cherrymui @suzmue reported this problem in go1.16 too (I am not sure if it's the same problem)

@cherrymui @suzmue reported this problem in go1.16 too (I am not sure if it's the same problem)

I looked at the DWARF produced by the 1.16 compiler. It is indeed broken, but it looks like in a different way (two different bugs).

With Go 1.17rc1, I am seeing that the location is correct within the systemstack call, but it is optimized out in the body of runtime.throw. Delve sets a breakpoint at runtime.fatalthrow for users to inspect the program state, so this is the point that it would be helpful to have access to the value of s.
suzmue@cloudshell:~/delve$ gdb fatalerror
...
(gdb) b runtime.throw
Breakpoint 1 at 0x433820: file /usr/local/go/src/runtime/panic.go, line 1107.
(gdb) b runtime.fatalthrow
Breakpoint 2 at 0x433a20: file /usr/local/go/src/runtime/panic.go, line 1163.
(gdb) b /usr/local/go/src/runtime/panic.go:1111
Breakpoint 3 at 0x460eaf: file /usr/local/go/src/runtime/panic.go, line 1111.
(gdb) run
Starting program: /home/suzmue/delve/fatalerror
...
Thread 1 "fatalerror" hit Breakpoint 1, runtime.throw (s=...) at /usr/local/go/src/runtime/panic.go:1107
1107    func throw(s string) {
(gdb) p s
$1 = <optimized out>
(gdb) c
Continuing.

Thread 1 "fatalerror" hit Breakpoint 3, runtime.throw.func1 () at /usr/local/go/src/runtime/panic.go:1111
1111                    print("fatal error: ", s, "\n")
(gdb) p s
$2 = 0x480a79 "go of nil func value"
(gdb) c
Continuing.
fatal error: go of nil func value

Thread 1 "fatalerror" hit Breakpoint 2, runtime.fatalthrow () at /usr/local/go/src/runtime/panic.go:1163
1163    func fatalthrow() {
(gdb) frame 1
#1  0x0000000000433892 in runtime.throw (s=...) at /usr/local/go/src/runtime/panic.go:1117
1117            fatalthrow()
(gdb) p s
$3 = <optimized out>

If this would be more appropriate as a new issue to open, since it seems that the incorrect location seems to be fixed I can do so.

Interesting. At the point of fatalthow call s is no longer live. Maybe we could keep it live in throw.
Why does it set a breakpoint in fatalthrow instead of throw?

I think its historical from when fatalpanic and fatalthrow split, but I'm not sure @derekparker @aarzilli would know better.
In both Go 1.16 and Go 1.17 the location info appears to only be available in the print function in runtime.throw:
systemstack(func() {
	print("fatal error: ", s, "\n")
})

It seems that s should also be live at the start of runtime.throw since it is not used print("fatal error: ", s, "\n"). Would it be possible to get the location information available then at least?

It seems that s should also be live at the start of runtime.throw

With @thanm 's fix I believe it should work for 1.17. I just tried at tip and it does seem to work
(gdb) b runtime.throw
Breakpoint 1 at 0x42b7e0: file /usr/local/google/home/cherryyz/src/go/src/runtime/panic.go, line 1188.
(gdb) run
Starting program: /tmp/d
[New LWP 267089]
[New LWP 267090]
[New LWP 267091]
[New LWP 267092]
[Switching to LWP 267092]

Thread 5 "d" hit Breakpoint 1, runtime.throw (s="all goroutines are asleep - deadlock!") at /usr/local/google/home/cherryyz/src/go/src/runtime/panic.go:1188
1188	func throw(s string) {
(gdb) p s
$1 = "all goroutines are asleep - deadlock!"

I know it doesn't work with Go 1.16 due to some bug. @thanm would it be possible to fix 1.16 with something simple?

Thanks it does seem to be working at runtime.throw. Sorry about that those logs must have been using a binary built with 1.16.
@derekparker @aarzilli What do you think about moving the fatal throw breakpoint to runtime.throw instead of runtime.fatalthrow? This seems like it would be a more reliable place to get the information about the throw message.

Echoing what Cherry said, the crux of the problem is that "s" is no longer live at the call to fatalthrow; in general it isn't possible to generate a good location unless the lifetime is extended somehow.
The location at the start of runtime.throw should be accurate now in 1.16. There are still many other issues with debug locations, but that one at least is working.

accurate now in 1.16
Sorry, I meant 1.17 (I edited the comment)

@derekparker @aarzilli What do you think about moving the fatal throw breakpoint to runtime.throw instead of runtime.fatalthrow? This seems like it would be a more reliable place to get the information about the throw message.

I think that should be ok, but I haven't dug into the ramifications of the change. I'll take a closer look tomorrow, but it does seem like a more reliable spot.

@suzmue ok if I close this issue out?

Cool, thanks.


AxisToAxisDamped plugin

#37 #38 #39
Sorry for the mess. I'm quite new to this. 🙂

Very interesting, @swift502! ;)

Should be useful in any driving game that allows for direct input. I made my own steering smoothing in Dirt Rally and it's night and day difference.

Indeed. I play space sim games, and I think that it could be great for such situation.

We are trying to minimize the number of plugins in core, else making changes can get cumbersome.
We have a repo https://github.com/HidWizards/UCR-Plugins for plugin contributions, could you please submit it there?

@swift502

We are trying to minimize the number of plugins in core, else making changes can get cumbersome.
We have a repo https://github.com/HidWizards/UCR-Plugins for plugin contributions, could you please submit it there?

I'll try to find some time but can't promise anything... :frowning_face:
Been quite busy lately.

@swift502, we could copy your PR and push it, of course, but we can't do it "under your name". It's a very clever solution, and actually quite useful, so it would be a pity to not be credited for such interesting contribution. I hope you find a little time to push it to it's proper repository, as I use it a lot (in a custom local build). Then, we can polish it out... ;)

I'll try to do it on Friday. But if can't, I give you guys my full permission to do it for me. "Not being credited for it" is not really something I'm concerned about... :slightly_smiling_face:

The other reason for doing it as you is so that if we wonder "who wrote this?" we can easily tell...
Only the person who wrote it knows what they intended - someone coming along later to maintain the code may not know what the original intent was, so by having your name against the code, we can ping you to ask ;)

Yeah sorry. I don't even use UCR anymore. I can't be bothered to setup the repos, test the functionality again, cleanup, commit and request a pull because of one file I wrote for a thing I don't even use anymore.
It's here as an interesting resource and anyone can use it if they think it might be useful to them.
The logic is literally 8 lines of code. I'm sure anyone will be able to figure out what it does.
And if not, that's fine.
Again sorry. 🙁

I realise it's ironic how instead of writing these comments I could've already done it, but I just can't bring myself to do it.
Guess I'm just really lazy and the joke's on me...


Add get and delete method for app in api server

What this PR does / why we need it:
Which issue(s) this PR fixes:
Add get and delete method for app in api server
part of issue #2107

Fixes #
Special notes for your reviewer:

For  current fake client, I  can not think of a way to mock the situation in delete app : returning 5xx internal err.
Is there someone can give a suggestion.


Add S3 Storage Lens support

References
Add any related links that will help us understand the resource, including vendor documentation, related GitHub issues, and Go SDK documentation.
S3 Storage Lens
<EMAIL_ADDRESS><EMAIL_ADDRESS>

Re-adding the stale label, as the intent of marking issues as stale is to help keep the issue list light + focused. If this feature request comes up again or is required for a new benchmark, control, etc., then we can remove the stale label.


document edge cluster setup

Goal
this task is to document edge cluster setup procedures, including:

[x] 1-layer edge cluster
[x] multiple-layer edge cluster
[ ] mission deployment through multiple-layer

mission in the right state
deployment in the right state
pod in the right state

[x] mission status check
[x] edge cluster status check
[ ] verify k3s cluster on the edge (no sub-cluster from k3s cluster)
[ ] edge AI application (stretch goal)

Deliverable
A set of markdown docs/wiki
Time estimate
~ 2 weeks by 17th

https://github.com/davidzhu22/fornax/blob/setupguide/docs/setup-guide/cluster_setup.md

https://github.com/davidzhu22/fornax/blob/setupguide/docs/setup-guide/vm_setup.md

https://github.com/davidzhu22/fornax/blob/setupguide/docs/setup-guide/edge_cluster_copy.md

Hi David, once the setup document is ready for review, please file a PR against the fornax repo to check it in.
Document can be continuously worked on so it doesn't have to be perfect. Let's get this checked with the best condition we can get by this week.

moving this task to the "review" phase for final review and fixup.


Add testcase for "Attribute correctness" check of protocol attribute

protocol is an attribute added to multiple services. This attribute is an enumeration of two values like "HTTP" and "HTTPS". To check if server is accepting only these two values, testcase to be added to applicable services under "Acceptance" :: "Attribute correctness" section.
Services required for changes are

[x] /v1/bequeath-your-data-and-die
[x] /v1/regard-application

Fixed as part of pull #219


[Forwardport 2.9][BUG] [CAPR] rancher-system-agent can be restarted during an etcd restoration operation which will lead to inconsistent results

Forwardport of https://github.com/rancher/rancher/issues/43658 - this was already merged prior to branching for 2.9 so it should already be available for testing in 2.9.

QA TEST PLAN

#
Scenario
Test Case

1
Restore snapshot
Provision downstream RKE2 cluster, take etcd snapshot, upgrade K8s cluster, restore snapshot

2
Restore snapshot with rotated worker nodes
Provision downstream RKE2 cluster, take etcd snapshot, rotate worker nodes, restore snapshot

3
Restore same snapshot with rotated worker nodes 3 times
Provision downstream K3s cluster, take etcd snapshot, rotate worker nodes, upgrade K8s cluster, restore same snapshot 3 times

4
Restore snapshot after rebooting nodes
Provision downstream K3s cluster, take etcd snapshot, reboot worker nodes, restore snapshot

5
Restore snapshot after rebooting rotated worker nodes
Provision downstream K3s cluster, take etcd snapshot, rotate worker nodes, reboot worker nodes, restore snapshot

Tested this against v2.9-head https://github.com/rancher/rancher/commit/ed8725676a615b0fb6851957f4295dad6593fb89. See details below:
ENVIRONMENT DETAILS

Rancher install: Docker
Rancher version: v2.9-head https://github.com/rancher/rancher/commit/ed8725676a615b0fb6851957f4295dad6593fb89

TEST RESULT

#
Scenario
Test Case
Result

1
Restore snapshot
Provision downstream RKE2 cluster, take etcd snapshot, upgrade K8s cluster, restore snapshot
:white_check_mark:

2
Restore snapshot with rotated worker nodes
Provision downstream RKE2 cluster, take etcd snapshot, rotate worker nodes, restore snapshot
:white_check_mark:

3
Restore same snapshot with rotated worker nodes 3 times
Provision downstream K3s cluster, take etcd snapshot, rotate worker nodes, upgrade K8s cluster, restore same snapshot 3 times
:white_check_mark:

4
Restore snapshot after rebooting nodes
Provision downstream K3s cluster, take etcd snapshot, reboot worker nodes, restore snapshot
:white_check_mark:

5
Restore snapshot after rebooting rotated worker nodes
Provision downstream K3s cluster, take etcd snapshot, rotate worker nodes, reboot worker nodes, restore snapshot
:white_check_mark:

VALIDATION STEPS
Scenario 1

Provisioned a downstream RKE2 v1.26.11+rke2r1 cluster (3 etcd, 2 cp, 3 worker) as a standard user.
Took an etcd snapshot.
Upgraded the K8s version of the downstream cluster.
Deployed 3 daemonsets with image nginx:latest.
Successfully restored snapshot with options cluster config, Kubernetes version and etcd.

Scenario 2

Provisioned a downstream RKE2 v1.26.11+rke2r1 cluster (3 etcd, 2 cp, 3 worker) as a standard user.
Took an etcd snapshot.
Rotated all of the worker nodes.
Deployed 3 daemonsets with image nginx:latest.
Successfully restored snapshot with options cluster config, Kubernetes version and etcd.

Scenario 3

Provisioned a downstream K3s v1.26.11+k3s2 cluster (3 etcd, 2 cp, 3 worker) as a standard user.
Took an etcd snapshot.
Rotated all of the worker nodes.
Upgraded the K8s version of the downstream cluster.
Deployed 3 daemonsets with image nginx:latest.
Successfully restored snapshot with options cluster config, Kubernetes version and etcd.

Repeated this step 3 times.

Scenario 4

Provisioned a downstream K3s v1.26.11+k3s2 cluster (3 etcd, 2 cp, 3 worker) as a standard user.
Took an etcd snapshot.
Rebooted all of the worker nodes in the backend infrastructure side.
Deployed 3 daemonsets with image nginx:latest.
Successfully restored snapshot with options cluster config, Kubernetes version and etcd.

Scenario 5

Provisioned a downstream K3s v1.26.11+k3s2 cluster (3 etcd, 2 cp, 3 worker) as a standard user.
Took an etcd snapshot.
Rotated all of the worker nodes.
Rebooted all of the worker nodes in the backend infrastructure side.
Deployed 3 daemonsets with image nginx:latest.
Successfully restored snapshot with options cluster config, Kubernetes version and etcd.

I have confirmed that the following steps work for reproducing this issue (and proving that it is resolved with the new system-agent version):

Start up Rancher that uses v0.3.4 system-agent
Create a new custom K3s cluster
Register a single node (all in one) with the cluster
Wait for the node to become active
When the cluster is stable, take an etcd snapshot
Take the original registration command that was used to initially register the node with the cluster, and wrap it with a bash while loop, i.e. while true; do ${CUSTOM_REGISTRATION_COMMAND}; sleep 5; done
Attempt to restore the etcd snapshot, and note that Rancher gets stuck trying at some point during the etcd restoration process
Upgrade to the version of rancher containing the updated system-agent version
Attempt to run a second restoration of etcd. Note that you may have to wait up to 5 minutes to see any progress, as the original plan delivered may start to be reconciled but fail due to the original failed etcd restoration step.

Observations:

The while loop running the registration command will start to provide log messages stating [INFO]  Active plan reconciliation detected. Sleeping for 5 seconds and retrying check

Reopening so that I can test the above https://github.com/rancher/rancher/issues/43964#issuecomment-1917864661 as a new scenario. I will update the earlier test result comment with the results.

Updated test plan with the new scenario. Closing issue.


Could someone help to put the pretrained models in google drive?

I am interested in the following models:
HRNETV2_W18: "./pretrained_models/hrnetv2_w18_imagenet_pretrained.pth"
HRNETV2_W32: "./pretrained_models/hrnetv2_w32_imagenet_pretrained.pth"
HRNETV2_W48: "./pretrained_models/hrnetv2_w48_imagenet_pretrained.pth"
I am not able to download them from baidu. I wonder if someone can help to put them in google drive.
Many thanks.

@MaitaYuki Please download them from https://github.com/HRNet/HRNet-Image-Classification/releases/tag/PretrainedWeights