Cannot use AdamOptimizer in C++ when running graph defined from Python

Running Ubuntu 14.04, with r1.2 Tensorflow
I have defined a graph in Python
features = 784
output_dim = 10
graph_name = "graph.pb"
graph_folder = "/home/fran/Repositories/tensorflow/bazel-bin/tensorflow/test"
input_node_name = "input"
output_node_name = "output"

with tf.Session() as session:
    x = tf.placeholder(tf.float32, [None, features], name="input")
    W = tf.Variable(tf.zeros([features, output_dim]), dtype=tf.float32, name="Weight")
    b = tf.Variable(tf.zeros([output_dim]), dtype=tf.float32, name="bias")
    y_pred = tf.nn.softmax(tf.matmul(x, W)+b, name=output_node_name)

    y_true = tf.placeholder(tf.float32, [None, 10], name="y_true")
    cross_entropy = tf.reduce_mean(-tf.reduce_sum(y_true * tf.log(y_pred), reduction_indices=[1]), name="loss")
    optimizer = tf.train.AdamOptimizer(0.00001)
    train_step = optimizer.minimize(cross_entropy, name="train")
    init = tf.variables_initializer(tf.global_variables(), name='init_all_vars_op')
    saver = tf.train.Saver()
    tf.train.write_graph(session.graph_def, graph_folder, graph_name, as_text=False)

If I run this graph in a C++ program, where I load the graph, initialize the variables and feed X and Y tensors to "train", I get the following error (works fine with other optimizers like GradientDescent or RMSPropOptimizer):
Training.
Step: 0; Loss: 9.25913
2017-07-03 09:54:43.264264: E tensorflow/core/common_runtime/executor.cc:644] Executor failed to create kernel. Invalid argument: NodeDef mentions attr 'use_nesterov' not in Op<name=ApplyAdam; signature=var:Ref(T), m:Ref(T), v:Ref(T), beta1_power:T, beta2_power:T, lr:T, beta1:T, beta2:T, epsilon:T, grad:T -> out:Ref(T); attr=T:type,allowed=[DT_FLOAT, DT_DOUBLE, DT_INT64, DT_INT32, DT_UINT8, DT_UINT16, DT_INT16, DT_INT8, DT_COMPLEX64, DT_COMPLEX128, DT_QINT8, DT_QUINT8, DT_QINT32, DT_HALF]; attr=use_locking:bool,default=false>; NodeDef: train/update_Weight/ApplyAdam = ApplyAdam[T=DT_FLOAT, _class=["loc:@Weight"], use_locking=false, use_nesterov=false, _device="/job:localhost/replica:0/task:0/cpu:0"](Weight, Weight/Adam, Weight/Adam_1, beta1_power/read, beta2_power/read, train/learning_rate, train/beta1, train/beta2, train/epsilon, gradients/MatMul_grad/tuple/control_dependency_1). (Check whether your GraphDef-interpreting binary is up to date with your GraphDef-generating binary.).
	 [[Node: train/update_Weight/ApplyAdam = ApplyAdam[T=DT_FLOAT, _class=["loc:@Weight"], use_locking=false, use_nesterov=false, _device="/job:localhost/replica:0/task:0/cpu:0"](Weight, Weight/Adam, Weight/Adam_1, beta1_power/read, beta2_power/read, train/learning_rate, train/beta1, train/beta2, train/epsilon, gradients/MatMul_grad/tuple/control_dependency_1)]]
2017-07-03 09:54:43.264468: F tensorflow/driving_school/training.cc:102] Non-OK-status: session->Run(inputs, {}, {"train"}, nullptr) status: Invalid argument: NodeDef mentions attr 'use_nesterov' not in Op<name=ApplyAdam; signature=var:Ref(T), m:Ref(T), v:Ref(T), beta1_power:T, beta2_power:T, lr:T, beta1:T, beta2:T, epsilon:T, grad:T -> out:Ref(T); attr=T:type,allowed=[DT_FLOAT, DT_DOUBLE, DT_INT64, DT_INT32, DT_UINT8, DT_UINT16, DT_INT16, DT_INT8, DT_COMPLEX64, DT_COMPLEX128, DT_QINT8, DT_QUINT8, DT_QINT32, DT_HALF]; attr=use_locking:bool,default=false>; NodeDef: train/update_Weight/ApplyAdam = ApplyAdam[T=DT_FLOAT, _class=["loc:@Weight"], use_locking=false, use_nesterov=false, _device="/job:localhost/replica:0/task:0/cpu:0"](Weight, Weight/Adam, Weight/Adam_1, beta1_power/read, beta2_power/read, train/learning_rate, train/beta1, train/beta2, train/epsilon, gradients/MatMul_grad/tuple/control_dependency_1). (Check whether your GraphDef-interpreting binary is up to date with your GraphDef-generating binary.).
	 [[Node: train/update_Weight/ApplyAdam = ApplyAdam[T=DT_FLOAT, _class=["loc:@Weight"], use_locking=false, use_nesterov=false, _device="/job:localhost/replica:0/task:0/cpu:0"](Weight, Weight/Adam, Weight/Adam_1, beta1_power/read, beta2_power/read, train/learning_rate, train/beta1, train/beta2, train/epsilon, gradients/MatMul_grad/tuple/control_dependency_1)]]
Aborted (core dumped)

Is this a bug?
For reference, the code I use to load the graph definition and train is the following:
#include "tensorflow/core/public/session.h"
#include "tensorflow/core/platform/env.h"

using namespace tensorflow;

int main(int argc, char* argv[]) {

    Session* session;
    std::cout << "Initializing Tensorflow session." << std::endl;
    TF_CHECK_OK(NewSession(SessionOptions(), &session));

    // Read in the protobuf graph we previously exported
    // (The path is relative to the cwd. Keep this in mind
    // when using `bazel run` since the cwd isn't where you call
    // `bazel run` but from inside a temp folder.)
    GraphDef graph_def;
    std::cout << "Reading protobuf graph." << std::endl;
    TF_CHECK_OK(ReadBinaryProto(Env::Default(), "graph.pb", &graph_def));

    std::cout << "Loading graph in Tensorflow session." << std::endl;
    TF_CHECK_OK(session->Create(graph_def));

    int batch_size = 64;
    int input_feature_len = 784;
    int output_feature_len = 10;
    int training_steps = 1000;
    int save_interval = 100;
    std::string save_path = "/home/fran/Repositories/tensorflow/tensorflow/test/";

    std::cout << "Initializing Tensorflow I/O tensors." << std::endl;
    Tensor X(DT_FLOAT, TensorShape({batch_size, input_feature_len}));
    Tensor Y(DT_FLOAT, TensorShape({batch_size, output_feature_len}));

    // Initialize our variables for training
    std::cout << "Initializing Tensorflow variables." << std::endl;
    TF_CHECK_OK(session->Run({}, {}, {"init_all_vars_op"}, nullptr));

    auto _XTensor = X.matrix<float>();
    auto _YTensor = Y.matrix<float>();
    _XTensor.setRandom();
    _YTensor.setRandom();

    // Assuming graph contains single input X, with node name "input"
    // and single ground truth placeholder, with node name "y_true"
    std::vector<std::pair<string, Tensor>> inputs = {
            { "input", X },
            { "y_true", Y }
    };

    // for checkpoint generation
    Tensor model_string(DT_STRING, TensorShape( { 1, 1 } ) );

    // Initialize output pointer for loss metric.
    // Assuming graph contains single loss, with node name "loss"
    // and single training node, with node name "train"
    std::cout << "Training." << std::endl;
    std::vector<Tensor> output;
    for (int i=0; i<training_steps; ++i) {
        TF_CHECK_OK(session->Run(inputs, {"loss"}, {}, &output)); // Get loss (for monitoring)
        float loss = output[0].scalar<float>()(0);
        std::cout << "Step: " << i << "; Loss: " << loss << std::endl;
        TF_CHECK_OK(session->Run(inputs, {}, {"train"}, nullptr)); // Train
        output.clear();

        // to save checkpoint feed name of checkpoint file as saver_def.filename_tensor_name
        // and fetch the value of saver_def.save_tensor_name, as per graph definition script.
        if (i % save_interval == 0){
            model_string.matrix< std::string >()( 0, 0 ) = save_path + "model_checkpoint_step" + std::to_string(i) + ".ckpt";
            TF_CHECK_OK(session->Run({{"save/Const:0", model_string}}, {}, {"save/control_dependency"}, nullptr));
        };
    };
    std::cout << "Training complete." << std::endl;

    std::cout << "Closing Tensorflow session." << std::endl;
    session->Close();
    delete session;
    return 0;
}

