text:
Cluster-level errors not marshalled as expected

When metastore errors pass from node-to-node, they are not marshalled in a way that allows the code on the receiving node to check types. The patch below shows this:
$ git diff
diff --git a/cmd/influxd/run/server.go b/cmd/influxd/run/server.go
index 0d23c0f..ac1b521 100644
--- a/cmd/influxd/run/server.go
+++ b/cmd/influxd/run/server.go
@@ -357,6 +357,12 @@ func (s *Server) Open() error {
                // Wait for the store to initialize.
                <-s.MetaStore.Ready()

+               if _, err := s.MetaStore.CreateDatabaseIfNotExists("testdb"); err != nil {
+                       fmt.Printf("create database failed: %s %T\n", err.Error(), err)
+               } else {
+                       fmt.Println("creation of testdb went fine")
+               }
+
                if err := s.Monitor.Open(); err != nil {
                        return fmt.Errorf("open monitor: %v", err)
                }
diff --git a/meta/store.go b/meta/store.go
index b2edf62..9a6aabe 100644
--- a/meta/store.go
+++ b/meta/store.go
@@ -897,13 +897,6 @@ func (s *Store) CreateDatabase(name string) (*DatabaseInfo, error) {

 // CreateDatabaseIfNotExists creates a new database in the store if it doesn't already exist.
 func (s *Store) CreateDatabaseIfNotExists(name string) (*DatabaseInfo, error) {
-       // Try to find database locally first.
-       if di, err := s.Database(name); err != nil {
-               return nil, err
-       } else if di != nil {
-               return di, nil
-       }
-
        // Attempt to create database.
        di, err := s.CreateDatabase(name)
        if err == ErrDatabaseExists {

The first change attempts to create a database if it does not already exist. The second change forces the system to check the actual error that comes back from the cluster. This check doesn't actually work, and when a second node starts up, it spits out the following error:
create database failed: exec failed: apply: database already exists *errors.errorString
This is the simple "string" version of the error, not the type.
I guess this should be expected, since the code just stores errors as strings, as far as I can see. Either we marshal the actual type, or the code must start checking error message strings in the protobuf code. In other words, the error that comes across the wire from the leader is not of ErrDatabaseExists type.

@benbjohnson @jwilder

From @benbjohnson: we should either serialize errors using protobufs or look them up by string when they arrive remotely. it’s nice to be able to check against a reference (e.g. ErrDatabaseNotFound).

@benbjohnson suggested the following:
i was thinking of keeping it simple and matching on string. maybe have a meta.Error type that automatically adds to a map when instantiated:
type Error struct {
s string
}
func (e Error) Error() string { return e.s }
var errorMap = make(map[string]*Error)
func NewError(s string) *Error {
e := &Error{s: s}
errorMap[s] = e
return e
}
then errors could be defined as:
var ErrDatabaseNotFound = NewError(“database not found”)
then we can check against errorMap when unmarshaling.

Turns out we're already doing something quite similar here: https://github.com/influxdb/influxdb/blob/master/meta/errors.go#L114
So this code is either failing because the lookup isn't working or because this slice hasn't been maintained correctly: https://github.com/influxdb/influxdb/blob/master/meta/errors.go#L97
If we move to what @benbjohnson suggests, the system will probably be more maintainable going forward.

source: gharchive/issue

license: mit

license_type: permissive

license_source: bigquery


text:
Use workspace dependencies

Closes: #3104
Description
according to rust verison 1.64.0 https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds , we can use this feature.

PR author checklist:

[x] Added changelog entry, using unclog.
[ ] Added tests: integration (for Hermes) or unit/mock tests (for modules).
[x] Linked to GitHub issue.
[ ] Updated code comments and documentation (e.g., docs/).
[ ] Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

[ ] Reviewed Files changed in the GitHub PR explorer.
[ ] Manually tested (in case integration/unit/mock tests are absent).

Great stuff, I have been meaning to do this for a while so thanks a lot for doing this! We'll wait a bit to merge this until we get in a couple of open PRs which introduce new or updates dependencies.

@DaviRain-Su Do you know if Dependabot is able to deal with workspace dependencies?

@DaviRain-Su Do you know if Dependabot is able to deal with workspace dependencies?

oh, not very clear. I have seen several projects do this.

aptos: https://github.com/aptos-labs/aptos-core/blob/main/Cargo.toml
subxt: https://github.com/paritytech/subxt/pull/832

@DaviRain-Su Do you know if Dependabot is able to deal with workspace dependencies?

https://github.com/paritytech/subxt/blob/master/.github/dependabot.yml Hi, I noticed that Subxt is also using a workspace, and upon reviewing the dependably.yml file, it doesn't require any changes. It seems like this issue can be resolved now.

source: gharchive/pull-request

authors: DaviRain-Su romac

repo: informalsystems/hermes

license_source: github-api


text:
Hermes may break the max_tx_size configuration param

Summary of Bug
When we batch messages in a Tx we may exceed the max_tx_size if max_msg_num is not hit. The problem code is here:
https://github.com/informalsystems/ibc-rs/blob/1d188187721051a34d20841c0146b8c16b5b413b/relayer/src/chain/cosmos/batch.rs#L152-L157
We keep in the batch the msg that caused the crossing of max_tx_size.
It becomes an issue with chains like osmosis where Tx-es with size bigger than some threshold may be priced differently resulting in Tx simulation failure and no recovery (see https://github.com/informalsystems/ibc-rs/issues/2422, the threshold is exceeded with 3 msgs, one update client and two packet messages)
In addition, the actual Tx will be slightly bigger due to extra auth encoding and we should do something about it.

Version
all recent

Steps to Reproduce
The code is obviously wrong but:

add assert!(current_size < max_tx_size); after L154
configure hermes with:

max_msg_num = 50
max_tx_size = 15000

send 100 packets

Acceptance Criteria

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Since batch_messages is now a pure function, we should write some unit tests that test the behavior of batch_messages directly without having to run the full integration test.

Since batch_messages is now a pure function, we should write some unit tests that test the behavior of batch_messages directly without having to run the full integration test.

Thanks for reminding, it's good unit testable function indeed.

@mzabaluev I've started working on adding some unit tests

authors: ancazamfir mzabaluev seanchen1991 soareschen

repo: informalsystems/ibc-rs


text:
Further JSON test fixes required

Context
PR #267 introduces directory structure changes to the existing JSON tests.
Problem
This requires us to change the way these tests are run in Rust code because the older files no longer exist. What we have currently is configured to read big JSON files that deserialize into a vector of TestCase and we loop over them to run our tests. But now, we have split all these huge JSON files into multiple files such that each JSON file is a single TestCase. Now that there are so many files, it is messy to read each file manually and run test over it.
Proposed Solution
Configure Rust test to loop over these files instead of manually having to read each one of them.

I'll cherrypick the changes from #267 and delete the now obsolete test code. If there are new test-failures (e.g. https://github.com/informalsystems/tendermint-rs/pull/267#issuecomment-629222593), I'll "blacklist" those for now and fix them later.

From the description I was expecting that all these 4 tests fail:
./single_step/sequential/commit/one_third_vals_don't_sign.json
./single_step/sequential/commit/more_than_two_third_vals_sign.json
./single_step/skipping/commit/one_third_vals_dont_sign.json
./single_step/skipping/commit/more_than_two_third_vals_sign.json
Weirdly only the first currently fails.

repo: informalsystems/tendermint-rs


text:
Handle RID default function

In RBK, all the RID columns have the following value as default:
_ermrest.urlb32_encode(nextval('_ermrest.rid_seq'::regclass))
I think this is true for all deployments that use RID.
When we see /_ermrest.*\(\.)*/, maybe we can treat that as a function and not pass that to the default value.

My thoughts were that if we know a column of domain type RID will always be generated, then we can ignore setting the "default value" for that column.

Yes, that works.. RID will always be generated by the server.. So we can mark that as "auto-generated" and ignore default.

authors: hongsudt jrchudy

repo: informatics-isi-edu/ermrestjs


text:
🛑 Uvirtual is down

In fbd372e, Uvirtual (https://uvirtual.unimonserrate.edu.co/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Uvirtual is back up in 70dd8d6 after 13 minutes.

repo: infraestructuraidt/status

license: MIT


text:
🛑 Uvirtual is down

In 05a08d5, Uvirtual (https://uvirtual.unimonserrate.edu.co/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Uvirtual is back up in 52c8770.


text:
Expose base field type

Expose a type for the base field. It would reduce confusion- https://github.com/ingonyama-zk/icicle/issues/538
Describe the changes
This PR...
Linked Issues
Resolves #

Already exposed via point_field_t in https://github.com/ingonyama-zk/icicle/blob/main/icicle/include/curves/macro.h#L9

repo: ingonyama-zk/icicle


text:
macOS install?

openjournals/joss-reviews#6573
Hi, is it possible to get a working install recipe for macOS? Currently the Julia Pkg install fails out of the box on an M1 machine.
I noticed that macOS-latest is excluded from the OS matrix, https://github.com/iniyannatarajan/Anime.jl/blob/9f9423f955c18c525078c832a6f984e127777116/.github/workflows/ci.yml#L37C17-L37C29, and the documentation notes that Anime has been tested on Ubuntu Linux. It seem that casatools may have some issues with M1/2/3 machines, but that they also may be surmountable.

Hi, sorry for the delay. I do not have access to a Mac, but I have put together the following ci.yml based on what I can find online for Mac support:
name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains two jobs called "build" and "docs"
  build:
    name: Julia ${{ matrix.version }} - ${{ matrix.os }} - ${{ matrix.arch }} - ${{ github.event_name }}
    # defines the type of runner that the job will run on
    runs-on: ${{ matrix.os }}

    # defines matrix with a bunch of options
    strategy:
      matrix:
        version:
          - '1.10'
          - '1'
        os:
          - ubuntu-latest
          - macOS-latest
        arch:
          - x64
        python-version:
          - '3.8'
        exclude:
          - os: macOS-latest
          - arch: x86

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3

      # Sets up python environment
      - name: Setup python ${{ matrix.python-version }}
        uses: actions/setup-python@v4
        with:
          python-version: ${{ matrix.python-version }}
          architecture: ${{ matrix.arch }}

      # Sets up venv and installs python dependencies for macOS
      - name: Setup venv and install dependencies (macOS)
        if: runner.os == 'macOS'
        run: |
          arch -x86_64 python3.10 -m venv myvenv
          source myvenv/bin/activate
          arch -x86_64 python3 -m pip install --upgrade pip setuptools wheel casatools

      # Installs python dependencies for other OS
      - name: Install python dependencies
        if: runner.os != 'macOS'
        run: |
          python -m pip install --upgrade pip setuptools wheel
          python -m pip install casatools

      # Sets up Julia environment
      - name: Setup Julia ${{ matrix.version }}
        uses: julia-actions/setup-julia@v1
        with:
          version: ${{ matrix.version }}
          arch: ${{ matrix.arch }}
      - uses: julia-actions/julia-buildpkg@v1
        env:
          PYTHON: python

      # Run tests
      - name: Run tests
        uses: julia-actions/julia-runtest@v1

      - uses: julia-actions/julia-processcoverage@v1

      - name: Upload coverage reports to Codecov
        uses: codecov/codecov-action@v3
        env:
          CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}

I have modified the casatools installation instructions in the workflow file per this link.
Please let me know if this works for you. Otherwise I can add some pointers for Mac users in the official documentation.
Thanks!

Hi, I was just wondering if the above CI file was helpful. Please let me know if you have any difficulties installing or running the package.
Thanks!

I tried installing under the macOS x86 (Rosetta) version of Julia v1.10, but the CondaPkg pip environment only supports cp38-cp38-macosx_10_16 and earlier according to pip debug, while the pinned casatools 6.5.5.21 is only available for macosx_11_0.
I am able to directly pip install the following on M1 mac under the Julia x86 Conda environment,
casatools-6.5.1.23 numpy-1.24.4


text:
Why does the function with arguments have errors?

error C2660	“std::packaged_task<int (int)>::operator ()”: The function does not take zero arguments

#include "thread_pool.hpp"
#include  "thread"
#include "future"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;

int f(int j)
{
	return j;
}

int main(int argc, char **argv)
{
	tp::ThreadPool pool;
	//
	std::packaged_task<int(int)> t(f);
	std::future<int> r = t.get_future();
	pool.post(t);
	r.get();
	//while (1);
	getchar();
	return 0;
}

What's the right thing to do?

Use a lambda to decide how your function is going to be invoked. E.g.
pool.post([]{ t(5); });

Use a lambda to decide how your function is going to be invoked. E.g.
pool.post([]{ t(5); });

Just test pool.post([]{ t(5); }); code and there's an error occurred.
Error C3493: "t" cannot be caught implicitly because the default capture mode has not been specified
#include "thread_pool.hpp"
#include  "thread"
#include "future"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;
int f(int j)
{
return j;
}
int main(int argc, char **argv)
{
tp::ThreadPool pool;
//
std::packaged_task<int(int)> t(f);
std::future r = t.get_future();
pool.post([]{t(5);});
r.get();
//while (1);
getchar();
return 0;
}

You doing it wrong. Use something like that:
std::future<void> r;
std::packaged_task<int()> t([&]() { f(v_input); });
r = t.get_future();
pool.post(t);
r.wait();

PS. It tell you directly - ""t" cannot be caught implicitly because the default capture mode has not been specified". Specify capture mode in lambda.

You doing it wrong. Use something like that:
std::future<void> r;
std::packaged_task<int()> t([&]() { f(v_input); });
r = t.get_future();
pool.post(t);
r.wait();

PS. It tell you directly - ""t" cannot be caught implicitly because the default capture mode has not been specified". Specify capture mode in lambda.

Thank you so much for your reply ！
but, there are still some errors. compile environment vs2015
Error C2664 "STD: : function < _Ret (void) > : : function (STD: : function < _Ret (void) > &&)" :1 cannot be parameters from the "main: : < lambda_52a96aedc09236acf9c18022602966b7 >" into "STD: : nullptr_t ConsoleApplication4" c: \ program files \ Microsoft visual studio (x86) vc 14.0 \ \ include \ the future 582
#include "thread_pool.hpp"
#include "thread"
#include "future"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;
class cc{
public:
int f(int j)
{
return j;
}
};
int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;
std::future r;
std::packaged_task<int()> t(& {bind(&cc::f,&obj,1);});
r = t.get_future();
pool.post(t);
getchar();
return 0;
}

What would you like to achieve on so complex manner?
To post subroutine call to pool just enough to wrap it in lambda directly:
	pool.post(([=]() { f(j); }));

No future, no bind requires.
Also keep in mind: using future here lead to serialization and makes pool useless.

so, there are still some errors.please use the vs2015 run this code to see  your result.
**
Error C2664 "STD: : function < _Ret (void) > : : function (STD: : function < _Ret (void) > &&)" :1 cannot be parameters from the "main: : < lambda_52a96aedc09236acf9c18022602966b7 >" into "STD: : nullptr_t ConsoleApplication4" c: \ program files \ Microsoft visual studio (x86) vc 14.0 \ \ include \ the future 582
**

What would you like to achieve on so complex manner?
To post subroutine call to pool just enough to wrap it in lambda directly:
	pool.post(([=]() { f(j); }));

No future, no bind requires.
Also keep in mind: using future here lead to serialization and makes pool useless.

please,

Ah, vs2015. AFAIK this version does not fully C++11 compliant. Try to use more fresh compiler.
Unfortunately, I cant verify due to does not using Windows.

Use a lambda to decide how your function is going to be invoked. E.g.
pool.post([]{ t(5); });

Thank you so much for your reply ！but, there are still some errors.
how should I modify this code?
Error C2664 "STD: : function < _Ret (void) > : : function (STD: : function < _Ret (void) > &&)" :1 cannot be parameters from the "main: : < lambda_52a96aedc09236acf9c18022602966b7 >" into "STD: : nullptr_t ConsoleApplication4" c: \ program files \ Microsoft visual studio (x86) vc 14.0 \ \ include \ the future 582
#include "thread_pool.hpp"
#include "thread"
#include "future"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;
class cc{
public:
int f(int j)
{
return j;
}
};
int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;
std::future r;
std::packaged_task<int()> t(& {bind(&cc::f,&obj,1);});
r = t.get_future();
pool.post(t);
getchar();
return 0;
}

Your code produces syntax error:
test12.cc: In function 'int main(int, char**)':
test12.cc:21:13: error: missing template arguments before 'r'
std::future r;
^
test12.cc:22:31: error: expected primary-expression before '{' token
std::packaged_task<int()> t(& {bind(&cc::f,&obj,1);});
^
test12.cc:23:1: error: 'r' was not declared in this scope
r = t.get_future();
^
g++: error: test12.o: No such file or directory
g++: fatal error: no input files
To make it work it is enough to write:
#include "thread_pool.hpp"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;
class cc{
public:
int f(int j)
{
return j;
}
};
int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;
pool.post([&] { obj.f(5); } );
getchar();
return 0;
}

Your code produces syntax error:
test12.cc: In function 'int main(int, char**)':
test12.cc:21:13: error: missing template arguments before 'r'
std::future r;
^
test12.cc:22:31: error: expected primary-expression before '{' token
std::packaged_task<int()> t(& {bind(&cc::f,&obj,1);});
^
test12.cc:23:1: error: 'r' was not declared in this scope
r = t.get_future();
^
g++: error: test12.o: No such file or directory
g++: fatal error: no input files
To make it work it is enough to write:
#include "thread_pool.hpp"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;
class cc{
public:
int f(int j)
{
return j;
}
};
int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;
pool.post([&] { obj.f(5); } );
getchar();
return 0;
}

Thank you so much for your reply ！but, there are still some errors.
how should I modify The following code?
#include "thread_pool.hpp"
#include
#include
#include
#include
struct A {
int b(const int &p)
{
return p;
}
void c(int &i)
{
i = 43;
}
};
int main()
{
A a;
int i = 0;
tp::FixedFunction<int(const int &)> f(std::bind(&A::b, &a, i));
auto f1 = std::move(f);
tp::ThreadPool pool;

std::packaged_task<int(const int &)> t(f1);

std::future<int> r = t.get_future();

pool.post(t);
return 0;

}

Thank you so much for your reply ！but, big brother...  I want use std::packaged_task , std::future method.
so,What should I modify code?

Your code produces syntax error:
test12.cc: In function 'int main(int, char**)':
test12.cc:21:13: error: missing template arguments before 'r'
std::future r;
^
test12.cc:22:31: error: expected primary-expression before '{' token
std::packaged_task<int()> t(& {bind(&cc::f,&obj,1);});
^
test12.cc:23:1: error: 'r' was not declared in this scope
r = t.get_future();
^
g++: error: test12.o: No such file or directory
g++: fatal error: no input files
To make it work it is enough to write:
#include "thread_pool.hpp"
#include "functional"
#include "memory"
#include "iostream"
using namespace std;
class cc{
public:
int f(int j)
{
return j;
}
};
int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;
pool.post([&] { obj.f(5); } );
getchar();
return 0;
}

Using future is bad idea here, due to thread pool serialization. With this you pool will execute one task a time.

Using future is bad idea here, due to thread pool serialization. With this you pool will execute one task a time.

thanks for the warning，  But I still want to use std::future method... What should I do?

Using future is bad idea here, due to thread pool serialization. With this you pool will execute one task a time.

thanks for the warning， But I still want to use std::future method... How should I pass parameters?

Can't advice. I'm not a C/C++ programmer. :)

