Prism does not take the "required" property into account when validating body param

Prerequisites
{
  "swagger": "2.0",
  "paths": {
    "/pet": {
      "get": {
        "produces": ["application/json"],
        "consumes": ["application/json"],
        "parameters": [
          {
            "in": "body",
            "name": "body",
            "required": false,
            "schema": {
              "type": "object",
              "properties": {
                "id": {
                  "type": "integer",
                  "format": "int64"
                }
              }
            }
          }
        ],
        "responses": {
          "200": {
            "schema": {
              "type": "string"
            }
          }
        }
      }
    }
  }
}

Steps to reproduce

Start prism with the provided endpoint2. curl -X POST http://<IP_ADDRESS>:4010/pet3. Observe output

Expected
Should return 200 and a lorem ipsum response
Actual
Returns an error
{"type":"https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY","title":"Invalid request body payload","status":422,"detail":"Your request body is not valid: [{\"path\":[\"body\"],\"code\":\"type\",\"message\":\"should be object\",\"severity\":0}]"}
Context
We currently don't check the required field when validating body. The proposed solutions is that HttpBodyValidator  should extend HttpParamsValidator class.

Confirmed. This is happening because the body schema in content is not a regular JSON Schema and needs to be transformed as well.


Update CircleCI config

Why?
It was a little bit old.
What?

Use latest Xcode version.
See if we can use the M1 runner instead of Intel.

Version Change
No changes to the library

"See if we can use the M1 runner instead of Intel." -> Nope


Support remote types served by https

Hey, love the concept of this plugin.
I'm currently serving my dts.tgz TAR from an https enforced CDN.
I get the following error:
(node:13580) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_PROTOCOL]: Protocol "https:" not supported. Expected "http:"
    at new ClientRequest (_http_client.js:155:11)
    at request (http.js:50:10)
    at Object.get (http.js:54:15)
    at node_modules\webpack-remote-types-plugin\lib\index.js:15:24
    at new Promise (<anonymous>)
    at downloadFile (node_modules\webpack-remote-types-plugin\lib\index.js:13:12)
    at downloadFederationTypes (node_modules\webpack-remote-types-plugin\lib\index.js:40:29)

It looks like the "http" library doesn't support HTTPS.
https://github.com/ruanyl/webpack-remote-types-plugin/blob/592f3eb73f72b6df3a2baa36c6dfb9a77ea23a99/src/index.ts#L13

Do you think it would be possible to switch between the "https" and "http" libraries based on the url endpoint?

I'm happy/would like to put a PR in for it, if you think the idea is good

@denis-heka sounds good to me, PR is welcome :)

@denis-heka sounds good to me, PR is welcome :)

PS open-source\webpack-remote-types-plugin> git push origin support-https
ERROR: Permission to ruanyl/webpack-remote-types-plugin.git denied to DenisKent.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Got a working branch but unable to push to github to make a PR. Do I need some permissions? Thanks

@denis-heka You need fork this repo first and then make a PR

@denis-heka You need fork this repo first and then make a PR

🤦


Dump blocks to file in machine-readable format

This is covered in the 'raw blocks logging' section of this document.

This is done, closing.


README

A README would help other people know what's going on here

Created a README for this effective alpha version, but we need to keep it up to date as we implement other features


Menus don't handle item selection properly

In Swing, when you use the keyboard to select items, the item under the mouse doesn't keep the selected state if you don't touch the mouse:

But in Jewel, they do:

This is likely because we're abusing the "focused" and "hovered" states instead of keeping track of the Selected state which is the semantically correct one to associate this behaviour with.

submenus shouldn't need a click to open
This issue fixed in #161

@fscarponi can you look into this please?

Another issue is that sub-menus don't close when you hover a different item on the parent.


Bug/fix sessions load