Maybe you used a different TF version for the C++ code? In here you see that use_nesterov is part of the ApplyAdam op. That was introduced in commit 53cb26d05a5c2080d8022124178b1cc43a30ffe5, which is part of TF 1.2.0.

@fferroni Hi , I am trying to execute the below line of code

TF_CHECK_OK(session->Run({{"save/Const:0", model_string}}, {}, {"save/control_dependency"}, nullptr));

But I get below error

Non-OK-status: session->Run({{"save/Const:0", string}}, {}, {"save/control_dependency"}, nullptr) status: Not found: FeedInputs: unable to find feed output save/Const:0

Can I PLEASE know if you have faced ny such issue and how could it be reolved
Thanks

@fferroni Can I please know how to create model_string.meta . The below command creates only  model_string.index and model_string.data-00000-of-00001 files. .meta file is needed to do prediction as described in https://stackoverflow.com/questions/35508866/tensorflow-different-ways-to-export-and-run-graph-in-c
TF_CHECK_OK(session->Run({{"save/Const:0", model_string}}, {}, {"save/control_dependency"}, nullptr));
Is there any other way to do prediction in c++ without help of .meta file ?

@fferroni Is the problem solved? Is it the TF version that matters? Very interested in it.


yum install, transation freeze with containerd.io 1.5.11

Description
I got got a freeze when I am trying to build centos 7 image.
My containerd.io version is:
containerd.io-1.5.11-3.1.fc34.x86_64.rpm
OS: Fedora 34
Kernel:Linux  5.16.15-101.fc34.x86_64
When I am trying to install packages (for example mc) inside the runnning container, yum stuck on transations.
One of my cpu thread at this time is working on 100%
Steps to reproduce the issue
Dockerfile:
FROM centos:7
RUN yum install -y mc
Step 1:
docker build -t test .
Describe the results you received and expected
This is where the docker stuck:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : gpm-libs-1.20.7-6.el7.x86_64                                1/31
.......
What version of containerd are you using?
1.5.11
Any other relevant information
runc version 1.0.1
commit: v1.0.1-0-g4144b63
spec: 1.0.2-dev
go: go1.15.14
libseccomp: 2.5.3
uname -a:
Linux *** 5.16.15-101.fc34.x86_64 #1 SMP PREEMPT Thu Mar 17 05:50:00 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Show configuration if it is related to CRI plugin.
No response

Unlikely to be an issue of containerd.
What is your Moby storage driver? (Shown in docker info)
With BuildKit or without?

My store driver is ZFS
After I downgrade the containerd to 1.4.9, the problem disappeared.
Docker info:
`Client:
Context:    default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.1-docker)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 3
Running: 1
Paused: 0
Stopped: 2
Images: 10
Server Version: 20.10.14
Storage Driver: zfs
Zpool: data
Zpool Health: ONLINE
Parent Dataset: data/docker
Space Used By Parent:<PHONE_NUMBER>
Space Available:<PHONE_NUMBER>12
Parent Quota: no
Compression: lz4
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: e25210fe30a0a703442421b0f60afac609f950a3
runc version: v1.0.1-0-g4144b63
init version: de40ad0
Security Options:
seccomp
Profile: default
cgroupns
Kernel Version: 5.16.16-100.fc34.x86_64
Operating System: Fedora 34 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.11GiB
Name: t480
ID: KITH:JKXD:Q54G:VTGQ:AX65:46R5:EQ7X:QSZO:VKDR:3253:KMB3:WNVW
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
`

Same problem here.
Fedora 35 with containerd.io 1.5.11 (also tried 1.5.10)
downgrading to 1.4.13 solved the issue for me
Steps I used to reproduce:
docker run -it centos:7 bash

and then inside container
yum install wget -y

the yum transaction takes almost 3 minutes to complete - whereas it usually is just a few seconds.
Strangely, I also tried the same with other images such as almalinux:8 and fedora:35 - but only experience the problem with centos:7
My storage driver is btrfs

Yup, same for me on Fedora 35 with containerd.io 1.5.11; any yum install in a CentOS 7 container takes seemingly forever. Based on @pnyheim's comment I downgraded to 1.4.13 (and rebooted just to be sure; didn't even bother with 1.5.10), and then it was again superfast.

Hi,
I think the change that is causing this issue is the value of LimitNOFILE:
cat /usr/lib/systemd/system/containerd.service | grep LimitNOFILE
changed between versions:
1.4.13: LimitNOFILE=1048576
1.5.11: LimitNOFILE=infinity
Changing the service file to the old value or alternatively creating a new file in /etc/systemd/system/containerd.service.d/override.conf with:
[Service]
LimitNOFILE=1048576
It may not be a perfect solution but it is a workaround that is working for me. (Personally i created the override.conf file to avoid messing with the service file that can be overwritten with an update)

Changing the service file to the old value or alternatively creating a new file in /etc/systemd/system/containerd.service.d/override.conf with:
[Service]
LimitNOFILE=1048576

I can confirm that @aleitao's work-around works for me too. So contrary too @AkihiroSuda's remark, it does appear to be caused by changes in containerd.io.

could someone check if there's a difference in output of ulimit -a (or ulimit -n) if LimitNOFILE=1048576 is set or LimitNOFILE= infinity is set?
This change was made in https://github.com/containerd/containerd/pull/4475, but according to the systemd docs I referenced in that PR, unlimited should have the same effect as the previously hardcoded value, but possibly newer versions of systemd changed that?
Here's on a Ubuntu machine with containerd.io 1.5.11 installed;
containerd --version
containerd containerd.io 1.5.11 3df54a852345ae127d1fa3092b95168e4a88e2f8

systemctl cat containerd.service | grep LimitNOFILE
LimitNOFILE=infinity

docker run --rm centos:7 sh -c 'ulimit -n'
1048576

docker run --rm centos:7 sh -c 'ulimit -a'

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3838
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1048576
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

FWIW, I think it's fine to revert that change, but it'd be good if we knew what changed (this could be a bug/regression in systemd, or a change in behaviour)

containerd --version
containerd containerd.io 1.5.11 3df54a852345ae127d1fa3092b95168e4a88e2f8

Without overriding configuration:
systemctl cat containerd.service | grep LimitNOFILE
LimitNOFILE=infinity

docker run --rm centos:7 sh -c 'ulimit -n'
1073741816
docker run --rm centos:7 sh -c 'ulimit -a'
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63109
max locked memory       (kbytes, -l) 8192
max memory size         (kbytes, -m) unlimited
open files                      (-n)<PHONE_NUMBER>
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Overriding configuration in /etc/systemd/system/containerd.service.d/override.conf
systemctl cat containerd.service | grep LimitNOFILE
LimitNOFILE=infinity
LimitNOFILE=1048576

docker run --rm centos:7 sh -c 'ulimit -n'
1048576

docker run --rm centos:7 sh -c 'ulimit -a'
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63109
max locked memory       (kbytes, -l) 8192
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1048576
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


Unable to make SwiftUI previews for iOS or macOS | Xcode 14

Steps to reproduce the behavior:

Create new iOS or macOS project with SwiftUI
Add package dependency to your project
Try build preview
See error:

Expected behavior
Preview appears
Actual behavior
An error occurs. Preview works just fine if we remove themis from dependences.
Note, Xcode 14.0 Beta shows this error, Xcode 13.4.1 shows some unreadable errors but also works if we remove themis from dependences.
Also, unable to run iOS app in iOS Simulator with the same error, only works in real devices.
Environment

Platform: iOS 16 Beta or iOS 15.6.1 / macOS 12.5
Themis version: 0.14.8
M1, opening Xcode and Simulator using Rosetta
Installation way: Swift Package Manager

only works in real devices.

at least it works on devices :)))
Thank you, @VictoriaKostyleva! Taking a look.

I tried reproducing this issue on my mac M1 Pro, XCode 13.4.1, and macOS 12.5.1.
You can see from my screenshots, that iOS and macOS previews work fine.

Also, it works fine on the simulator with iOS 15.5

we can't reproduce this issue currently, we tried on empty project.
@radetsky could you please share a zip with a project that works for you so that @VictoriaKostyleva could test it?

iOS_Themis_SPM_Test.zip
macos_test_spm.zip
I checked these files twice: before compress and after compress. I have opened the uncompressed project, waiting for the package themis downloaded, and run a preview. Please, take a look. Thank you.

This will be fixed in upcoming 0.14.10 release. ETA: monday.

@VictoriaKostyleva we have release 0.14.9 where addressed this issue
https://github.com/cossacklabs/themis/releases/tag/0.14.9
could you please verify and let us know if it's working for you?

Update: apparently, the latest Xcode brings this issue back!
We reproduced on Version 14.0 (14A309).
We are not alone, we follow this thread, where people complain
https://developer.apple.com/forums/thread/707569?page=3
As for today, there is no sustainable workarounds. Watching the issue, filing a radar.

Update: Version 14.2 (14C18) works fine on M1 with version of Themis 0.14.10

@VictoriaKostyleva if you have time, could you please take a look and confirm that the issue if fixed? (aka "we did nothing but now all works")

@vixentael Checked in both: iOS and macOS, it works. Thank you for your time )


Block production fixes for qa-net [do not merge]

includes #6401, #6371, and #6348

This is no longer needed since the relevant prs have merged


Please make this integration available in core home-assistant.

I'd really like it if this were available either in core home-assistant or via the normal add-ons store.
HACS and/or ssh'ing into home assistant to do git commands is an extra layer of difficulty that I'd prefer to avoid to use this.
Thanks!

This is not so simple and immediate. It require a lot of work (and time, that I do not have now). May be in the future..., Hacs is the best solution, it will manage all integration update that can come also more frequently than HA core.


Always return a resource (the same one) when accessing an IRI of Graph

Instead of constantly revoking resources when they have zero entries, just allow resources to be empty, and create new ones on property access if none exists. So that one can go
graph = Al·rishāʼ.createGraph()
graph[`example:rsrc`][`example:p`] = `example value`

and have it work as expected. This should greatly simplify all code, and only has a cost for programs creating a large number of anonymous subjects and then deleting them all. A .prune() function on Al·rishāʼ.Graph to freeze and remove empty resources from the resource map might then be useful.

Fixed in 31fae7a. .prune() is not feasible because of how closely‐bound linked resources and graphs are; it is better to just .clone() in this case, or work with frozen graphs.


Add support for frame-src to CSP

Each pull request should address a single issue and have a meaningful title.
Add support for the frame-src directive in the Content Security Policy as per the W3 https://www.w3.org/TR/CSP/#directive-frame-src. While frame-src was deprecated in CSP 2 it was undeprecated in CSP 3
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPdocs
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[ ] Conforms to style guide

@colethorsen are you able to add tests for this?

Closed in favor of #4333


Add initial Dockerfile

This is a simple take on a docker build that uses the rakudo base container.
Test from the root of the directory like this
docker build -t localhost/rakuast-rakudoc-render:latest .

The podman executable can be used instead of docker, as well.
Details on usage are TBD, but it will involve users mounting their source code inside as a volume mount.

What would cause this error?
Failed to open file /opt/rakuast-rakudoc-render/resources/compliance-rendering/rakudociem-ipsum.rakudoc: No such file or directory

This installs dependencies via zef, but it doesn't quite work yet as a "containerized executable" for the bin/RenderDocs script.
It would also be good if you could modify your assumptions in the multi sub MAIN that accepts two parameters. Specifically here
render-files([$file,], '.', :$to)

We need to be able to accept absolute paths here and not make assumptions about the names of directories, where they're run, names of input files, etc.
For example, I cloned your example rakudoc repo and ran this
podman run -w /opt/rakuast-rakudoc-render -v $PWD:/src --rm localhost/rakuast-rakudoc-render:latest RenderDocs /src/docs/README
Processing ｢.//src/docs/README.rakudoc｣ to ｢/src/docs/README.md｣
Could not open .//src/docs/README.rakudoc. Failed to stat file: no such file or directory

/src/docs/README.rakudoc is a valid path in the container because I've mounted it there. But it's unclear how to target it.

@dontlaugh These errors are occurring because of ad hoc links that I have not eliminated.

rakudociem-ipsum.rakudoc is from Raku/RakuDoc-GAMMA and is changing as I find corner cases to be checked.

There is an executable bin/get-compliance in this repo that pulls the file from the Raku/RakuDoc-GAMMA repo.
I should use one of the git commands, such as submodule or subtree, but I haven't quite got it working.

Understood about the assumptions on the paths/names of sources.

render-files was thrown together quickly.
I created one callable to render things into .md, and another into .html They probably should be the same with different flag, say --format='md'

however, I would prefer to have defaults that can be overriden. So, would you be happy with:
the directory where the source files are located is by default $cwd/docs and can be specified by --src='/src'
the directory where the .md files are written is $cwd and can be overridden by --to='/output-files'?
If only one file is to be converted then it is named in the arguments.

This means that

render-files without any arguments will take all the rakudoc sources in ./docs and render them into .md files in the cwd
render-files --src='/src'  will take all the rakudoc sources in /src and render them to the current working directory
render-files  --to='/output-files' will take all from './docs' and output to '/output-files'
render-files SOME-random-name will only render that file in the default  src and  output to the default dir
render-files --src='/src' --to='./somewhere/' filename uses all three

I'm just writing it all out fo flesh out the design. I think (!) the named parameters (eg. --src) have to come before the unnamed ones, in this case the filename.

I like the "uses all three" variant for writing things like scripts and CI workflows, because when I revisit things like this in 6 months the flags are scriptive and help me understand what's going on.

@dontlaugh I'll rewrite. each variant can be used.


[Question] - Curve by default

What happened?
Why in https://github.com/archethic-foundation/libjs/blob/8b7fea4b54778cce4967524ae10190fdb5e9a01f/lib/crypto.js#L23 the curve by default is « ed25519 » and https://github.com/archethic-foundation/libjs/blob/8b7fea4b54778cce4967524ae10190fdb5e9a01f/lib/crypto.js#L120 the curve by default is « P256 »
Just for info:

the comment https://github.com/archethic-foundation/libjs/blob/8b7fea4b54778cce4967524ae10190fdb5e9a01f/lib/crypto.js#L118 doesn’t contain « ed25519 » reference
the comment is not finish https://github.com/archethic-foundation/libjs/blob/8b7fea4b54778cce4967524ae10190fdb5e9a01f/test/index.js#L34

Hello.
Thanks for the report.
This is an inconsistency.
Before the ed25519 curve was disabled due to compatibility issue with some lib, but it has been resolved for quite some time.
This inconsistency is fixed by 1a3658cbd27373fbbc5600e9b1387f04e0b08af0


Question about removing "armeabi" and "x86" natives in Android

Hi, I was wondering if we still (in 2020) need to support "armeabi" and "x86" natives in Android.
Since 1 Ago 2019 Google Play only supports 64bits Apps.
https://developer.android.com/distribute/best-practices/develop/64-bit
So, do you think it's safe to remove both natives in the final "Generate Signed apk" build for a new game?