However, if you're insist....
#include "thread_pool.hpp"
#include
#include
#include
#include
class cc{
public:
static int f(int j)
{
return j;
}
};
int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;
std::packaged_task<int()> t(& { return obj.f(5); });
std::future r = t.get_future();
pool.post(t);
r.wait();
getchar();
return 0;
}
This works.

Thank you, you are a kind one.

If you're insist....On your responsibility:
#include "thread_pool.hpp"
#include <functional>
#include <memory>
#include <iostream>
#include <future>

class cc{
public:
static int f(int j)
{
return j;
}
};

int main(int argc, char **argv)
{
tp::ThreadPool pool;
cc obj;

std::packaged_task<int()> t([&]() { return obj.f(5); });
std::future<int> r = t.get_future();
pool.post(t);
r.wait();

getchar();
return 0;
}

This works.
Don't understand, why thread pool here... It will not work as pool. Just enough to use std::async.
But I'm not C/C++ programmer.

repo: inkooboo/thread-pool-cpp


text:
FIX: optional field without default value (#5031)

Pull request opened by the merge tool on behalf of #5031

Merged into branches iso5 in b3934d1ef2b0fc4ec672b10f4ca7c766d790ad9c

repo: inmanta/inmanta-core


text:
Issue/4337 scenario4 (#4537)

Pull request opened by the merge tool on behalf of #4537

Merged into branches iso5 in ffa4beb6bb425ac99908e9e2dca3f4f3b8f22533

repo: inmanta/web-console


text:
Problem using "_innative_funcptr"

Sorry for the cross-post with the Discord channel but I thought it might be better for InNative users to see this discussion here.
I am currently trying to get a pointer to a function that resides in a WASM module so that it can be called back by a C module. I used the "_innative_funcptr" function to get a C-style pointer from within my WASM module, but it always returns ERR_INVALID_ARGUMENT_TYPE instead of the expected pointer.
Tracing into the code, I found that the cast "auto v = llvm::dyn_cast<llvm::ConstantInt, llvm::Value>(params[0]);" done in "innative::code::IN_Intrinsic_FuncPtr" always failed.
Here is (part of) the WAT code I am using (made it dead simple while debugging, just trying to access the 7th function in the module - the "final" aim is actually to call another C-function with the correct i64 pointer as a parameter...).
  (type (;6;) (func (param i32) (result i64)))
  (type (;9;) (func (result i32)))
  (import "env" "_innative_funcptr" (func $_innative_funcptr (type 6)))

  (func $do_simple_test(type 9) (result i32)
    (local i32 i32)
    i32.const 0
    local.set 0
    i32.const 7
    local.set 1
    local.get 1
    call $_innative_funcptr
    drop
    local.get 0
    return)

It looks like LLVM does not consider the parameter passed to _innative_funcptr as a constant (which is not totally wrong!). However, I don't understand how to make this work - hope someone can help!

The issue is here:
    i32.const 7
    local.set 1
    local.get 1```
You essentially push a constant, use it to set a local, then get the local instead of the constant. Because it's a local, inNative can't prove that it was a constant, so LLVM correctly says it isn't a constant. `_innative_funcptr` is currently limited to pure constants because it can't resolve the function pointers at runtime, at least right now. I may add a metadata table to the binary to lift this requirement, but for the moment, you should simply do this:

(type (;6;) (func (param i32) (result i64)))
(type (;9;) (func (result i32)))
(import "env" "_innative_funcptr" (func $_innative_funcptr (type 6)))
(func $do_simple_test(type 9) (result i32)
(local i32 i32)
i32.const 0
local.set 0
i32.const 7
call $_innative_funcptr
drop
local.get 0
return)```

Thanks a lot for your prompt answer which confirms what I suspected (sorry for not finding the issue myself, I am not very familiar with WebAssembly yet !).
Now the issue I have is that the WAT excerpt I gave above was created by compiling some C code through clang + wasm-ld. I did many tests to get the result you suggest through this toolchain but without success. Would you have a suggestion about this?
Again, thanks a lot for your time!

If clang + wasm-ld is producing this code, then there is a transformation pass injecting unnecessary indirections somewhere and it's unlikely anything is going to be able to fix it. This means that I either have to create a pass in inNative that undoes this transformation, or allow non-constant values in the indirection.
If you know the constant value of the function you're trying to get, you could manually build a custom webassembly function that gets it for you by injecting something like:
(func $getfunc7 (result i32)
  i32.const 7
  call $_innative_funcptr
  return)

and then calling this function from whatever you're compiling. Unfortunately there's no way to do this in another module because the function pointer index is per-module.

To be honest it would help if in the end we could get the pointer by specifying the function name rather than its index (as you’d do in plain C when specifying a callback). That being said I am still in the prototyping stage of this project, checking if WASM through InNative can meet our requirements. Looks promising! :-)

Specifying the function name is problematic, because that function name technically doesn't exist in WASM. It is only an optional debug parameter that may or may not exist, and will be stripped when anything happens to drop the optional name section in the WASM module. The compiler is supposed to be figuring this stuff out for you, and should provide some way of getting the function index.

Do you mean that today’s compilers should already have what I need to solve this problem or that they will eventually when WASM gets more “standardised” interfaces?

I don't know if compilers are providing a way to do this, I suggest looking into it. If they don't there's very little that inNative can do because inNative is blind to the source language - it doesn't know what you're compiling so all it can do is look at the debug information, which may or may not exist at all.

Thanks again for your help - I’ll try to go forward from here and will report back about my findings! :-)

