[#4027] Remove thrift dependency from pinpoint-commons

Codecov Report

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

@@            Coverage Diff             @@
##           master    #4112      +/-   ##
==========================================
- Coverage   41.24%   41.21%   -0.03%
==========================================
  Files        2342     2342
  Lines       73849    73849
  Branches     9994     9994
==========================================
- Hits        30457    30437      -20
- Misses      40579    40597      +18
- Partials     2813     2815       +2

Impacted Files
Coverage Δ

...n/server/bo/serializer/trace/v2/SpanDecoderV0.java
89.91% <ø> (ø)
:arrow_up:

...vercorp/pinpoint/io/util/AnnotationTranscoder.java
77.67% <ø> (ø)

...vercorp/pinpoint/common/server/bo/SpanFactory.java
90.07% <ø> (ø)
:arrow_up:

...n/server/bo/serializer/trace/v2/SpanEncoderV0.java
92.96% <ø> (ø)
:arrow_up:

...npoint/bootstrap/classloader/ProfilerLibClass.java
100% <ø> (ø)
:arrow_up:

...rp/pinpoint/rpc/packet/ControlHandshakePacket.java
51.51% <0%> (-24.25%)
:arrow_down:

...npoint/rpc/server/SimpleServerMessageListener.java
80% <0%> (-20%)
:arrow_down:

...pinpoint/profiler/instrument/AccessorAnalyzer.java
57.14% <0%> (-8.58%)
:arrow_down:

...m/navercorp/pinpoint/test/OrderedSpanRecorder.java
68.26% <0%> (-5.77%)
:arrow_down:

...navercorp/pinpoint/rpc/common/SocketStateCode.java
82.92% <0%> (-2.44%)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

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


Resources non composable functions

I would be great if resources non composable functions would be in a separate library to be used for kotlin multiplatform without compose multiplatform (ideally with their own gradle plugin or as a part of kotlin multiplatfrom plugin).

KMP doesn't support resources. Make an issue in the kotlin tracker: kotl.in/issue

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Is it possible to draw curves ? ()

Hi, I love this library.
Is it possible to add curves (quadratic and/or cubic) to this?
Where should I should start if I would add it by myself?
Best regards

Yes!
You can use LINE_STRIP. Please the docs: https://github.com/Niekes/d3-3d?tab=readme-ov-file#shapes


specs-go: add label to config.go

Signed-off-by: Lei Jitang<EMAIL_ADDRESS>follow up https://github.com/opencontainers/image-spec/pull/371

@coolljt0725 rebase please?

@vbatts  rebased

LGTM

LGTM


ci: Bump to use CMake 3.20.5

With CMake minimum required as 3.20.0 we update CI to use docker image
v0.18.2, which contains CMake 3.20.5.
For doc builds we fetch the same CMake v3.20.5 but using pip as the doc
build doesn't use the docker image.
The main reason for increasing CMake version is better toolchain
support.
The decission to bump the CMake version was taken by the Toolchain WG.
Better toolchain support is added in the following CMake versions:

armclang, CMake 3.15
Intel oneAPI, CMake 3.20
IAR, CMake 3.15 and 3.20

Signed-off-by: Torsten Rasmussen<EMAIL_ADDRESS>

@galak I've discovered that the bumped docker image is not being used for the PR that actually does the bumping:
For example, the commit in this PR was originally part of: #37575
But the clang build log states:
https://pipelines.actions.githubusercontent.com/CKGajMpgCzQWX4XjShK5oKjVyu04amuYTIxfbSdRBG3PD4p5UT/_apis/pipelines/1/runs/200357/signedlogcontent/8?urlExpires=2021-08-16T11%3A09%3A15.2938911Z&urlSigningMethod=HMACV1&urlSignature=n%2BG4lWa%2FyD%2BHgA83hXlewUVPhRfksUEWriTpxBITaeo%3D
2021-08-16T09:40:24.3868380Z ##[group]Starting job container
2021-08-16T09:40:24.3876373Z ##[command]/usr/bin/docker pull zephyrprojectrtos/ci:v0.18.0
2021-08-16T09:40:25.2998666Z v0.18.0: Pulling from zephyrprojectrtos/ci

And the same was actually happening when docker was updated to v0.18.0 here:
https://github.com/zephyrproject-rtos/zephyr/pull/37418
Where the workflowed was still using v0.17.1 when running CI:
https://github.com/zephyrproject-rtos/zephyr/runs/3236066851

Starting job container
  /usr/bin/docker pull zephyrprojectrtos/ci:v0.17.1
  v0.17.1: Pulling from zephyrprojectrtos/ci

So we must start using the new container before we can get CI green for #37575

Can you update the commit message to say WHY we are updating to cmake 3.20.5 (I think you had this on the docker side).

You probably think of this:

The main reason for increasing CMake version is better toolchain
support.
The decision to bump the CMake version was taken by the Toolchain WG.
Better toolchain support is added in the following CMake versions:

armclang, CMake 3.15
Intel oneAPI, CMake 3.20
IAR, CMake 3.15 and 3.20

which I have added to the commit message.


Stacked video removal issue

When you stack videos directly atop each other then try to remove one by dragging it to the bottom, the loading of a new video/relocation of the new video happens in a different spot in the video table.

thank you rob!


Use cargo-nextest to run the tests

Description
This balances the tests accross multiple cores better and speeds up our test run.
Closes #1864
Notes & open questions
This completes everything suggested in #1864.  Runtimes can now be
further improved by getting more runners.  Probably 2 more of each
for linux, mac and windows is a good start.
Change checklist

[ ] Self-review.
Documentation updates if relevant.
Tests if relevant.

Total run time reduced from 1h50 to 1h10 :tada:


feat: update Go version to 1.19.1

Description
Includes security updates
Verification Steps

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

@bf2fc6cc711aee1a0c2a/control-plane remember to update your local Go version to Go 1.19.1


Dosya iyileştirme

#Add

What is the current behavior?

What changes are you suggesting?

Additional information

Mwrhaba

Mwrhaba


Disable appveyor

Now that we have kokoro testing windows, it would be nice to disable appveyor on this repo :) I don't seem to have permissions to do that 🤷♂
@ofrobots @alexander-fenster

Done. I've deleted the project from appveyor.


Shell not compatible with c++

Describe the bug
A clear and concise description of what the bug is.
What have you tried to diagnose or workaround this issue?
Shell is not compatible with C++.
To Reproduce
Steps to reproduce the behavior:

Enable C++ and Shell at the prj file;
Add code to initialize some shell command using the Shell Macros;
mkdir build; cd build
cmake -DBOARD=nucleo_f091rc -GNinja ..
ninja
See error