React-transmission doesn't read/save to cookies necessary data (compact, etc.). Sort of bundled up #34 here since I realized react-transmission at its current state does not support this.
NOTE: used master as a starting point, which re-introduces some bugs already fixed in other pull requests (iirc https://github.com/fcsonline/react-transmission/pull/33).

All preferences should be save in server as we were talking before. The rest of preferences like UI ones could be stored in the client but I think that cookies are not the best approach. IMHO localstorage is a better approach.

Completely agree with @fcsonline here, if we need to store data on client side localstorage is a good option.

Hello!
Note that I'm not saving any server side pref, all of the preferences I'm saving here are client-side only (view options, sort, etc.).
As I noted on https://github.com/fcsonline/react-transmission/issues/34 I agree that localstorage is the best option. I opted to use cookies for feature-parity, because transmission-web uses cookies.
However I guess an even better option is only to initially hydrate the preferences using cookies, but persist them using localstorage, which will allow us to transparently carry over transmission-web preferences while using localstorage in the future. Of course this has the disadvantage of not supporting older browsers, but since we're using screw_ie8, flex, etc., I'm thinking we're supporting modern browsers only anyway.
Let me know what you think!

After reviewing the original application we realized that they are storing information in cookies as you said and implemented. It's quite mind blowing.
IMO storing information in cookies just to remember what you chose is a bad pattern used years ago. We have localStorage alternative that is better and doesn't impact to every single request size we do to the server. In terms of feature parity is good to implement this feature to restore UI selections but not implementing it in the old way is a tradeoff that we can assume becuase we are not breaking the contract between client and server.
On the other hand, if we store/serialize a JSON in some localStorage value, we can get rid of all those parsing string types that always are a source of bugs.

Hey, slr been busy lately.
Yup that's true enough. I guess when transmission-web was deployed it made sense as no browser supported cookies back then, but at this point I agree that using cookies to support older browsers is detrimental.
I think that using the "read from cookies to hydrate initially then save to localStorage" is the best solution. I'll submit a PR once I have the time!

Fixed it.
There's a failing test here, cause as I mentioned, this reintroduces the pause filter bug and since it's been merged the bug's caught by the test. I'll decouple the stores and add a filteredTorrents selector and let the components aggregate the data.

localStorage is supported for all browsers since 2009. You can check it here: http://caniuse.com/#search=localstorage
I think that we don't need the fallback, remove all the cookie stuff and simplify the code.

Good point!

:recycle: rebase from master please

Can you rebase this branch, please?

Closing this PR. If you rebase it, just publish it again


getProfile does not update at the same time of getOwner

Let's assume I want to register this free ENS domain myensname.eth.
In my application I check in every block if myensname.eth has been registered via polling.
Inside my app, I call the functions .getProfile and .getOwner.
  const provider = new ethers.providers.JsonRpcProvider(INFURA_NODE);
  await ENSInstance.setProvider(provider);

  provider.on("block", async () => {
    const ensProfileObject = await ENSInstance.getProfile(
      "myensname.eth"
    );

    const ensRegisteredObject = await ENSInstance.getOwner(
      "myensname.eth"
    );

    console.log(ensProfileObject)
    console.log(ensRegisteredObject)

}

Before registration, I have two undefined as output of the console.log
    ensProfileObject: undefined
    ensRegisteredObject: undefined

then I register the ENS on https://app.ens.domains/
After the registration I get this:
    ensProfileObject: undefined
    ensRegisteredObject: {
          registrant: '0x...402',
          owner: '0x...402',
          ownershipLevel: 'registrar'
        }

Expected:
Both .getProfile and .getOwner should return an object with the actual information
Actual:
Only .getOwner returns the object, .getProfile returns undefined

the subgraph needs to be up to date with the block in which the registration is done, nothing we can really do about the lag at the moment (although we are looking into it)


Fix code scanning issue: URL opening

Tracking issue for:

[x] https://github.com/SettRaziel/bsi_cert_bot/security/code-scanning/1

Done with #26.


deps: bump document ready version

Fixes https://github.com/bendrucker/document-ready/issues/2#issuecomment-230455428

Tests pass, merg! 🚄🚋🚋🚋🚋


Curious use of h64 immediately truncated down to 32 bits

The package is currently doing XXH.h64(...), then taking the result and calling toNumber() on it. This drops the most significant 32 bits, giving you effectively the same result as if you'd just used XXH.h32(...) instead of h64 (maybe even the exact same output if one is an extension of the other in xxhash). I don't think this is a big problem - 32 bits should still be enough entropy - but it does look kindof odd; wondering if it's intentional, and if so what the reason is?
(Sidenote: thankyou for making this! :blush: Nice implementation. It's very strange that the most widely used JS bloom filter implementation uses one number per bit, insanely wasteful given the whole point of bloom filters is to be space-efficient)

Nice catch :D
Yeah this seems to indeed not be using 64 bits and I assume 32 bits is fine for this as well.
This package was actually made for the luca app which is a german covid tracing app. We needed an efficient bloom filter implementation for anonymous data retrieval. Sadly the only js bloom filter implementation I could find was extremely inefficient since it used a js number instead of 1 bit (so 64 times the memory)


Documentation for LabGraph Installation on MacOS

Description
Installation documentation is added for macOS 12.x and 11.x.
Readme is updated.
Type of change

[x] Documentation update. No changes have been made to the code itself.

@celikbasak thank you so much for this new documentation, I have been struggling with setting up labgraph on my MacOS for two days now, and I kept facing this error

Thanks to your documentation I'm finally able to run labgraph on my personal machine 😊


Windows bot keeps resources locked

The builds in #11318 failed because some resources are locked on the Windows bot. @brendandahl @yurydelendik Could one of you take a look?

Restarted it, let me know if that doesn't work.


MySQL changes not reflected in Postgres

Hi,
I'm test driving pg_chameleon, but I've hit a snag. None of the changes in MySQL show up in Postgres (both tables and rows). I've put all the relevant information I can think of into https://gist.github.com/samplesizeofone/bf9019e8ff0dcb272405afa3c47c7d09 (pg_chameleon config, the relevant lines from my deploy, logged output, test sql, and some of sch_chameleon.*).
It looks like information is making it to sch_chameleon.t_log_replica. I'm logged in as vagrant, which should be the replica user.
Any help is very appreciated.
Thanks!

Hi, thanks for the report. I'll have a look this week and when back from holiday.
In the meanwhile can you please give me this query output after the init replica?
Select * from sch_chameleon.t_replica_tables?
Thanks for the feedback

Hi, I'm afraid my lack of postgres experience is showing. I was setting the schema to 'spaeth' and conflating that with the database 'spaeth'. My boss took a look and was able to see the replication happening, so it's all good.
Thanks for getting back to me, though. I appreciate it.
All the best.

I tested the configuration you posted on gist on my virtual machine (virtualbox I have no experience with vagrant unfortunately) and it worked fine.
Thanks for the report. I hope the software will be useful :-)
I'm closing the issue.
Kind regards


Deploy empty config

should resolve #286
2nd attempt of #284
Previously there was an issue where if you had two alerting groups where one had only old-type alarms, and one had new-type alarms, you got an exception. This was because the first would end up with a default config for the new-type alarms, but this only happens if another config defines some new-type alarms, as otherwise the part that handles the new-type alarms is skipped entirely.
Added test case for this and set the list so it isn't null.

closing as superseded by #303


Using a found in raid keycard in-raid before extracting causes it to be unable to sell on flea

Using a keycard you find in a raid, in that same raid, increments the NumberOfUsages property. This causes the getItemQualityModifier method to try dividing by 0 in this code:
else if (key && key.NumberOfUsages > 0)
{
    // keys - keys count upwards, not down like everything else
    const maxNumOfUsages = itemDetails._props.MaximumNumberOfUsage;
    result = (maxNumOfUsages - key.NumberOfUsages) / maxNumOfUsages;
}

Which results in a target of 0 for the average offer price in RagfairController
Steps to reproduce:

Use attached profile
Try to sell green keycard on flea for 42m
Check server and see the % sell chance

Attachments

65ca93be000160c79002374e.zip (82 KiB)

Originally written by DrakiaXYZ

Fixed with https://dev.sp-tarkov.com/SPT-AKI/Server/commit/fbbc410182c289798ddc45ad0eb743233bbcad36
Thanks again Drakia

Originally written by Kaeno


Is it possible to share DTO classes?

I'm generating a client for 2 swagger specs. I have used external $ref in one of the swagger specs to refer to some definitions in the other one.
I did this to avoid DRY violation, however when I generate the C# clients for each (separately), they each have independent DTO classes.
Edit to add Also, the versions created through the external-$ref often have unhelpful names eg Anonymous, Anonymous2, ..
How can I make them share DTOs?

Currently there are only two options to achieve this:

Preprocess the two swagger specs and merge them into a single one
Generate both independently and exclude DTO classes from one spec with the excludedTypeNames setting

Ok, thanks


Decide on metadata schema

Metadata should come in two forms:

Optional metadata - probably in the form of a dictionary

description
publications
any other notes

Mandatory metadata

'Pretty' name
Supported platforms - {win32, win64, linux32, linux64, osx64, all}

These should be used in conjunction with the yaml for validating an experiment.

The metadata framework has largely been implemented as of 444290ae0816c10264ea2f79f0e205c132d2a883, but now we need to get a feel for what keys we actually need and set the schema appropriately.


 It will take some refactoring, but it will ensure better data integrity than the current naive/optimistic transaction model that the package employs.
It would be necessary (and a big improvement) to change the way that transactions originating on the client are handled.  Instead of make client side collection updates, thereby pushing a bunch of inserts, updates and removes through the allow/deny rules, the whole set of transaction data can be sent to the server via a method, processed there, and the db changes made or rejected based on identical permission checks to those used for transactions originating on the server.  This would lead to much more maintainable/reliable app code, preserve latency compensation, and allow for a proper 2-phase commit for transactions originating from both client and server.

It would be really impressive if you managed to implement this. I wish i could help but its a bit beyond me atm.

I can sort of see my way through how it would go down, but it would take a big refactor of the whole package. There are a bunch of other things that are higher on the priority on my priority list at the moment, as this package works in its current form, even though I know the approach used is pretty brittle.  One day ...

:+1:

0.7.0 gets very close to achieving this.  Leaving the issue open until I can make it bulletproof.

0.7.5 is another big improvement.  The approach is not as solid as the one outlined in the mongo docs, but it makes fewer writes and, with oplog/mergebox pressure to consider it's "good enough" for the moment.

Amazing!


Pagination with code cleanup

This is branched off of Jake and Remy's work (https://github.com/bolt-design-system/bolt/pull/780), I have added some updates to improve the component.
Enhancements

Semantic nav markup
Accessibility updates with additional aria tags and visually hidden micro copy
Circle background is more scalable and not just limited to 3-digit numbers
Alignment can now be controlled by layout objects such as grid, instead of always centering without any opt-out
Bolt spacing variables are used instead of px units
Nested inline-blocks and absolute positioning are removed in favor of flexbox

Fantastic work everyone! Let's merge this in! :-D 👍

💯 freakin love the team effort to get this bad boy shipped! 🎉


Add Ruby 2.4.1 to Travis CI

Hello!
Is it possible to add Ruby 2.4 to Travis CI?
Thanks.

@sparklemotion ping ping :)

The commit here is clearer than the more recent PR


Shims and dev dependencies are inluced in the final package

I'm having a simple DNT setup and for whatever reason my GH action doesn't care about npmignore and it ends up putting all the files in the npm folder.
My scripts/npm.ts script:
import { build, emptyDir } from<EMAIL_ADDRESS>
await emptyDir('./npm')

await build({
  packageManager: 'pnpm',
  entryPoints: ['./mod.ts'],
  outDir: './npm',
  scriptModule: false,
  shims: { deno: 'dev', weakRef: 'dev' },
  test: true,
  compilerOptions: {
    lib: ['DOM', 'ES2021.String'],
    target: 'ES2022',
  },
  package: {
    name: '@stauro/filebase-upload',
    version: Deno.args[0],
    description: 'Minimal library to upload files on Filebase S3 API. Partially based on AWS SDK v3.',
    license: 'Apache-2.0',
    repository: {
      type: 'git',
      url: 'git+https://github.com/stauroDEV/filebase-upload.git',
    },
    bugs: {
      url: 'https://github.com/stauroDEV/filebase-upload/issues',
    },
    devDependencies: {
      '@types/node': 'latest',
      '@types/aws4': 'latest',
    },
    files: ['esm'],
    publishConfig: {
      access: 'public',
    },
  },
  postBuild() {
    // steps to run after building and before running the tests
    Deno.copyFileSync('LICENSE', 'npm/LICENSE')
    Deno.copyFileSync('README.md', 'npm/README.md')
  },
})

My GH action:
name: Publish

on:
  push:
    tags:
        - '*'

env:
    FILEBASE_TOKEN: ${{ secrets.FILEBASE_TOKEN }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v1
        with:
          deno-version: v1.x
      - name: Get tag version
        if: startsWith(github.ref, 'refs/tags/')
        id: get_tag_version
        run: echo TAG_VERSION=${GITHUB_REF/refs\/tags\//} >> $GITHUB_OUTPUT
      - name: install pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 8.x
      - uses: actions/setup-node@v3
        with:
            node-version: '18.x'
            registry-url: 'https://registry.npmjs.org'
      - name: npm build
        run: deno run -A ./scripts/npm.ts ${{steps.get_tag_version.outputs.TAG_VERSION}}
      - name: npm publish
        if: startsWith(github.ref, 'refs/tags/')
        env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: cd npm && npm publish

In npm files I see DNT stuff that shouldn't be there:

@talentlessguy I think it's because the package.json has "files": ["esm"] in it. If you remove that, I believe it will work.

@dsherret this helped, thank you very much


Cobalt jewel minion prefixes always shows

As stated in title currently when creating a Cobalt Jewel it always shows the minion prefixes no matter what value they have. Example
I found this bug while running version 1.4.4 however it still remains after I updated to version 1.4.5
Reproduction steps:

Create a new build
Search for cobalt jewel in the premade items list and double click to enter edit mode
It should now have 2 minion prefixes that is both at 0%

I tested to see if this was a problem with the other 2 jewels but it only happens to the cobalt jewel.

Thanks for the report; this is fixed in the next update.


CppFlow/ops.h missing

Following the installation instructions, when running 'make' I have this error:
/Users/david/Desktop/cppflow/examples/load_model/main.cpp:3:10: fatal error: 'cppflow/ops.h' file not found #include "cppflow/ops.h"
I might be messing a step?

Hi @Dazzid
How did you install the library? I have to update the docs, because since one of the latest PR, now the library is installed with CMake. You can check that PR here, and follow the instructions.
Hope this helps!

Hi @serizba
Ok, I'm testing with the M1 Pro chip and tried opening the Terminal in Rosseta mode but now I have this error:
ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
The instructions I'm following are this:
git clone https://github.com/serizba/cppflow
cd cppflow
mkdir build
cd build
cmake -DBUILD_EXAMPLES=ON ..
make -j8

So, the error is produced when you do the make -j8? What else is said in the error message?

yes, after make -j8
ld: symbol(s) not found for architecture arm64 clang: clangclang: : clang: clang: error: error: linker command failed with exit code 1 (use -v to see invocation)linker command failed with exit code 1 (use -v to see invocation)error:  error:  linker command failed with exit code 1 (use -v to see invocation) linker command failed with exit code 1 (use -v to see invocation) error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [examples/multi_input_output/multi_input_output] Error 1 make[2]: *** [examples/load_model/load_model] Error 1 make[2]: *** [examples/efficientnet/efficientnet] Error 1 make[2]: *** [examples/tensor/tensor] Error 1 make[2]: *** [examples/eager_op_multithread/eager_op_multithread] Error 1 make[1]: *** [examples/load_model/CMakeFiles/load_model.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [examples/multi_input_output/CMakeFiles/multi_input_output.dir/all] Error 2 make[1]: *** [examples/tensor/CMakeFiles/tensor.dir/all] Error 2 make[1]: *** [examples/efficientnet/CMakeFiles/efficientnet.dir/all] Error 2 make[1]: *** [examples/eager_op_multithread/CMakeFiles/eager_op_multithread.dir/all] Error 2 make: *** [all] Error 2

But, doesn't it says what is the symbol that it's not found?

Ah, I copied the last part
[  9%] Linking CXX executable efficientnet
[ 18%] Linking CXX executable load_model
[ 27%] Linking CXX executable eager_op_multithread
[ 36%] Linking CXX executable tensor
[ 45%] Linking CXX executable multi_input_output
ld: warning: ld: warning: ld: warning: ld: warning: ignoring file /usr/local/lib/libtensorflow.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64ignoring file /usr/local/lib/libtensorflow.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /usr/local/lib/libtensorflow.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64ignoring file /usr/local/lib/libtensorflow.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ignoring file /usr/local/lib/libtensorflow.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
"_TFE_DeleteContext", referenced from:
Undefined symbols for architecture arm64:
"_TFE_DeleteContext", referenced from:
Undefined symbols for architecture arm64:
"_TFE_DeleteContext", referenced from:
Undefined symbols for architecture arm64:
"_TFE_DeleteContext", referenced from:
Undefined symbols for architecture arm64:
"_TFE_DeleteContext", referenced from:
cppflow::context::~context() in main.cpp.o
cppflow::context::~context() in main.cpp.o
cppflow::context::~context() in main.cpp.o
cppflow::context::~context() in main.cpp.o
cppflow::context::~context() in main.cpp.o
"_TFE_DeleteContextOptions", referenced from:
"_TFE_DeleteContextOptions", referenced from:
"_TFE_DeleteContextOptions", referenced from:
"_TFE_DeleteContextOptions", referenced from:
"_TFE_DeleteContextOptions", referenced from:
cppflow::context::context(TFE_ContextOptions*) in main.cpp.o
cppflow::context::context(TFE_ContextOptions*) in main.cpp.o
cppflow::context::context(TFE_ContextOptions*) in main.cpp.o
cppflow::context::context(TFE_ContextOptions*) in main.cpp.o
"_TFE_DeleteOp", referenced from:
"_TFE_DeleteOp", referenced from:
cppflow::context::context(TFE_ContextOptions*) in main.cpp.o
cppflow::mul(cppflow::tensor const&, cppflow::tensor const&) in main.cpp.o
cppflow::fill(cppflow::tensor const&, cppflow::tensor const&, TF_DataType) in main.cpp.o
cppflow::add(cppflow::tensor const&, cppflow::tensor const&) in main.cpp.o
cppflow::tensor::shape() const in main.cpp.o
cppflow::add(cppflow::tensor const&, cppflow::tensor const&) in main.cpp.o
"_TFE_DeleteOp", referenced from:
cppflow::string_format(std::__1::vector<cppflow::tensor, std::__1::allocatorcppflow::tensor > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, long long) in main.cpp.o
"_TFE_DeleteOp", referenced from:
"_TFE_DeleteTensorHandle", referenced from:
cppflow::tensor::tensor(TFE_TensorHandle*) in main.cpp.o
"_TFE_DeleteOp", referenced from:
cppflow::tensor::tensor(TF_DataType, void const*, unsigned long, std::__1::vector<long long, std::__1::allocator > const&) in main.cpp.o
"_TFE_DeleteTensorHandle", referenced from:
(...)
ld: symbol(s) not found for architecture arm64
"_TF_SessionRun", referenced from:
cppflow::model::operator()(std::__1::vector<std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, cppflow::tensor>, std::__1::allocator<std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, cppflow::tensor> > >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >) in main.cpp.o
"_TF_TensorByteSize", referenced from:
std::__1::vector<float, std::__1::allocator > cppflow::tensor::get_data() const in main.cpp.o
cppflow::tensor::tensor(TF_DataType, void const*, unsigned long, std::__1::vector<long long, std::__1::allocator > const&) in main.cpp.o
ld: symbol(s) not found for architecture arm64
"_TF_TensorData", referenced from:
std::__1::vector<float, std::__1::allocator > cppflow::tensor::get_data() const in main.cpp.o
cppflow::to_string(cppflow::tensor const&) in main.cpp.o
cppflow::tensor::tensor(TF_DataType, void const*, unsigned long, std::__1::vector<long long, std::__1::allocator > const&) in main.cpp.o
"_TF_TensorType", referenced from:
std::__1::vector<float, std::__1::allocator > cppflow::tensor::get_data() const in main.cpp.o
ld: symbol(s) not found for architecture arm64
clang: clangclang: : clang: clang: error: error: linker command failed with exit code 1 (use -v to see invocation)linker command failed with exit code 1 (use -v to see invocation)error:
error:
linker command failed with exit code 1 (use -v to see invocation)
linker command failed with exit code 1 (use -v to see invocation)
error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [examples/multi_input_output/multi_input_output] Error 1
make[2]: *** [examples/load_model/load_model] Error 1
make[2]: *** [examples/efficientnet/efficientnet] Error 1
make[2]: *** [examples/tensor/tensor] Error 1
make[2]: *** [examples/eager_op_multithread/eager_op_multithread] Error 1
make[1]: *** [examples/load_model/CMakeFiles/load_model.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [examples/multi_input_output/CMakeFiles/multi_input_output.dir/all] Error 2
make[1]: *** [examples/tensor/CMakeFiles/tensor.dir/all] Error 2
make[1]: *** [examples/efficientnet/CMakeFiles/efficientnet.dir/all] Error 2
make[1]: *** [examples/eager_op_multithread/CMakeFiles/eager_op_multithread.dir/all] Error 2
make: *** [all] Error 2

I see.
What version of TF C API are you using?

https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-darwin-x86_64-2.8.0.tar.gz
Maybe the wrong one?

I don't know. I only have linux and cpu-linux-x86_64-2.8.0 works fine in my computer. I think is some issue with the MacOS compiler. Have you checked this?

Same error on my ubuntu system too with cpu-linux-x86_64-2.8.0 version of the C API.

I have the same error :
git clone https://github.com/serizba/cppflow.git
Cloning into 'cppflow'...
remote: Enumerating objects: 1011, done.
remote: Counting objects: 100% (313/313), done.
remote: Compressing objects: 100% (139/139), done.
remote: Total 1011 (delta 195), reused 250 (delta 170), pack-reused 698
Receiving objects: 100% (1011/1011), 8.70 MiB | 5.32 MiB/s, done.
Resolving deltas: 100% (483/483), done.
Checking connectivity... done.
root@amax:/data/tenforflow# date
2023年 02月 15日 星期三 17:40:31 CST
root@amax:/data/tenforflow# cd cppflow/examples/load_model
root@amax:/data/tenforflow/cppflow/examples/load_model# mkdir build
root@amax:/data/tenforflow/cppflow/examples/load_model# cd build/
root@amax:/data/tenforflow/cppflow/examples/load_model/build# cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.5s)
-- Generating done (0.0s)
-- Build files have been written to: /data/tenforflow/cppflow/examples/load_model/build
root@amax:/data/tenforflow/cppflow/examples/load_model/build# make -j
[ 50%] Building CXX object CMakeFiles/load_model.dir/main.cpp.o
/data/tenforflow/cppflow/examples/load_model/main.cpp:36:25: fatal error: cppflow/ops.h: No such file or directory
compilation terminated.
CMakeFiles/load_model.dir/build.make:75: recipe for target 'CMakeFiles/load_model.dir/main.cpp.o' failed
make[2]: *** [CMakeFiles/load_model.dir/main.cpp.o] Error 1
CMakeFiles/Makefile2:82: recipe for target 'CMakeFiles/load_model.dir/all' failed
make[1]: *** [CMakeFiles/load_model.dir/all] Error 2
Makefile:90: recipe for target 'all' failed
make: *** [all] Error 2

I have the same error : git clone https://github.com/serizba/cppflow.git Cloning into 'cppflow'... remote: Enumerating objects: 1011, done. remote: Counting objects: 100% (313/313), done. remote: Compressing objects: 100% (139/139), done. remote: Total 1011 (delta 195), reused 250 (delta 170), pack-reused 698 Receiving objects: 100% (1011/1011), 8.70 MiB | 5.32 MiB/s, done. Resolving deltas: 100% (483/483), done. Checking connectivity... done. root@amax:/data/tenforflow# date 2023年 02月 15日 星期三 17:40:31 CST root@amax:/data/tenforflow# cd cppflow/examples/load_model root@amax:/data/tenforflow/cppflow/examples/load_model# mkdir build root@amax:/data/tenforflow/cppflow/examples/load_model# cd build/ root@amax:/data/tenforflow/cppflow/examples/load_model/build# cmake .. -- The C compiler identification is GNU 5.4.0 -- The CXX compiler identification is GNU 5.4.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done (0.5s) -- Generating done (0.0s) -- Build files have been written to: /data/tenforflow/cppflow/examples/load_model/build root@amax:/data/tenforflow/cppflow/examples/load_model/build# make -j [ 50%] Building CXX object CMakeFiles/load_model.dir/main.cpp.o /data/tenforflow/cppflow/examples/load_model/main.cpp:36:25: fatal error: cppflow/ops.h: No such file or directory compilation terminated. CMakeFiles/load_model.dir/build.make:75: recipe for target 'CMakeFiles/load_model.dir/main.cpp.o' failed make[2]: *** [CMakeFiles/load_model.dir/main.cpp.o] Error 1 CMakeFiles/Makefile2:82: recipe for target 'CMakeFiles/load_model.dir/all' failed make[1]: *** [CMakeFiles/load_model.dir/all] Error 2 Makefile:90: recipe for target 'all' failed make: *** [all] Error 2

copy header file: cp -rf cppflow/include/cppflow /usr/local/include     ; worked
### then try  make again:
cppflow/examples/load_model/build# make
[ 50%] Building CXX object CMakeFiles/load_model.dir/main.cpp.o
In file included from /usr/include/c++/5/type_traits:35:0,
from /usr/local/include/cppflow/datatype.h:39,
from /usr/local/include/cppflow/tensor.h:52,
from /usr/local/include/cppflow/ops.h:38,
from /data/tenforflow/cppflow/examples/load_model/main.cpp:36:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support
^
In file included from /usr/local/include/cppflow/tensor.h:51:0,
from /usr/local/include/cppflow/ops.h:38,
from /data/tenforflow/cppflow/examples/load_model/main.cpp:36:
/usr/local/include/cppflow/context.h:57:18: error: expected ‘,’ or ‘...’ before ‘&&’ token
context(context&&) noexcept;
^
/usr/local/include/cppflow/context.h:57:20: error: invalid constructor; you probably meant ‘cppflow::context (const cppflow::context&)’
context(context&&) noexcept;
^
/usr/local/include/cppflow/context.h:57:20: error: expected ‘;’ at end of member declaration
/usr/local/include/cppflow/context.h:57:22: error: ‘noexcept’ does not name a type
context(context&&) noexcept;
^
/usr/local/include/cppflow/context.h:57:22: note: C++11 ‘noexcept’ only available with -std=c++11 or -std=gnu++11
/usr/local/include/cppflow/context.h:62:29: error: expected ‘,’ or ‘...’ before ‘&&’ token
context& operator=(context&&) noexcept;
^
/usr/local/include/cppflow/context.h:62:31: error: expected ‘;’ at end of member declaration
context& operator=(context&&) noexcept;
^
/usr/local/include/cppflow/context.h:62:33: error: ‘noexcept’ does not name a type
context& operator=(context&&) noexcept;
^
/usr/local/include/cppflow/context.h:62:33: note: C++11 ‘noexcept’ only available with -std=c++11 or -std=gnu++11
/usr/local/include/cppflow/context.h:54:47: error: ‘nullptr’ was not declared in this scope
explicit context(TFE_ContextOptions* opts = nullptr);
^
/usr/local/include/cppflow/context.h:70:28: error: ‘nullptr’ was not declared in this scope
TFE_Context* tfe_context{nullptr};
^
/usr/local/include/cppflow/context.h:70:35: error: cannot convert ‘’ to ‘TFE_Context*’ in initialization
TFE_Context* tfe_context{nullptr};
^
/usr/local/include/cppflow/context.h: In function ‘cppflow::context& cppflow::get_global_context()’:
/usr/local/include/cppflow/context.h:78:20: error: call to ‘cppflow::context::context(TFE_ContextOptions*)’ uses the default argument for parameter 1, which is not yet defined
static context global_context;
^
/usr/local/include/cppflow/context.h: In static member function ‘static TF_Status* cppflow::context::get_status()’:
/usr/local/include/cppflow/context.h:90:3: error: ‘thread_local’ was not declared in this scope
thread_local std::unique_ptr<TF_Status, decltype(&TF_DeleteStatus)>
^
/usr/local/include/cppflow/context.h:92:10: error: ‘local_tf_status’ was not declared in this scope
return local_tf_status.get();
^
/usr/local/include/cppflow/context.h: In constructor ‘cppflow::context::context(TFE_ContextOptions*)’:
/usr/local/include/cppflow/context.h:96:8: error: ‘tf_status’ does not name a type
auto tf_status = context::get_status();
^
/usr/local/include/cppflow/context.h:97:15: error: ‘nullptr’ was not declared in this scope
if (opts == nullptr) {
^
/usr/local/include/cppflow/context.h:98:5: error: ‘unique_ptr’ is not a member of ‘std’
std::unique_ptr<TFE_ContextOptions, decltype(&TFE_DeleteContextOptions)>
^
/usr/local/include/cppflow/context.h:98:39: error: expected primary-expression before ‘,’ token
std::unique_ptr<TFE_ContextOptions, decltype(&TFE_DeleteContextOptions)>
^
/usr/local/include/cppflow/context.h:98:75: error: ‘decltype’ was not declared in this scope
std::unique_ptr<TFE_ContextOptions, decltype(&TFE_DeleteContextOptions)>
^
/usr/local/include/cppflow/context.h:99:68: error: ‘new_opts’ was not declared in this scope
new_opts(TFE_NewContextOptions(), &TFE_DeleteContextOptions);
^
/usr/local/include/cppflow/context.h:100:56: error: ‘tf_status’ was not declared in this scope
this->tfe_context = TFE_NewContext(new_opts.get(), tf_status);
^
/usr/local/include/cppflow/context.h:102:46: error: ‘tf_status’ was not declared in this scope
this->tfe_context = TFE_NewContext(opts, tf_status);
^
/usr/local/include/cppflow/context.h:104:16: error: ‘tf_status’ was not declared in this scope
status_check(tf_status);
^
/usr/local/include/cppflow/context.h: At global scope:
/usr/local/include/cppflow/context.h:107:32: error: expected ‘,’ or ‘...’ before ‘&&’ token
inline context::context(context&& ctx) noexcept
^
/usr/local/include/cppflow/context.h:107:40: error: expected initializer before ‘noexcept’
inline context::context(context&& ctx) noexcept
^
/usr/local/include/cppflow/context.h:110:43: error: expected ‘,’ or ‘...’ before ‘&&’ token
inline context& context::operator=(context&& ctx) noexcept {
^
/usr/local/include/cppflow/context.h:110:51: error: expected initializer before ‘noexcept’
inline context& context::operator=(context&& ctx) noexcept {
^
In file included from /usr/local/include/cppflow/tensor.h:52:0,
from /usr/local/include/cppflow/ops.h:38,
from /data/tenforflow/cppflow/examples/load_model/main.cpp:36:
/usr/local/include/cppflow/datatype.h:43:7: error: expected nested-name-specifier before ‘datatype’
using datatype = TF_DataType;
^
/usr/local/include/cppflow/datatype.h:48:30: error: ‘cppflow::to_string’ declared as an ‘inline’ variable
inline std::string to_string(datatype dt) {
^
/usr/local/include/cppflow/datatype.h:48:30: error: ‘datatype’ was not declared in this scope
/usr/local/include/cppflow/datatype.h:48:43: error: expected ‘,’ or ‘;’ before ‘{’ token
inline std::string to_string(datatype dt) {
^
/data/tenforflow/cppflow/examples/load_model/main.cpp:55:1: error: expected ‘}’ at end of input
}
^
CMakeFiles/load_model.dir/build.make:75: recipe for target 'CMakeFiles/load_model.dir/main.cpp.o' failed
make[2]: *** [CMakeFiles/load_model.dir/main.cpp.o] Error 1
CMakeFiles/Makefile2:82: recipe for target 'CMakeFiles/load_model.dir/all' failed
make[1]: *** [CMakeFiles/load_model.dir/all] Error 2
Makefile:90: recipe for target 'all' failed
make: *** [all] Error 2

Same I constantly get the following error on Mac, Intel chip:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@Dazzid have you found a solution?
i am facing the same problem now

I changed the relative paths in main.cpp and most .h files for which this error was appearing. seems like this error has been fixed.
now I get the next error
$ make -j
[ 50%] Linking CXX executable load_model
/usr/bin/ld: cannot find -lcppflow: No such file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/load_model.dir/build.make:97: load_model] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/load_model.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

@nongrata2 not to discourage you and I am not sure if it's feasible for you, but after many trials, I switched to Pytorch which had its own set of issues but worked out in the end.

btw seems like i found a way to fix it
i used commands
git clone https://github.com/serizba/cppflow
cd cppflow
mkdir build
cd build
cmake -DBUILD_EXAMPLES=OFF ..
make -j
sudo make install

and it installed successfully

g++ -std=c++17 -o main.out main.cpp -ltensorflow
In file included from /usr/local/include/tensorflow/c/tf_tensor.h:23,
from /usr/local/include/cppflow/tensor.h:41,
from /usr/local/include/cppflow/model.h:56,
from /usr/local/include/cppflow/cppflow.h:42,
from main.cpp:2:
/usr/local/include/tensorflow/c/tf_datatype.h:47:14: error: multiple definition of ‘enum TF_DataType’
47 | typedef enum TF_DataType {
|              ^~~~~~~~~~~
In file included from /usr/local/include/cppflow/cppflow.h:35,
from main.cpp:2:
/usr/local/include/tensorflow/c/c_api.h:98:14: note: previous definition here
98 | typedef enum TF_DataType {
|              ^~~~~~~~~~~
In file included from /usr/local/include/tensorflow/c/tf_tensor.h:23,
from /usr/local/include/cppflow/tensor.h:41,
from /usr/local/include/cppflow/model.h:56,
from /usr/local/include/cppflow/cppflow.h:42,
from main.cpp:2:
/usr/local/include/tensorflow/c/tf_datatype.h:72:3: error: conflicting declaration ‘typedef int TF_DataType’
72 | } TF_DataType;
|   ^~~~~~~~~~~
In file included from /usr/local/include/cppflow/cppflow.h:35,
from main.cpp:2:
/usr/local/include/tensorflow/c/c_api.h:123:3: note: previous declaration as ‘typedef enum TF_DataType TF_DataType’
123 | } TF_DataType;
|   ^~~~~~~~~~~
In file included from /usr/local/include/tensorflow/c/tf_tensor.h:24,
from /usr/local/include/cppflow/tensor.h:41,
from /usr/local/include/cppflow/model.h:56,
from /usr/local/include/cppflow/cppflow.h:42,
from main.cpp:2:
/usr/local/include/tensorflow/c/tf_status.h:42:14: error: multiple definition of ‘enum TF_Code’
42 | typedef enum TF_Code {
|              ^~~~~~~
In file included from /usr/local/include/cppflow/cppflow.h:35,
from main.cpp:2:
/usr/local/include/tensorflow/c/c_api.h:133:14: note: previous definition here
133 | typedef enum TF_Code {
|              ^~~~~~~
In file included from /usr/local/include/tensorflow/c/tf_tensor.h:24,
from /usr/local/include/cppflow/tensor.h:41,
from /usr/local/include/cppflow/model.h:56,
from /usr/local/include/cppflow/cppflow.h:42,
from main.cpp:2:
/usr/local/include/tensorflow/c/tf_status.h:60:3: error: conflicting declaration ‘typedef int TF_Code’
60 | } TF_Code;
|   ^~~~~~~
In file included from /usr/local/include/cppflow/cppflow.h:35,
from main.cpp:2:
/usr/local/include/tensorflow/c/c_api.h:151:3: note: previous declaration as ‘typedef enum TF_Code TF_Code’
151 | } TF_Code;
error while compiling the program


Fix download links

Looks like the generator script is out of date. Manually fix the links
This will need to be fixed in the new_release script as well.
Thanks @terracatta

Testing locally, I think this works.


feat: add compile-time checking for selectors that don't exist when using index signature syntax, ie. a['my-selector'] #26

feat: add compile-time checking for selectors that don't exist when using index signature syntax, ie. a['my-selector']

@mattsjones Mind giving this a review?
I'm not sure how to get robust tests on this logic without having TypeScript as a dep and actually running it through the type-checker :/

@mattsjones Mind giving this a review?
I'm not sure how to get robust tests on this logic without having TypeScript as a dep and actually running it through the type-checker :/

TypeScript doesn't seem to like this. Here's a playground link that throws an error for this definition.
http://www.typescriptlang.org/play/?ssl=2&ssc=1&pln=3&pc=1#code/JYOwLgpgTgZghgYwgAgMIGd0FEAeAHAeyjHWQG8AoZZAbQGsIBPALmXTClAHMBdVgNwLAAJgG5kVZAHIiAIymt2nEF1EUAvhQoICIdsjisM2fERLIAvOUnU5rKVI1qgA

Huh that's interesting. Cheers.
We're running that exact version right now and I didn't see such an error come up when I manually tested this with *.d.ts files. I tweaked the playground to closer match what we do but it still gets errors.
This signals to me that merging this in would be a bad idea, though I don't understand why it's working with our build system. (Not that crazy, Webpack + ts-loader + TypeScript outputting ES5)
I'll close this for the time-being until I figure out a better solution.


is it possible to change * color

Hi,
I like zsh-autosuggestions which saves me tons of time on typing.
However, when I type "find *" whose * is in dark blue color. It is not clear on my iterm2 . It is possible to change the color for *?

This plugin does not do any coloring of text that you have already typed. It sounds like the * you’re referring to is not a suggestion but has already been typed? In that case I’m wondering if you’re using the zsh-syntax-highlighting plugin and that is what’s coloring it blue. I would check out the docs for that project and possibly ask on that GitHub repo instead.

Hi @ericfreese
Thanks! I guess you are right.
I installed zsh-syntax-highlighting and zsh-autosuggestions at the same time.
I guess it is caused by https://github.com/zsh-users/zsh-syntax-highlighting/blob/db6cac391bee957c20ff3175b2f03c4817253e60/tests/tap-colorizer.zsh#L45
I will close this issue. Thanks


Custom collector for multiple metrics

Hi! I've been looking at implementing a Prometheus collector for the recently announced tokio-metrics crate. Every scrape, I'd like to gather runtime metrics for the currently Tokio runtime. The problem is that doing so requires a non-trivial amount of up-front work to aggregate all of the stats across the N workers in the runtime, which I'd rather not do during every metric's encode function (following the custom metric example).
Instead I think it'd be ideal if there was a way to do something similar to the client_python Custom Collector example, which allows custom collectors to record values for multiple metrics at each scrape time - that'd avoid me having to duplicate work (non-atomically) on every scrape. Do you think such an API would be possible?
Alternatively if you know of another pattern to get around this, I'd love to hear it!

As you stated above, a clean solution is not possible today, i.e. would require some changes within prometheus-client. I am not opposed to supporting this use-case, though I need to put more thoughts into the design of a clean abstraction. Design suggestions are most welcome.
In the meantime would sharing some state between the custom metrics be an option? That shared state would be updated with a new aggregate by a single custom metric per scrape. Consecutive custom metrics within the same scrape don't need to aggregate themselves, but instead access the shared state.

Thanks for the reply! Yep, I thought as much, no worries - I'll have a think about potential APIs.

In the meantime would sharing some state between the custom metrics be an option? That shared state would be updated with a new aggregate by a single custom metric per scrape. Consecutive custom metrics within the same scrape don't need to aggregate themselves, but instead access the shared state.

Yeah, I've got a solution where each custom metric shares a reference to some shared state, but there's a few things about it that are suboptimal:

for the metrics to be 'static they can't hold references, so I'm having to use an Rc<RefCell<State>> instead (this isn't too bad though)
the only way I can determine whether one metric's encode call is within the same scrape as another metric's encode call is by either:

storing the Instant that the state was last updated (and only updating the state if it's more than some Duration ago), or
assuming that metrics are scraped in the same order that they're registered, so that I can set a flag in the state in the first metric's encode and unset it in the final metric's encode. I'm not super happy relying on that assumption though since it could change in future!

the only way I can determine whether one metric's encode call is within the same scrape as another metric's encode call is by either:

We could give each Prometheus scrape an ID and then make that ID available through the Encoder passed in EncodeMetric::encode. Not yet sure how much I would consider that to be a hack.

The problem is that [collecting metrics] requires a non-trivial amount of up-front work to aggregate all of the stats across the N workers in the runtime

Can you say more about this? What work is involved?

I've now changed the implementation so that comment isn't quite correct, although my current implementation still feels a bit suboptimal.
Previously I'd thrown together a cumulative method for RuntimeMonitor, which basically iterated over the workers in the pool and calculated each of the metrics on RuntimeMetrics. I would have had to call cumulative for every metric since their encode calls can't share state, though.
I do something a bit different now - I've pushed it up to http://github.com/sd2k/tokio-metrics-prometheus in case it's of any use. I'd like to get it up to crates.io soon but want to figure out #57 first!

I'm going to describe some fundamental assumptions of Prometheus, because it's not totally clear to me if these crates abide those requirements. But I'm no expert and it's entirely possible that the issues you're talking about have nothing to do with this stuff. If that's true, or if I'm telling you stuff you already know, my apologies!
Prometheus operates in a "pull" model whereby Prometheus servers scrape targets on a regular interval. Scrape means make an HTTP GET which should yield the current state of all metrics (timeseries) known to the process. But reading the current state of a metric should — with some exceptions — not be an expensive operation. The expectation is that each timeseries value is maintained as a simple primitive value, which is cheap to both read and write.
(The exception is "func" metrics, like gauge funcs, which are implemented as functions that get called during scrapes, and return values. These can be expensive! But shouldn't be. Scrapes are expected to be fast.)
So...

. . . iterated over the workers in the pool and calculated each of the metrics on RuntimeMetrics . . .

When Prometheus performs a scrape, the expectation is that the HTTP handler is doing a bunch of relatively cheap, likely atomic, reads of simple primitive values. Is that not the case here?

the only way I can determine whether one metric's encode call is within the same scrape as another metric's encode call is by either: . . .

A scrape will indeed invoke encode on a set of metrics, but encode shouldn't know anything about scrapes. Rather, encode should operate on an immutable snapshot, i.e. a copy, of a metric value, which scrapes should capture.

Indeed, we're in agreement on most things here I think! In my specific case I'm trying to instrument an external crate so I don't have the ability to increment counters or anything when it's actually happening. Instead, the tokio_metrics::RuntimeMonitor::intervals method is the only way to get hold of the state I need and it comes in the form of an iterator, which I need to advance at the start of each scrape to get the current value.
The quoted part of your comment:

. . . iterated over the workers in the pool and calculated each of the metrics on RuntimeMetrics . . .

is a (poor) workaround I had to use due to the lack of such an API 🙂 I've since switched to a much less expensive method, but that still requires sharing state between multiple custom metrics which isn't a super clean implementation.
The aim of this issue is to provide a convenient API that allows efficient scraping of multiple metrics that represent some state that's out of my control, without resorting to complex state sharing.

What I'd like is to be able to:

create a struct that represents multiple metrics (in this case, each of the tokio-metrics metrics)
implement a trait provided by the prometheus_client crate (say EncodeMetrics - note the plural)
write an implementation of something like EncodeMetrics::encode_metrics, which is similar to EncodeMetric::encode but is permitted to encode multiple metrics, not just one (which isn't permitted for the existing trait - it's assumed to be encoding a single metric)

That would allow me to do something like:
struct TokioRuntimeCollector {
    // The iterator to get data since the last scrape
    runtime_monitor_iter: Box<dyn Iterator<Item = tokio_metrics::RuntimeMetrics>>,

    // The metrics we care about
    park_count: Counter,
    busy_duration: Counter<f64, Atomic<F64>>,
    // ...other metrics here
}

impl EncodeMetrics for TokioRuntimeCollector {
    fn encode_metrics(&mut self, &mut encoder: Encoder) -> Result<(), std::io::Error> {
        // Get data since the last scrape.
        let new = self.runtime_monitor_iter.next().unwrap();

        // Update state.
        self.park_count.inc_by(new.park_count);
        self.busy_duration.inc_by(new.busy_duration.as_secs_f64());

        // Encode new state
        self.park_count.encode(&mut encoder)?;
        self.busy_duration.encode(&mut encoder)?;
        // etc
    }
}

(Note: I'm not proposing that this is an API that would actually work, but hopefully it conveys my meaning).

The Collectors example in the Golang client docs explains this in better detail than I possibly could, too.

What I'd like is to be able to:

create a struct that represents multiple metrics (in this case, each of the tokio-metrics metrics)

Check.

implement a trait provided by the prometheus_client crate (say EncodeMetrics - note the plural)

Ah! So this shouldn't be EncodeMetrics, but rather CollectMetrics. I think the disconnect here may be that client_rust doesn't currently provide a well-defined abstraction layer between collection and encoding. A registry is something that holds long-lived mutable metric values which can be mutated and collected; a collector is typically a trait implemented by a registry which yields a "snapshot" of each metric which can be encoded; and an encoder is something that encodes those fixed metrics for scraping.
tl;dr: collecting != encoding

The aim of this issue is to provide a convenient API that allows efficient scraping of multiple metrics that represent some state that's out of my control, without resorting to complex state sharing.

I think not scraping but collecting? Which I think could be solved by defining a new collector trait?

Yep, I think that's accurate! (I did find it strange that I was implementing something called encode - there's nothing encoding specific about what I'm doing.)

Cross referencing proposal here https://github.com/prometheus/client_rust/pull/82


是否可以使用raspberry pi创建tars服务器

What language are you using?
c++
What operating system (Linux, Ubuntu, …) and version?
Raspberry Pi OS / Linux
What runtime / compiler are you using (e.g. jdk version or version of gcc)
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

没试过呢, 这是啥机器? 啥OS linux的么?


A Full-Stack Example of AWS SAM

Please consider incorporating this full-stack example of the ubiquitous TodoMVC app using AWS SAM in your reference documentation. The project features a React frontend. The backend is provisioned with AWS SAM and features Webpacked Node.js Lambda functions. Both frontend and backend code is 100% unit test covered and is a great example of how to unit test serverless code.
Thanks for your consideration. Please let me know if you have any questions.

I know that this issue is closed, but I agree with OP. I recently learned AWS SAM and I immediately wanted a full stack example. However, I was surprised that none was available. I think a full stack example would be very welcome and valuable.

@tbrunia wrote a full stack example that he posted above: https://github.com/xilution/xilution-react-todomvc
Here is an another example for full stack in realworld-serverless-application repository


Roadmap until beta

These are the changes I would like to happen before NX beta is released. In my opinion the beta should be as stable as possible to let us focus on bug fixes and documentation improvements. With a good pace the below changes should take around 2-3 months. What is your opinion? Would you like to see a stricter roadmap with rough deadlines?
Framework changes:

form validation middleware
transition/animation middleware
change Custom Elements polyfill to a subset of the official v1 polyfill
Shadow DOM support (requires changes in core and the render middleware)
optimize the nx-compile and nx-observe helper libraries for speed
determine a list of officially supported browsers with exact versions
get 100% test coverage with all supported browsers
setup a linter

Small fixes and refactors:

refactor core and all middlewares one by one: main goal is speed and readabilty
fix all reported bugs (naturally)

Docs and utilities:

NX-CLI for project seed generation
complex example apps and walk throughs written in NX
home page cleanup and public release for contributors (the home page is an NX app)
documentation for contributors
separate, short API documentation instead of 'cheat sheets'

What comes after the beta:

unofficial API freeze, breaking changes will happen only if unavoidable
release a distributed version of NX, where every middleware is in its own repo (something similar to what Express is doing)

I like it! Looking forward to using this after the beta! It would be neat if there was a flag for when a site using NX is accessed by an unsupported browser so I could easily set up a message for those users.

Great idea, I will include it in the next release. Sorry for the (very) late response.


Specialization (tuxml.config)

Based on our large-scale campaign, learning results, and domain knowledge, I suggest we pre-set the following values:
CONFIG_64BIT=y
CONFIG_DEBUG_INFO=n
CONFIG_GCOV_PROFILE_ALL=n
CONFIG_KASAN=n
I guess in tuxml.config?
Then we still use some "randomisation" (with make randconfig)
It would be nice to have thousands of such configurations in the next upcoming days

I will add those new lines in the tuxml.config, do you need it right now ? I just have to repush the docker image

I think it's good to finish the current compilations and then yea update the Docker image, control that everything goes fine, and launch jobs ;)

The new image has been pushed !

It is possible once the current campaign is finished to modify again the image so that the following options values are preset?
CONFIG_UBSAN_SANITIZE_ALL=n
CONFIG_RELOCATABLE=n
CONFIG_XFS_DEBUG=n
(internal note: RANDOMIZE_BASE and X86_NEED_RELOCS will be automatically set to 'n' thanks to CONFIG_RELOCATABLE)

Added !

I suspect that there is only one machine which is still running with the old tuxml.config, i have one that is running since friday. I launch it to compile during the week-end. I will check this

Still the problem (first number is "index", second number is "cid") even with recent compilations
2445  92445           y
2455  92455           y
2461  92461           y
2465  92465           y
2468  92468           y
2473  92473           y
2478  92478           y
2491  92491           y

I made a test, 12 out of 100 .config had CONFIG_RELOCATABLE=y (freshly generated), so maybe this is something rewrited by an other option ?

From where could it comes?

I close this issue. I am opening a new, proper, related issue (specialization fails)


cargo shuttle init does not handle directory argument properly

Issue #665
Description of change
Skip over prompting for directory name if directory name is specified in init command
Note: Not solved issue of file path being created properly as don't have time right now but will look into this later
closes issue #665

Hey @h-dav, thanks for this :pray: There is a note in your comment about looking into the file path being created correctly, are you still doing that or is this ready for review? No rush of course, just curious!

Hi @oddgrd, I’m happy to do the file path being created correctly issue but currently don’t have time. The pull request is ready to be reviewed but it only fixes one of the issues detailed on the linked issue. However, I can create another pull request for the file path issue once it’s ready.

@h-dav thanks for the effort and thanks for getting started on this! :pray:
Since I was already updating init for our upcoming release, I included my suggestions from above in this PR: https://github.com/shuttle-hq/shuttle/pull/706. Feel free to open a new PR if you find any other issues with init (or anything else)!


relicense non-core code under 3-clause New BSD

All authors on changed files have been contacted, and consent given.
Add CONTRIBUTING file describing current license policy

Summary of current license:

zmq.core: LGPL (permanent)
perf: LGPL (permanent, © iMatix)
zmq.devices.monitoredqueue.pxd: LGPL (permanent, adapted from libzmq code)
zmq.ssh.forward: LGPL (permanent, © paramiko)
zmq.eventloop: Apache (permanent, © Facebook)
examples/chat: LGPL (pending authorization)
examples/devices: LGPL (pending authorization)
everything else: 3-Clause New BSD

I looked through everything and this is great!  Thanks for doing this.  I would say it is merge ready.


(Question) Is this lib maintained?

I'm wondering if this library is still maintained and if there are plans of expanding it to make it work with the newest Microchip modules. Is there anybody out there? (cit)

I don't think it's mantained. I worked on my own fork that adapts part of this library to work the Microchip SAMR34/WLR089 modules. See https://github.com/danalvarez/arduino-device-lib

That's pretty unfortunate. Great work on the fork by the way, did you also make upgrades for RN modules on the fork? Maybe we should think of some sort of community edition of this lib if TTN doesn't want to maintain it. @jpmeijers are you still on the project?

So just to be sure, @johanstokking can you confirm this lib is unmaintained?

@LasaleFamine we don't intent to make this library support other modules than the RN modules.

@johanstokking thanks for the response. I'm gonna close the issue.


Add tag option "Show only available models" to filter not available one

          I would add a checkbox or toggle on the top right that says "Show only available services" that hides all the not usable services. It's ok to start "un-checked" or "un-toggled"

Originally posted by @tiero in https://github.com/premAI-io/prem-app/issues/386#issuecomment-1779155540

@johnsBeharry Please can you provide me a svg icon that represent availability, in the same style as the existing tags https://github.com/premAI-io/static.premai.io/tree/main/daemon/interfaces

Can you use an emoji for no? Like 💻  Available on this computer


Problem when you change direction of the scroll in one view while both views moving

Setup scroll view 1 and 2 side by side and setup code.
scroll views are large array of numbers for example 1...1000
Drag scroll view 1 in one direction, and both lists will scroll simultaneously correctly.
Now let off the gesture on list 1, and the inertia of the scroll will continue moving the two lists, but now touch the list 2 and drag it the opposite direction. Now the two lists will NOT be synchronized any longer, and when they run out of inertia they will be messed up. Only fix now is to let off the screen, then touch to drag and they re-synch.
?
https://user-images.githubusercontent.com/132616008/236322237-652ad3fb-6fee-4520-82d3-eb27581ffd59.mov

Thanks for reporting. I will see if there is an easy fix to this.

Awesome! thanks

This was fixed and released in 1.0.1 🥳


create-react-app fails to create a project on windows 10

Can you reproduce the problem with latest npm?
yes; using npm 4.1.2
when executing the command:
create-react-app
the terminal window disappears (ie: exits) and NOTHING GETS CREATED!
tried with and w/o sudo privs with same terminal window results
this happens with create-react-versions 1.0.3 and 1.0.4
have tried to reproduce the issue again and again and again and again and .......
Can you still reproduce it?
yes
Expected behavior
have create-react-app CREATE AN APP!.
Actual behavior
when executing the command:
create-react-app
the terminal window disappears (ie: exits) and NOTHING IS CREATED
tried with and w/o sudo privs with same terminal window results
this happens with create-react-versions 1.0.3 and 1.0.4
have tried to reproduce the issue again and again and again and again and .......
Environment
Run these commands in the project folder and fill in their results:

node -v: v6.9.5
npm -v:  v4.1.2
Operating system: Microsoft Windows 10 Enterprise 10.0.14393 Build 14393
Browser: Chrome v56.0.2924.87 (64-bit)

Can you show a screenshot of how you run it? Are you using Cmd or PowerShell?

I'm using the Windows CMD environment, which I have setup for ALL OF MY COMMAND processing. I have a complex setup for things like android, SharePoint, web development and more. I have A COMPLETE tool chain that includes YO, BOWER, NODEJS, ANGULARJS, and much more.
Unfortunately, there is nothing to show you from the Windows CMD side because when I run the create-react-app command, the command exits and and the CMD window closes which is very unusual, but when running under POWERSHELL, the create-react-app fails and it shows there is an exit command forcing the window to close and I don't see it when I use the CMD command.
but just to make sure it's not me unless I'm doing something I don't know about and something is missing I just run this on POWERSHELL TO SEE IF I MISSED anything, but alas the create-react-app  also FAILED under POWERSHELL. and I have installed the REACT module under admin, under non-admin, with NPM, with YARN and each and everytime I cleaned up any left over files from the ROAMING directory under /user/appData folder.
PowerShell image included.
Anywho: thanks for your quick response.
Regards,
LuisCarlos Rodriguez

From: Dan Abramov<EMAIL_ADDRESS>Sent: Saturday, February 18, 2017 7:07 AM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Author
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
Can you show a screenshot of how you run it? Are you using Cmd or PowerShell?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-280841507, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr3nq2CmfApWQkAeEKZzQoWqSVuT1ks5rdt8DgaJpZM4MFAsO.

hello  any news on the create-react-app issue?
still waiting for your support.

From: Dan 10Abramov<EMAIL_ADDRESS>Sent: Saturday, February 18, 2017 7:07 AM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Author
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
Can you show a screenshot of how you run it? Are you using Cmd or PowerShell?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-280841507, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr3nq2CmfApWQkAeEKZzQoWqSVuT1ks5rdt8DgaJpZM4MFAsO.

I don't see a PowerShell screenshot, can you attach it please?
Please keep in mind this is an open source project. We try to help you but since this issue doesn't occur for a vast majority of users, we will need more help and information to diagnose it.

powershell image onclosed.....
in was enclosed the last time but it had a white background and easy to miss...
Regards,
"LuisCarlos"

From: Dan Abramov<EMAIL_ADDRESS>Sent: Monday, February 20, 2017 6:58 PM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Author
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
I don't see a PowerShell screenshot, can you attach it please?
Please keep in mind this is an open source project. We try to help you but since this issue doesn't occur for a vast majority of users, we will need more help and information to diagnose it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281208926, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr_qygOSXrDmAL4N1fJszoxUo21Ljks5reijCgaJpZM4MFAsO.

I think you'll need to use GH web interface. If you're attaching a file via email, it gets ignored.

Dan,
I'm also following one of your react-redux tutorials with webpack and I'm getting an error when including the react modules. something about loaders and I don't understand what the error is all about. a copy of the error image is included...
please note the image has a white background.
Reards,
"LuisCarlos"

From: Dan Abramov<EMAIL_ADDRESS>Sent: Monday, February 20, 2017 6:58 PM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Author
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
I don't see a PowerShell screenshot, can you attach it please?
Please keep in mind this is an open source project. We try to help you but since this issue doesn't occur for a vast majority of users, we will need more help and information to diagnose it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281208926, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr_qygOSXrDmAL4N1fJszoxUo21Ljks5reijCgaJpZM4MFAsO.

at the risk or sounding like a twit,, what's GH
LuisCarlos

From: Dan Abramov<EMAIL_ADDRESS>Sent: Monday, February 20, 2017 7:17 PM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Author
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
I think you'll need to use GH web interface. If you're attaching a file via email, it gets ignored.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281211076, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwryLOzdQO2DBpTsXM3BSgnmG52cssks5rei0JgaJpZM4MFAsO.

@dcu-sharepoint GH = GitHub. You can drag images onto the text entry box on this issue and it will upload the image to GitHub and include it in your message. It's not possible to send images from email (as far as I know).

Dan,
let's start all over again,
my apologies, I thought I was working with somebody else from who m I bought a course on REACT and one of the objects they gave me to work with was this create-react-app which I've not been able to get going and for some reason I thought you were with them....
anywho: in looking at the email address and your suggestion of working with GH then I put 2 & 2 together and now I FEEL LIKE THE TWIT I tried to avoid being....
anywho: I do not have the GIT UI user interface installed. I only have the GIT CLI which I use for everything I do with Git Hub.
is there any other way I can send you the images or do I have to go somewere in GIT get on the issues thing....
Thanks for your help, but up to now I was completly lost....
LuisCarlos

From: Dan Abramov<EMAIL_ADDRESS>Sent: Monday, February 20, 2017 7:17 PM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Author
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
I think you'll need to use GH web interface. If you're attaching a file via email, it gets ignored.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281211076, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwryLOzdQO2DBpTsXM3BSgnmG52cssks5rei0JgaJpZM4MFAsO.

Thank you much;
i'm on the GH site now and will be putting my images on the issue
Unable to create an APP #1594
thanks for your help....
and you're right, now to include images on the  email....

From: tbillington<EMAIL_ADDRESS>Sent: Monday, February 20, 2017 7:29 PM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Mention
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
@dcu-sharepointhttps://github.com/dcu-sharepoint GH = GitHub. You can drag images onto the text entry box on this issue and it will upload the image to GitHub and include it in your message. It's not possible to send images from email (as far as I know).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281212345, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr4ZG-TAx2IkriUr8V88uSvDnW2XBks5rei_QgaJpZM4MFAsO.

Let's continue the discussion in this topic. #1594 is an unrelated thread.
What I'm seeing from your screenshot in https://github.com/facebookincubator/create-react-app/issues/1594#issuecomment-281216291 is that Yarn command doesn't seem to work correctly.
I think this might be a Yarn bug: https://github.com/yarnpkg/yarn/issues/2192. You can try the workarounds described here, but I'd suggest just uninstalling Yarn for the time being. Create React App will fall back to npm if Yarn isn't installed, and that should solve your issue.
Hope it helps!

I noticed the yarn string in the error message, however, I tried both NPM and YARN and both give me the same error or behaviour...
will uninstall yarn and try it again.
will visit this at github....
Thanks

From: Dan Abramov<EMAIL_ADDRESS>Sent: Monday, February 20, 2017 8:29 PM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Mention
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
Let's continue the discussion in this topic. #1594https://github.com/facebookincubator/create-react-app/issues/1594 is an unrelated thread.
What I'm seeing from your screenshot in #1594 (comment)https://github.com/facebookincubator/create-react-app/issues/1594#issuecomment-281216291 is that Yarn command doesn't seem to work correctly.
I think this might be a Yarn bug: yarnpkg/yarn#2192https://github.com/yarnpkg/yarn/issues/2192. You can try the workarounds described here, but I'd suggest just uninstalling Yarn for the time being. Create React App will fall back to npm if Yarn isn't installed, and that should solve your issue.
Hope it helps!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281219848, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwrwHL56EOw_Gr2zAF1KH7VbO_uF9Fks5rej3igaJpZM4MFAsO.

I tried both NPM and YARN and both give me the same error or behaviour

To be clear, Create React App always uses Yarn if it is installed. So I recommend trying to uninstall it, and then Create React App will fall back to npm. If this solves the problem, then it was a Yarn bug.

yarn is COMPLETELY uninstalled, all of yarn's files, directories, path strings and anything related to yarn has been uninstalled and the system has been rebooted => SAME RESULTS. I don't know what else to do except give up....
I have cloned the CREATE-REACT-APP component from github so I can play with it.... otherwise I can't use it at all....
Thanks for your help.....

From: Dan Abramov<EMAIL_ADDRESS>Sent: Tuesday, February 21, 2017 8:41 AM
To: facebookincubator/create-react-app
Cc: L. Carlos Rodriguez; Mention
Subject: Re: [facebookincubator/create-react-app] create-react-app fails to create a project on windows 10 (#1587)
I tried both NPM and YARN and both give me the same error or behaviour
To be clear, Create React App always uses Yarn if it is installed. So I recommend trying to uninstall it, and then Create React App will fall back to npm. If this solves the problem, then it was a Yarn bug.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/facebookincubator/create-react-app/issues/1587#issuecomment-281347102, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr3Ww6yC-f4liosG2oP4sYoUbAcnSks5reul9gaJpZM4MFAsO.

Maybe you still have a broken create-react-app installation from Yarn.
Try running
npm install -g create-react-app

Then try again. If it doesn't work, please post another screenshot.

@gaearon Yarn is caputed! create-react-app has been caputed!, system has been rebooted, any folders mentioning yarn have been caputed!. using the windows control panel->programs->uninstall yarn has been executed to remove yarn completely of the system, and the only thing I can think of is if "create-react-app" or yarn puts anything on the registry but I work with a non-administrator account and I did not find anything on the windows registry with yarn in it.
still buffled... 👎 :(

Have you tried what I suggested above?
npm install -g create-react-app

I think you need to do that to redirect the global command to the new location.

@gaearon 1: I've removed, re-installed, re-removed, re-re-installed, re-re-remove, re-re-re-failed again...
2: if I move the globals folder then I REALLY will get all screwed up because I have a complete application infrastructure that is working well for me and it took me a L O  O  O  N G time to setup, so that is not an option. However, you just gave me an idea i'm going to try later on in the afternoon and that is to open a new user account and dedicated it to react/create-react-app scenario and see if that works, because it will have a virgin globals folder. Stay tuned... more to come...

Sounds good. Sorry for the trouble. Yarn is generally working pretty well but there are annoying bugs like this on some systems.

yeah, Yarn is also giving me problems with an MS app in widows where it is looking for an apple mac environmental issue in a WINDOWS environment and the app install fails. I posted the issue in the yarn site about a month ago.

anywho: will keep u posted, Gracias....

Going to close this because all the problems appear related to the installation of create-react-app itself which is managed by either Yarn or npm. There’s nothing we can do there.

I think that you should start using a Node Console for decompose the issue. Did you had success? I had a problem similar and I solved it using the Node Console. Regards!

yes node console and -g global settings resolved problem for sure :)

@gaearon I have done npm install -g create-react-app and yet I get error messages

phavor, try running from administrator. Right click the command prompt in the search bar, run as admin, then install create-react-app again. This is the equivalent to running sudo on Linux.

can anyone help me with this issue??

@ali0053 have you tried closing CMD and opening it again?

@ali0053 Have you installed create-react-app globally?

@ali0053 npx create-react-app should help you


Style watch is unsuitable in node::input::area

This task is automatically imported from the old Task Issue Board and it was originally created by Ilya Bogdanov.
Original issue is here.

// StyleWatch is unsuitable here, as it was designed as an internal tool for shape system

graph-editor/src/component/node/input/area.rs

Relevant code:
https://github.com/enso-org/enso/blob/75fda33837214a774b7c8bbbbe64aeb72db069bd/app/gui/view/graph-editor/src/component/node/input/area.rs#L445-L451

Do we need to fix it now? I mean, does it cause any bad visual artifacts?

It works fine. This comment has been in the codebase longer than I am.

It works fine. This comment has been in the codebase longer than I am.

hahahaha, 😂, this comment made my day :D

Removed code along with EnsoGL


Open autocomplete on backspace

I find it odd that right now clicking on an input and backspacing until empty doesn't show any suggestions.
I think doing this makes sense because if a user deletes the first character of text that was previously auto-completed into an input, they'll see that the previous value was arrived at by one of the suggestions (as opposed to it being random).
In my application I've also added open on focus which could be added as a built in configuration option here but it's probably fine leaving it up to the person implementing the library.

You could also make the argument that people will find it annoying that backspacing suddenly shows the autocomplete when you wanted to get rid of it. I'll wait on some more opinions on this one if you don't mind.

Thanks for responding :smile:
That could be true in some cases but if you consider the placement, it doesn't actually get in the way.

I would like this merged too.
This is one of the differences between horsey and GitHub mentions that is a bit off-putting the first time using horsey if you are used to GitHub.


mle: finish running & give better error message when every day is bad

this breaks but really should complete and say sorry we couldn't model any of the days:
> dat <- data_metab('1', res='30', flaws='missing middle')
> mm <- metab_mle(data=dat)
Error in get_params.metab_model(metab_model, date_start = date_start,  :
  can't find metabolism parameters GPP.daily, ER.daily, K600.daily

moving this up in priority because it's breaking the cluster model runs.

probably these ones:
can't find metabolism parameters GPP.daily, ER.daily, K600.daily
job  row  site
  0   23  nwis_01484085
  2   55  nwis_02042222
  3   74  nwis_02198950
  4   76  nwis_021989792
  5   89  nwis_02231254
  6   90  nwis_02231291
 12  189  nwis_04085427
 13  193  nwis_04087170
 14  194  nwis_04092750
 20  334  nwis_11313433
 21  340  nwis_11455315
 22  341  nwis_11455350


In createOdspCreateContainerRequest support the option of setting the LoaderHeader.cache header

Feature
For our scenario (Loop), we want to specify that we want to override the container loader's default caching behaviour to not use any caching in the request returned by createOdspCreateContainerRequest. The problem with using the default caching behaviour in our scenario is that after attaching the container with the request returned, the ODSP file gets created with a cached file name instead of the fileName parameter provided to the createOdspCreateContainerRequest function.
The current workaround for this has been to modify the request returned by createOdspCreateContainerRequest by adding [LoaderHeader.cache]: false to its headers after, but it would be cleaner if this could be set in the function itself.
Describe the solution you'd like
Allow specifying a value for LoaderHeader.cache header through a parameter, e.g.:
export function createOdspCreateContainerRequest(
    siteUrl: string,
    driveId: string,
    filePath: string,
    fileName: string,
    createShareLinkType?: ShareLinkTypes | ISharingLinkKind,
    useLoaderCache?: boolean) {
       ...
      headers: {
         ...
         // set LoaderHeader.cache to useLoaderCache if it exists
         ...
      }
      ...
}

@tiffany-ou, our current plan is not to provide this kind of capability.
But instead, to remove caching altogether from Loader.
https://github.com/microsoft/FluidFramework/pull/14680 is the very first step on this jorney
https://dev.azure.com/fluidframework/internal/_workitems/edit/3118 tracks this work.
Please reach out if you think this item should stay around.


[2023 Yearly Social Media ] Call to action: MPWG Submit Quote

Yearly Spreadsheet Media Inventory
Media Description
#WordOnTheStreet: Submit your @MicroProfileIO quote and share why you invest your time & resources developing & using the #MicroProfileTechnology.
https://microprofile.io/workinggroup/#testimonials
#ByCommunityForCommunity #SharingIsCaring #OpenSource
2022 issue
https://github.com/eclipse/microprofile-marketing/issues/662
Schedule
1 per month

How about if we make it a question, like:
Submit your MicroProfile Testimonial
Why do you invest/adopt MicroProfile?


fix: update GQL E2E test to use unique names

Description of changes
This commit updates the @searchable v2 aggregates test to use a unique stack and bucket name to avoid race conditions with other tests.
Issue #, if available
Description of how you validated changes
Ran the E2E test.
Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #8014 (0dfd8e9) into master (b0600c8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8014   +/-   ##
=======================================
  Coverage   54.04%   54.04%
=======================================
  Files         592      592
  Lines       33380    33380
  Branches     6917     6917
=======================================
  Hits        18040    18040
  Misses      14568    14568
  Partials      772      772

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 b9134f5...0dfd8e9. Read the comment docs.


MoistAir entropy and isentropicExponent issue

Added assert(relativeHumidty<=1) to MoistAir.isentropicExponent and MoistAir.specificEntropy and added 3 Test Models for further discussion closes #169

What is the reason for this being a draft? I would otherwise go on with the regression test

I think jakub suggested the PR to be a draft, because i called the package "MoistAirDiscussion" and wrote "I assume" and "I suggest" in the docu, since im no expert in the media model but just noticed some issues at saturation where the media model retuns not reasonable results without warning the user, and maybe also since we said we might want to tell the MSL directly.


Support for polars

Polars is an increasingly popular data frame package. Although polars users can currently convert to pandas to run Skimpy would it be better if it was native?

closed in #514


Add BP_DOTNET_PROJECT_PATH docs

Signed-off-by: Timothy Hitchener<EMAIL_ADDRESS>
Summary

Use Cases

Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[x] I have reviewed the styleguide for guidance on my code quality.

Can we PR this docs change into the dotnet-core language family repo so that the docs in the hugo module remain up to date? // Or move this PR over to the language family repo?
Worried about the docs falling out of date while we make the switch over.

@emmjohnson or @thitch97 can you open a draft PR to the dotnet language family repo with this change and close this PR?


perf: Gfal2 remote provider using gfal2-python instead of  gfal2-utils.

Description
Added support of gfal2-python library instead of gfal2-utils. Time(wallclock) of a dry run with 100 files on a gridftp  server was reduced by a 7 to 11 fold (from about a minute to 6 seconds!), while the system and user time was also significantly less. This speed-up is caused because no shell->python->gfal2 objects have to be generated for every file (gfal2-utils are  gfal2-python commands wrapped with a command line interface).
If gfal2-python is not installed, it will fall back to gfal2-utils. This makes the code unclear, but this will not break the current installation when upgrading. A deprecation warning is given if gfal2-python is not installed.
QC

[ ] The PR contains a test case for the changes or the changes are already covered by an existing test case.
Test case was not written because of lack of generic available server and adding dependencies
[X] The documentation (docs/) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behaviour or functionalities of Snakemake).
Should not change behaviour

It is not clear to me why CI / testing (pull_request)   failed. Can someone take a look?

Thanks a lot, sounds great! I would vote for ditching the gfal2-utils dependency though. I don't think it is a problem to have a message that gfal2-python needs to be installed. Also, as the new dependency is much faster, I don't want people to silently use the old one without noticing.

I agree.  (I thought removing code was easier than introducing backward compatibility). I will run this code in production next week to verify it really works.

I tested the code and I did not introduce bugs while removing the gfal-utils code.


Don't report Kubernetes pause containers

Right now there are tens of gcr.io/google_containers/pause containers getting reported (one per running pod in the cluster). These only exist as an artifact of setting up networking and IPC in the pods. They're just adding noise and should be ignored by default (do they count for billing purposes?).
A few approaches:

Ignore them in the default Docker config
Ignore them in the code
Allow setting an environment variable to ignore them, without having to rebuild the image.

Option 3 might be the best because

the image can be changed through a kubelet flag, e.g. for people using local/private registries
people might have other containers they want to ignore for whatever reason (I have a few more, actually)

Hi @therc,
Excluding containers is already possible as you can see in docker_daemon.yaml. There are currently two ways of using this feature if you're using the containerized agent:

create your own image based on datadog/docker-dd-agent with a customized docker_daemon.yaml
if you can store files on the host beforehand, use the runtime configuration reload as described here: https://github.com/DataDog/docker-dd-agent#enabling-integrations

However it should be made easier for platforms like Kubernetes, we'll look into it.

I think I can store the file in a Kubernetes 1.2 ConfigMap (a place in cluster-wide storage for configurations and other non-secret items), under the key docker_daemon.yaml. Then I can run dd-agent with a volume that exposes the ConfigMap as /conf.d. That will create automatically a file in the container under /conf.d for each key in the ConfigMap. In this case there'll be just one file. I've done something similar for fluentd.
Thanks! I'll report back if successful so that documentation can be updated.

@therc was your ConfigMap method successful?

Kinda successful. The configmap gets mounted, it's the contents that I still have to get right. :-)

One limitation is that 1.3 doesn't support exposing ConfigMaps as filenames with underscores in them, because of overzealous validation (it looks for a DNS-valid string).

I take back the ConfigMap filename comment: you have to create keys without underscores, but when mounting them later, you can use a different filename, adding the underscore back.

@therc was that method ultimately successful? I've tried the same steps, but it seems as though the file from /conf.d/docker_daemon.yml does not get copied into /etc/dd-agent/conf.d/docker_daemon.yml. I'm wondering if there's some race that happens on container startup where the mounting of the config map happens too late.

Nevermind, I found my bug. I had named the file with .yml instead of .yaml.
I'm now no longer seeing metrics reported for these pods which is great, but I am still seeing them reported in the count for docker.containers.running. Are these containers counted for billing purposes now?

Closing this one as it should be resolved (pause containers are ignored by default). Note that container exclusion doesn't impact docker.containers.running as we don't want to lie on the real number of containers managed by your docker daemon, but billing counts on docker.cpu.user so it won't impact what you pay.
Feel free to comment if anything unclear remains.


How to change keybinds for schematica?

I don't have a number pad on my computer, how do I cnage the keybinds to [;  ];  and = ...
So I can actually use it...

Oh tnxm8!


Add /opt/python3.5/bin to $PATH

Implements #45

Cool, agree about the debian case. We want ours to always be preferred.
On Mon, Nov 7, 2016, 4:17 PM Douglas Greiman<EMAIL_ADDRESS>wrote:

@duggelz commented on this pull request.
In Dockerfile
https://github.com/GoogleCloudPlatform/python-runtime/pull/46:

@@ -23,6 +23,9 @@ RUN pip install --upgrade pip virtualenv

Install the Google-built interpreters
ADD interpreters.tar.gz /
+# Add Google-built interpreters to the path
+ENV PATH $PATH:/opt/python3.5/bin
And the flip side is the case where Debian adds a python3.5 package in
/usr/bin, the user installs something which, unbeknownst to them also
installs python 3.5, and suddenly the user is no longer using our
interpreter, they are using the Debian one.
Basically failure is always an option. In this case, seeing as how python
is the entire reason this runtime exists, I will add it to the front of the
$PATH.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/python-runtime/pull/46, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPUcwM3quXflrVP75ZMq4g-bhLSX6FFks5q77-JgaJpZM4Kr1Uc
.


Update project config

Thank you really much @Sunbreak for this PR!
@g-ortuno Can you review it by any chance?