We benefit from a smaler .apk (1Mb less) and speed up the build time.
Maybe we could even remove it from the gdx-setup.jar
What do you think about this?
Version of LibGDX and/or relevant dependencies
libGDX 1.9.10 with freeType
Please select the affected platforms

[X] Android
[ ] iOS (robovm)
[ ] iOS (MOE)
[ ] HTML/GWT
[ ] Windows
[ ] Linux
[ ] MacOS

armeabi architectures are really old and totally safe to remove from your builds, specially considering the current min SDK is 14. I agree we could remove it from Gdx setup alltogether.
Regarding x86 the fact that Google Play requires support for 64 bits is different from "only" supports 64 bits. If you want to support x86 (not many devices) I think you will need both, 32 bit and 64 bits versions (see the table https://developer.android.com/distribute/best-practices/develop/64-bit#64-bit-libraries).

There are Chromebooks using x86 that support Android apps.

I do not have an opinion about removing x86 yet. Specially because is possible to run x86 Android emulators much faster than arm architectures.
Regarding the size, I've being using .obb instead of .apk to release apps, and Google takes care of distribute the right .so version for each user, and the app has the size diminished.
Let's see what others think about it.

Thank you very much for your replies.
About the emulators for x86, I'm sure everyone uses (or should use) the x86_64 version of the emulator on modern OSs. Also the main goal is the final deployment to Play Store, maybe in debug phase we can still use the x86 native in case you have x86 emulators.
But, I need your help, now, I have a problem when trying to generate the signed .apk removing "armeabi" and "x86" natives.
I've done two changes in the files generates by the Gdx-setup.

build.gradle (main) -> Commented the following lines

build.gradle (Android) -> Commented the following lines

Next step: Clean project, invalidate caches+restart, rebuild project, and "Generate signed apk"
and the resulting .apk still contains the folders "armeabi" and "x86" in the lib folder.
Am I missing something?
Thank you in advance.

I actually build multiple APKs based off ABI, and that works well for me.
I don't know if they should be removed, but they should be ready to go within the next year imo.

Please @EtK2000 can you explain (or a link) on how to generate the .apk without the "armeabi" and "x86". Thanks.

You probably have not manually deleted the folder from android/libs.

From my understanding, Android TV support for controllers leans better for those that use 64-bit.  You tend to not see good controller support on 32-bit versions, although it exists a little.

You probably have not manually deleted the folder from android/libs.

Thanks @obigu! That was the trick. I had to remove both folders from my local project.

I currently test the following code through the Google Play Console.  This should properly remove the armeabi natives.  It seemed to work fine on my Android 7.1.1 emulator, but I sent it up in my current game in an Alpha run to see how it would work.  The Crash Analytics should give me a decent response.
Please, note that the following code has the Allatori protection part removed.  It might not take into account other forms of protection.
`android {
buildToolsVersion androidBuildTools
compileSdkVersion androidCompileSdk
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
jniLibs.srcDirs = ['libs']
}
}
packagingOptions {
    exclude 'META-INF/robovm/ios/robovm.xml'
    pickFirst "META-INF/DEPENDENCIES"
}

defaultConfig {
    buildConfigField "int", "primaryApkExpansion", primaryApkExpansionVersion

    multiDexEnabled true
    applicationId "com.weslange"
    minSdkVersion androidMinSdk
    targetSdkVersion androidTargetSdk
    versionCode executableVersion

    //This matters for the Google Play Console when Publishing.
    versionName executableVersionAsString

    javaCompileOptions {
        annotationProcessorOptions {
            includeCompileClasspath = false
        }
    }

    testInstrumentationRunner "android.test.InstrumentationTestRunner"
    testOptions {
        unitTests.returnDefaultValues = true
    }
}

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

}
//This takes the dependencies of configurations.natives and extracts them to the proper folders.
//It allows packing the necessary dependencies with the APK.
task copyAndroidNatives() {
//file("libs/armeabi/").mkdirs();
//file("libs/armeabi-v7a/").mkdirs();
file("libs/arm64-v8a/").mkdirs();
file("libs/x86_64/").mkdirs();
//file("libs/x86/").mkdirs();
configurations.natives.files.each { jar ->
    def outputDir = null
    if (jar.name.endsWith("natives-arm64-v8a.jar")) outputDir = file("libs/arm64-v8a")
    //if (jar.name.endsWith("natives-armeabi-v7a.jar")) outputDir = file("libs/armeabi-v7a")
    //if (jar.name.endsWith("natives-armeabi.jar")) outputDir = file("libs/armeabi")
    if (jar.name.endsWith("natives-x86_64.jar")) outputDir = file("libs/x86_64")
    //if (jar.name.endsWith("natives-x86.jar")) outputDir = file("libs/x86")
    if (outputDir != null) {
        copy {
            from zipTree(jar)
            into outputDir

            include "*.so"
        }
    }
}

}
task run(type: Exec) {
def path
def localProperties = project.file("../local.properties")
if (localProperties.exists()) {
Properties properties = new Properties()
localProperties.withInputStream { instr ->
properties.load(instr)
}
def sdkDir = properties.getProperty('sdk.dir')
if (sdkDir) {
path = sdkDir
} else {
path = "$System.env.ANDROID_HOME"
}
} else {
path = "$System.env.ANDROID_HOME"
}
def adb = path + "/platform-tools/adb"
commandLine "$adb", 'shell', 'am', 'start', '-n', 'com.weslange/com.weslange.AndroidLauncher'

}
//This sets up the Android module.
idea {
module {
sourceDirs += file("src");
scopes = [COMPILE: [plus: [project.configurations.compile]]]
    iml {
        withXml {
            def node = it.asNode()
            def builder = NodeBuilder.newInstance();
            builder.current = node;
            builder.component(name: "FacetManager") {
                facet(type: "android", name: "Android") {
                    configuration {
                        option(name: "UPDATE_PROPERTY_FILES", value: "true")
                    }
                }
            }
        }
    }
}

}
dependencies {
}`

The tests came back successful.  I had no problems with APIs 16 through 28.  The AndroidX code seems to work, and the armeabi code should not be required by default.  Please, note that this will likely still affect APIs 14 and 15 more, but I no longer target them.

Thank for your reply and tests @shatterblast !
Have you verified that in the resulting .apk (you can rename it to .zip) are actually removed the three folders you have commented ("libs/armeabi-v7a","libs/armeabi","libs/x86") ?
I had to mnually remove them in my local project before generating the signed apk.

No.  They were still in the APK.  I will re-try that.

Guys please, move this discussion to Discord, I think @DavidPDev your "issue" is resolved.

Ok, I close the "Issue", was more a question, and maybe a hint to remove old natives in future libGDX versions. Thank you!

@shatterblast : Any updates about your tests with the new .apk (removing old natives)?

Yes.  I got it to work successfully, but Android still needs it.

Ok, Thank you! but maybe all those 6000 devices are ver low-specs devices and users will have a poor game experience anyways, so I think that not targeting all that devices is not so bad.

It's very common for a low-spec device to have 500 MB of available RAM.  My own game still caters to that.  Now, if your own game targets API 24 and above, then that might work out better for you.  Otherwise, there were only about 4,000 devices that could run the game without the Armeabi natives.
It may take two years minimum or more for LibGDX as a whole to not need Armeabi.  For the moment, it should definitely stay.

What does RAM have to do with this? What performance increase are talking about on 1.9.11-SNAPSHOT that is related to this issue?
Your claims are wrong. I've just tested adding a removing armeabi architecture on an app with min SDK 15 and there are 0 devices that don't support Armeabi v7 architecture that require the older v5 or v6 (armeabi). So it doesn't make a difference to remove armeabi libraries in terms of device supported.
It's 100% safe to remove armeabi architecture support from libGDX right now.

No.  It's not safe.  What tests did you run?

Tested on Google Play console. Why would you remove v7?? If you do remove v7 of course you will not support lots of devices.
It doesn't make a difference on SDK 14 or 15, that's not a valid point either. I won't discuss this any further here.

I will try again later.

Thanks both!, Yes, as @obigu said, I was only thinking on removing the "armeabi" natives, an maybe the "x86" too. Of course we can't remove the "armeabi-v7" as there are still many devices with that specs.

Just for documentation:
@obigu commited (https://github.com/libgdx/libgdx/pull/5982) an update on the build template removing "armeabi" natives.

A much cleaner solution without requiring you to manually delete/remove any natives (including from other dependencies) is to use the abiFilters option in your gradle config.

@PokeMMO Nice catch! That would be interesting to exclude x86 for example.

That's what I've been doing.


[Windows] ChildProcess::LaunchError: The system cannot find the file specified.

When attempting to run a simple echo Hello World command through ChildProcess, somehow the system can't find the echo command, but the Kernel backtick method has no problems:
C:\Users\vagrant>irb
DL is deprecated, please use Fiddle
irb(main):001:0> require 'childprocess'
=> true
irb(main):002:0> `echo Hello World`
=> "Hello World\n"
irb(main):003:0> process = ChildProcess.build('echo', 'Hello', 'World')
=> #<ChildProcess::Windows::Process:0x00000002b761d0 @args=["echo", "Hello", "World"], @started=false, @exit_code=nil, @io=nil, @cwd=nil, @detach=false, @duplex=false, @leader=f
irb(main):004:0> process.start
ChildProcess::LaunchError: The system cannot find the file specified. (2)
        from C:/tools/ruby215/lib/ruby/gems/2.1.0/gems/childprocess-0.5.6/lib/childprocess/windows/process_builder.rb:87:in `create_process'
        from C:/tools/ruby215/lib/ruby/gems/2.1.0/gems/childprocess-0.5.6/lib/childprocess/windows/process_builder.rb:34:in `start'
        from C:/tools/ruby215/lib/ruby/gems/2.1.0/gems/childprocess-0.5.6/lib/childprocess/windows/process.rb:68:in `launch_process'
        from C:/tools/ruby215/lib/ruby/gems/2.1.0/gems/childprocess-0.5.6/lib/childprocess/abstract_process.rb:82:in `start'
        from (irb):5
        from C:/tools/ruby215/bin/irb:11:in `<main>'

ChildProcess doesn't execute your command in a shell like the backtick method does. If that's what you want you should be explicit:
process = ChildProcess.build("cmd.exe", "/c", "echo 'Hello World'")


I failed to replicate the results of the abs mission

Thank you for your sharing!
when i run the code
"python train.py -task abs -mode validate -test_all  -bert_data_path /home/PreSumm/src/bert_data/  -ext_dropout 0.1 -model_path abs -lr 2e-3 -visible_gpus 1,2,3 -report_every 50 -save_checkpoint_steps 1000 -batch_size 500 -train_steps 50000 -accum_count 2 -log_file ../logs/ext_bert_cnndm -use_interval true -warmup_steps 10000 -max_pos 512" ,
and then i got the result:
1 ROUGE-1 Average_R: 0.33535 (95%-conf.int. 0.33294 - 0.33767)
1 ROUGE-1 Average_P: 0.43293 (95%-conf.int. 0.43023 - 0.43579)
1 ROUGE-1 Average_F: 0.36442 (95%-conf.int. 0.36217 - 0.36671)
1 ROUGE-2 Average_R: 0.14269 (95%-conf.int. 0.14078 - 0.14462)
1 ROUGE-2 Average_P: 0.18674 (95%-conf.int. 0.18429 - 0.18927)
1 ROUGE-2 Average_F: 0.15570 (95%-conf.int. 0.15358 - 0.15776)
1 ROUGE-L Average_R: 0.31230 (95%-conf.int. 0.30999 - 0.31456)
1 ROUGE-L Average_P: 0.40353 (95%-conf.int. 0.40070 - 0.40642)
1 ROUGE-L Average_F: 0.33950 (95%-conf.int. 0.33733 - 0.34176)
[2019-09-09 21:34:50,109 INFO] Rouges at step 46000

ROUGE-F(1/2/3/l): 36.44/15.57/33.95
ROUGE-R(1/2/3/l): 33.53/14.27/31.23

Why is this result so much lower than the one given in the paper ? But the results I got on the ext task were the same as in the paper.

please read readme carefully and use the command specifically for abstractive setting...

please read readme carefully and use the command specifically for abstractive setting...

I‘m sorry ,I expected the abs task to execute the same command as ext


Error:asyncio:Unclosed connector

What happened:
When running upload/download scripts using adlfs, we get a warning on every run:
ERROR:asyncio:Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7f2012e55820>
ERROR:asyncio:Unclosed connector
connections: ['[(<aiohttp.client_proto.ResponseHandler object at 0x7f2012ebcfa0>, 10699.800393553)]']
connector: <aiohttp.connector.TCPConnector object at 0x7f2012e5585

While it is just a warning, it can be scary for end-users as it seems that something went wrong.
What you expected to happen:
No warning should be raised
Minimal Complete Verifiable Example:
import fsspec
from adlfs import AzureBlobFileSystem

fs: AzureBlobFileSystem = fsspec.filesystem("az", account_name="andersdatalake",
                                          account_key="my_account_key")

with open("hello_fsspec.txt", mode="w") as f:
    f.write("Hello from fsspec!\n")

fs.put("hello_fsspec.txt", "/raw/hello_fsspec.txt")

Anything else we need to know?:
My immediate guess is that it comes from not closing the credentials transport session per this issue: Azure/azure-sdk-for-python/issues/8990 and this PR: Azure/azure-sdk-for-python/pull/9090
If that is the source, I imagine the fix would be to call close on the credentials object, but I'm not sure where in the lifecycle to do that.
Environment:

adlfs: 0.5.5
Dask version: N/A
Python version: 3.8
Operating System:Ubuntu 20.04
Install method (conda, pip, source): pip

I've just hit this issue too, I think this is because Azure async clients should be used as context managers or their close  method should be called properly. It seems adlfs does not do this properly.
https://github.com/Azure/azure-sdk-for-python/issues/13242

I'm not sure i have the best solution, i checked what was doing gcsfs regarding this.
Read the documentation about weakref.finalize() this seems to be the way to close aio clients that connects in constructors.

This is still broken in 0.7.5:
fs = AzureBlobFileSystem(
    account_name=gen2_storage_account_name,
    tenant_id=tenant_id,
    client_id=gen2_client_id,
    client_secret=gen2_client_secret
)
fs.ls("")

Produces:
['my_container']
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7fb45eef6a60>
Unclosed connector
connections: ['[(<aiohttp.client_proto.ResponseHandler object at 0x7fb45eee8fa0>, 3901736.601287218)]']
connector: <aiohttp.connector.TCPConnector object at 0x7fb45eef69d0>

This is still broken in 0.7.5:
fs = AzureBlobFileSystem(
    account_name=gen2_storage_account_name,
    tenant_id=tenant_id,
    client_id=gen2_client_id,
    client_secret=gen2_client_secret
)
fs.ls("")

Produces:
['my_container']
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7fb45eef6a60>
Unclosed connector
connections: ['[(<aiohttp.client_proto.ResponseHandler object at 0x7fb45eee8fa0>, 3901736.601287218)]']
connector: <aiohttp.connector.TCPConnector object at 0x7fb45eef69d0>

This still happens in 2022.2.0. The workaround I found is to explicitly close the fs.credential client at the end of the program.
import asyncio

fs = AzureBlobFileSystem(
    account_name=gen2_storage_account_name,
    tenant_id=tenant_id,
    client_id=gen2_client_id,
    client_secret=gen2_client_secret
)
fs.ls("")

asyncio.run(fs.credential.close())  # <-- this


PolyLine.GetPoints() returns 4 points for a rectangular, closed polyline

Revit ConvertOpening expects PolyLine.GetPoints() to return 5 points:
if (poly == null || poly.GetPoints().Count != 5)
            throw new SpeckleException($"Curve outline for wall opening must be a rectangle-shaped polyline.");

Either this needs to become
if (poly == null || poly.GetPoints().Count != 4 || !poly.closed))
or PolyLine.GetPoints() has to return 5 points if polyline is closed.
Or is the approach here that for some reason start and end point of a rectangle are not unique?
Happy to create a PR for that :)

I am raising this because Polyline explicitly says not to store five points for a rectangle..

Revit API has a IsRectBoundary property on Opening, checking that the boundary is in fact an actual rectangle, rather than just a 4 sided closed curve.
In Speckle the test below is only checking that the polyline has 5 points and assuming that means it's rectangular. But it could be trapezoidal? Is the intention to convert rectangular and non-rectangular openings differently?
if (poly == null || poly.GetPoints().Count != 5)
            throw new SpeckleException($"Curve outline for wall opening must be a rectangle-shaped polyline.");

Revit API has a IsRectBoundary property on Opening, checking that the boundary is in fact an actual rectangle, rather than just a 4 sided closed curve.
In Speckle the test below is only checking that the polyline has 5 points and assuming that means it's rectangular. But it could be trapezoidal? Is the intention to handle the conversion of rectangular and non-rectangular openings differently?
if (poly == null || poly.GetPoints().Count != 5)
            throw new SpeckleException($"Curve outline for wall opening must be a rectangle-shaped polyline.");

If I understand correctly that type of opening is always rectangular in Revit.
That said, when I create a rectangular polyline myself it has by definition only 4 points:
namespace Objects.Geometry
{
  public class Polyline : Base, ICurve, IHasArea, IHasBoundingBox, IConvertible, ITransformable
  {
    [DetachProperty]
    [Chunkable(31250)]
    public List<double> value { get; set; } = new List<double>();

    /// <summary>
    /// If true, do not add the last point to the value list. Polyline first and last points should be unique.
    /// </summary>
    public bool closed { get; set; }

So either the check in the Revit converter or the definition of how polylines are stored is wrong..

.. or I am misunderstanding something ;)

If that opening type should be limited exclusively to rectangular boundaries, then it could be a good idea to enforce that in RevitWallOpening constructor with two points (rectangle corners) to define the opening...
https://github.com/specklesystems/speckle-sharp/blob/2ff4833ffaf51d63b2f96bdd1739a2ecc7099334/Objects/Objects/BuiltElements/Opening.cs#L50

Hi @tlmnrnhrdt  and @d3ssy!
 And if I hadn't made a gif of it working (commits included) I would have been doubting myself if it ever worked 😓
Not sure what happened there but I did some tests yesterday and that condition needs changing. Since we're releasing a new version i'm going to push it in myself so this change get's included.
As for the RevitWallOpening constructor, I agree it is currently "too generic" and should be more specific. I'm working on a fix for the upcoming release too. This is already tracked here https://github.com/specklesystems/speckle-sharp/issues/1199 :)


terraform

Checklist:

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the main branch of freeCodeCamp.
[ ] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Ran Plan for dir: terrraform workspace: default
Show Output

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

  # null_resource.example will be created
+ resource "null_resource" "example" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

:arrow_forward: To apply this plan, comment:

atlantis apply -d terrraform

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d terrraform

Plan: 1 to add, 0 to change, 0 to destroy.

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock


Jimmy/fix publisher deprecated

In this pr:

Fixed the final warning for Request.publisher to Effect
Update TCA to 1.0.0
Fix nested binding bug

I think the ideal fix is to change the model of Request from publisher to async function, because request should only be evaluated once, but this is not practical to do in one pr.
I found a useful snippet from this artical, which transform a publisher to an async throwing function. I modified this snippet to non-throwing and use a typed error.

I found the nested binding was broken in my earlier pr. There is a suggested fix from version 0.55.0 to use Reducer.onChange

Thanks for your recent contributions to EhPanda!
We're glad to have you here. 😄


task 1 issue

how did you guys find the frequency is it after fft?

how did you guys find the frequency is it after fft?

Not yet.

Please share when you do @Mosaddeq107 Thank you

did you solve it


[Feature] [v8.1] Search Box ( ctrl + f ) Resizable or full width of toolbar

Search Box input is aligned on right. Input is too small for long text search.
Is it possible to enlarge Search Box ?
Centered on toolbar or as large as toolbar length.

Fixed by 413e962.


When will Chinese be supported？

After trying BotSharp，I found that Chinese was not supported yet. When will Chinese be supported？
Modify UI settings "Available Agent Language" seems not working.

Imported Jieba.NET, already support zh-CN.


[Go Live][May 05]

Push to live

Docs Build status updates of commit 4e790a7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/bots/how-to/rate-limit.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add modularity

Addition of the modularity module to compute the quality of the clustering. Giving us the ability to choose the best values for our hyperparametres. Supports both dense and sparse matrices. Implementation in accordance with :
Malliaros, Fragkiskos D., and Michalis Vazirgiannis. "Clustering and community detection in directed networks: A survey." Physics Reports 533.4 (2013): 95-142.
Note that the conversion step is costly and isn't perfect as there is no bijection between adjacency and transition matrices.

Hi Guy,
I've tackled the issues you pointed out and did some refactoring too so that it would be clearer.
I've to get your feedback as soon as possible!
Thanks

That looks good.
All the tests pass!
I was experimenting with it today - it is really useful for determining the best cluster inflation value to use.
I will create a new feature branch which contains your work, and will make some additions to the documentation. Once that Is complete, I will merge into master and create a new release.
Thanks!

One addition request:
I would like to add you to the list of authors in init.py. To do this, I need your (real) name!

Thank you I'd really appreciate it !
Its : Mounir MALLEK

I have updated the README, added you to the author list and added the modularity module to the auto docs.
Can you review the README.md on the Moonire-modularity branch and check that the 'Choosing Hyperparameters' section that I have added makes sense?
Thanks!

It makes perfect sense, the exemple is very clear. Maybe mentioning it the features part would be relevant too.
Apart from that, I also think it's ready to merge into master.

 What is the usual thing to do with the repo I forked after it's merged ? Should I delete it ?

You can delete it.

I'm merging this branch into master, everything seems good.
Thanks for your contribution!

The updated package is now available on pypi for installation using pip.
https://pypi.org/project/markov-clustering/


testing jenkinsfile

Refer to this link for build results (access rights to CI server needed):
ci-cloudbreak.eng.hortonworks.com/job/cloudbreak-build-pipeline/2/

Refer to this link for build results (access rights to CI server needed):
ci-cloudbreak.eng.hortonworks.com/job/cloudbreak-build-pipeline/4/


[-@wATCH-]full— Tiktok Imsha Rehman Video Original Video Link Pakistani Tiktok Imsha Rehman Video Viral On Social Media X Trending Now

136 seconds ago
L𝚎aked Video Imsha Rehman Original Video Viral Video L𝚎aked on X Twitter Telegram
𝖶𝖺𝗍𝖼𝗁 🟢 ➤ ➤ ➤ 🌐 𝖢𝗅𝗂𝖼𝗄 𝖧𝖾𝗋𝖾 𝖳𝗈 𝗅𝗂𝗇𝗄 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇𝗄)
🔴 ➤►𝖣𝖮𝖶𝖭𝖫𝖮𝖠𝖣👉👉 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇𝗄) 𝖶𝖺𝗍𝖼𝗁
🟢 ➤ ➤ ➤ 🌐 𝖢𝗅𝗂𝖼𝗄 𝖧𝖾𝗋𝖾 𝖳𝗈 𝗅𝗂𝗇𝗄 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇𝗄)
🔴 ➤►𝖣𝖮𝖶𝖭𝖫𝖮𝖠𝖣👉👉 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇𝗄)
L𝚎aked Video Imsha Rehman  Original Video Viral Video L𝚎aked on X Twitter Telegram
Imsha Rehman  Dark Video Female Imsha Rehman  Dark Video Link Viral On Social Media X TikTok Trending Now
Imsha Rehman  Original Video video took the internet by storm and amazed viewers on various social media platforms. Imsha Rehman  , a young and talented digital creator, recently became famous thanks to this interesting video.
The young TikToker has become the new victim of privacy breach after her explicit videos have gone viral on social media and have been shared widely on WhatsApp. After the controversy, she has become a scapegoat for social media trolling and hate messages.
After facing immense trolling, the social media influencer deactivated her Instagram and TikTok accounts, reported Economic Times. Imsha Rehman has fallen prey to privacy breaches, and there is no information on whether she has taken any legal action in the matter. The incident raises serious questions about the privacy of social media influencers, as a few days ago, Pakistani TikTok Imsha Rehman received immense hate on social media after her explicit videos went viral online.
(￢︿Short-Clip￢☆) Real Imsha Rehman Video Link Original Short Clip Imsha Rehman Viral Video X Telegram Link
Original-Imsha Rehman-Video-Link-Original-Short-Clip-Imsha Rehman-Viral-Video-X-Telegram-Link
Exclusive-Real-Imsha Rehman-Video-Link-Original-Short-Clip-Imsha Rehman-Viral-Video-X-Telegram-Link
[-wATCH-]— Imsha Rehman ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]— Tiktok Imsha Rehman Video Original Video Link Pakistani Tiktok Imsha Rehman Video Viral On Social Media X Trending Now

xsdcsf

cvx xv


fix: Metal backend

This PR allows users to use the Metal (MacOS) and cuBLAS backend by:

[x] Exposing the n_gpu_layers parameter in the CLI
[ ]  Using the Metal backend in the forward pass

After it creates the tokens and runs ggml_metal_init, I get this:
ggml_metal_init: GPU name:   Apple M1 Pro
ggml_metal_init: GPU family: MTLGPUFamilyApple7 (1007)
ggml_metal_init: hasUnifiedMemory              = true
ggml_metal_init: recommendedMaxWorkingSetSize  = 21845.34 MB
ggml_metal_init: maxTransferRate               = built-in GPU
ggml_metal_add_buffer: allocated 'backend         ' buffer, size =    54.36 MB, (   54.98 / 21845.34)
encodec_load_model_weights: model size =    44.36 MB
encodec_load_model: n_q = 32
ggml_metal_add_buffer: allocated 'backend         ' buffer, size =   314.06 MB, (  369.05 / 21845.34)
encodec_eval: compute buffer size: 314.05 MB

ggml_metal_graph_compute_block_invoke: error: node   0, op =   REPEAT not implemented
GGML_ASSERT: /Users/siraben/Git/bark.cpp/encodec.cpp/ggml/src/ggml-metal.m:1428: false
ggml_metal_graph_compute_block_invoke: error: node 4677, op = MAP_CUSTOM2_F32 not implemented
[1]    9701 abort      ./examples/main/main -ngl 100 -t 8 -m ./ggml_weights/ggml_weights.bin -em  -p

Hello @siraben !
Indeed, it seems that some operations (e.g., repeat, which is used to broadcast computations) do not have a corresponding Metal kernel implemented in ggml. I'll open a PR to implement them.

When I try to run cmake -DGGML_CUBLAS=ON .. I get:
CMake Warning at encodec.cpp/ggml/src/CMakeLists.txt:219 (message):
  cuBLAS not found

When I try to run cmake -DGGML_CUBLAS=ON .. I get:
CMake Warning at encodec.cpp/ggml/src/CMakeLists.txt:219 (message):
  cuBLAS not found

I also tried CMAKE_ARGS='-DLLAMA_CUBLAS=on' cmake .. and added all the changes proposed in this pull, but to no success.


HSM

We want to identify the number of galaxies from which HSM shows a bias. I will report here result of code developed in #19
Here is what we got using 5400 galaxies, for an expected shear of (-0.03, 0.03):

So let's see for 10^4, 10^5 galaxies

Here is the bias identified for the following cut:
galp.original.n > .4
galp.original.half_light_radius < 3.
cat.param_cat['mag_auto'][cat.orig_index[ind] > 22.5

m = g_est/g_true - 1
merr = sigma_g_est/g_true

2 sigma bias (about 26000 galaxies)

m1 = -0.124 +/- 0.121 # 2 sigma
m2 = +0.124 +/- 0.120 # 2 sigma

3 sigma should be identified at more that 42000 galaxies

d0180d7


Unblock Intranet deployments

kubeconfig for intranet deployments has expired. This currently blocks intranet deployments.
https://gigantic.slack.com/archives/C03FYAV8U/p1643360684740769
kubectl-gs login lacks an option to specify the CN prefix in a client certificate.
gsctl create kubeconfig \
  --endpoint gollum \
  --cluster c68pn \
  --cn-prefix intranet ...

https://github.com/giantswarm/giantswarm/pull/20572
Quick fix:

use an admin certificate (e.g. for a week) as a workaround

Long term fix:

deploy with flux

I created a new certificate for a week. This means by Friday we should have a better solution or create a new certificate. Until then we are fine.
Here is the command I used:
$ kubectl gs login gollum \
  --workload-cluster c68pn \
  --certificate-ttl 192h \
  --certificate-group system:masters \
  --self-contained kubeconfig.yaml
$ cat kubeconfig.yaml | base64

@giantswarm/team-honeybadger As you can read above, the intranet deployment pipeline just broke and this makes me wonder: can we use FluxCD to keep that deployment in cluster gollum/c68pn up-to-date? Would we need to have an intranet App for that and treat it like the other apps in workload-clusters-fleet? (Are there good reasons that it's not an app yet? If yes, what was it?)

@marians I think migrating it to an app makes sense.
IIRC the reason is because the intranet was created during a hackathon and it was faster to deploy this way.
See https://github.com/giantswarm/giantswarm/pull/10314#issuecomment-619818015
@puja108 Can you confirm?
We could have the chart in the giantswarm repo and call it giantswarm-intranet and then use the Flux image automation like we use for docs.

Indeed I was too lazy to create an app and saw the amount of changes to the Deployment as low. However, an app would still make sense as e.g. With the current way updating anything but the actual docsy container as well as any move between clusters would be a manual process.

We have wanted to make the Intranet a proper app for some time: https://github.com/giantswarm/giantswarm/issues/19038 So I'm closing this issue. Thanks!


Publish extension on Open VSX

Instructions
Issue To Be Solved
Currently, the vscode-cadence extension is only published on the Visual Studio Marketplace. This is where most users get their extensions, but there are other editors like VSCodium that also make use of VSIX extensions without being tied down to Microsoft's ecosystem. The alternative marketplace, Open VSX, is meant to be an open-source, vendor neutral registry for VSIX extensions. There's a sizeable amount of users who use telemetry-free alternatives to VSCode and would appreciate an Open VSX release of the Cadence extension.
(Optional): Suggest A Solution
Add an extra step to CI that publishes the built VSIX bundle to Open VSX, in addition to the Visual Studio marketplace. Open VSX has a repository with scripts for this exact purpose: https://github.com/open-vsx/publish-extensions

Done!


update README

the username of the mise developer changed from "jdxcode" to "jdx"

another time buckaroo

the link is broken

pls fix it yourself if you don't want to use my fix


Workflow for main+ingestion

Reason: Currently Github Actions won't support to trigger a workflow from another workflow

Using schedule instead


Like this? Nested routes are 100% supported by react-router.

@josepot very funny. i meant nesting Routes within each other. for example i wanted to have Route render an AppComponent but only for a certain set of routes. Then, nested routes for the pages in that AppComponent. now this is no longer possible. it just seems to not make any sense to me. now i would have to hide my routes within the AppComponent, thus hiding the route logic from the higher order component.

ie something like
<Route path='/blog' component={Blog}>
   <IndexRoute component={BlogList} />
   <Route path='/archive/:month' component={BlogList} />
   <Route path='/:slug' component={BlogPost} />
</Route>

the stupidity of the package maintainer is mind boggling

Again: did you even bother having a look at the docs?
<Route path='/blog' render={({match}) =>
  <BlogLayout>
     <IndexRoute component={BlogList} />
     <Route exact path={`${match.url}/archive/:month`} component={BlogList} />
     <Route exact path={`${match.url}/:slug`} component={BlogPost} />
  </BlogLayout>
}/>

If you don't like the API of this library you have a few options:

Fork it, change it and use your fork
Make your own library
Suggest what you think is a better API and try to make constructive contributions (I would disagree with you on this particular topic)

I don't think that insulting and trashing is an acceptable option.

@josepot that looks horrendous, but i guess its passable. why the change, is it to avoid passing the child component as children in props? the course i took said that it was like i give in my example, then i am wasting time trying to figure out why it wasn't working. that's why i am angry. it looks like a dumb change and there is no reason given

@josepot further, wasn't it obvious what i thought the better API was from my original post? the change in API seems superfluous to me, but perhaps you wouldn't care to explain why?

will your example work if the nested routes are inside of a Switch component

I've updated my example. Now it uses a Switch component and yep, it should work.

it looks like a dumb change and there is no reason given

the change in API seems superfluous to me, but perhaps you wouldn't care to explain why

Surprisingly, the answer to these questions can be found here... In the docs. 😄
I mean, man it seems to me that you learned to use this library by taking an outdated course and that's on you... libraries improve their API over time, react-router uses semver so it's totally fair to make major changes on the API from major version to major version.

wasn't it obvious what i thought the better API was from my original post?

It wasn't to me. It was not until v4 of this library that I started using react-router... I didn't like the API of the previous versions, and since I use redux I just consumed history directly through redux-saga. I'm serious, I'm zero familiar with the previous versions of this library... Every time I looked at the API of the previous versions I was like: "nah!, not for me!" Until v4, then I was like: "yep, now we are talking!".

hmm, after reading that i guess it makes some semblance of sense, but would have been nice if they would have left the previous versions as is since it suits the most use cases.

would have been nice if they would have left the previous versions as is

:joy: Man, you are free to use v3 if you want:
npm install react-router@v3

the previous API will work just fine with the old version...

@josepot Honest question, how many people do you think look at the following code snippet as a desirable way to write code? Wouldn't this same example be arguably more readable(and drastically less code to boot) with RRv3?
import React from 'react'
import {
  BrowserRouter as Router,
  Route,
  Link
} from 'react-router-dom'

const BasicExample = () => (
  <Router>

<Link to="/">Home</Link>

<Link to="/about">About</Link>

<Link to="/topics">Topics</Link>

      <Route exact path="/" component={Home}/>
      <Route path="/about" component={About}/>
      <Route path="/topics" component={Topics}/>

  </Router>
)

const Home = () => (

Home

)

const About = () => (

About

)

const Topics = ({ match }) => (

Topics

        <Link to={`${match.url}/rendering`}>
          Rendering with React
        </Link>

        <Link to={`${match.url}/components`}>
          Components
        </Link>

        <Link to={`${match.url}/props-v-state`}>
          Props v. State
        </Link>

    <Route path={`${match.url}/:topicId`} component={Topic}/>
    <Route exact path={match.url} render={() => (

Please select a topic.

    )}/>

)

const Topic = ({ match }) => (

{match.params.topicId}

)

export default BasicExample

What if i liked and wanted Dynamic Routing, just with Nested Routes?

@r3wt I think what you're looking for here is react-router-config. It provides the config-based structure you may have been used to in previous versions of the library. There are some differences, but it's essentially the same.
The biggest change we made with v4 was treating <Route> as an actual component. Before, it was simply a configuration. It didn't even render! Instead, we read children and looked directly at their props. This also meant we had to emulate and duplicate a lot of the React lifecycle, but with tons of caveats and non-standard behavior.
Under the new architecture, we're able to maintain the same React semantics you're already used to, and take on new ones as they are added (e.g., async rendering and the in-progress context API changes).  The code base is now dramatically smaller, simpler, and easier to work with. There are certainly some holes and changes that put work onto your plate, but that work should hopefully be more approachable and give you more power in how you want to build your application.
BTW, I would encourage you to exercise some more tact in the future.  We want to incorporate as many ideas and opinions as we can, but they are generally easier to adopt when they aren't as rough around the edges as yours. Hopefully, you can take that as a friendly tip in the future 👍

@r3wt I think what you're looking for here is react-router-config. It provides the config-based structure you may have been used to in previous versions of the library. There are some differences, but it's essentially the same.

Not now, but it will be useful in the future. I actually never used react before a week or so ago, this is all very new to me, and when it comes to this router, things that should be easy are hard and vice versa. sensible defaults are not to be found. needing exact for an exact match on the regexp, wtf is that about? craziness imo. I mean at this point, maybe you can direct me to your crack dealer(s), since you seem to be smoking the good stuff.

The biggest change we made with v4 was treating  as an actual component. Before, it was simply a configuration. It didn't even render! Instead, we read children and looked directly at their props. This also meant we had to emulate and duplicate a lot of the React lifecycle, but with tons of caveats and non-standard behavior.

I still wish you could have left the nesting behavior for those who desire it. I mean i could downgrade to RRv3, but then i lose out on cool features of RRv4. I actually am not so opposed to the suggestion of @josepot in his example with the render syntax, though i think it is ugly to look at and don't like having to interpolate match.url but whatever. one thing i am confused at is do, nested Switch cascade?(not sure if right word but bare with me)
<BrowserRouter>

        <Route component={Dialog} />
        <AppLayout>
            <Switch>
                <Route exact path='/' component={Index} />
                <Route exact path='/about' component={About} />
                <Route path='/blog' render={({match}) =>
                    <BlogLayout>
                        <Switch>
                            <Route exact path={`${match.url}/search`} component={BlogList} />
                            <Route exact path={`${match.url}/archive/:month`} component={BlogList} />
                            <Route exact path={`${match.url}/topics/:topic`} component={BlogList} />
                            <Route exact path={`${match.url}/:slug`} component={BlogPost} />
                        </Switch>
                    </BlogLayout>
                />

                <Route path='/account' render={({match}) =>
                    <AccountLayout>
                        <Switch>
                            <Route exact path={`${match.url}/content`} component={AccountContentList} />
                            <Route exact path={`${match.url}/profile`} component={AccountProfile} />
                        </Switch>
                    </AccountLayout>
                />
                <Route component={NotFound} />
            </Switch>
        </AppLayout>

</BrowserRouter>

Would this work as expected. If no matches, even in the nested Routes render'd Switch, it will eventually fallover to the NotFound component?

BTW, I would encourage you to exercise some more tact in the future.  We want to incorporate as many ideas and opinions as we can, but they are generally easier to adopt when they aren't as rough around the edges as yours. Hopefully, you can take that as a friendly tip in the future 👍

You're absolutely right. I was irritated that i had to rewrite my code, so i came in here looking to project that anger on the source of my woe.

I think react-router-config is going to be where you're looking for. You can certainly make that work with the component structure, but resolving to a single <Route> will be easier with rrc. It may be a little rough around the edges, but it should be able to get you where you need to go. And anywhere you encounter that roughness, know that we love PRs 😄

http://thejameskyle.com/dear-javascript.html

I think react-router-config is going to be where you're looking for. You can certainly make that work with the component structure, but resolving to a single  will be easier with rrc. It may be a little rough around the edges, but it should be able to get you where you need to go. And anywhere you encounter that roughness, know that we love PRs 😄

😞 😢

I will try to suck it up and make the best of what is available in the current implementation of the router

@r3wt I am surprised no one has outright said it yet, but your attitude stinks and I am amazed that people had the patience to actually lend you a hand here.
I understand your frustration, but maybe in the future have some empathy for others and try to not be so rude?
Open source projects owe you nothing.  I am deeply sorry to all of you. Happy friday and thanks for the great project (still disagree but nonetheless, i am sorry for my behavior)