@EricSivilog While investigating this, it occurred to me that in order to provide an external function that is correctly wrapped for being called from C, this requires that the function be exported from the WASM module. However, if the function is exported from the WASM module, you could simply use LoadFunction to get a pointer to the function.
I believe the use-case here was that you want to load a webassembly module, which then returns a function pointer to an internal function that should be called by your C code. Could this module instead return a pointer to a string using cref as described in #23? This string could then be used to load the function using LoadFunction and remove the need for _innative_funcptr entirely.

@blackhole12 - Just to give you a more complete picture of what I am trying to achieve:

I have a Windows DLL which exports a function that takes a function pointer and calls it back at some point.
From my WASM module, I am calling this function with a function ptr which is actually turned into a function index (as expected).
I'd like to avoid changing the prototype of the function (because it's been used with a ptr for a long time so switching to a string that contains the function name would break a lot of existing code).

What I've been doing up to now to overcome the issue is to create a proxy DLL between the WASM module and the existing DLL, intercepting calls to this function. I then get the function index, and find its pointer through the "__indirect_function_table" table.
Hope that makes sense!

This function has been changed so that it will work without requiring a constant, and it will always return a pointer to a __cdecl wrapper function. However, it can still return NULL if you attempt to get a pointer to an imported function (because it doesn't know what calling convention it is). This restriction may be lifted in the future. Intrinsics are now also enabled on any sandboxing setting - you are instead required to use the whitelist to decide what intrinsics to expose to the webassembly module.

authors: EricSivilog ErikMcClure blackhole12

repo: innative-sdk/innative


text:
Prediction does not output a prediction path for obstacles

InnoSimulator Version 2020.1.5
Perception module in Apollo does not return any prediction path of the obstacles from Sim. Thus ego vehicle just ignore them in planning and make collisions.

Seems this issue is on Apollo side.

repo: inno-robolab/InnoSimulator


text:
feat(tf): use GitHub API to commit tf state in CI

If we are running a terraform apply from CI, the GH API will sign the commit for us.

@manveru, @dermetfan, not sure exactly what the CI error is, but the message in cicero shows something about an image, which seems unrelated to this change. I have already tested and confirmed that this still works both locally and in Mamba World CI so it should be safe to merge, but I'd love to have a green run anyway.

The CI error was likely corrupted podman zfs state again. I updated tullia and switched CI to use the exec driver so we avoid podman. It is now failing due to https://github.com/input-output-hk/bitte/pull/199 so you can rebase onto that when it's merged.

Already using this with success from a tag:
https://github.com/input-output-hk/mamba-world/commits/tf
The error still seems unrelated.

authors: dermetfan nrdxp

repo: input-output-hk/bitte


text:
check orphaned rewards

check that orphaned rewards are being inserted in the orphaned_reward table and not into the reward table.

most probable orphaned_rewards table will be removed at some point so we should not spend time on automating it for the moment;

this table would be removed

repo: input-output-hk/cardano-node-tests


text:
Alternative Retry when checking node api connection

#87
Context
Alternative, more chaotic version of #314
When starting a wallet we would see
[2019-02-06 11:08:25.49 UTC] There was an error connecting to the node: ErrFromServant (ConnectionError "HttpExceptionRequest Request {\n  host                 = \"127.0.0.1\"\n  port                 = 8080\n  secure               = True\n  requestHeaders       = [(\"Accept\",\"application/json;charset=utf-8,application/json\")]\n  path                 = \"/api/v1/node-settings\"\n  queryString          = \"\"\n  method               = \"GET\"\n  proxy                = Nothing\n  rawBody              = False\n  redirectCount        = 10\n  responseTimeout      = ResponseTimeoutDefault\n  requestVersion       = HTTP/1.1\n}\n (InternalException (HostCannotConnect \"127.0.0.1\" [Network.Socket.connect: <socket: 49>: does not exist (Connection refused)]))")

In the logs from https://github.com/input-output-hk/cardano-wallet/blob/3d769cff56bc754d2355cdb8369858f67e2ff892/src/Cardano/Wallet/Server/Plugins.hs#L103-L111
as the server hadn't started yet.
Overview

[x] I have added hoist to NodeClient
[x] I have put retrying in the NodeClient itself that is returned from setupNodeClient

Comments

A side effect is that when the wallet is forwarding a request to the node, like
https://github.com/input-output-hk/cardano-wallet/blob/dd1a28204136e3b9b73f00fe8b4ea48ce7d71a13/src/Cardano/Wallet/API/V1/Handlers/Info.hs#L21
we get the retrying here too.

Went for #314 :+1:

authors: Anviking KtorZ

repo: input-output-hk/cardano-wallet


text:
Chore/ddw 206 Create PR template with review checklist

This PR adds PR template with review checklist: https://github.com/input-output-hk/daedalus/blob/chore/ddw-206-create-pr-template-with-review-checklist/.github/pull_request_template.md

Thanks @DominikGuzei! We need @darko-mijic's approval for this one :)

repo: input-output-hk/daedalus


text:
PLT-7566 Add docker images for marlowe-apps

Pre-submit checklist:

Branch

[ ] Tests are provided (if possible)
[ ] Test report is updated (if relevant)
[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages
[x] Formatting, PNG optimization, etc. are updated

PR

[x] Self-reviewed the diff
[x] Useful pull request description

Review required
[x] Substantial changes to code, test, or documentation
[ ] Change made to Marlowe validator (@bwbush and @palas must be included as reviewers)
Review not required
[ ] Minor changes to non-critical code, documentation, nix derivations, configuration files, or scripts
[ ] Formatting, spelling, grammar, or reorganization

[x] Reviewer requested

Fixes https://github.com/input-output-hk/marlowe-starter-kit/issues/42

repo: input-output-hk/marlowe-cardano


text:
Reuse the current ledger state when moving a ledger cursor

The ledgerCursorMove operation can be made more efficient by reusing the ledger snapshot the ledger cursor is holding onto.
For example, consider the following scenario:

We open a ledger cursor, which is initially focused on the ledger state corresponding to the current tip of the chain. This is cheap, as we have this ledger state in memory.
We move the ledger cursor to a point 100 blocks back from the current snapshot. We have no ledger snapshot at this point, but let's say we have a snapshot 200 blocks back. This means we rollback to the snapshot of 200 blocks back and then roll forward 100 blocks, which requires reading 100 blocks and applying each of them to the ledger state.
We move the ledger cursor to the next point, i.e. the point 99 blocks back from the current snapshot. We have to do the same work as in (2), but now with 101 blocks. If we reuse the current snapshot, we only have to reapply 1 block instead of 101.

Imagine we're rolling forward the ledger one block at a time, this would mean reapplying 100, 101, 102, 103, ... blocks instead of 100, 1, 1, 1, ... blocks.

Now that we're going ahead with #1936 (in #2440), there will be no more block replaying required and no more optimisation left to do.

repo: input-output-hk/ouroboros-network


text:
Enable block production dynamically

For redunancy reasons SPOs are running backup block production nodes.
Currently, with a firewall rules, they can prevent relays to connect to the
backup node, and thus prevent the duplicate blocks to be diffused.   This will
no longer work with p2p nodes, as relays will be able to reuse inbound
connection from the block producer.  For this reason we would like a block
producing node to be able to start without being able to produce blocks and
start when it receives a SIGHUP signal.
This feature should be implemented against p2p-master branches (both in
ouroboros-network and cardano-node).

This sounds reasonable. Though the choice of SIGHUP seems a bit odd to me; maybe a USR* instead? (Disclaimer: I'm unaware of any conventions here, just "hangup" sounds wrong here.)
Also, is sending it a signal that much more convenient than restarting the backup non-BP node with a slightly altered config file/argument that enables BP? IE is it sufficiently more convenient to justify the additional complexity in the implementation? Signals are usually a pain. (Slippery slope though: will we also want to be able to similarly stop the block producer, eg once the primary one is back online?)

Signals are very simple to send. SIGHUP is used in many other processes to mean "reload your config". For example, prometheus does this.
kill -SIGHUP <pid>

As Andrew mentions it is common for unix daemon's to support reloading their config files upon receiving SIGHUP. For p2p we've added support for reloading the topology file. What we're after here is a reloading a config file, not simply switching between block production enabled/disabled upon receiving the signal.

Thanks @AndrewWestberg @karknu for elaborating.

What we're after here is a reloading a config file, not simply switching between block production enabled/disabled upon receiving the signal.

@karknu @coot Would you update this Issue title and description according to this clarification ^^^? That's quite a bit more general than the current wording, if I understand correctly. Thanks.

My immediate thought regarding "have the Consensus layer reload its config upon SIGHUP" is that a lot of our config is captured in a lot of closures, not (just) held in mutvars. Depending on which exact "config" we're thinking of reloading, this could task could range from relatively simple to invasive. EG Karl mentioned that the Network Layer only reloads the topology file -- maybe the necessary portion of the Consensus config for our immediate needs is indeed only stored in a mutvar; I'd have to get some more details and track that down. If the necessary config is curently captured in closures, then the shortest path might be the sledgehammer option of essentially restarting the necessary components of the node kernel (eg the block-producing threads). The less-sledgehammery option would be to migrate the config from closures to mutvars. Navigating those options depends on the details of what exactly we need to reload.
Either option should probably involve a new tracer event.
Also; Consensus doesn't read config files: cardano-node does that before invoking our layer. So the ultimate PR here will probably be adding an updateFooConfigToNewValue method to our interface, so that node can catch SIGHUP, reparse the file, and then invoke that new method.

I'm thinking out loud a bit, in the above, based on what I think this Issue is about. If what I discussed there seems unexpected, please let me know and we can talk about it at an upcoming Consensus Planning meeting (ie Tuesdays) to get on the same page.
If we do seem to already be on the same page, then maybe you could suggest here which exact config needs to be reloaded -- that would help me get a better sense of what this PR might look like.
Thanks.

@coot @karknu We're planning to prioritize Genesis work over this. This should be simpler, and they both unblock the same things, at a coarse level.
So we probably won't touch this until some time in July. Does that sound viable for you?

That's ok.

This snippet is the existing logic that determines when the node attempts to forge a block. In particular, the knownSlotWatcher means that we attempt every time the current slot changes (if it's known -- which ~means we're sufficiently synced with mainnet).
https://github.com/input-output-hk/ouroboros-network/blob/7a56e888428d76ba5598641aac201b0cd7f5121e/ouroboros-consensus/src/Ouroboros/Consensus/NodeKernel.hs#L406-L418
@coot Would it be sufficient to put aside the reparsing of the config file and simply immediately abort each leadership check (ie go above) if a mutable flag that receiving SIGHUP toggles is set to false? Would the node additionally need a way to specify whether the flag should start in the off or on position?

@nfrisby I think we have three options on the table:

re-read whole configuration (on SIGHUP), and make it available to the rest of the application
re-read the configuration (on SIGHUP), but only extract things that we are interested in (right now a single boolean flag)
to have a controlling mini-protocol which allows to read / change specific values

First, option is very intrusive, and its scope is probably too large to achieve in reasonable time frame.
The second option, would fit nicely with what you suggest, and it would have a nicer interface, where the value is read from the configuration file, rather than be a switch which state is hidden.
I think I prefer the second option over the third one in terms of ux for SPOs, and it's also simpler to implement.

I think I prefer the second option over the third one in terms of ux for SPOs, and it's also simpler to implement.

I don't anticipate it being simpler to implement. The main reason is that we have at least some closures that contain configuration data. We'd need to track all those down and replace them with STM m Config actions.
The third option seems very simple to implement: add some new state and a related config option (command-line alone would likely be fine, I expect) with a very narrow intended use.
I think the main downside of the third option is that if we eventually do support "reconfigure on SIGHUP", then this flag (and its eg command-line option) would have to be deprecated.

I don't anticipate it being simpler to implement. The main reason is that we have at least some closures that contain configuration data. We'd need to track all those down and replace them with STM m Config actions.

You don't need STM m Config, just STM m ReconfigurableConfig, where ReconfigurableConfig would just contain a small part of the real configuration, for now it could be just a single boolean value.  But the point is that on SIGHUP, the node would parse the config file, and extract ReconfigurableConfig and made it available in the stm transaction.
The main downside point for third option, as I see it, are that:

on / off switch becomes error prone for the operator: the state becomes virtual, lives only in cardano-node process, one cannot double check the value.  Sending SIGHUP will change the state every time.
config file is not the only source of configuration.

While what I propose:

keeps the simplicity of the third point, one only exposes tiny bits from the config file.
SIGHUP is idempotent: one can double check if the config file contains the right value, and send SIGHUP to make sure the in memory value is synced with the config value.
allows gradually expand ReconfigurableConfig, until all sensible parts of it are reconfigurable.  We could extend it with other network parts, other teams (consensus :)) could follow in their pace

The downside is:

for the users it might be confusing which pieces are reconfigurable on SIGHUP, and which aren't.  Good logging should help.
anything else?

@coot I like it! I wasn't considering the new separate config. Way better than my hidden state idea.
Heads up: @Jimbo4350 does the plan that Marcin outlined above ^^^ make sense to you? Does Node Team have any other config like this that we'd prefer to be able to change on the fly? Just looking for overlap with existing tech debt/upcoming goals, etc.

btw, we're using SIGHUP to reload p2p topology configuration.
@deepfire are you planing to do reconfiguration of the logging system in a similar way?  What's your take on the above plan.

would it be possible to have an entry in the main config.json that is refering to a second file that is also loaded and merged with the main one on a SIGHUP signal? and a flag to disable blockproduction on a node via an config entry in the main or the linked config file? in that case it would be really easy to change either the small extra config file on the fly or to change the linked config file in the main config.json to point to a for example bp_enable.json config file which could also contain a reference to the node keys instead of passing it on via the starting parameters, and a bp_disable.json which contains a set parameter to disable bp production (should be on by default if keys are present). in that way we could not only enable/disable blockproduction but we could also change the provided keys if needed on the fly.
something like:
   "AdditionalConfigFile": "enable_bp.json",

   "AdditionalConfigFile": "disable_bp.json",

for the main config
and in the referenced enable_bp.json like:
   "DisableBlockProduction": false
   "VrfKeyFile": "mynode.vrf.skey",
   "KesKeyFile": "mynode.kes.skey",
   "OperationalCertificateFile": "mynode.node.opcert"

and disable_bp.json like:
   "DisableBlockProduction": true
   "VrfKeyFile": "mynode.vrf.skey",
   "KesKeyFile": "mynode.kes.skey",
   "OperationalCertificateFile": "mynode.node.opcert"

merging these together so the configuration can took place in the single main config file or in an additional one.
and of course some flag that is checkable via the metrics to verify the current set blockproduction state of the running node.
...  just an idea

@gitmachtl We already have something like this which is the bulk credentials file. It's used mostly in setting up test nodes, but could be modified to add the extra flag for DisableLeaderCheck.

@gitmachtl We already have something like this which is the bulk credentials file. It's used mostly in setting up test nodes, but could be modified to add the extra flag for DisableLeaderCheck.

you're right, i think i have used it once in the past but totally forgot about it. yep, maybe we could bring it together with some extra flags.

It might need to just be renamed as "--credentials-file" and modified to make it more user friendly. Right now, it's very tricky to set up with the array of arrays and the order needing to be very specific as 1.) opcert, 2.) vrf, 3.) KES.
Ideally a better format would be to just use exactly what you have above except wrap it in an array so it could still be used for bulk credentials in test environments. Then there would be exactly one way to configure credentials for a node instead of two.
[
  {
     "DisableLeaderCheck": true,
     "VrfKeyFile": "mynode.vrf.skey",
     "KesKeyFile": "mynode.kes.skey",
     "OperationalCertificateFile": "mynode.node.opcert"
  }
]

Does Node Team have any other config like this that we'd prefer to be able to change on the fly (without restarting the process)?
Not to my knowledge
re-read the configuration (on SIGHUP), but only extract things that we are interested in
This sounds reasonable

Would it be possible to have two signals? One that enables BlockProduction and one that disables BlockProduction? StartUp defaults to enabled.

We understand that signals are not ideal for this scenario and eventually the cardano-node team will provide an IPC to load / unload keys to process memory; Although initially this might be done with a SIGHUP while the key is loaded in process memory (through configuration as it's done now).

authors: AndrewWestberg Jimbo4350 coot gitmachtl karknu nfrisby


text:
Robcohen/docs

Added readthedocs for consistency across repos.
https://docs.cardano.org/projects/ouroboros-network/en/latest/

Please give all PRs a proper title instead of just accepting the branch name.

This PR refers to a private version network design doc.  Hopefully, by the end of the week we will have a public version.

@robcohen shall we translate our technical documentation, which is written in a pdf format to markdown? If so can somebody help us with that?

authors: coot erikd robcohen


text:
[Builtins] Only be 'Lazy' for the result of a builtin application

Same as #4581 except the history is correct.

/benchmark plutus-benchmark:validation

Comparing benchmark results of 'plutus-benchmark:validation' on '4af22f9fb' (base) and 'a2c72aa7d' (PR)

Results table

Script
4af22f9
a2c72aa
Change

auction_1-1
201.6 μs
205.2 μs
+1.8%

auction_1-2
817.7 μs
835.0 μs
+2.1%

auction_1-3
807.5 μs
823.6 μs
+2.0%

auction_1-4
257.8 μs
261.3 μs
+1.4%

auction_2-1
201.8 μs
205.5 μs
+1.8%

auction_2-2
818.6 μs
833.2 μs
+1.8%

auction_2-3
1.045 ms
1.065 ms
+1.9%

auction_2-4
811.7 μs
823.8 μs
+1.5%

auction_2-5
258.1 μs
262.3 μs
+1.6%

crowdfunding-success-1
236.8 μs
240.3 μs
+1.5%

crowdfunding-success-2
237.0 μs
240.1 μs
+1.3%

crowdfunding-success-3
236.1 μs
240.0 μs
+1.7%

currency-1
300.9 μs
306.2 μs
+1.8%

escrow-redeem_1-1
429.7 μs
435.2 μs
+1.3%

escrow-redeem_1-2
429.2 μs
434.9 μs
+1.3%

escrow-redeem_2-1
504.9 μs
512.5 μs
+1.5%

escrow-redeem_2-2
504.9 μs
513.0 μs
+1.6%

escrow-redeem_2-3
504.0 μs
512.9 μs
+1.8%

escrow-refund-1
177.3 μs
182.6 μs
+3.0%

future-increase-margin-1
301.9 μs
308.1 μs
+2.1%

future-increase-margin-2
683.3 μs
690.6 μs
+1.1%

future-increase-margin-3
683.0 μs
691.8 μs
+1.3%

future-increase-margin-4
641.6 μs
649.6 μs
+1.2%

future-increase-margin-5
1.015 ms
1.026 ms
+1.1%

future-pay-out-1
302.1 μs
306.7 μs
+1.5%

future-pay-out-2
681.3 μs
689.1 μs
+1.1%

future-pay-out-3
681.8 μs
688.9 μs
+1.0%

future-pay-out-4
1.013 ms
1.022 ms
+0.9%

future-settle-early-1
301.2 μs
306.2 μs
+1.7%

future-settle-early-2
678.7 μs
690.8 μs
+1.8%

future-settle-early-3
678.7 μs
690.4 μs
+1.7%

future-settle-early-4
768.4 μs
780.0 μs
+1.5%

game-sm-success_1-1
485.6 μs
493.2 μs
+1.6%

game-sm-success_1-2
221.8 μs
223.8 μs
+0.9%

game-sm-success_1-3
810.2 μs
819.6 μs
+1.2%

game-sm-success_1-4
232.1 μs
260.2 μs
+12.1%

game-sm-success_2-1
486.2 μs
496.0 μs
+2.0%

game-sm-success_2-2
221.1 μs
225.2 μs
+1.9%

game-sm-success_2-3
813.1 μs
823.6 μs
+1.3%

game-sm-success_2-4
233.5 μs
260.4 μs
+11.5%

game-sm-success_2-5
812.8 μs
821.4 μs
+1.1%

game-sm-success_2-6
233.7 μs
259.7 μs
+11.1%

multisig-sm-1
503.4 μs
510.5 μs
+1.4%

multisig-sm-2
491.1 μs
496.5 μs
+1.1%

multisig-sm-3
493.5 μs
502.5 μs
+1.8%

multisig-sm-4
499.9 μs
508.1 μs
+1.6%

multisig-sm-5
717.7 μs
729.1 μs
+1.6%

multisig-sm-6
501.3 μs
511.1 μs
+2.0%

multisig-sm-7
488.0 μs
496.5 μs
+1.7%

multisig-sm-8
493.7 μs
501.5 μs
+1.6%

multisig-sm-9
500.4 μs
507.5 μs
+1.4%

multisig-sm-10
718.2 μs
728.6 μs
+1.4%

ping-pong-1
412.8 μs
418.8 μs
+1.5%

ping-pong-2
410.7 μs
416.8 μs
+1.5%

ping-pong_2-1
240.0 μs
242.5 μs
+1.0%

prism-1
183.8 μs
185.1 μs
+0.7%

prism-2
521.6 μs
532.3 μs
+2.1%

prism-3
443.6 μs
449.7 μs
+1.4%

pubkey-1
156.0 μs
158.3 μs
+1.5%

stablecoin_1-1
1.120 ms
1.129 ms
+0.8%

stablecoin_1-2
217.6 μs
218.3 μs
+0.3%

stablecoin_1-3
1.282 ms
1.292 ms
+0.8%

stablecoin_1-4
231.1 μs
230.6 μs
-0.2%

stablecoin_1-5
1.605 ms
1.613 ms
+0.5%

stablecoin_1-6
284.4 μs
289.1 μs
+1.7%

stablecoin_2-1
1.120 ms
1.131 ms
+1.0%

stablecoin_2-2
217.0 μs
219.2 μs
+1.0%

stablecoin_2-3
1.277 ms
1.288 ms
+0.9%

stablecoin_2-4
229.9 μs
231.4 μs
+0.7%

token-account-1
224.4 μs
229.0 μs
+2.0%

token-account-2
399.6 μs
407.6 μs
+2.0%

uniswap-1
511.4 μs
525.3 μs
+2.7%

uniswap-2
261.9 μs
267.4 μs
+2.1%

uniswap-3
2.073 ms
2.101 ms
+1.4%

uniswap-4
379.0 μs
386.6 μs
+2.0%

uniswap-5
1.413 ms
1.436 ms
+1.6%

uniswap-6
364.3 μs
370.8 μs
+1.8%

vesting-1
430.3 μs
441.9 μs
+2.7%

Hm, Ok, I guess this somehow interferes with the MakeKnownM optimization, although I have no idea how. Perhaps it's time to try again the other PR.

/benchmark plutus-benchmark:validation

Comparing benchmark results of 'plutus-benchmark:validation' on '4af22f9fb' (base) and 'fb6a43af7' (PR)

Results table

Script
4af22f9
fb6a43a
Change

auction_1-1
202.3 μs
204.7 μs
+1.2%

auction_1-2
818.1 μs
823.8 μs
+0.7%

auction_1-3
806.3 μs
809.9 μs
+0.4%

auction_1-4
258.2 μs
260.3 μs
+0.8%

auction_2-1
203.1 μs
203.8 μs
+0.3%

auction_2-2
817.6 μs
820.1 μs
+0.3%

auction_2-3
1.042 ms
1.042 ms
0.0%

auction_2-4
805.4 μs
806.3 μs
+0.1%

auction_2-5
258.6 μs
259.9 μs
+0.5%

crowdfunding-success-1
236.0 μs
238.4 μs
+1.0%

crowdfunding-success-2
237.1 μs
238.3 μs
+0.5%

crowdfunding-success-3
237.4 μs
238.9 μs
+0.6%

currency-1
302.5 μs
300.7 μs
-0.6%

escrow-redeem_1-1
428.4 μs
430.0 μs
+0.4%

escrow-redeem_1-2
428.5 μs
429.0 μs
+0.1%

escrow-redeem_2-1
504.9 μs
504.6 μs
-0.1%

escrow-redeem_2-2
504.1 μs
504.0 μs
-0.0%

escrow-redeem_2-3
504.3 μs
504.2 μs
-0.0%

escrow-refund-1
179.3 μs
179.5 μs
+0.1%

future-increase-margin-1
301.3 μs
299.9 μs
-0.5%

future-increase-margin-2
676.9 μs
678.4 μs
+0.2%

future-increase-margin-3
678.7 μs
677.2 μs
-0.2%

future-increase-margin-4
637.7 μs
637.9 μs
+0.0%

future-increase-margin-5
1.012 ms
1.008 ms
-0.4%

future-pay-out-1
302.1 μs
299.8 μs
-0.8%

future-pay-out-2
680.2 μs
676.0 μs
-0.6%

future-pay-out-3
679.8 μs
675.8 μs
-0.6%

future-pay-out-4
1.012 ms
1.010 ms
-0.2%

future-settle-early-1
301.1 μs
300.6 μs
-0.2%

future-settle-early-2
680.9 μs
677.7 μs
-0.5%

future-settle-early-3
682.6 μs
677.2 μs
-0.8%

future-settle-early-4
774.9 μs
767.2 μs
-1.0%

game-sm-success_1-1
488.6 μs
484.9 μs
-0.8%

game-sm-success_1-2
221.9 μs
220.0 μs
-0.9%

game-sm-success_1-3
811.9 μs
808.2 μs
-0.5%

game-sm-success_1-4
231.8 μs
259.4 μs
+11.9%

game-sm-success_2-1
485.0 μs
486.8 μs
+0.4%

game-sm-success_2-2
220.5 μs
221.3 μs
+0.4%

game-sm-success_2-3
809.1 μs
806.0 μs
-0.4%

game-sm-success_2-4
232.5 μs
258.0 μs
+11.0%

game-sm-success_2-5
810.7 μs
805.4 μs
-0.7%

game-sm-success_2-6
231.7 μs
257.7 μs
+11.2%

multisig-sm-1
504.5 μs
501.6 μs
-0.6%

multisig-sm-2
490.5 μs
487.3 μs
-0.7%

multisig-sm-3
495.8 μs
496.7 μs
+0.2%

multisig-sm-4
500.7 μs
503.3 μs
+0.5%

multisig-sm-5
720.5 μs
719.3 μs
-0.2%

multisig-sm-6
504.9 μs
505.7 μs
+0.2%

multisig-sm-7
493.0 μs
489.3 μs
-0.8%

multisig-sm-8
497.6 μs
496.5 μs
-0.2%

multisig-sm-9
502.3 μs
502.1 μs
-0.0%

multisig-sm-10
719.8 μs
720.0 μs
+0.0%

ping-pong-1
411.9 μs
414.0 μs
+0.5%

ping-pong-2
411.9 μs
413.3 μs
+0.3%

ping-pong_2-1
240.8 μs
242.5 μs
+0.7%

prism-1
183.5 μs
186.2 μs
+1.5%

prism-2
522.6 μs
524.8 μs
+0.4%

prism-3
440.8 μs
443.4 μs
+0.6%

pubkey-1
156.4 μs
156.6 μs
+0.1%

stablecoin_1-1
1.110 ms
1.110 ms
0.0%

stablecoin_1-2
215.6 μs
217.6 μs
+0.9%

stablecoin_1-3
1.271 ms
1.263 ms
-0.6%

stablecoin_1-4
229.0 μs
230.6 μs
+0.7%

stablecoin_1-5
1.586 ms
1.577 ms
-0.6%

stablecoin_1-6
282.5 μs
284.7 μs
+0.8%

stablecoin_2-1
1.112 ms
1.106 ms
-0.5%

stablecoin_2-2
215.1 μs
216.2 μs
+0.5%

stablecoin_2-3
1.273 ms
1.262 ms
-0.9%

stablecoin_2-4
230.1 μs
229.9 μs
-0.1%

token-account-1
226.0 μs
224.8 μs
-0.5%

token-account-2
400.7 μs
397.1 μs
-0.9%

uniswap-1
515.0 μs
509.5 μs
-1.1%

uniswap-2
262.8 μs
263.6 μs
+0.3%

uniswap-3
2.058 ms
2.046 ms
-0.6%

uniswap-4
375.9 μs
383.1 μs
+1.9%

uniswap-5
1.400 ms
1.396 ms
-0.3%

uniswap-6
362.6 μs
366.6 μs
+1.1%

vesting-1
430.8 μs
429.2 μs
-0.4%

Closing in favor of #4610. I like this one more, but the other one actually helps.

/benchmark plutus-benchmark:validation

Comparing benchmark results of 'plutus-benchmark:validation' on '4af22f9fb' (base) and '9674d36d7' (PR)

Results table

Script
4af22f9
9674d36
Change

auction_1-1
225.8 μs
203.5 μs
-9.9%

auction_1-2
850.0 μs
825.1 μs
-2.9%

auction_1-3
845.3 μs
814.9 μs
-3.6%

auction_1-4
292.9 μs
260.5 μs
-11.1%

auction_2-1
226.8 μs
204.7 μs
-9.7%

auction_2-2
849.0 μs
821.3 μs
-3.3%

auction_2-3
1.076 ms
1.043 ms
-3.1%

auction_2-4
837.2 μs
808.1 μs
-3.5%

auction_2-5
291.1 μs
259.4 μs
-10.9%

crowdfunding-success-1
267.2 μs
238.1 μs
-10.9%

crowdfunding-success-2
266.3 μs
238.3 μs
-10.5%

crowdfunding-success-3
266.6 μs
238.4 μs
-10.6%

currency-1
319.0 μs
301.3 μs
-5.5%

escrow-redeem_1-1
462.4 μs
430.0 μs
-7.0%

escrow-redeem_1-2
461.2 μs
429.9 μs
-6.8%

escrow-redeem_2-1
541.4 μs
504.2 μs
-6.9%

escrow-redeem_2-2
540.3 μs
502.6 μs
-7.0%

escrow-redeem_2-3
543.4 μs
502.9 μs
-7.5%

escrow-refund-1
202.2 μs
179.5 μs
-11.2%

future-increase-margin-1
320.2 μs
300.8 μs
-6.1%

future-increase-margin-2
718.9 μs
679.1 μs
-5.5%

future-increase-margin-3
719.3 μs
677.7 μs
-5.8%

future-increase-margin-4
671.3 μs
640.7 μs
-4.6%

future-increase-margin-5
1.045 ms
1.013 ms
-3.1%

future-pay-out-1
318.0 μs
300.3 μs
-5.6%

future-pay-out-2
717.9 μs
676.8 μs
-5.7%

future-pay-out-3
718.5 μs
676.7 μs
-5.8%

future-pay-out-4
1.038 ms
1.008 ms
-2.9%

future-settle-early-1
319.2 μs
299.5 μs
-6.2%

future-settle-early-2
718.6 μs
678.9 μs
-5.5%

future-settle-early-3
717.8 μs
680.6 μs
-5.2%

future-settle-early-4
798.1 μs
772.9 μs
-3.2%

game-sm-success_1-1
519.1 μs
486.7 μs
-6.2%

game-sm-success_1-2
250.4 μs
220.2 μs
-12.1%

game-sm-success_1-3
851.0 μs
806.8 μs
-5.2%

game-sm-success_1-4
292.3 μs
258.8 μs
-11.5%

game-sm-success_2-1
522.9 μs
488.9 μs
-6.5%

game-sm-success_2-2
249.9 μs
222.2 μs
-11.1%

game-sm-success_2-3
846.4 μs
808.5 μs
-4.5%

game-sm-success_2-4
291.7 μs
258.9 μs
-11.2%

game-sm-success_2-5
845.3 μs
805.9 μs
-4.7%

game-sm-success_2-6
290.4 μs
258.7 μs
-10.9%

multisig-sm-1
531.8 μs
504.6 μs
-5.1%

multisig-sm-2
521.1 μs
490.2 μs
-5.9%

multisig-sm-3
528.1 μs
496.5 μs
-6.0%

multisig-sm-4
533.1 μs
503.3 μs
-5.6%

multisig-sm-5
746.0 μs
718.0 μs
-3.8%

multisig-sm-6
533.9 μs
505.3 μs
-5.4%

multisig-sm-7
519.3 μs
491.0 μs
-5.4%

multisig-sm-8
526.4 μs
495.9 μs
-5.8%

multisig-sm-9
532.3 μs
503.4 μs
-5.4%

multisig-sm-10
746.7 μs
716.2 μs
-4.1%

ping-pong-1
438.7 μs
413.7 μs
-5.7%

ping-pong-2
437.5 μs
413.3 μs
-5.5%

ping-pong_2-1
261.5 μs
242.2 μs
-7.4%

prism-1
208.2 μs
186.5 μs
-10.4%

prism-2
564.6 μs
523.0 μs
-7.4%

prism-3
478.7 μs
441.9 μs
-7.7%

pubkey-1
177.2 μs
156.2 μs
-11.9%

stablecoin_1-1
1.175 ms
1.111 ms
-5.4%

stablecoin_1-2
244.2 μs
217.4 μs
-11.0%

stablecoin_1-3
1.349 ms
1.267 ms
-6.1%

stablecoin_1-4
258.0 μs
229.9 μs
-10.9%

stablecoin_1-5
1.698 ms
1.584 ms
-6.7%

stablecoin_1-6
320.3 μs
285.2 μs
-11.0%

stablecoin_2-1
1.173 ms
1.108 ms
-5.5%

stablecoin_2-2
244.2 μs
217.3 μs
-11.0%

stablecoin_2-3
1.353 ms
1.269 ms
-6.2%

stablecoin_2-4
259.3 μs
230.6 μs
-11.1%

token-account-1
242.6 μs
225.3 μs
-7.1%

token-account-2
431.3 μs
397.7 μs
-7.8%

uniswap-1
535.4 μs
509.6 μs
-4.8%

uniswap-2
283.2 μs
262.9 μs
-7.2%

uniswap-3
2.186 ms
2.049 ms
-6.3%

uniswap-4
429.3 μs
384.2 μs
-10.5%

uniswap-5
1.512 ms
1.404 ms
-7.1%

uniswap-6
412.1 μs
367.3 μs
-10.9%

vesting-1
457.7 μs
431.7 μs
-5.7%

-7.07%. The only thing I did is moved Lazy from PlutusPrelude to Runtime, see the commit.

fyi: Looking around in hackage for something an established way of the Lazy datatype, I only found this https://hackage.haskell.org/package/vector-0.12.3.1/docs/Data-Vector-Fusion-Util.html#t:Box

-7% is worse than -8%, hence choosing #4610 over this one.

authors: bezirg effectfully iohk-devops

repo: input-output-hk/plutus


text:
exe-common::sync: Hot-fix a u32 underflow panic

This was originally found on a first run of Hermes which would catch the
underflow on the genesis epoch. The finish_epoch() function would use an
imprecise logical expression to determine that the specified epoch has a
predecessor.
This commit fixes the underflow which would happen for
epoch_id equal to 0 a.k.a. genesis.
I don't think this is the correct way to handle this, because I believe
the sync module is inconsistent. It assumes in finish_epoch() that
previous_epoch_id(N) == N - 1 always holds true and therefore that the
genesis epoch ID is always 0, while at the same time other parts of the
code use different methods than checking the ID to check for genesis
(e.g. is_genesis() on block date).
What do you think should be the definitive way to determine the epoch
that's allowed not to have a predecessor?

One job errored in CI due to no output, I'm confident it doesn't have anything to do with my changes, could you please rerun the job when you get the chance?

Thanks, I messed up the assertion - epoch_id > 0 was supposed to be epoch_id == 0.
Ideally, we would use net_cfg.epoch_start here. That will require passing net_cfg to finish_epoch.

repo: input-output-hk/rust-cardano


text:
Improve trait bounds on blockchain entities

Add chain-core property trait FromStr to impose extra requirements on parsing values such as block dates from strings.
Require the error types for deserialization and string parsing to be safe for passing between threads, so that they can be boxed and contained in e.g. client::Error of network-core.
Trait work in gRPC client code to reduce repetitive bound clauses.

Codecov Report

Merging #443 into master will decrease coverage by 0.07%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   47.62%   47.54%   -0.08%
==========================================
  Files         123      123
  Lines       12108    12131      +23
==========================================
+ Hits         5766     5768       +2
- Misses       6342     6363      +21

Impacted Files
Coverage Δ

chain-core/src/property.rs
94.66% <ø> (ø)
:arrow_up:

chain-impl-mockchain/src/block.rs
72.68% <0%> (-9.19%)
:arrow_down:

...tocol-tokio/src/network_transport/response_code.rs
54.54% <0%> (-12.13%)
:arrow_down:

chain-impl-mockchain/src/transaction.rs
93.1% <0%> (+3.44%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-io mzabaluev


text:
Fix: pass revalidateOnFocus option to useSWR to reduce number of requ…

This PR fixes performance issue identified during the performance review of PB
The useDataset hook was re-fetching the dataset whenever the window was unfocused and then refocused. To prevent unnecessary requests, this PR adds the passing of revalidateOnFocus set to false to the useSWR hook.

[ ] I've added a unit test to test for potential regressions of this bug.
[ ] The changelog has been updated, if applicable.
[x] Commits in this PR are minimal and have descriptive commit messages.

Closing because it duplicates draft PR https://github.com/inrupt/solid-ui-react/pull/561

repo: inrupt/solid-ui-react


text:
Cookie is ignored, when Cookie for "/" on same domain exists

I'm running multiple sites on the same domain. The cookies for different paths don't interfere with each other, but as soon as the cookie for the path "/" exists, the cookies for all other paths are ignored.

Take a look at Cookie Options to set a custom path for each site.

I did. Sorry if that wasn't clear from my original comment.
I set cookie.path to the correct value for each path (including "/"), but as soon as the cookie for the path "/" exists, the cookies for all other paths are ignored.

You could also set a custom cookie.name for each site.

Let me just clarify, if you set a cookie with a path of "/", then any other cookie (with the same name on a different path) will get ignored.
I think this is an issue with cookies in general, and not specific to our tool (although I may be mistaken).
You could take a look at the solution offered here and see if that works. It's a bit of work though.

authors: InsanityMeetsHH alexmorleyfinch seeeeew

repo: insites/cookieconsent


text:
Add Volume Mount for /var/lib/ig/oci-store in Gadget DaemonSet

Fixes #2203

Hi,
Could we make this optional and opt-out by default?
{{- if .Values.config.xxx

@alban

Hi,
Could we make this optional and opt-out by default?
{{- if .Values.config.xxx

@alban changes added.

How is using a hostPath persistent volume different than mounting a hostPath volume in the pod as proposed in the first version of this PR?

Good catch! We should really avoid using hostPath when not necessary.

What's the reason for avoiding hostpath?

We should really avoid using hostPath when not necessary.

I'll change this to a local volume.

Hi!
Thank you for switching to local! Can you please run make generate-manifests to propagate your changes to pkg/resources/manifests/deploy.yaml?
Best regards.

Already pushed with the last amend :)

@eiffel-fl I don't understand, do you mean using an empty directory volume here rather than defining a PV?

Thinking more about it, I am wondering if we should not also add a flag kubectl gadget deploy. This way, we have the same set of options in both the CLI and the helm chart.

what would this flag do exactly, can you ellaborate?

Thinking more about it, I am wondering if we should not also add a flag kubectl gadget deploy. This way, we have the same set of options in both the CLI and the helm chart.

what would this flag do exactly, can you ellaborate?

Sure! The flag would basically use a volume mount instead of what we have currently. You can take a look at 3ddce30, to see how we implemented the option in both the HELM charts and the CLI. It would need more code, as instead of setting an environment variable you would need to add the volume as well as do the wiring to actually use this volume, but it can give you an idea.

Thank you for the explanation, I can definitely give this a try.

repo: inspektor-gadget/inspektor-gadget


text:
Cover IR 78

The following metadata response parameters shall be contained in a Get View Service Metadata response:

View Service Metadata;
Operations Metadata;
Layers Metadata;
Languages.

Most of the necessary metadata can be provided through the service Capabilities, as defined in the WMTS Standard [OGC 07-057r7, Section 7.1.1]. These capabilities are mandatory and defined when a WMTS is set up. They consist of server's information, supported operations and parameters values.

View Service Metadata and Operations Metadata requirements are covered in the OGC WMTS ATS. Layers Metadata for the part the INSPIRE spatial data set MD record reference by #6 and #11.
For Languages, the requirements are covered by #4

Closed as duplicate

repo: inspire-eu-validation/ats-view-wmts


text:
update yaml download function - [closed]

In GitLab by @sokril on Jan 2, 2018, 08:01
Merges yaml -> dev

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:23
closed

repo: inspursoft/board


text:
technical infos in datapoints

Can you create some datapoints like 'uptime', 'load average'?

DiskStationManager.info

authors: darkiop instalator


text:
feat: Support using Stability AI API as a model connector

Because

we want to integrate with 3rd party models/APIs and do not have connector for models

This commit

introduces the concept of connector for models and code for Stability AI integration

And because the repo's name has been changed. Please also update the go pkg name

I've fixed the above problem.

repo: instill-ai/connector-ai


text:
Updating governance to point to Oversight Committee members

Surfacing current list of oversight committee members as a community member wasn't able to easily find current membership.

/rebase

authors: joesepi lhawthorn

repo: instructlab/community


text:
Generate coverage reports on the code that caffeine runs

Description todo for @mishazharov

Dupe of #494

authors: Phantomical mishazharov

repo: insufficiently-caffeinated/caffeine


text:
🛑 Shopintake is down

In 2c545e8, Shopintake (https://www.shopintake.com) was down:

HTTP code: 403
Response time: 523 ms

Resolved: Shopintake is back up in a2bf51a after 15 minutes.


text:
🛑 Shopintake is down

In 26053fc, Shopintake (https://www.shopintake.com) was down:

HTTP code: 403
Response time: 340 ms

Resolved: Shopintake is back up in 50d4aaf after 52 minutes.


text:
INTLY-5356: Add app versions to Managed services tab

Motivation
https://issues.redhat.com/browse/INTLY-5356
What
Add versions to the services listed in the Managed services tab of solution explorer, for OpenShift 4 clusters only.
Verification Steps
Point an OpenShift 4 deployment of solution explorer to this docker image:
docker.io/mfrances17/dev-tutorial-web-app:latest

Go to the Managed services tab.
Verify that versions exist in parenthesis after the pretty name, e.g. Red Hat OpenShift (version 4).

Checklist:

[x] Code has been tested locally by PR requester
[ ] Changes have been successfully verified by another team member

Progress

[x] Finished task

Additional Notes
Screen shot of OS4 system running this code:

@mfrances17 Do you know why only two services are displayed? There is an error about an undefined variable in middlewareServices in the browser log.


text:
APPDUX-113: Show unauthorized page if non-Admin accesses Settings

Motivation
https://issues.redhat.com/browse/APPDUX-113
What
We removed the ability for non-Admins to get to the Settings page by disabling the settings cog in the masthead. This JIRA covers if a non-Admin attempts to get to the Settings page by typing the route in the URL, e.g. host/settings. We display a 'Permissions needed' screen with a button that allows them to go back to the home page.
Why
Prevent non-Admins from accessing the settings page. Note that this functionality is only for OpenShift 4, not OpenShift 3.
Verification Steps
If testing locally:

Run the code with yarn start:dev.
By default, you should have full Admin access because in demo mode, the openshift version is 3. Verify that you can click the Settings cog or use /settings to access the normal populated Settings page.
To force a dev user, aka non-admin rights, change the following lines to false:
masthead.js - ln 232
settings.js - ln 114
Verify that the Settings cog is not clickable and displays the descriptive tooltip.
Append your current host URL with /settings e.g. localhost:3006/settings.
Verify that the permissions needed screen is displayed vs the normal settings page.

If you have access to a cluster, you can test the code on a live server by pointing the solution explorer yml to the following docker image:
docker.io/mfrances17/dev-tutorial-web-app:latest
Checklist:

[x] Code has been tested locally by PR requester
[ ] Changes have been successfully verified by another team member

Progress

[x] Finished task

Additional Notes
Non-admin account logged in, Settings page accessed using /settings URL:

@tiffany as requested, changed button text to 'Go to home'... Also changed the same button text in the other empty state pages to be consistent - specifically, the congrats page and the error page.


text:
all-in-one based version 2.1.0b1 issue for llama3-8b-instruct with 128-2048

Last iterator is verfy slow for llama3-8b-instruct & fp8.

Cannot reproduce the issue in the env provided by user, will sync details offline.

After sync with user offline, cannot reproduce in users' env, will keep monitor similar behavior, close issue for now.

authors: Fred-cell lalalapotter

repo: intel-analytics/ipex-llm


text:
refactor mistral and phi3

Description
After this PR, mistral only supports transformers >= 4.36
1. Why the change?

2. User API changes

3. Summary of the change

4. How to test?

[ ] N/A
[ ] Unit test: Please manually trigger the PR Validation here by inputting the PR number (e.g., 1234). And paste your action link here once it has been successfully finished.
[ ] Application test
[ ] Document test
[ ] ...

PR validation: https://github.com/intel-analytics/ipex-llm-workflow/actions/runs/12479388429


text:
AutoRound/Examples dependency is injected to AutoRound pkg dependency

GPTQModel has merged AutorRound integration via PR https://github.com/ModelCloud/GPTQModel/pull/166 but we find the the CI tests is importing auto-gptq (via auto-round depends)  as dependency which is strange to us since the only auto-gptq code in AutoRound is in examples.
Can examples/require*txt not be merge into auto-round pkg depends proper?

GPTQModel has merged AutorRound integration via PR ModelCloud/GPTQModel#166 but we find the the CI tests is importing auto-gptq (via auto-round depends) as dependency which is strange to us since the only auto-gptq code in AutoRound is in examples.
Can examples/require*txt not be merge into auto-round pkg depends proper?

Thank you for integrating Autoround. We should have not merge the example/requirement.txt  in the main branch.
During the  model packing, we need to import some packing functions from autogptq.
BTW, our API has changed a little to support the new features

@wenhuach21 We are closely following pending v0.3 autoround release in https://github.com/ModelCloud/GPTQModel/issues/179 as there are lots of feature and internal api change. Is there an estimated release date for autoround v0.3?

@wenhuach21 We are closely following pending v0.3 autoround release in ModelCloud/GPTQModel#179 as there are lots of feature and internal api change. Is there an estimated release date for autoround v0.3?

about 2 weeks

sorry for the late. V0.3 has been released

repo: intel/auto-round


text:
move device-plugin-operator resources to values

Hi team!
In our environment device-plugin-operator sometimes CLBOs due to OOMkill.
Proposing to parametrise resources request/limits as such.
Cheers, Alexey

@agrevtsev thanks, are you using the latest version? #34 requested this too but we ended up just updating the values.

Hi @mythi ! Yes, we are using the last version, and for now also resorted to edit chart, but i suppose moving resource allocation to values would be more convenient and pretty solution.

authors: agrevtsev mythi

repo: intel/helm-charts


text:
some issues with model.generate in itrex

I have encountered two questions while using the model.generate function in the itrex project.

When executing model.generate with the stopping_criteria parameter as a stopping_criteria class, it seems that the max_new_tokens parameter is ignored. This behavior can be observed in the file /home/username/intelpython3/envs/ITREX/lib/python3.10/site-packages/intel_extension_for_transformers/llm/runtime/graph/__init__.py on line 196.
https://github.com/intel/intel-extension-for-transformers/blob/938a3f069bfd72574aecd1407434876ec8674bd6/intel_extension_for_transformers/llm/runtime/graph/__init__.py#L196C13-L196C13

I am also curious about the support for the frequency_penalty parameter. In the llama.cpp, this parameter is supported and effectively prevents some model degradation issues. However, it appears that this parameter is not supported in itrex. Is it possible to add support for this parameter in itrex?

hi @kunger97 ,

When executing model.generate with the stopping_criteria parameter as a stopping_criteria class, it seems that the max_new_tokens parameter is ignored.

Yes, you can check max_new_tokens inside stopping_criteria.

I am also curious about the support for the frequency_penalty parameter.

We will sync with llama.cpp recently and new functions in llama.cpp will be added.

hi @kunger97 ,
here is an example:
import torch
from typing import List
from transformers import StoppingCriteria, StoppingCriteriaList

class StopOnTokens(StoppingCriteria):
    def __init__(self, min_length: int, start_length: int, stop_token_id: List[int], max_new_tokens):
        self.min_length = min_length
        self.start_length = start_length
        self.stop_token_id = stop_token_id
        self.max_new_tokens = max_new_tokens

    def __call__(
        self, input_ids: torch.LongTensor, scores: torch.FloatTensor, **kwargs
    ) -> bool:
        if input_ids.shape[-1] - self.start_length > max_new_tokens:
          return True
        if input_ids.shape[-1] - self.start_length > self.min_length:
            for stop_id in self.stop_token_id:
                if input_ids[0][input_ids.shape[-1] - 1] == stop_id:
                    return True
        return False

stopping_criteria = StoppingCriteriaList(
    [
        StopOnTokens(
            min_length=80,
            start_length=inputs.shape[1],
            stop_token_id=[tokenizer.eos_token_id],
            max_new_tokens=300,
        )
    ]
)

outputs = model.generate(inputs, streamer=streamer, stopping_criteria=stopping_criteria)

that work well. thanks for your help!

repo: intel/intel-extension-for-transformers


text:
Update requirements.txt

Update jupyter-core version to patch a security vulnerability.

Both security issues should be addressed in this PR:

Execution with Unnecessary Privileges in JupyterApp
Certifi removing TrustCor root certificate

repo: intel/intel-qs


text:
[Performance] Enable the SLPVectorizer to improve flash attention performance

The SLPVectorizer + IGC_DisablePHIScalarizer improves the overall 3% performance on flash attention forward kernel.
Enable the SLPVectorizer before the IGCVectorizer could do the same transformation.

There is no need to enable the SLP Vectorizer on Triton side because:

IGC is going to improve the IGC vectorizer to cover our requirements.
We can get FA performance without PHI node vectorization improvement already.

repo: intel/intel-xpu-backend-for-triton


text:
Add aten::igamma and aten::igammac

igamma
igamma.out
igamma_
igammac
igammac.out
igammac_
Add these methods to xpu device.

Please provide evidence of passing the unit tests

authors: gaopengff xytintel

repo: intel/torch-xpu-ops


text:
Improve 'before you begin' section in code snippets user docs

Each code snippets page has a Before You Begin section that contains multiple expands for signing up with/setting up Rafiki.money. However, after going through the steps once, you don't need to do them again. Instead of having the same set of expands on every page, let's create a stand-alone page and link to the content from the code snippets pages.

[x] Create a "Before you begin" page in the Code Snippets section that contains the content of the original 4 partial files. Delete the partial files.
[x] To ensure we use the same lang string and link(s) on each code snippet page, create the new 'before you begin' content within a partial and add to each page
[x] Update each code snippet page by changing the partials 'import' to call the new partial file

This is complete from a docs standpoint, but I'm having problems with PR #377. When that's resolved, the updates in this issue will be available.

repo: interledger/open-payments


text:
Create List of Accounts page (BE)

Return Balance and list of accounts for the wallet to display on home page.
The accounts in our DB need to be mapped with accounts with funds on Rapyd side.
Our DB might have an account with a specific currency and Rapyd have 0 funds in that currency. This means that we still display this account with Balance=0, even if Rapyd doesn't have this type of currency account.
Usefull links:
Retrieve Rapyd Wallet balances:
https://docs.rapyd.net/build-with-rapyd/reference/wallet-transaction#retrieve-wallet-balances

Closed by: PR https://github.com/interledger/testnet/pull/170

authors: Tymmmy raducristianpopa

repo: interledger/testnet


text:
Some more automation

Would be great to somehow better specify the devices instead of specifying the exact device name entries. Feeding the output of v4l2-ctl --list-devices into the weffe arguments is not extraordinary user friendly.

Thanks for the feedback! I haven't edited this repository in a while but if you have an idea of what you think this could look like I'm open to implementing it! (And yes... I mostly used that for debugging but it sure could be more user-friendly)

authors: intermezzio sebastian-philipp

repo: intermezzio/weffe


text:
Update CSS reset

Details here: https://github.com/international-labour-organization/designsystem/pull/627
Careful that the reset doesn't unfix #546

@justintemps Just a reminder that we should merge this soon.

authors: bashlk justintemps


text:
Dear DonghaoFeng, do you have some manual for your DML learning.

Dear DonghaoFeng, do you have some manual for your DML including the software configuration?
Thank you very much.

@sirelays please have a look https://github.com/interpss/DeepMachineLearning/wiki/人工智能课开发环境部署

authors: DonghaoFeng sirelays

repo: interpss/DeepMachineLearning


text:
ZkVM: refactor predicate logic [WIP]

DO NOT USE THIS PATCH

@vickiniu This patch poisons a bunch of APIs with failability only due to Prover that could encounter invalid compressed point down the hierarchy of data structures. I don't think this is a good way forward. If the prover cannot construct a good witness, it's better to detect this at the construction time, not during VM execution time.
Let's try another approach (will open another PR and abandon this one):
Predicate is a structure, not enum, that holds compressed point which is always ready for to_point conversion, and an additional Option<PredicateWitness>. This way encoding of the predicate tree never fails and does not poison the APIs. Maybe we'll need to adopt the same Option<Witness> style for other structs as a result.

Solved in a nicer way by @vickiniu in #75

repo: interstellar/slingshot


text:
Issue with publishing declarative-objectscript package via OEX

We received the following error while publishing your package declarative-objectscript:
ERROR #6901: XSLT XML Transformer Error: unable to determine file base pathname in at line 0 offset 0
discussion

I can't repeat this problem
I've published this package using a request as usual
I suppose it could be a problem with receiving data from github

ERROR #5001: Invalid repository for this Package
InterSystems OpenExchange Team ```

Once again.

I checked "use README from github" and sent to approval.

The problem with this package is due to the use "%" symbol in file names.
Now all "%" in filenames must be replaced to _.

authors: atygaev evshvarov nsolov

repo: intersystems-community/zpm


text:
Cannot remove devices - InTheHand 4.0.14

When I wanna use BluetoothSecurity.RemoveDevice method with the specified Bluetooth address, the function seems not working which means that it is not able to remove the paired device. Do all u guys face the same problem with me?

What platform (OS and version) are you using?

What platform (OS and version) are you using?

I am using Windows 10 2004

authors: FungGor peterfoot


text:
🛑 Teylers Museum is down

In b64a7b6, Teylers Museum (https://www.teylersmuseum.nl) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Teylers Museum is back up in 2f64ee8 after 5 minutes.

repo: intk/intk-upptime


text:
Bug: Delayed CSS loading

Hey y'all, I seemed to run across a bug.
For reference, I am using GatsbyJS v2 as the framework for the web application I am building, so the issue may lie in there.
Browser: Firefox 66.0.3 (64-bit)
React-Big-Calendar: v20.4
What's the current behavior?
Link to current behavior: here
When deploying the production build to Netlify, the CSS for React-Big-Calendar seems to load after page load. I've tried a number of things to mitigate the issue, which you can view over at here. Initially, I thought it was due to not having a componentDidMount() method, but I've added one since then and it still produced the same result.
What's the expected behavior?
The CSS should load smoothly, along with the rest of the page.

Actually experiencing a similar problem where the page loads in an un-styled manner and then quickly updates to the correct layout. You can see this when you reload the sample on the react-big-calendar demo/docs page. Anyone have a way to correct/mitigate?

@moyamanuel @perrypelletier Have you thought about preloading that CSS instead of having it load as the page loads?

No, I have not, @arecvlohe. It seems like GatsbyJS already does that according to the docs. Is there an explicit way to preload the CSS?

What about using link plus preload? https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

Closing since this is a loading/bundling issue and not a calendar issue.

authors: arecvlohe moyamanuel perrypelletier

repo: intljusticemission/react-big-calendar


text:
unzip of the FMU does not maintain the permissions

I noted that during the unzip of the FMU, the unzipped directory does not maintain the permissions of the contained files.
More precisely, the FMU that I am working with contain a separate executable that when unzipped under /tmp/ has lost the x permission. Without the correct permissions I am not able to run correctly the co-simulation.

With the last snapshot of the  coe the issue is solved for linux-32bit

this is fixed in coe 0.2.14 which is in the dev bundle now and will be released soon. Just switch to development mode to use it.

authors: lausdahl tfabbri

repo: into-cps/intocps-ui


text:
Nested keys trigger conflict warning

Given the following class:
class Foo < Hashie::Mash
  def bar
    self.baz
  end
end

I'm finding that

Foo.new(baz: 1) generates no warnings, as expected
Foo.new(bar: 1) generates warnings, as expected
Foo.new(baz: { bar: 1 }) generates warnings, which is not expected

The final example gives this warning:
W, [2018-02-01T12:07:40.621060 #22182]  WARN -- : You are setting a key that conflicts with a built-in method Foo#bar defined at (irb):2. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

Is this behavior intended?

That definitely looks like a bug. Care to write a spec and maybe even a fix?

This isn't a bug, surprisingly, but it is definitely unexpected behavior. The way Mashes propagate themselves inside of nested hashes involves wrapping the included hashes inside the Mash class. When you subclass a Mash, instead of wrapping the included hashes in a Mash, it wraps it in itself (in this case a Foo).
Since Foo has a #bar method, the warning is raised on the inside hash, as it is wrapped in a Foo.
I'm not sure what would be more surprising - if the inner hash was a Mash, or if the inner hash is a Foo. What do you think?

Mash keeps on giving. Maybe someone can update http://code.dblock.org/2017/02/24/the-demonic-possession-of-hashie-mash.html for me? No but really, please.
I think Mash should propagate all behavior except when otherwise. Frankly this is an amazing side effect - sometimes we want functions to propagate, sometimes not. I want it both ways :)

I would see if wrapping the inside of the Mash in a Hashie::Mash instead of itself breaks any specs. If not I would call that a fix and add a spec for this exact scenario.

This change:
diff --git a/lib/hashie/mash.rb b/lib/hashie/mash.rb
index a6d1347..a5d3900 100644
--- a/lib/hashie/mash.rb
+++ b/lib/hashie/mash.rb
@@ -324,7 +324,7 @@ module Hashie
         duping ? val.dup : val
       when ::Hash
         val = val.dup if duping
-        self.class.new(val)
+        Mash.new(val)
       when Array
         val.map { |e| convert_value(e) }
       when ::Array

causes these failures:
Failures:

  1) Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on method calls
     Failure/Error: expect(subject).to eq(outer: { inner: 42 }, testing: [1, 2, 3])

       expected: {:outer=>{:inner=>42}, :testing=>[1, 2, 3]}
            got: {:outer=>#<Hashie::Mash inner=42>, :testing=>#<Hashie::Array [1, 2, 3]>}

       (compared using ==)

       Diff:
       @@ -1,3 +1,3 @@
       -:outer => {:inner=>42},
       +:outer => {"inner"=>42},
        :testing => [1, 2, 3],

     # ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:32:in `block (3 levels) in <top (required)>'

  2) Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on explicit operator call
     Failure/Error: expect(**instance).to eq(outer: { inner: 42 }, testing: [1, 2, 3])

       expected: {:outer=>{:inner=>42}, :testing=>[1, 2, 3]}
            got: #<#<Class:0x00007fe753cae648> outer=#<Hashie::Mash inner=42> testing=[1, 2, 3]>

       (compared using ==)

       Diff:
       @@ -1,3 +1,3 @@
       -:outer => {:inner=>42},
       +:outer => {"inner"=>42},
        :testing => [1, 2, 3],

     # ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:36:in `block (3 levels) in <top (required)>'

Finished in 0.18218 seconds (files took 0.83603 seconds to load)
648 examples, 2 failures

Failed examples:

rspec ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:31 # Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on method calls
rspec ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:35 # Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on explicit operator call

This is because the class that uses the Mash extension loses the extension when we cast it back to a Mash via the change.
Since that's the case, making the change would require a major version bump. I'm not sure I want to do that right now - I would rather save the bump to 4.0 for more changes than this little one. What do you think, dB?
If this is a change we want to make, we could start a 4.0 branch and make it on there ... and if we make the change, I think we need to work out a way to not drop any Mash extensions that are included on the class.
The more I think about it, the more I think that this is probably intended behavior and not a bug, in particular because of the existence of Mash extensions.

At any rate, @rpdillon, if you would like to suppress the warning, you can do this:
class Foo < Hashie::Mash
  disable_warnings

  def bar
    self.baz
  end
end

I think we should leave things as is and document the behavior of inheriting the class itself for nested mashes.

authors: dblock michaelherold rpdillon

repo: intridea/hashie


text:
Clash: cannot nest twice even when key is Clash class

Hello,
In the example found in README:
https://github.com/intridea/hashie#clash
The suggestion to access one of the nested hashes is by using bang methods:
c = Hashie::Clash.new
c.where!.nested(10)._end!
# => {:where=>{:nested=>10}}

However, a second attempt to do the same results in ChainError exception:
c = Hashie::Clash.new
c.where!.nested(10)._end!
c.where!.another(10)._end!
Hashie::Clash::ChainError: Tried to chain into a non-hash key.

Of course this is a naive example, as the issue trying to solve is merge nested elements:
c = Hashie::Clash.new
c.where(location: { near: [1, 2] })
# => {:where=>{:location=>{:near=>[1, 2]}}}
c.where(location: { distance: "100mi" })
# => {:where=>{:location=>{:distance=>"100mi"}}}

There is no way, without using the nested (bang) methods to workaround this limitation.
Looking at the logic of the code:
https://github.com/intridea/hashie/blob/59069f13ea067a319584a56674cc02de887b999f/lib/hashie/clash.rb#L73-L76
Seems that one scenario is missing, which is the case when self[key] is already a Clash instance.
Wanted to confirm if is the desired behavior, there are alternatives or a pull request might be in order :grin:
Thank you!

Bump @luislavena

@dblock just to be clear: take your change, change the changelog and then send as a pull request?

@luislavena I just want you to finish this PR! It needs a CHANGELOG entry.

Hello @dblock
Really sorry to upset you. I do understand you want to get this change merged, however while I originally reported this issue, wasn't me who contributed the change (or turned the issue into a pull request)
The user that provided the change is @bartoszkopinski and the changes were in his fork.
To be honest is the first time that a reporter of the issue is being asked to provide the CHANGELOG entry description, even when wasn't me who provided the patch.
Anyway, I went ahead and forked, pulled the changes from @bartoszkopinski branch (bk-240-clash-fixes) and amend into this commit:
https://github.com/intridea/hashie/compare/master...luislavena:bk-240-clash-fixes
Not sure I should be submitting another pull request for the same and also don't want to take credit for the change made by @bartoszkopinski .
Please let me know if I missed something.
Thank you.

My bad @luislavena I didn't notice that :)

Just make a PR with that? You can amend on behalf of the original author.

@dblock done, see #321, rebased.

Closed via https://github.com/intridea/hashie/pull/321.

authors: dblock luislavena


text:
Callback path isn't aware of sub-directory placement

I'm using rails 4 and omniauth-ldap,deploying with warbler in glassfish. Looking through the source its grabbing callback_path from omniauth core.
For some reason the rest of the rails app works fine, even the login pages, but the callback URL is going to the root of the webserver, this conflicts with how glassfish is deploying the applications.
http://glassfishserver/application/users/auth/ldap is the form. This posts to
http://glassfishserver/users/auth/ldap/callback.
To be honest I'm not sure if this is being covered by rails automagic everywhere else, or jboss/glassfish magic, but it's causing issues with omniauth. Does anyone know of an elegant way to fix it?. It works fine in development which isn't put in a subfolder, but doesn't in production and the jboss/glassfish subfolder.

+1, afaik this is still not resolved?

authors: aldanor btrepp

repo: intridea/omniauth


text:
JSON path expression doesn't work

I am trying this * def orgVal =  karate.jsonPath(response, "$.segments[?(@.id ==7613603227418679)]").id. But getting no value. Not sure what I am doing wrong.
18:05:42.896 [main] INFO  com.intuit.karate - [print] Origin Value  [
]
Sample data -
{
  "requestId": "8ehd6-6c32-4766-a253-1c9cdnidc4cec2",
  "searchRefKey": "826879461625",
  "responseStatus": {
    "code": "1",
    "reasonCode": "SUCCESS",
    "message": "Successful Request"
  },
  "responseSummary": {
  },
  "referral": {
  },
  "passengers": [
    {
      "numOfPax": 5,
      "type": "ADT"
    }
  ],
  "slices": [
    {
      "id": 7591164138534052,
      "duration": {
        "value": 1675,
        "unit": "MINUTE"
      },
      "segments": [
        {
          "id": 1,
          "segmentRefId": 7591164138529651
        },
        {
          "id": 2,
          "segmentRefId": 7591164138531002
        },
        {
          "id": 3,
          "segmentRefId": 7591164138532394
        }
      ]
    }
  ],
  "segments": [
    {
      "id": 23783268357325705,
      "departDateTime": "2019-10-05T19:50:00",
      "arrivalDateTime": "2019-10-06T14:25:00",
      "originAirport": "LAX",
      "destinationAirport": "LHR",
      "duration": {
        "value": 635,
        "unit": "MINUTE"
      },
      "marketingAirline": "BA",
      "operatingAirline": "AA",
      "flightNumber": "1509",
      "equipmentCode": "77W",
      "subjectToGovtApproval": false,
      "numOfStops": 0,
      "stops": []
    }
  ],
  "brands": [],
  "baggageAllowances": [
  ],
  "restrictions": [
  ],
  "trips": []
}

@zeesattarny please ask this question on stack overflow. and please simplify it: https://stackoverflow.com/help/how-to-ask

@ptrthomas Sorry in rush I forgot to add proper details. Here is the link I have added this question  to stackoverflow.
https://stackoverflow.com/questions/57282428/karate-json-path-filter-not-working-when-trying-to-extract-elements-that-meet-so

authors: ptrthomas zeesattarny

repo: intuit/karate


text:
POC: Add traits to support generalising the apply methods

POC for #75
Some brief notes to guide review:
This started off implementing the idea in the description of #75: adding traits to describe the cardinality of our transforms and defining an intermediate _apply method that dispatched on the traits.
But after some refactoring at the end, I noticed that the key difference boiled down to how the data was prepared before going into a ManyToOne transform (LinearCombination).
So I refactored a bit more to create two simple formatting functions:

_preformat structures the input to _apply according to the cardinality of the transform. Effectively, this just calls eachslice before calling _apply for LinearCombination.
_preformat structures the output of _apply according to the cardinality of the transform. This is really only needed for append_apply because LinearCombination returns a Vector, if we are appending it as a row cat throws a DimensionMismatch. So we have to pivot the data before doing so.

I added some TestUtils with Fakes for the above transforms and an example testset for how we might test a new data type in a more manageable way in the future.
The idea being that: once a datatype supports each type of transform (and returns correct result for the kwargs) then it should support any  of the transforms defined in the package.
Then, each transform just needs to be tested against Arrays and nothing else, which should give us full test coverage but in a much simpler way.

closed in favour of https://github.com/invenia/FeatureTransforms.jl/pull/80


text:
Beta release

Waiting for https://github.com/inveniosoftware/invenio-search/pull/111 to be merged.

Ready to be reviewed and merged.

One more thing :) RELEASE-NOTES.rst seems that is missing. In all the other repos we have it, wasn't it part of the release checklist?

We decided to remove RELEASE-NOTES.rst. It's actually mentioned in the revised checklist, that I linked to in HackMD :)

authors: drjova switowski

repo: inveniosoftware/invenio-search