Expected behavior
A clear and concise description of what you expected to happen.
It must be possible to compile and execute the shell properly with C++.
Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
The code does not compile, so the user would not use the shell on the firmware. Shell is an important feature for testing, interact and updating the code via mcumgr shell backend.
Screenshots or console output
If applicable, add a screenshot (drag-and-drop an image), or console logs
(cut-and-paste text and put a code fence (```) before and after, to help
explain the issue.
Here is the compilation log:
../src/main.cpp
In file included from ../src/main.cpp:22:0:
/home/r...t/zephyr/include/shell/shell.h:170:41: error: uninitialized const ‘shell_sub_h’ [-fpermissive]
  static const struct shell_static_entry shell_##name[];                 \
                                         ^
../src/main.cpp:104:1: note: in expansion of macro ‘SHELL_CREATE_STATIC_SUBCMD_SET’
 SHELL_CREATE_STATIC_SUBCMD_SET(sub_h)
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/r...t/zephyr/include/shell/shell.h:107:8: note: ‘const struct shell_static_entry’ has no user-provided default constructor
 struct shell_static_entry {
        ^~~~~~~~~~~~~~~~~~
/home/r...t/zephyr/include/shell/shell.h:108:14: note: and the implicitly-defined constructor does not initialize ‘const char* shell_static_entry::syntax’
  const char *syntax; /*!< Command syntax strings. */
              ^~~~~~
/home/r...t/zephyr/include/shell/shell.h:170:54: error: storage size of ‘shell_sub_h’ isn’t known
  static const struct shell_static_entry shell_##name[];                 \
                                                      ^
../src/main.cpp:104:1: note: in expansion of macro ‘SHELL_CREATE_STATIC_SUBCMD_SET’
 SHELL_CREATE_STATIC_SUBCMD_SET(sub_h)
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/r...t/zephyr/include/shell/shell.h:172:12: error: expected primary-expression before ‘.’ token
            .u.entry =                \
            ^
../src/main.cpp:104:1: note: in expansion of macro ‘SHELL_CREATE_STATIC_SUBCMD_SET’
 SHELL_CREATE_STATIC_SUBCMD_SET(sub_h)
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/r...t/zephyr/include/shell/shell.h:82:2: error: taking address of temporary [-fpermissive]
  }
  ^
/home/r...t/zephyr/include/shell/shell.h:213:52: note: in expansion of macro ‘SHELL_ARG’
   .args = _mandatory ? (&(struct shell_static_args)SHELL_ARG(    \
                                                    ^~~~~~~~~
/home/r...t/zephyr/include/shell/shell.h:227:2: note: in expansion of macro ‘SHELL_CMD_ARG’
  SHELL_CMD_ARG(_syntax, _subcmd, _help, _handler, 0, 0)
  ^~~~~~~~~~~~~
../src/main.cpp:106:5: note: in expansion of macro ‘SHELL_CMD’
     SHELL_CMD(t, NULL, "APP Power on self test status", shell_app_post),
     ^~~~~~~~~
../src/main.cpp:104:32: warning: ‘sub_h’ defined but not used [-Wunused-variable]
 SHELL_CREATE_STATIC_SUBCMD_SET(sub_h)
                                ^
/home/r...t/zephyr/include/shell/shell.h:171:38: note: in definition of macro ‘SHELL_CREATE_STATIC_SUBCMD_SET’
  static const struct shell_cmd_entry name = { .is_dynamic = false,      \
                                      ^~~~
cc1plus: warning: unrecognized command line option ‘-Wno-register’
ninja: build stopped: subcommand failed.

Environment (please complete the following information):

OS: Linux Ubuntu 18.04.1 LTS
Toolchain Zephyr SDK 0.9.5
Zephyr Version: zephyr-v1.13.0-4557-g2e68bc02b9
git SHA: 2e68bc02b9a97cf24b3f74d92f3bc6444aa7749a

Additional context
The main issues I had to resolve was:

... error: uninitialized const ...
... error: expected primary-expression before ‘.’ token .u.entry ...
... error: taking address of temporary ...
... note: ‘const struct shell_static_entry’ has no user-provided default constructor ...

I could get the code running by changing the initialization approach on the shell macros, but I had to change the way to do, so here is the current solution:

#include <misc/printk.h>
#include <shell/shell.h>
#include <shell/shell_fprintf.h>
#include <stdio.h>

/**
 * @brief Initializes a shell command arguments
 *
 * @param[in] _mandatory Number of mandatory arguments.
 * @param[in] _optional  Number of optional arguments.
 */
#define XXSHELL_ARG(_mandatory, _optional) \
    {                                      \
        _mandatory, _optional,             \
    }

#define XXSHELL_CMD_ARG(_syntax, _subcmd, _help, _handler, _mandatory, _optional)   \
    {                                                                               \
        (const char *) STRINGIFY(_syntax), (const char *) _help, _subcmd, _handler, \
        {                                                                           \
            _mandatory, _optional                                                   \
        }                                                                           \
    }

/**
 * @brief Macro for creating a subcommand set. It must be used outside of any
 * function body.
 *
 * @param[in] name	Name of the subcommand set.
 */
#define XXSHELL_CREATE_STATIC_SUBCMD_SET(name, ...)                                 \
    static const struct shell_static_entry shell_##name[] = {__VA_ARGS__,           \
                                                             SHELL_SUBCMD_SET_END}; \
    static const struct shell_cmd_entry name              = {false,                 \
                                                {(shell_dynamic_get) shell_##name}};

/**
 * @brief Initializes a shell command.
 *
 * @param[in] _syntax	Command syntax (for example: history).
 * @param[in] _subcmd	Pointer to a subcommands array.
 * @param[in] _help	Pointer to a command help string.
 * @param[in] _handler	Pointer to a function handler.
 */
#define XXSHELL_CMD(_syntax, _subcmd, _help, _handler)                                   \
    {                                                                                \
        (const char *) STRINGIFY(_syntax), (const char *) _help, _subcmd, _handler, NULL \
    }

/**
 * @brief Macro for defining and adding a root command (level 0) with
 * arguments.
 *
 * @note All root commands must have different name.
 *
 * @param[in] syntax	Command syntax (for example: history).
 * @param[in] subcmd	Pointer to a subcommands array.
 * @param[in] help	Pointer to a command help string.
 * @param[in] handler	Pointer to a function handler.
 */
#define XXSHELL_CMD_REGISTER(syntax, subcmd, help, handler)                        \
    static const struct shell_static_entry UTIL_CAT(_shell_, syntax) =             \
        XXSHELL_CMD(syntax, subcmd, help, handler);                                \
    static const struct shell_cmd_entry UTIL_CAT(shell_cmd_, syntax)               \
        __attribute__((section("." STRINGIFY(UTIL_CAT(shell_root_cmd_, syntax))))) \
            __attribute__((used)) = {false,                                        \
                                     {(shell_dynamic_get) &UTIL_CAT(_shell_, syntax)}}

int shell_app_post(const struct shell *shell, size_t argc, char **argv)
{
    shell_print(shell, "post");
    return 0;
}
int shell_app_reboot(const struct shell *shell, size_t argc, char **argv)
{
    shell_print(shell, "reboot");
    return 0;
}

XXSHELL_CREATE_STATIC_SUBCMD_SET(sub_h,
                                 XXSHELL_CMD(t, NULL, "APP Power on self test status",
                                             shell_app_post));

int main(void)
{
    XXSHELL_CMD_REGISTER(h, &sub_h, "Info commands", NULL);
    XXSHELL_CMD_REGISTER(r, NULL, "General reset commands", shell_app_reboot);

    while (1) {
        k_sleep(K_SECONDS(10));
        printk("ping\n");
    }

    return 0;
}

Code edited to avoid the warning: missing braces around initializer when compiling it in C.

It is not possible to compile shell with C++. It is because C++ does not allow to declare a const variable and assign it later. I do not have a fix for that now and I have no idea when it can be done.

It is not possible to compile shell with C++. It is because C++ does not allow to declare a const variable and assign it later. I do not have a fix for that now and I have no idea when it can be done.

The code I have done is working. Could you consider that as a solution? ;)

ahh sorry! :) sure I will!

@rodrigopex : It it shell API change. I have nothing agains it but it would be good to have it in Zephyr 1.14 because it is planned to be LTS. This requires lot of changes in already implemented commands. Do we have a volunteer? :)
@nashif @carlescufi : what do you think about it?

It would be great to help. Do you think the way that I have made the XX SHELL_CREATE_STATIC_SUBCMD_SET variant a good option? I think the biggest changes would be at the samples, right?

@rodrigopex @jarz-nordic I don't think it would be an issue including this for 1.14, since ultimately the new shell broke C++ support and this would bring it back, so I would consider this a bugfix.

@carlescufi Ok. @jarz-nordic Should I start to write the code? I can help. I think the other macro would not change at all, so the "only" part that will need to be changed is the code related to SHELL_CREATE_STATIC_SUBCMD_SET.

I think an API change would be easier to see in a commit (doesn't have to be PR yet). My 2 cents.

I think an API change would be easier to see in a commit (doesn't have to be PR yet). My 2 cents.

I will do that.

@rodrigopex : As you noticed main problem is with SHELL_CREATE_STATIC_SUBCMD_SET and it is good idea to change it. Regarding updating all already existing commands we were thinking about some kind of script. It should not be a rocket science. I hope to have some proposal by end of tomorrow for that.
@rodrigopex thank you for this change!

@jarz-nordic I was trying to make it work inside the shell code, and I am facing issues with the dynamic shell when I change the code of the MACROs. It seems to be easy to change for static, but not so easy to dynamic.
This will not work in C++:
#define SHELL_CMD_ARG(_syntax, _subcmd, _help, _handler,		      \
		      _mandatory, _optional) {				      \
	.syntax = (const char *)STRINGIFY(_syntax),			      \
	.subcmd = _subcmd,						      \
	.help  = (const char *)_help,					      \
	.handler = _handler,						      \
	.args = _mandatory ?						      \
	(&(struct shell_static_args) SHELL_ARG(_mandatory, _optional)) : NULL \  //<-- this will not work in C++
}

Maybe using alloca we could alloc the bytes. But could not set that inline.

(&(struct shell_static_args) SHELL_ARG(_mandatory, _optional)) : NULL \  //<-- this will not work in C++

@jarz-nordic, regarding the issue above. It could be fixed by changing:
const struct shell_static_args *args; in struct shell_static_entry to
const struct shell_static_args args; and using values like 0xFF to disable args checking.

It it not a problem, we can document that.

@rodrigopex : Please start a PR with your changes and add a macro: XXSHELL_CREATE_STATIC_SUBCMD_SET.
Next we will start another PR:

Remove old SHELL_CREATE_STATIC_SUBCMD_SET
Rename your XXSHELL_CREATE_STATIC_SUBCMD_SET to SHELL_CREATE_STATIC_SUBCMD_SET
Implement fix in SHELL_ARG proposed by @nordic-krch
Update all existing macros creating subcommands (we have prepared automated solution for that).

@jarz-nordic It will be necessary to modify other macros to make the XXSHELL_CREATE_STATIC_SUBCMD_SET work. It will be more productive if you add that, don't you think? I guess I will only interfere in a bad way here if I add that.
@nordic-krch I was trying to change that yesterday. Is it possible to have the fields mandatory and optional both zero, right? I would guess it will be better to maintain that as the default value when using SHELL_CMD macros and set different values when using the SHELL_CMD_ARG.

@rodrigopex : Ok we will add that and put you as a resolver in a commit message.

@jarz-nordic don't mind, the important is that it will run in C++. For help, I have done some code on my fork, you could take a look. It seems to not working properly yet, I am trying to figure out what is happening. https://github.com/rodrigopex/zephyr/tree/i13257

Fixed by #13319


receiver: fix the calculation logic of minimum number of replicas

[x] I added CHANGELOG entry for this change.
[x] Change is not relevant to the end user.

Changes
I modified the pattern to int(((h.options.ReplicationFactor - 1) / 2) + 1).
The original pattern is int((h.options.ReplicationFactor / 2) + 1). there will be a issue when the ReplicationFactor is even numbers.
if the ReplicationFactor is 2. the value of the pattern would be (2/2+1)=2. therefore, both replicas must be successfull to return success to prometheus.
if the ReplicationFactor is 4, the value of the pattern would be (4/2+1)=3. therefore, there need to be 3 successful replicas to return success to prometheus.
Recently we alter the replicas from 1 to 2, but all the receivers would be stuck if one receiver was crashed.
It works after alter this pattern.
Verification

Thanks so much for the clear enumeration of the change. Really helpful.
There is also a difference between replication factor which 'dictates' the quorum and the actual replica's you are running for the receive. IMO it's always better to run more replica's than your replication factor is, so you can always have your quorum.
I.e. run one or two replica's for a replica factor of 1. Run a minimum of 3 replica's for a replication factor of 2.
So your change would work but I'm not sure if it's good to basically run a higher replication factor than actual replica's required. Especially on the 'lower' figure segment. For example your change would require only 1 receive replica to handle a replication factor of 2.
Personally my 2 cents here is that one should run a higher replica count to meet quorum quota's rather than lowering the quorum quota. What's your thought on this?
current factor & quorum
replication factor: 1 quorum: 1  // but this is fine regardless, no quorum required for 1 replica factor.
replication factor: 2 quorum: 2
replication factor: 3 quorum: 2
replication factor: 4 quorum: 3
replication factor: 5 quorum: 3
replication factor: 6 quorum: 4
replication factor: 7 quorum: 4
replication factor: 8 quorum: 5
replication factor: 9 quorum: 5
replication factor: 10 quorum: 6

This change
replication factor: 1 quorum: 1
replication factor: 2 quorum: 1
replication factor: 3 quorum: 2
replication factor: 4 quorum: 2
replication factor: 5 quorum: 3
replication factor: 6 quorum: 3
replication factor: 7 quorum: 4
replication factor: 8 quorum: 4
replication factor: 9 quorum: 5
replication factor: 10 quorum: 5

Hi @GaoJiasheng, the current logic is intentional and not actually a bug. We in fact wanted the hashring to require at least more than one half of the nodes to agree I'm order to consider a write successful. If we want to change this then I would suggest we first continue the discussion on one of the existing issues like https://github.com/thanos-io/thanos/issues/3194


876 preview tests

This picks up #876:
@connorjburton I made two changes I want to call your attention to.
First on TimberPost::get_post_preview_id I switched the assumption on true/false. For security reasons (admittedly, hypothetical) it's better practice to start with a no-access assumption. That way if something screwy happens with permissions, the code makes the assumption that viewing the post preview should not be allowed.
On the test itself (testPreviewContent), PHPUnit assertEquals compares:
$this->assertEquals( Expected Thing, Thing to Test );

The test will still pass either way, but the formatting of errors/failures will read correctly.
All this is just tweaks on your earlier work — give it a look and if you like what you see this should be good to (finally) merge!

Makes sense about the test.
For the refactor of get_post_preview_id, I can see a couple of issues:
$can is an array that contains all the permissions that a user needs to have to preview the post, as there is abreak on the first instance of current_user_can:

We are assuming if the user can do any of $can they should be able to preview the post, which isn't true, it needs to pass all of the array $can.
If we removed the break we still have an issue where $can[0] may be false (keeping $can_preview at false), but the $can[1] may be true, and because we no longer have the break $can_preview is now  true. However that isn't right because the user shouldn't be able to preview.

Phew, think that makes sense.
I propose to change the foreach to (not the prettiest, if you can think of a better way I'm all for it):
                $can_preview = array();

	 	foreach( $can as $type ) {
	 		if( current_user_can( $type ) ) {
	 			$can_preview[] = true;
	 		}
	 	}

	 	if ( count( $can_preview ) !== count( $can ) ) {
	 		return;
	 	}

Hopefully that all makes sense? Can clarify if not.

Yep! Makes sense — thanks for the fix on that. I merged that in with #887


fixing schedule table and hyperlink to animal telemetry

closes #125
@timvdstap Schedule table is now fixed and animal telemetry is hyperlinked

@timvdstap if this looks good, do you mind merging? I'm not sure if you have the privileges or not.


fixed menu bg on small screen

#667
added background to nav menu on hamburger when screen size get smaller
so that it wont be hidden on white bg.

Great contribution to Hacktoberfest'24! 🎉


NextGen Stats

I had a general question whether the nfl provides an api for the nextgen stats and if yes if there are plans to integrate it with nflgame.

It looks like sportsradar is the exclusive provider of these stats.  Their API actually looks pretty easy to use.
I believe a trial account is limited to 1000 total API calls, and registration was easy enough so I gave it a shot.  Their documentation is geared toward Python 3, but a simple conversion of http.client to httplib in their example fixes that.
import httplib
conn = httplib.HTTPSConnection("api.sportradar.us")
conn.request("GET", "/nfl-ngs-bt1/games/25fde8b4-6e4e-468c-ba0a-a511530a303c/leaders.xml?api_key=MY_API_KEY")
res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

Unfortunately, that's about as far as I can get:

Developer Inactive

(Calling https://api.sportradar.us/nfl-ngs-bt1/games/25fde8b4-6e4e-468c-ba0a-a511530a303c/leaders.xml?api_key=MY_API_KEY and https://api.sportradar.us/nfl-ngs-bt1/games/25fde8b4-6e4e-468c-ba0a-a511530a303c/leaders.xml?api_key={MY_API_KEY} in my browser both lead to same response)
Don't know if someone on their end has to approve the app I proposed when registering for an API key before it is live or what (Their website shows that API key active on my account).
All that said, it probably isn't going to be sustainable for any project I'd want to use it for.  If you plan on making fewer than 750 API calls per month, you can have access to their data for the $950/month and that ramps up to $6000/month for 35k API calls.

I was able to use my trial key with the API to get schedule, player, and play-by-play (all stuff that is in nflgame) so I believe everything is functional, but I guess the next gen stats like "Play Tracking Statistics" are only available to the $6000/month Gold tier
Feed availability


SILFR a  a cryptocurrency payment system for data transfer over the LOKI.network.

SILFR coin
Proposal
By William E. Coyote
Silfr is a Norse name for silver, a type of money.
This is a proposal to implement SILFR, a cryptocurrency that is designed to function as a payment system for data transfer over the LOKI.network.
===========================
Section 1: Introduction
===========================
The driving idea of the design of SILFR is that a USER with LOKI in their wallet can use the LOKI.network free of charge. Instead of paying for use of the LOKI.network with LOKI or some other cryptocurrency, they will simply stake LOKI for a limited time. This is the same as staking LOKI to a SN and receiving block rewards. Instead of rewards, the USER is receiving access to the services of the LOKI.network.
The SILFR wallet is an access point where the volume of data that passes through this point is paid for in SILFR. The primary use of SILFR is to create a method for users to pay for the use of Exit Nodes. The same access point technology can be used across the LOKI.network and track data traffic for SN, EN, and SNApp Providers. USERs pay for accessing the open internet through the LOKI EN. SNApp Providers will pay for the traffic from their SNApp on the LOKI.network. SN and EN get paid in SILFR for the traffic that crosses the node. All payment is made to or from CONTROL a centralized wallet. CONTROL is not owned by any individual or group of individuals. CONTROL is decentralized across the SN of the LOKI.network.
Transferring SILFR into LOKI takes place on the LOKI DEX. The LOKI DEX is a SNApp that permits the buying and selling of LOKI and SILFR. USERS and SNApp Providers can buy SILFR with LOKI to support their use of the LOKI.network. SN and EN will sell their SILFR to receive LOKI. In time, as volume grows, the LOKI DEX could expand to include BTC and other cryptocurrencies. The Advantages of this DEX is that it removes LOKI from centralized exchanges and increases security. In time, all of the needs of the LOKI.network to be a functioning private information service would be provided from within the LOKI.network.
===========================
Section 2: Personal Statement and Motivation
===========================
I am a crypto currency hobbyist and enthusiast. I do not work in the tech industry in any capacity. I recognize that this proposal is based on my own limited knowledge of cryptocurrency and related technologies. Everything in this proposal is based on what I imagine is generally easy to implement.  I recognize that I could be catastrophically wrong, have overlooked something that is extremely important, or even hysterically incorrect in my assumptions. I have a pretty robust relationship with failure. This could just be another day of building my supra-genius invention with high hopes for success, and I end up falling off a cliff with my defunct contraption falling on top of me. No worries. I would appreciate any feedback that you can give if my assumptions are wildly erroneous. It has taken a considerable amount of time to write this proposal and I hope to at least learn something from the endeavor.
I own a sizable stake in LOKI because it is an amazing project that may become one of the most important crypto currencies in the world. The strengths of LOKI and the LOKI.network are numerous. LOKI is private when transferred to another wallet. It can be transferred immediately with BLINK. LOKI is proof of Work, that includes check-pointing and will soon be updated to Pulse which moves the PoW burden to the Service Nodes. These reasons alone make LOKI an important coin. But the LOKI coin is not the most important part of the project. The LOKI.network provides instantaneous, completely secure and private messaging along with a host of other features. And furthermore, the LOKI.network will provide private, secure and anonymous communication and data transfer to the open internet. And the LOKI.network will host an even more secure community of SNApps which will provide many unique services as well as many services found on the open internet. It appears that the goal of the LOKI network is to surpass the technology of the TOR network. The LOKI.network is on track to accomplish this goal in 2020.
The LOKI cryptocurrency is extremely robust, but there are many areas that need to be improved to have a functioning LOKI.network. The primary deficiency is in developing a method for the LOKI.network to become financially stable. Presently there are no limitations to the bandwidth for users of the LOKI.network. Anyone can use the LOKI.network for free.  It is easy to foresee that users and other enterprises will take advantage of this design flaw and create more traffic than the LOKI.network can financially support.
The benefit of using a second cryptocurrency is that it gives a secure and private method of payment for the quantity of data traffic over the LOKI.network. For this to work there has to be a way to calculate the amount of traffic that crosses any Service Node, and Exit Node. Furthermore there has to be a way of calculating the data traffic that crosses the user access point and to determine if it is from services on the LOKI.network or general traffic on the open internet. The idea is to simply calculate the amount of traffic and not to determine the direction of traffic, type of traffic, or information held within the traffic. The amount of traffic will be paid for in SILFR.
To add a secondary coin to the LOKI network there has to be a way of transferring value between LOKI and SILFR. This has to be a form of Atomic Swap or Decentralized Exchange (DEX). This DEX is completely necessary because it is designed in such a way that it is extremely difficult to to be traded on any other exchange. This DEX will also increase the security of the LOKI.network and increase the overall profitability of the LOKI.network.
SILFR is designed to work seamlessly with the many aspects of the LOKI.network and creates a payment system that incorporates all participants in the network. With this in mind, it is difficult to describe SILFR as a stand alone cryptocurrency. Because it connects many working parts, there is no easy place to begin describing SILFR and you may be a bit lost at the beginning. Please take some time to work through the proposal before you draw any conclusions.
The following description begins by defining the terms and working parts of SILFR. Then a description of SILFR is provided. SILFR is designed to be a simple solution but is sophisticated in how it pulls many parts of the LOKI.network together. I have written significantly more about how SILFR could work and I will provide this information if there is any interest in this proposal.
===========================
Section 3: Terms and Abbreviations
===========================
(The names SILFR and CONTROL are chosen because they are descriptive and help identify the different working parts of the proposal. Actual names can be much different.)
The following abbreviations and terms are used:
SILFR = SILFR coin or cryptocurrency.
LOKI = LOKI coin or cryptocurrency.
SN = LOKI network Service Node..
EN = LOKI network Exit Node.
USER = any individual who is using the LOKI network or cryptocurrency.
SN Network = The activities of all the individual SN when working together.
CONTROL = the control wallet.
Staked LOKI = Loki that has been staked to receive SILFR.
Access Point = Any point on the LOKI network that transfers data.
SILFR Wallet = A wallet at an access point that is charged SILFR for the transfer of data.
SNApp Provider = any provider of SNApps that transfer data over the LOKI network.
LOKI DEX = the DEX hosted by LOKI Service Nodes.
Market Price = Present transaction ratio between LOKI and SILFR
If SILFR is adopted, The LOKI network would be supported by two different coins: LOKI and SILFR. Users will staking LOKI and receive SILFR. Paying in SILFR would become the normal method to pay for services on the LOKI network. This would give the USERs who hold LOKI virtually free use of services offered by the LOKI network. "virtually free" meaning that if they hold enough LOKI they can continue to pay SILFR for all the services that they use. Also, if the USER needs more SILFR they can trade LOKI (or another cryptocurrency) for SILFR on the LOKI DEX.
!!! IMPORTANT !!!!
For SILFR to work as described, SILFR wallets are attached to Acess Points. There is a provision in the SILFR wallet that calculates the volume of data traffic that passes through the Access Point and charges SILFR for that data. Data is not tracked through the LOKI network, it is just paid for at the Access Points. The USER Access Point can determine if the traffic originated on the LOKI network or came though the EN.
For this description the following fees and values will be used. (In actuality, these values could be significantly different.)

A USER will receive 1 SILFR for every LOKI that he stakes.
When a USER stakes LOKI to receive SILFR, his lock up time will be 100 days.
Transfer Fees will be 1% of the entire contents of the wallet per 24 hour period.

===========================
4: Description.
===========================
Control Wallet:
CONTROL is the wallet that holds all SILFR that is not in use. There is 1 SILFR available in the CONTROL for every LOKI staked in a SN. If there is 1,000,000 LOKI staked in all SN on the LOKI.network, then there is a total of 1,000,000 SILFR available.
CONTROL pays SILFR when a USER stakes LOKI or when an EN or SN are paid for data traffic.
Access Point:
For SILFR to work as described, SILFR wallets are attached to Access Points. There is a provision in the SILFR wallet that calculates the volume of data traffic that passes through every Access Point and charges SILFR for that data. Data is not tracked through the LOKI network, it is just paid for at the Access Points. SN are paid for any traffic that they facilitate. EN only paid for open internet traffic that they facilitate. The USER Access Point only pays for traffic from the open internet and can determine if the traffic originated on the LOKI network or came through the EN. USERS do not pay for traffic on the LOKI.network.
A USER pays SILFR for data traffic over the EN network:
The USER access point (on his computer or device) is connected to his SILFR wallet. As the USER accesses data over the EN network his wallet is automatically deducted for that amount of traffic. The payment goes to the CONTROL wallet.
Staking LOKI:
SILFR is paid to a USER when a USER stakes LOKI for 100 days. This is basically a 100 day loan of SILFR that is paid back at the rate of 1% per day. In this way a user does not have to pay any LOKI to receive SILFR.
The amount of SILFR that is paid for staking LOKI is proportional to the percentage of SILFR that is available.

If 100% of SILFR is available, then there is no SILFR in circulation, and a USER receives 100 SILFR for every LOKI that they stake.
If 70% of SILFR is available, there is 30% of SILFR in circulation, and a USER will receive 70 SILFR for each LOKI that they stake.

Transaction fees:
The transaction fee for sending SILFR is 1% of the total contents of a wallet per day. All fees are paid to CONTROL.

If a USER receives 100 SILFR then 10 days later they send a transaction of 80 SILFR, then they will have 10 SILFR in their wallet. They sent 1 SILFR and paid a fee of 10 SILFR. 100 SILFR - 80 SILFR - 10 (for fee)= 10
IF a USER receives 100 SILFR then 10 days later they send a transaction of 1 SILFR, then they will have 89SILFR in their wallet. They sent 1 SILFR and paid a fee of 10 SILFR. 100 SILFR - 1 SILFR - 10 (for fee)= 89

The fees represent paying the 100 day loan. Because all wallets are paying the 1% per day fee to CONTROL, the 100 day loan is returned. This results in all wallets only holding SILFR for 100 days. Therefore the SILFR blockchain is only 100 days long.
A USER Does not have to acquire SILFR to access the LOKI EN.network.
A USER can hold LOKI in their access point wallet. The wallet would instantly stake LOKI and send SILFR to CONTROL as the USER accesses the EN.network. This would reduce transaction fees to 0. And the USER would still have to wait for 100 days to free and reuse their staked LOKI.
The USER can acquire SILFR in two ways, they can STAKE SILFR or they can buy SILFR on the LOKI DEX.
When a USER stakes LOKI to receive SILFR. The USER can use this SILFR to pay for EN traffic or other services or they can sell this SILFR on the LOKI DEX and receive LOKI or another cryptocurrency.

IF a USER stakes 100 LOKI. and 20% of SILFR is in circulation the USER would receive  8,000 SILFR (100*80=8000). If the USER sells 8000 SILFR on the DEX for the market price of 1 to 1000 then he would receive 8 LOKI. Therefore the USER made a profit of 8 LOKI over 100 days for staking 100 LOKI. (In actuality, This profit ratio would probably be much less.)

Because the market price of SILFR is inexpensive, the USER may choose to buy SILFR instead of STAKING LOKI to acquire SILFR.

A USER can buy SILFR on the DEX to pay for EN traffic. A USER has 5 LOKI and wants to download a large file over the LOKI.network. He buys 5000 SILFR on the DEX with the 5 LOKI, then he can afford to download the large file.

EN and SN are paid for data traffic in SILFR from the CONTROL wallet, not from a USER wallet.
An EN is an Access Point that calculates the amount of data traffic that it passes for an entire block reward cycle. At the end of the cycle it submits this statement to CONTROL. CONTROL pays for the data traffic in SILFR. Therefore the SN is paid in LOKI as part of the block reward and in SILFR for the actual amount of DATA that is passed.  The SILFR is part of the payment and sent proportionally to the wallets of the USERS who staked LOKI in the EN.
SNs are also paid for DATA traffic from CONTROL in the same way, but the reward is significantly smaller. Perhaps even 1 to 10.
In this way ENs and SNs are paid for the actual data traffic that they carry and operators will work to optimize their traffic. They will move the SN/EN to areas or servers that facilitate higher payment.
SNApp Providers pay for traffic in SILFR.
All SNApp providers will have a SILFR Wallet at their access point. The wallet will be charged SILFR to use the LOKI network. SNApp providers would provide data and service on the Network and pay for network traffic that uses data with SILFR. SNApp Providers will have to Stake LOKI or buy SILFR on the open market to pay for their traffic.
USERs would pay the SNApp Providers for their content or service, but not for the network traffic. Network traffic on the LOKI.Net is free to the USER.
A SNApp Provider does not have to acquire SILFR to pay for the traffic of his SNApp.
A SNApp Provider can hold LOKI in their access point wallet. The wallet would instantly stake LOKI and send SILFR to CONTROL as USERs accesses the SNApp.  This would reduce transaction fees to 0. And the USER would still have to wait for 100 days to free and reuse their staked LOKI.
LOKI DEX
The LOKI DEX is a completely necessary part of the LOKI SN Network with SILFR. The primary service for the LOKI DEX is to provide instant buy or sell transactions between SILFR and LOKI.
Because the primary service of the LOKI DEX is to facilitate transactions between only LOKI and SILFR it does not have to operate like a centralized exchange. A centralized exchange facilitates a bid/ask price and buying and selling happens in real time. The LOKI DEX does not have to make a trade in real time. The LOKI DEX can act more like a semi-fluid marketplace. It can reduce transactions to happen once a block interval (10 seconds?). The LOKI DEX can set a Market Price between LOKI and SILFR based on availability and can automatically move that price a set increment between block intervals. This slower semi-fluid marketplace would stimulate buying at the Market Price instead of waiting for a better price. Also, Because this is a marketplace more than a DEX, the LOKI foundation could set a minimum Market Price.
As volume on the DEX develops, it would be possible for other coins to participate on the DEX. A USER may have BTC and want to buy SILFR for the EN. Instead of buying LOKI on an exchange then buying SILFR on the LOKI DEX he can buy LOKI or SILFR directly on the LOKI DEX.
SILFR is bought on the DEX by USERS who want to use the LOKI EN.s and by SNApp Providers that want to pay for the traffic that passes through their SNApp.
SILFR is primarily sold on the DEX by two parties that are making a profit, USERS who are staking LOKI and SN/EN owners.
All SILFR that is being sold on the DEX will still have to pay the transaction fee when traded. The SILFR seller would pay this fee and it would be invisible to the buyer. This would inspire the SILFR seller to sell as soon as possible.
The LOKI Foundation will set all rates of payment. .
This payment system would need to be balanced by setting appropriate pay rates. For example: EN would need to be paid at a higher rate than SN to ensure the EN are optimizing for increased data traffic.
This example uses a 100day period and 1% per day transaction fee, but a longer or shorter time frame may be more efficient. Furthermore it may be necessary to pay SILFR to stakers on a different curve.
This system will have to be tuned for optimal functionality.
===========================
Section 5: Design Criteria for SILFR
===========================
SILFR is a method of payment for data traffic on the LOKI.network. Should SILFR be on a blockchain? Should SILFR be a cryptocurrency? If so, what type of architecture should it have?
I am not a crypto currency engineer.I can not efficiently design a cryptocurrency that meets this criteria; but I can help clarify the design criteria.
Design Criteria for SILFR:

SILFR is a payment system for a CONTROL wallet, distributed set of wallets and a DEX.
Block Validation for SILFR will happen across the LOKI SN network.
SILFR has a centralized nature. Most of SILFR exists in the CONTROL wallet. SILFR in every other wallet is quickly depreciating.
SILFR has to be able to make automatic instantaneous micro-payments for USERs and SNApp providers.
SILFR will be the building block of the LOKI DEX.
SILFR should be private and secure when used on the LOKI.network. SILFR transactions can rely on the LOKI network to increase privacy. Because SILFR is designed to be used only on the LOKI.network it does not have to be strictly private when used across the open internet.
SILFR only has to have a 100 day blockchain.

SILFR is used for a payment network for a distributed set of wallets. The value of those wallets has to be verified by a neutral third party,  therefore I do think that SILFR meets the need to be on a blockchain.
Most other cryptocurrencies use a method of validation that is distributed across a host of unknown actors and it is taken for granted that some of these actors are bad actors that are trying to steal from the network. Because SILFR is validated across the LOKI.network it is inherently more secure.
Presently LOKI has a two minute blockchain and this is not fast enough for a micro-payment network with a DEX. Also the LOKI Blockchain would expand exponentially if used for a micro-payment system. SILFR would need to have a 10 second validation period or faster. SILFR will have a limited, 100 day, blockchain. (Or some other predefined amount of time.0
The SILFR wallet has to charge the 1% of all the contents of the wallet per day fee.
SILFR needs to have a contract capability to be the backbone of a DEX, but it probably does not need to have a Smart Contract capability. It only needs to solve a predefined set of parameters. But I can imagine that SILFR could be the beginning of a Smart Contract system if one needs to be developed.
===========================
Section 6: Problems Solved
===========================
Method to account for traffic and pay SN/EN directly for the service that they provide.
Users pay for EN open internet traffic and SNApp providers pay for LOKI.network traffic in SILFR. SN and EN are paid for the volume of DATA that passes their node. With the implementation of SILFR USERS, SNApp Providers and NODE operators are held accountable for the traffic that they create or the service that they provide.
Optimize Network data traffic.
SN and EN that are poorly located or on low quality equipment will get paid less SILFR. SN and EN operators will be paid more SILFR for moving to higher bandwidth servers and better locations. Because SN and EN are financially incentivized the LOKI.network will be optimized to handle increased data traffic.
SNApp Providers will be paying for the data traffic for access to their SNApp. This will reduce the amount of bad actors taking advantage of the LOKI.network and not contributing to a better user experience.
USERS will be paying for traffic that they create through EN to the open internet. Because they will be paying for this service, they will be incentivized to find a similar service provided by SNApp Providers on the LOKI.network. This further creates a more positive user experience and optimizes the network.
Increased Security.
The primary way that SILFR increases security is by reducing the use and reliance of centralized exchanges. The privacy of individuals can be compromised by tracking their data use across EN. If a large amount of LOKI resides on centralized exchanges these exchanges already use significant bandwidth and can easily host LOKI EN. On top of making income through block rewards they can sell the data they acquired through monitoring EN. The only way to combat this security flaw is to decrease the amount of LOKI on centralized exchanges.
Implementing SILFR decreases the LOKI available to trade on centralized exchanges in four ways.
First, USERs will stake LOKI to use the LOKI.network. This decreases the amount of available LOKI on the open market. Furthermore, this will create a chain reaction of increasing the need for more SN that further decrease the amount of LOKI on the open market.
Secondly, centralized exchanges will easily incorporate high bandwidth and well located EN that will attract a significant amount of network traffic across every EN that they host. This gives them more data to mine and sell with lower cost. Because SILFR helps to optimize the EN traffic, all of the EN on the network will be competing for increased traffic. This will lower the data volume across exchange owned EN and decrease their profitability for operating an EN.
Third, USERS will have to pay for EN use, but they can use the LOKI.network for free. USERs are incentivized to find SNApps to fulfill their needs instead of accessing the open internet. This will increase the security for the user and help to incentivize SNApp Providers to create more services. This will decrease the amount of traffic across EN.
Finally, It is difficult to trade SILFR on any other exchange. SILFR is a quickly depreciating asset and it would not be financially beneficial for any other exchange to offer SILFR unless they were operating SN or EN. This gives the added protection of being able to identify which exchanges have a large stake in LOKI.
Other ways in which SILFR increases security:
Most transactions of SILFR involve the CONTROL wallet. Almost all transactions are to or from CONTROL, and the CONTROL blockchain is only 100 days long.  This removes almost any ability to track SILFR across multiple parties. This also increases the security and incentivizes use of the LOKI DEX.
Increase the value of LOKI.
Users will know that if they hold LOKI they will be able to use the services on the LOKI network for no charge. Therefore, they will hold their LOKI instead of trading the coin. Furthermore, this will create a chain reaction of increasing the need for more SN that further decrease the amount of LOKI on the open market and increasing the price of available LOKI.
USERS will bring value to the LOKI.network by trading BTC or any other supported cryptocurrency on the LOKI DEX. Individuals who own LOKI know that their stake in LOKI can purchase other crypto assets. This will further incentivize ownership in LOKI and reduce LOKI on the open market.
Provide a DEX that people will actually use.
The main reason why there are no working DEX is that there is no real need for a DEX. Presently, there is no real use of cryptocurrency other than trading back and forth between currencies as a way to rate the potential of different projects. Cryptocurrencies represent the possible potential of a decentralized financial system in the far future. Centralized exchanges provide the ability to trade cryptocurrencies far better than any DEX ever will.
The LOKI.network provides privacy. This is a real service that many people will happily pay to use. As individuals use the LOKI.network they will appreciate the service of the LOKI DEX even if it is only a limited marketplace. The LOKI DEX provides the ability to buy SILFR or LOKI which gives them access to the LOKI.network. In time the LOKI DEX will develop increased liquidity and take on the form of a proper exchange.
The LOKI DEX is private and will provide all of the security of a DEX. Individuals will own coins instead of loaning them to the centralized exchange hoping to receive a better return through trading and buying fees for trading. The LOKI DEX will have enough liquidity to buy LOKI or SILFR and give use of the LOKI.network. Users who value privacy will simply prefer to use the LOKI.DEX to buy LOKI or SILFR and support the LOKI.network.
===========================
Section 6: Difficulties
===========================
100 Day depreciation of SILFR as an asset.
At first, this is a difficult concept to understand or appreciate. It is easy to ask, "Why would anyone want to own an asset that depreciates to 0 value in 100 days?" And the answer is, "Of course no one wants to own this asset, therefore they  are highly motivated to trade this asset to one that holds value." And it is this degree of motivation which provides the necessary force for SILFR to be successful.
Money is only useful when it is being exchanged regardless of  it being exchanged for goods,  services or time value. Money is not useful just sitting around. SILFR will be completely necessary for USERs of the LOKI network, yet it will depreciate rapidly. Therefore anyone who owns SILFR will be highly motivated to purchase something with it as soon as possible regardless of how poor of a price that they are receiving. Anything is better than nothing.  And because someone is continually purchasing something, there will be increased liquidity. Because there is liquidity, someone will offer something better at a higher price. And this activity will develop an effective market that everyone will prefer to use instead of centralized exchanges.
Access Point security.
SILFR depends on access point security. The data traffic at an access point has to be measured for quality without being measured for direction or contents. I do not know how difficult this would be to accomplish in a secure manner. SILFR would facilitate this by paying SN and EN for quantity of traffic, therefore traffic does not have to be tracked back to the USER and divulge his location.
It is also necessary to be able to determine if traffic across a USER access point is from a SNApp on the LOKI.network or the open internet. This capability helps to increase the traffic from the SNApp Providers. It may be easier to flag traffic from SNApp providers instead of determining traffic from the open internet.
Incorporating this plan on the LOKI.network without a second currency.
It would be possible to incorporate parts of this plan without a second currency. For example, the LOKI team could devise a method of staking LOKI and providing access to the LOKI.network. But sooner or later you would need a way to financially incentivize the network to optimize the network and increase security.
Smart Contracts.
SILFR is not a system for Smart Contracts. From what I have heard from the LOKI dev team, they feel that smart contracts are a creation of the cryptocurrency community that do not solve any problems of the real world. SILFR is not designed to facilitate Smart Contracts. But SILFR could be used as a way to pay for smart contracts if the LOKI DEV team ever decides to develop this functionality. NEO uses NEO GAS to power its smart contracts. In a similar way, LOKI could create a third crypto currency that facilitates smart contracts and use SILFR to power the contracts. This new currency would incorporate the idea of staking LOKI to receive SILFR inside the contract. Then the contract would automate the payment of SILFR for the use of the LOKI.network. Because a payment is involved, this would decrease the unwanted crypto kitties and other parasitic behavior. This would also create the capability to sell contracts with staked LOKI and other cryptocurrency/financial derivatives over the LOKI DEX.
===========================
Section 7: Conclusion
===========================
This proposal has been prepared to describe SILFR in as short a proposal as possible. Although the idea of SILFR is simple, the implementation and working system is quite sophisticated. I have written more material that describes SILFR. If the LOKI development team finds this interesting and would like to learn more, please let me know. If you are not interested and would like me to remove this proposal, please let me know or just block it from your side. I am interested in working together.
Please report any spelling or grammatical errors and please ask any questions. I may have misstated something or perhaps I can rewrite something to clarify what I envision.
Thank you for reading this proposal!
===========================
Section 8: Payment
===========================
I hope to be paid for this design. I know that if this proposal is implemented this design would become extremely important to the LOKI project. I recognize that the LOKI development team is also inventing solutions that may be more effective or even similar to this proposal. The LOKI leadership and all members of the team have continually demonstrated honest and ethical behavior.  I ask that if LOKI development incorporates any aspects of this design, that the LOKI foundation pays me for my ideas in whatever way that they consider appropriate.

Hey @William-E-Coyote , Thanks for your effort in compiling this proposal, we have been thinking about about the idea of staking Loki to gain access to the services inside the Loki network since the beginning of the projects inception.
However we have consistently decided against this approach because of the difficulty to onboard users into the Loki cryptocurrency. It is extremely hard to onboard users to applications where they need to KYC with an exchange to Buy bitcoin in their nationalized currency, transfer that Bitcoin to a Loki accepting exchanges, setup a Loki wallet, Buy Loki with Bitcoin on an exchange, transfer that Loki to a wallet and Stake it. When you compare this user experience with that of Tor or Signal which only require you to download an application and run you can get a sense of the difficult of onboarding.
This is why we intend to go with the approach of providing additional perks alongside the Loki.network suite (Like LNS) that burn Loki to use. This way the users who really enjoy the product after using it can opt into the difficult process of acquiring Loki.

@loki-project thank you for your immediate feedback. I recognize your concerns and clarified the first paragraph. I also added a section on Implementation.
The first paragraph now states:
This is a proposal to implement SILFR, a cryptocurrency that is designed to function as a payment system for data transfer over the LOKI.network. This system should not interfere with the user experience of using Session or accessing SNApps on the LOKI.network. The driving idea of the design of SILFR is that a USER with LOKI in their wallet can use the LOKI.network Exit Nodes (EN) free of charge. Instead of paying for use of the LOKI.network EN with LOKI or some other cryptocurrency, they will simply stake LOKI for a limited time. This is the same as staking LOKI to a SN and receiving block rewards. Instead of rewards, the USER is receiving access to the services of the LOKI.network.
and
===========================
Section 7: Implementation
===========================
This proposal represents a significant amount of work for the LOKI development team to accomplish. I realize that there may be more effective solutions to the problems I defined and there may be a significantly more robust set of problems that I do not understand. The LOKI development team will take a considerable amount of time considering easier solutions before they would begin to implement this solution. But if the development team decides to implement this solution, then it will have to be accomplished in a careful manner that does not interrupt the present network.

Develop access points that have the ability to quantify the volume of data without exposing user privacy.

Install these access points on USER access Points, SN, and EN, then begin to understand how data flows through the LOKI.network.

Develop a second cryptocurrency that meets the needs of the network. (SILFR)

When SILFR is first deployed it will have minimal or no value and will simply be a placeholder.

When the LOKI.network begins to demonstrate difficulty transferring an increased amount of network traffic, there will already be a system in place to throttle the traffic and optimize the network.

Everything up to this point could be invisible to the USER.

SILFR and the LOKI DEX would only be fully deployed when it becomes necessary to throttle EN traffic and/or optimize the LOKI.network.


Extract instrumentation agent supporting code out of :core and :integ-test

Quick overview of changes:

New subproject :instrumentation-agent-services is introduced to hold agent-related code.
Code from :core that resided in org.gradle.internal.agents moved to the new project with org.gradle.internal.instrumentation.agent package. We don't use agent for anything but the instrumentation anyway.
AgentApplicationTest moved from :integ-test to the new :instrumentation-agent-services too.
InstrumentingClassLoader interface residing in :base-services moved from org.gradle.internal.agents to org.gradle.internal.classloader, closer to the classloader implementations. It is not possible to easily move it to the new project and inverse the dependency without making the whole :instrumentation-agent-services Java 6-compatible. Extracting instrumented classloader implementation out of base-services is even more involved.
The rest are dependency and import updates.

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test this without PTS

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

The merge queue build has failed. Click here to see all failures.

WARN: The milestone of this PR is 8.10 RC1, but the base branch version is 8.9

WARN: The milestone of this PR is 8.10 RC1, but the base branch version is 8.9

Nice!


Show a screen for "no media query"

Since I usually do things mobile-first, it'd be awesome to have one default small screen (maybe 360 in width, which might be configurable) on the far left.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3060946-show-a-screen-for-no-media-query?utm_campaign=plugin&utm_content=tracker%2F3374384&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F3374384&utm_medium=issues&utm_source=github).

In v2 there’s a default view if breakpoints list is empty


Switch to go 1.23

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Switch to go 1.23.
Which issue(s) this PR fixes:

None
Does this PR have test?
None

Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

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

Project coverage is 42.08%. Comparing base (11d77f4) to head (74b2a24).
Report is 391 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2413      +/-   ##
==========================================
- Coverage   45.50%   42.08%   -3.42%
==========================================
  Files          79      109      +30
  Lines        7782    15916    +8134
==========================================
+ Hits         3541     6698    +3157
- Misses       4099     8722    +4623
- Partials      142      496     +354

/retest

/test pull-security-profiles-operator-build
/test pull-security-profiles-operator-build-image
/test pull-security-profiles-operator-test-unit
/test pull-security-profiles-operator-verify

Looks like pull-security-profiles-operator-verify hangs.
/hold

/unhold
@kubernetes-sigs/security-profiles-operator-maintainers PTAL

/lgtm


Add YOLOv3 to model zoo

Issue Description
YOLOv3 weights are now available, with a couple of Keras conversions in the wild:

https://github.com/xiaochus/YOLOv3
https://github.com/qqwweee/keras-yolo3

Version Information
v1.0.0-snapshot

any work in this issue


Search returning incorrect results after migration to latest version

I had an old version of pgstac running, which I have just upgraded to the latest version. Since then, I've found that some of the search queries I've run have returned incorrect results. I actually found the incorrect results when querying using stac_fastapi, but I've checked by running queries using the underlying pgstac SQL functions and have found that they are returning incorrect results, which are then just displayed by stac_fastapi).
For example, when running the query:
SELECT * FROM pgstac.search('{"collection":"test-bec-4"}'::jsonb)

I get a JSON result which starts like this:
{
  "next": "N51E000.tif",
  "prev": null,
  "type": "FeatureCollection",
  "context": {
    "limit": 10,
    "returned": 10
  },
  "features": [
    {
      "id": "core-4",
      "bbox": [
        35,
        19.3,
        35,
        19.3
      ],
      "type": "Feature",
      "links": [
        {
          "rel": "self",
          "href": "http://localhost/test.tif",
          "type": "application/json"
        }
      ],
      "assets": {},
      "geometry": {
        "type": "Point",
        "coordinates": [
          35,
          19.3
        ]
      },
      "collection": "test-anglo-cores-3",
      "properties": {
        "datetime": "2020-02-08T11:23:00Z",
        "core-type": "shallow",
        "last-reviewed": "2021-03-19"
      },
...

In that returned JSON, it lists the collection as test-anglo-cores-3 not test-bec-4.
Running
SELECT * FROM items WHERE collection_id = 'test-bec-4'

gives me 100 results, which is the correct number - and shows that there are items in the database with that collection ID. I've also checked the content field of the items table, and in there the collection is also specified correctly as test-bec-4.
I have no idea how to go forward with debugging this, as my SQL skills are quite limited. Any help would be very much appreciated.

A few more pieces of information that may be useful:

The collection I was querying for (test-bec-4) was added after the migration
The items that were incorrectly returned were added to the database before the migration
I've created a new database at the latest version and added my new test-bec-4 items and the search is giving the correct results

Hey @robintw which version was working? and by latest you mean v.0.4.3?

Yup, I upgraded to 0.4.3.
Before that I was running 0.3.4.

A bit more investigation has shown that this seems to be occurring for the latest version that I created from scratch (ie. without migrating from an old version) as well: I'm still getting entries from other collections appearing in the results for a search by collection.
I think for the moment I'm going to create another database using version 0.3.4 and stick with that for the moment, but it'd be good to get some ideas as to what is going on here, as it's scaring me a bit!

Thanks, I hadn't realised that change had occurred.
I've done some more investigation and I'm still having some problems.
Running this query:
SELECT * FROM pgstac.search('{"collections": ["test-bec-4"], "limit": 10, "filter-lang": "cql-json", "fields": {"include": [], "exclude": []}}'::jsonb)

gives the correct results - by setting filter-lang explicitly in the JSON.
However, setting it in the pgstac_settings table doesn't seem to have any effect. For example:
select * from pgstac_settings;

gives the following results:
"context_estimated_count"	"100000"
"context_estimated_cost"	"1000000"
"context_stats_ttl"	"1 day"
"default-filter-lang"	"cql-json"
"context"	"on"

but running the query as:
SELECT * FROM pgstac.search('{"collections": ["test-bec-4"], "limit": 10, "fields": {"include": [], "exclude": []}}'::jsonb)

that is, without the explicit passing of filter-lang gives results that include all collections.
Is there any way for me to debug this to see why the setting isn't being used?

Thanks @bitner - the PR seems to have fixed things, but I'm still concerned that setting default-filter-lang in the pgstac settings table doesn't seem to have had any effect on which filter lang is used. Do you have any ideas on this?


chore: Move RLS to src/pages folder

SUMMARY
Moved RowLevelSecurityList to src/pages folder to apply the direction outlined in https://github.com/apache/superset/discussions/22330
This work is part of SIP-61
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@michael-s-molina @lyndsiWilliams Can you review it?

@EugeneTorap The only files that should go into src/pages are index.tsx and RowLevelSecurityList.test.tsx


settings: fix settings_line_val_get_len while base64 encoding is enabled

While base64 encoding was enabled settings_val_get_len_cb() returned
encoded length instead of decoded value length.
This patches introduce procedure which calculates the value length
properly. For that additional read of the end of the encoded value is
required for checking how many form last 3 value bytes wear encoded.
fixes #12122
Signed-off-by: Andrzej Puzdrowski<EMAIL_ADDRESS>

Codecov Report

Merging #12213 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12213   +/-   ##
=======================================
  Coverage   48.25%   48.25%
=======================================
  Files         293      293
  Lines       44130    44130
  Branches    10591    10591
=======================================
  Hits        21296    21296
  Misses      18567    18567
  Partials     4267     4267

Continue to review full report at Codecov.

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

LGTM


App still detecting root / emulator

App:
de.payback.android.client -> https://www.apkmirror.com/apk/payback/payback-deutschlands-grostes-bonusprogramm/
OS tested:
Android 7, 8, 9, 10, 11
Until version 23.02.2100 the app ran fine, without any noticeable anti root / emulator stuff.
Every version after that does not run anymore on Android Studio Emulator.  Would be most interested in version from 24.01.1800 forward (new API)
Edit: Also, what is the Difference between WR and WOR Apks?

UP

Hi @hrylx,
The application you mentioned appears to have tamper detection and verifies the app's signature.


FEAT: Use conda zig rather than upstream binary dist

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin rerender

@xmnlab I removed the dependencies on the upstream binaries. In the pipeline, I plan to transition to revisit the windows build, I seem to make progress with the latest gcc 13. Also, it'll be good to use cmake, but @xhochy has not yet greenlighted the use of a local qemu with execve() intercept.

@xmnlab I removed the dependencies on the upstream binaries. In the pipeline, I plan to transition to revisit the windows build, I seem to make progress with the latest gcc 13. Also, it'll be good to use cmake, but @xhochy has not yet greenlighted the use of a local qemu with execve() intercept.

It's not the best, but for now I don't see a good alternative and don't have time to investigate myself: so go ahead!

It's not the best, but for now I don't see a good alternative and don't have time to investigate myself: so go ahead!

Would it be slightly better to make a separate qemu-execve recipe that other maintainer facing the same issue could use. Ideally, it would be used sparingly, only when the qemu-static already available is not working.


rbenv update

Should we have an rbenv update command? /cc @rkh
It would work only if RBENV_ROOT is where rbenv is installed, and if it's a git repo.
I think it might be useful, considering the slow release cycle, and especially now that we have rbenv --version capable of displaying edge versions from git.

@mislav , if it's okay - I recommend that we "get inspired" from pyenv's update plugin. Pyenv folks are nice and they consider rbenv{,-build} as upstream. So it will be a nice fit.
I have also read through the pyenv-update bash script and I think it's pretty solid in terms of quoting things, and making sure things don't blow up. We just need to change few variables from PYENV_ROOT to RBENV_ROOT.
Do you want it to be part of rbenv core or as a separate plugin? In either case, I will be happy to submit a PR/repo.

I've started to use basher to manage these tools.
Otherwise, my +1 is for what @wadkar said; a rbenv-update plugin.

Every time I run rbenv instlal <new_version> and I get this message I think:

We're so, so close to a nice experience for Ruby upgrades, it's really a shame rbenv doesn't just run this update in the background

ruby-build: definition not found: 3.0.1

See all available versions with `rbenv install --list'.

If the version you need is missing, try upgrading ruby-build:

  git -C /Users/olivierlacan/.rbenv/plugins/ruby-build pull

Having to run git pull is not the end of the world, but considering a tool like Homebrew routinely does it behind its own commands, it would really make a ton of sense to just run it (and be clear that rbenv is running a git pull).

@olivierlacan I do believe that this should be easier for the user, and what you're suggesting sounds completely reasonable.
However, there's something that feels slightly risky about software that updates itself by itself without any intervention from the user—especially when the software has never done so before. I'm not sure if we should alienate our users' trust by automatically updating ruby-build on every rbenv install.
I like the approach of ruby-install (an alternative to ruby-build): they are able to install new Ruby versions as they come out without having to upgrade ruby-install itself: https://github.com/postmodern/ruby-install#anti-features

re: auto-updating
I really like this idea. Given that the rbenv-update plugin exists, but there hasn't been any movement to pull it into core, this feels like the perfect feature to add to the plugin itself.
ruby-build's rbenv-install subcommand executes before and after install hooks. It seems feasible that the rbenv-update plugin could add an install hook to run itself. (Perhaps even guarded by an opt-in environment variable to avoid being a breaking change?)

FWIW while I still use rbenv, I semi-automatically update it a ruby-build via homebrew now, and thus don't actually use rbenv-update myself anymore. I am happy to offer maintenance/commit rights if someone wants to (ideally someone using it) or have it output some message if it is no longer useful.

@rkh I believe I still have commit rights on that repo so if someone tackles a PR, I could handle reviewing and releasing.

I think the concern about self-updating can be handled by a prompt.

3.0.1 is available but rbenv needs to update itself in order to install it, is that ok? Yes/No

@jasonkarns I’m down !

I realize saying this out loud how much is involved for this to happen. And I'm a bit exhausted, but does that even still sound like something reasonable @mislav?

Thanks for thinking long and hard about this. Yes, this does sounds like something that could improve the user experience when installing new versions. However, I would not couple this to rbenv-update, since rbenv-update updates rbenv and all its plugins, and we're only interested in updating ruby-build. So I would move this conversation to ruby-build, add an auto-updater there (we don't even need a hook; we could just bake it into rbenv-install). Of course, the whole thing would only work if ruby-build was installed via git.
I would also avoid a prompt, because prompts are annoying, so if someone checked out ruby-build via git, we can just assume that they don't mind if we fast-forward it to the latest version.

rbenv update would be nice to jump to the latest stable of the current channel which is part of rbenv versions. I came up with my own solution, that looks like this:
current_ruby_version=$(rbenv global)
installed_ruby_versions=($(rbenv versions | awk -F "[ ]+" '/ /{print $2}'))
available_ruby_versions=($(rbenv install -l 2>/dev/null))

echo "[o] Upgrading Ruby builds ..."

for installed in "${installed_ruby_versions[@]}"; do
	if [ "$installed" = "system" ]; then
		continue
	fi
	for available in "${available_ruby_versions[@]}"; do
		if [ \
			"$(echo $installed | tr '.' '\n' | head -2)" \
			= \
			"$(echo $available | tr '.' '\n' | head -2)" \
			]; then
			rbenv install $available
			# TODO: Install all global packages from $installed to $available
			if [ "$current_ruby_version" = "$installed" ]; then
				rbenv global $installed
			fi
			rbenv uninstall $installed
		fi
	done
done

The issue is that I lose my globally installed packages. nvm provides a flag to reinstall packages from another version.
Since rbenv update seems to have not made it for a decade now, why not providing such a flag at least?

Closing in favor of either manually updating using git -C ~/.rbenv pull or using https://github.com/rbenv/rbenv-installer as an idempotent install+update mechanism.


redirect edit of intro/links directly to profile page of elements

Can you make it land on the profile in edit mode (em=true)?
Also, have it open in a new tab, not in the same window.

@Vensberg
I can adjust that. Do you want editing Roles and Name to also open in new tab?

@UcDust yes, please. Just to confirm, for now Roles and Names stay with ODR.

@UcDust will do, and yes that's correct.

@Vensberg this should be ready for review on test.

@UcDust ---looks good

[x] opens in a new tab
[x] opens Elements profile in edit mode


add enhanced metrics: invocations and errors

What does this PR do?
Adds the enhanced metrics of aws.lambda.enhanced.invocations and aws.lambda.enhanced.errors and the respective tags from the Lambda Context. This includes the custom tag of  cold_start:true|false.
Testing Guidelines
Includes unit tests for proper grabbing of enhanced metric tags, and for submission of the metric to a host/site.

Codecov Report

Merging #25 into master will increase coverage by 0.19%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
+ Coverage   88.59%   88.78%   +0.19%
==========================================
  Files          12       12
  Lines         526      553      +27
==========================================
+ Hits          466      491      +25
- Misses         45       47       +2
  Partials       15       15

Impacted Files
Coverage Δ

internal/metrics/listener.go
95.83% <100%> (+1.49%)
:arrow_up:

internal/wrapper/wrap_handler.go
100% <100%> (ø)
:arrow_up:

ddlambda.go
76.11% <100%> (+1.11%)
:arrow_up:

internal/metrics/processor.go
94.44% <0%> (-2.78%)
:arrow_down:

Continue to review full report at Codecov.

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


Add -RecreateTimeSeries option to LocationDeleter

This would function like the -RecreateLocations option, but for time-series.
Recreate any basic or reflected time-series with the same configuration and metadata, but no points.
Not sure if this could be done for derived time-series.

Closing, won't do right now.


Error when run python og_marl/tf2/systems/iql_cql.py

Hello,
I am very interested in your outstanding work, but I encountered a minor issue while attempting to reproduce it. I followed the steps in your Readme to configure the environment as follows:
git clone https://github.com/instadeepai/og-marl.git
pip install -r requirements.txt
pip install -e .
bash install_environments/smacv1.sh
pip install -r install_environments/requirements/smacv1.txt

All configurations were completed successfully. However, when I tried to run
python og_marl/tf2/systems/iql_cql.py task.source=og_marl task.env=smac_v1 task.scenario=3m task.dataset=Good

I received the following error:
2024-10-29 13:56:20.393968: I tensorflow/core/util/port.cc:113] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
2024-10-29 13:56:20.433449: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:9261] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-10-29 13:56:20.433491: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:607] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-10-29 13:56:20.434731: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1515] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-10-29 13:56:20.441134: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 AVX512F AVX512_VNNI FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-10-29 13:56:21.266027: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
2024-10-29 13:56:22.862481: I external/local_xla/xla/stream_executor/cuda/cuda_executor.cc:901] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero. See more at https://github.com/torvalds/linux/blob/v6.0/Documentation/ABI/testing/sysfs-bus-pci#L344-L355
2024-10-29 13:56:22.906527: I external/local_xla/xla/stream_executor/cuda/cuda_executor.cc:901] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero. See more at https://github.com/torvalds/linux/blob/v6.0/Documentation/ABI/testing/sysfs-bus-pci#L344-L355
2024-10-29 13:56:22.906887: I external/local_xla/xla/stream_executor/cuda/cuda_executor.cc:901] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero. See more at https://github.com/torvalds/linux/blob/v6.0/Documentation/ABI/testing/sysfs-bus-pci#L344-L355
{'system_name': 'iql+cql', 'seed': 42, 'wandb_project': 'og-marl', 'training_steps': 100000.0, 'task': {'source': 'og_marl', 'env': 'smac_v1', 'scenario': '3m', 'dataset': 'Good'}, 'replay': {'sequence_length': 20, 'sample_period': 1}, 'system': {'learning_rate': 0.0003, 'linear_layer_dim': 64, 'recurrent_layer_dim': 64, 'discount': 0.99, 'target_update_period': 200, 'add_agent_id_to_obs': True, 'cql_weight': 3.0}}
/root/miniconda3/envs/ogmarl/lib/python3.10/site-packages/flashbax/buffers/trajectory_buffer.py:473: UserWarning: Setting max_size dynamically sets the `max_length_time_axis` to be `max_size`//`add_batch_size = 50000`.This allows one to control exactly how many timesteps are stored in the buffer.Note that this overrides the `max_length_time_axis` argument.
  warnings.warn(
/root/miniconda3/envs/ogmarl/lib/python3.10/site-packages/flashbax/buffers/trajectory_buffer.py:498: UserWarning: `sample_sequence_length` greater than `min_length_time_axis`, therefore overriding `min_length_time_axis`to be set to `sample_sequence_length`, as we need at least `sample_sequence_length` timesteps added to the buffer before we can sample.
  warnings.warn(
[2024-10-29 13:56:23,154][jax._src.xla_bridge][INFO] - Unable to initialize backend 'cuda':
[2024-10-29 13:56:23,154][jax._src.xla_bridge][INFO] - Unable to initialize backend 'rocm': module 'jaxlib.xla_extension' has no attribute 'GpuAllocatorConfig'
[2024-10-29 13:56:23,155][jax._src.xla_bridge][INFO] - Unable to initialize backend 'tpu': INTERNAL: Failed to open libtpu.so: libtpu.so: cannot open shared object file: No such file or directory
[2024-10-29 13:56:23,156][jax._src.xla_bridge][WARNING] - An NVIDIA GPU may be present on this machine, but a CUDA-enabled jaxlib is not installed. Falling back to cpu.
Dataset from https://huggingface.co/datasets/InstaDeepAI/og-marl/resolve/main/core/smac_v1/3m.zip could not be downloaded. Try entering a different URL, or removing the part which auto-downloads.
Error executing job with overrides: ['task.source=og_marl', 'task.env=smac_v1', 'task.scenario=3m', 'task.dataset=Good']
Traceback (most recent call last):
  File "/root/autodl-tmp/og-marl/og_marl/tf2/systems/iql_cql.py", line 273, in run_experiment
    buffer.populate_from_vault(cfg["task"]["source"], cfg["task"]["env"], cfg["task"]["scenario"], cfg["task"]["dataset"])
  File "/root/autodl-tmp/og-marl/og_marl/replay_buffers.py", line 99, in populate_from_vault
    self._buffer_state = Vault(
  File "/root/miniconda3/envs/ogmarl/lib/python3.10/site-packages/flashbax/vault/vault.py", line 169, in __init__
    raise ValueError(
ValueError: Vault does not exist and no experience_structure was provided.

Set the environment variable HYDRA_FULL_ERROR=1 for a complete stack trace.

I suspect the issue may stem from my use of CUDA 12.1. When I attempted to update certain packages, such as via
pip install --upgrade "jax[cuda]" -f https://storage.googleapis.com/jax-releases/jax_cuda_releases.html

I encountered environment conflicts.
Therefore, I am reaching out to kindly ask for your guidance in resolving this issue.
Thank you very much!

Hi there, thank you so much for reaching out. I am happy to help. I think the problem is actually that the dataset was downloaded to the wrong directory. This is the important part of the error:
ValueError: Vault does not exist and no experience_structure was provided.
You should have a directory called vaults/og_marl/smac_v1/3m.vlt/Good/.
Do you have such a directory? Take careful note of the .vlt after 3m. This directory should have been downloaded when you ran the script. But maybe the script has a but, I will check.

As an aside, I recommend not downloading the "cuda" version of Jax. We only use Jax for the replay buffer, so the CPU version is fine. Rather download the "cuda" version of Tensorflow (which is what we have in the requirements file). Having the cuda version of both Jax and TF is possible but can easily result in dependency conflicts.

Thank you so much for your help! Your response resolved a major issue for me. When I ran examples/download_dataset.py, I was able to download the data, and the problem was completely resolved. Thanks again for your assistance!

That's great! Don't hesitate to ask any further questions! I am happy to help!


Fix 'An error occurred when loading todomvc.core.js'

Upgraded shadow-cljs to 2.12.5

Thanks @brandon-atkinson 👍🏻 😄


How to update Osiris.dll myself if CSGO is updated

If CSGO is updated, how should I update it to adapt to the new version。

If Osiris is not working anymore due to a CS:GO update, stop using it and constantly check the latest Osiris updates, here: https://github.com/danielkrupinski/Osiris/commits/master
When you see that Osiris has been updated (this usually takes a few hours), you download it again and rebuild it.