Idea: Use AsyncLocalStorage for context

Could be opt in.
https://developers.cloudflare.com/workers/runtime-apis/nodejs/asynclocalstorage/
If the Hono context object would be an AsyncLocalStorage you could retrieve whatever is inside it without passing c around. If you have a function somewhere and you want to, for example, elegantly handle a failure but log the error to Sentry, you would have to pass c potentially very deep down into you stack.

Can't you do this with a middleware already?
const ctxStore = new AsyncLocalStorage<Context>();

app.use((ctx, next) => {
   ctxStore.run(ctx, next);
})

or something similar

Let me try. I'll re-open if needed.

Any news on this?
I tried the example but it gave this error:
Error: Context is not finalized. You may forget returning Response object or `await next()`

Also tried it + a few variations and got the same error. Being able to provide a "context" for a request via AsyncLocalStorage would be very useful for using ParaglideJS with Hono.
Can this be reopened?

Using AsyncLocalStorge is a good idea. You can see the example middleware using it:
https://github.com/yusukebe/async-local-storage-middleware
Either way, we generally do not need it since we have a context.

@yusukebe as my app is growing I noticed that I'm passing the c from the handle to other functions, multiple layer deeps.
import { Hono } from 'hono'

const app = new Hono<AppType>()

app.get('/', (ctx) => {
  ..
  doSomething(c, foo, bar) // which calls then another function passing the c as well
  doSomethingElse(c)
  ..
})

export default app

I've looked at the https://github.com/yusukebe/async-local-storage-middleware example,
but I'm wondering if it would be possible to create a middleware that "mimics" the whole c by putting it in the AsyncLocalStorage?
And that in other files in the app we could do an import like:
import { c } from '..'

and use it similar as the c argument from the handler:
c.env.KV_NAMESPACE
c.var.requestId

This would give a consistent way of accessing the context anywhere.

@marceloverdijk
I can't say whether we can do it immediately, but it's a good idea. It's enough to use Hono's c in almost all cases. But it's alright that there is another way to access c globally.

Thx @yusukebe !
FWIW I'm using this currently:
ctx.ts:
import { AsyncLocalStorage } from 'node:async_hooks';
import { createMiddleware } from 'hono/factory';
import { Context } from 'hono';
import { AppEnv } from '@/env';

type Callback = (ctx: Context<AppEnv>) => Context<AppEnv>;

const asyncLocalStorage = new AsyncLocalStorage<Context<AppEnv>>();

export const setCtx = (callback: Callback) =>
  createMiddleware(async (ctx, next) => {
    const obj = callback(ctx);
    return asyncLocalStorage.run(obj, next);
  });

export const getCtx = () => {
  return asyncLocalStorage.getStore() as Context<AppEnv>;
};

export const ctx = new Proxy(
  {},
  {
    get: (_, prop) => {
      const context = getCtx();
      return context ? context[prop as keyof Context<AppEnv>] : undefined;
    },
  },
) as Context<AppEnv>;

Note that is currently tight to my custom AppEnv.
index.ts:
import { ctx, setCtx } from '@/ctx';

const app = new Hono<AppEnv>();

app.use(setCtx((ctx) => ctx));
app.use(requestId());
app.use(
  logger((message: string, ...rest: string[]) => {
    ctx.var.logger.debug(`${message.trim()}`, ...rest);
  }),
);
app.use(async (ctx: Context<AppEnv>, next) => {
  ctx.set('logger', createPinoLogger());
  // other c.set variables.
  await next();
});

Note that the logger middleware is already using the "global" ctx as the PrintFunc has no access to the context directly.
other.ts:
import { ctx } from '@/ctx';

export const doSomething() = () => {
  // we can now access the global ctx
  c.var.logger.debug('The request id = %s', c.var.requestId);
}

If you see some issues or improvements I appreciate your feedback.
As you mentioned

But it's alright that there is another way to access c globally

should we re-open this issue or create a new issue to "Access c globally" so I can track the progress?

@yusukebe
I went a bit further and extracted the code above in a standalone context-holder middleware (inspired on https://github.com/yusukebe/async-local-storage-middleware).
/middleware/context-holder/index.ts:
import { AsyncLocalStorage } from 'node:async_hooks';
import { createMiddleware } from 'hono/factory';
import { Context, Env } from 'hono';

const asyncLocalStorage = new AsyncLocalStorage<Context>();

export const contextHolder = <E extends Env = Env>() => {
  return {
    setContext: createMiddleware(async (c, next) => {
      return asyncLocalStorage.run(c, next);
    }),
    getContext: () => {
      const store = asyncLocalStorage.getStore() as Context<E>;
      return store;
    },
  };
};

export const getContext = <E extends Env = Env>() => {
  return contextHolder<E>().getContext();
};

This can be used like:
import { contextHolder } from '@/middleware/context-holder';

const app = new Hono<AppEnv>();

const { setContext, getContext } = contextHolder<AppEnv>();

app.use(setContext);
app.use(requestId());

app.use(async (c: Context<AppEnv>, next) => {
  const city = (c.req.raw.cf?.city ?? 'nowhere') as string;
  c.set('city', city);
  await next();
});

app.get('/', async (c) => {
  return c.json(`${getContext().var.requestId} is from ${getContext().var.city}`)
})

or in another file:
import { getContext } from '@/middleware/context-holder';

export const doSomething() = () => {
  // we can now access the global context
  const requestId = getContext<AppEnv>().var.requestId;
  console.log(`requestId = ${requestId}`;
}

or
import { contextHolder } from '@/middleware/context-holder';

const { getContext } = contextHolder<AppEnv>();

export const doSomething() = () => {
  // we can now access the global context
  const requestId = getContext().var.requestId;
  console.log(`requestId = ${requestId}`;
}

getContext<AppEnv>() might still be a bit verbose ;-) but we need the type.
In my own project I created a ctx.ts helper file with:
import { getContext } from '@/middleware/context-holder';

export const c = new Proxy(
  {},
  {
    get: (_, prop) => {
      const context = getContext();
      return context ? context[prop as keyof Context<AppEnv>] : undefined;
    },
  },
) as Context<AppEnv>;

and it allows me to use:
import { c } from '@/ctx';

export const doSomething() = () => {
  // we can now access the global context
  const requestId = c.var.requestId;
  console.log(`requestId = ${requestId}`;
}

This works quite well so far.
@yusukebe Would you be interested in a PR that provides the above context-holder middleware? (or let me know if you prefer another name)

@marceloverdijk Looks good!
I remember we did a similar thing in HonoX: https://github.com/honojs/honox/pull/168

cc: @usualoma If you have any ideas, please share them.

About naming, I prefer context-storage because it uses AsyncLocalStorage.

@marceloverdijk
Anyway, can you create a PR? And let's discuss it on the PR!

Sure, I will do that later today.

PR created to further discuss: https://github.com/honojs/hono/pull/3335


/check endpoint for list of relations

Currently, if we want to check multiple relations at once, we have to call parallelly /check endpoint. The problem is that we have to send multiple requests for something that could be done by one. It would be great if there is some endpoint for evaluating multiple relations.

Thanks for your request @psadovsky
We are planning on making this part of our SDKs first before making it a server side API endpoint.
That is for several reasons, some of which include:

It allows us to support this faster without having to expand the API surface
It allows us to get feedback and use-cases before settling on an interface we cannot break without an API backward incompatible change
Ideally, the check requests should go to multiple servers so as not to overload one. We don't currently have server request dispatching where one server would delegate to others, but even then, it would be doing roughly the same thing

The SDK implementation ticket is being tracked here: https://github.com/openfga/sdk-generator/issues/23
There is also another issue here tracking Batch Check: https://github.com/openfga/openfga/issues/182
I will close this as a duplicate of it, but please feel free to upvote the original and add your use-cases/idea to it.


Safari Desktop & Mobile: Cross-origin loading of tiles with crossOrigin="anonymous" not possible

I'm loading multires tiles inside a web application from the same origin over a proxy (Load balancer). This works for Chrome, Internet Explorer, Edge and Firefox, but not for Safari (Desktop and Mobile). All browsers except Safari send their cookies in the header file (Which is needed for validating the session).
Changing crossOrigin="anonymous" to crossOrigin="use-credentials" in pannellum solved this issue for Safari. Would it be possible to make this the new default crossOrigin behavior for fetching tiles?
Thanks!

Setting it as an option in the config.json would be a nice workaround (Default could still be crossOrigin set to anonymous). I already got it to work with the manual change, but that's always a dangerous game with future framework updates.
In any case, appreciating your work, the viewer works great :)


add inflation metadata

Add inflation asset metadata

Creating a new schema is very security-critical task. LNP/BP Association and this repository will not host third-party developed schemata.
Any developer can create and distribute their schemata independently and permissionlessly - no need to submit a PR here. We have no capacity of providing peer review for third-party schemata at this moment. Thank you for understanding.


Please create guide for how to set this up with ubuntu or centos

Trying to get the dependancies correct has been an absolute nightmare.
EDIT: I will even provide a VPS to the person who writes a guide.

True, I had to install everything at least 6 times and then it just worked.
On Apr 17, 2015 10:27 AM, "justinoreilly"<EMAIL_ADDRESS>wrote:

Trying to get the dependancies correct has been an absolute nightmare.
—
Reply to this email directly or view it on GitHub
https://github.com/agermanidis/SnapchatBot/issues/59.

Does it work now?

Here is that I get in my console when I try to install.
http://pastebin.com/r34q11L4

I have managed to make it work but I am stonewalled by needing updated responses.

You try installing:
sudo pip install requests==2.5.3
That was a previous fix, not sure about now. What is your error message?

[root@xmpp examples]# python storifierbot.py -u ********** -p *************
[2015-04-17 12:53:21,595] Starting new HTTPS connection (1): feelinsonice-hrd.appspot.com
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:79: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
[2015-04-17 12:53:22,119] "POST /loq/login HTTP/1.1" 200 None
Traceback (most recent call last):
File "storifierbot.py", line 16, in
bot = StorifierBot(args.username, args.password)
File "build/bdist.linux-x86_64/egg/snapchat_bots/bot.py", line 27, in init
KeyError: 'updates_response'

You could always run the bot in a docker container. I created a Dockerfile that installs all dependencies, so you don't have to - check it out.
https://github.com/Samze/SnapchatBot-docker
If you a set of instructions that allow you to install dependencies on your ubuntu machine, you can always check out the instructions in the Dockerfile.
https://github.com/Samze/SnapchatBot-docker/blob/master/Dockerfile


"MĂRĂȘEȘTI" is listed in the drop-down menu

Description:
When user writes ”MĂRĂȘEȘTI” the location appears in the drop-down menu next to the town which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "MĂRĂȘEȘTI"

Expected results
The location appears in the drop-down menu as "Oras MĂRĂȘEȘTI, Vrancea ".


08/09/2018 02:08 : Create Pull Request for branch master -> prTesting1_2018080902

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Error in VM with multiple Users (8013150A - The source was not found, but some or all event logs could not be searched)

Hi all,
I'm running a script using Selenium inside a VM, where multiple users can be connected at the same time.
If one user runs a script with selenium, it works fine, but if other users connected to the same VM tries to run it at the same time, they're get this error:

If the user that is running the selenium ends it, then one of the other users is able to start it without any trouble (the one who opens first).
The Seleniumbasic was installed for each user separately, on its own profile but, for me, it seems that its using some shared file/resource... Is there anyway to work around this issue?
I didn't add any code example because it happens even using the script samples that comes with selenium basic, like StartChrome.vbs, StartEdge.vbs, etc.
I think it is worth mentioning that the error happens even with users running scripts that use different drivers
Thanks in advance!

Hello Matheus,
I have the same issue!
Did you find something to fix it since last february ?
Best Regards
Martial.

have the same issue in ts with multiple users once a users starts other users cannot run it.
quit dose not seem to release all references.
the only way i can use it if the other users close completely the application that used the driver, otherwise i cant free it up.

Hi I fixed for myself this issue my changing  @"Global\InterruptKey"  to  @"Local\InterruptKey" in SysWaiter.cs, I than recompiled the DLL.
if you you have this issue and cant compile yourself, i can share my compiled DLL
(btw, as i compiled the DLL i also added a new property to allow you to set the driver executable, its just handy when using this for  multiple users  and each one can sometimes have a different browser version, so i have some logic that will download the right driver and name it with a version number , i keeps all versions so when browser with version i already have i will pass the proper drivers , if drivers is not yet in directory ill download it.)

Hi there,
I'm facing the same problem and tried to compile the DLL unfortunately the output didn't worked. I always got an error on VisualBasic.

Could you maybe send us the DLL?


Fixed test again

Apparently the error code on Bamboo is different from the one tested on my mac.

This change is

Coverage remained the same at 73.301% when pulling 761c03ebff5686e9558deac691e522accadb7209 on david-puglielli:pdo_utf8_conn-test-fix into 72a10273231bde9653b1849b72c5874d6675419f on Microsoft:dev.

Codecov Report

Merging #741 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #741   +/-   ##
=======================================
  Coverage   78.99%   78.99%
=======================================
  Files          25       25
  Lines        7190     7190
=======================================
  Hits         5680     5680
  Misses       1510     1510

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 72a1027...f15a3f8. Read the comment docs.

Merging because I want to run the fix tonight.


Load testing: compare with similar systems via TPoX benchmark

To compare with: Zorba/in mem, Zorba/Mongo DB, MarkLogic, eXist, Oracle Berkeley XML DB

done for MarkLogic. See comparison results on our Wiki pages


1.6.2  unable to initialize tor controller

After a fresh reinstall of 1.6.2 and recovering LND using backup everything went well until unlocking LND wallet, restarting didn't help. i get the following error:
Dec 22 21:24:58 raspberrypi lnd[3782]: unable to initialize tor controller: unable to retrieve authentication cookie: open /run/tor/control.authcookie: permission denied

I've checked #1704 but, this is a permission error.
On checking #1816:
On: curl --socks5 localhost:9050 --socks5-hostname localhost:9050 -s https://check.torproject.org/ | cat | grep -m 1 Congratulations | xargs
Get: Congratulations. This browser is configured to use Tor.
So, Tor is running, but somehow there's a permission issue. I don't want to go through a reinstall if it is as trivial as changing permission for the contentious file.
Log file: https://termbin.com/sl4t
Thanks!

@openoms can you take a look if that is relevant for v1.6.3 release?

This is about the old lnd.conf not containing the Tor password.
https://t.me/raspiblitz/46276
This needs to be in the lnd.conf:
[Tor]
tor.password=passwordB
and nothing else about Tor.
Use the menu to change PasswordB to sync the passwords if not sure.

worked, closing issue


Remove pending invite - design needed

When an admin clicks the link to remove a pending invite, the confirmation is a default browser alert.
URL:
https://managing-registers-staging.cloudapps.digital/admin
Steps to recreate:

Login as an admin
Click 'Manage admin team'
Invite a new admin user
Click 'Remove invite' on the 'Admin team' page

Expected result:
Not sure
Actual result:

for next iteration - not a condition of this release


Set up mongodb memory server & supertest for testing

NOTE: your .env should now include NODE_ENV=test
How does it all work together?

supertest added to wrap express app during testing ('mock server')

supertest is also used to make request to the mock server

supertest requests can be chained to check response status
eg) from src/controllers/__test__/person.controller.test.ts

mongodb-memory-server now set up so that it is available at port 27017 of <IP_ADDRESS> during testing ( can be configured at src/test/config)

src/test/db-handler contains utils for creating, starting, cleaning, stopping mock database, and can be used by any test files for beforeAll/afterEach/afterAll
eg) from src/controllers/__test__/person.controller.test.ts

tests are organised within the __test__ directory in each folder that the test subject belongs to. For instance, person.controller.test.ts is located at src/controllers/__test__/person.controller.test.ts and person.controller.ts is located at src/controllers/__test__/person.controller.ts

fix #83

I am gonna close this and open another PR because some commit histories are a bit messy atm
Will incorporate the changes mentioned above!


import a .txt feature

You should make a feature where you can import a .txt file and the script will check the codes in it. I saw it in few generators and it would be really helpful.

Why would you want to check a file with codes instead of generating the codes while checking?


[Failing Test][Go SDK]: Flake in lastModified test for local filesystem.

What happened?
-- FAIL: TestLocal_lastModified (0.00s)
    local_test.go:177: LastModified("/tmp/TestLocal_lastModified2985575980/001/file.txt") = 2023-05-15 21:32:42.998867243 +0000 UTC, want in range [2023-05-15 21:32:43 +0000 UTC, 2023-05-15 21:32:43.004302634 +0000 UTC m=+0.001527498]
FAIL
	github.com/apache/beam/sdks/v2/go/pkg/beam/io/filesystem/local	coverage: 77.4% of statements
FAIL	github.com/apache/beam/sdks/v2/go/pkg/beam/io/filesystem/local	0.036s

https://github.com/apache/beam/blob/05eba4cfc86785f18ee4b7625bbb2f564afef95b/sdks/go/pkg/beam/io/filesystem/local/local_test.go#L157
Might need to update that resolution to 2 seconds. The system time modification is after the time range oddly enough. TIL there's system vs go runtime skew...
Issue Failure
Failure: Test is flaky
Issue Priority
Priority: 1 (unhealthy code / failing or flaky postcommit so we cannot be sure the product is healthy)
Issue Components

[ ] Component: Python SDK
[ ] Component: Java SDK
[X] Component: Go SDK
[ ] Component: Typescript SDK
[ ] Component: IO connector
[ ] Component: Beam examples
[ ] Component: Beam playground
[ ] Component: Beam katas
[ ] Component: Website
[ ] Component: Spark Runner
[ ] Component: Flink Runner
[ ] Component: Samza Runner
[ ] Component: Twister2 Runner
[ ] Component: Hazelcast Jet Runner
[ ] Component: Google Cloud Dataflow Runner

cc: @johannaojeling

Interesting, thanks for raising this. I'll open a PR. Looks like the system mod time in this case is below the range though? I can increase the range on both ends

.take-issue


Propose the next version - Vert.x Kue 2.0

Planning to propose a next step - Vert.x Kue 2.0. This version is expected to work better in production environment. The architecture of Vert.x Kue should be refactored and refined. Here is some of expected features:

Adapt to large scale data processing
Separate the scheduler (more generalized)
Better mechanism dealing with failure
Support more distributed storage system (e.g. HDFS, Ceph)
Enhance monitoring
Performance Optimization

Maybe this can be a prototype of Vert.x Batch Processing


Add "updateCannonScale" method to body component

Calling this method will update the scale of the shapes in the underlying Cannon body, for those shapes with shape components.
(I did not implement the update for those shapes that are attached by a shape component, because I do not know those shapes' halfExtents / radius in the local space of this entity.)

Looks good, just one minor issue.

Closing for now but happy to revisit this.


fix(levm): handle all post states on EF tests

Motivation
Currently, in the EF tests execution only the first one of the post states vector is being taken, this pr aims to choose the one corresponding to the transaction
Description
The change is to search the post state using the index hashmap matching with the tx indexes tuple. It is not an optimal implementation, but in a future a better implementation could be to the post states being a hashmap with the indexes being the hashmap's key.

This code was picked and merged in another PR


GPII-3641: Create Google Container Registry

I've tested this code on my local machine (MacOS) and in CI:

First run, which created the common-stg registry from scratch (search for initialize_registry): https://gitlab.com/gpii-ops/gpii-infra/-/jobs/186446053
Second run, which made the registry public and added the gcr_uploader SA to common-stg (search for public_readable): https://gitlab.com/gpii-ops/gpii-infra/-/jobs/186452762

I verified that the CI worker is still able to push to Docker Hub.
I verified that I can push to the registry using manually-created Keys for the gcr_uploader SA.
I verified that I can pull from the registry without being authenticated.
I'm leaving the registry up in common-stg if anyone wants to experiment with it: gcr.io/gpii2test-common-stg

Looks good.

LGTM!


[nlohmann-fifo-map]new port

new port: nlohmann-fifo-map

Hey @ChaoJia! I've removed the hashed info from the version strings and CMakeLists.txt to keep consistency and simplify maintenance. Thanks for the new port!

@grdowns Thank you 😸


 See #15257 for more detail.
Related issue (if applicable): fixes #15257
Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.

Off topic: Why is there 7 checks for codeowners mention?

Off topic: Why is there 7 checks for codeowners mention?

New codeowners-mention thing, see #devs-backend for a very recent explanation.


Client Allocation Request for:Shanghai Aihui Health Technology Co., Ltd.

Client Allocation Questions
Core Information

Name: Shanghai Aihui Health Technology Co., Ltd.
Website / Social Media: http://www.aihuichina.com/
Region: Greater China
DataCap Requested: 100TiB
Addresses to be Notarized: f1crhsa6czawwislz35lcwt3zke2cr2vy5rmdmt3y
Notary Requested: XnMatrixSV

@dalzellng Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Hi, @dalzellng
Thanks for your request. Can you kindly add more information here.
1.Is your company located in North America？
2.Please give the following informations, duration of etablishment, number of employees, business scope, users volume, number of social media followers, data size to be stored, products or projects, and so on. Provide links to social media/news mentions.
3.The history working on IPFS / Filecoin, e.g. notable contributions to the community, type of engagement shown over time, etc.
Type, size, and source of the data you will be store on Filecoin,e.g. public data or private data, etc. Is there any sensitive or illegal content?
4.How do you intend to store the data on Filecoin, e.g. redundancy, location/miner preferences, etc
5.Have you already apply for DataCap to another notary, and whether it is accepted or rejected. Is there any reliable DataCap left?
6.Would you like to post real transactions on Github?

Hi, @dalzellng Thanks for your request. Can you kindly add more information here. 1.Is your company located in North America？ 2.Please give the following informations, duration of etablishment, number of employees, business scope, users volume, number of social media followers, data size to be stored, products or projects, and so on. Provide links to social media/news mentions. 3.The history working on IPFS / Filecoin, e.g. notable contributions to the community, type of engagement shown over time, etc. Type, size, and source of the data you will be store on Filecoin,e.g. public data or private data, etc. Is there any sensitive or illegal content? 4.How do you intend to store the data on Filecoin, e.g. redundancy, location/miner preferences, etc 5.Have you already apply for DataCap to another notary, and whether it is accepted or rejected. Is there any reliable DataCap left? 6.Would you like to post real transactions on Github?

Hi, @XnMatrixSV
Thanks for the feedback. We would love to provide more information.

Our company is not located in North America; instead, we are located in China.
We are a 6 years old company, started from 2016. We currently have around 220 employees due to the covid in China; we had over 300 people during peak time. We are an IoMT, Internet of Medical Things, based e-health company, and provided IoMT services to 250 hospitals. We planned to store most of our data over 1-year time frame to decentralized storage providers, but not yet decided how much to the Filecoin network. Our first patch would likely be the smart hospital data collected by our 60,000 medical devices inside of general wards of a hospitals. We don't directly interact much with individual customers, other than the wechat account AihuiHealth offers free wifi inside of hospitals to doctors and patients. There are media/news mentions about us from many channels, e.g.
https://news.newseed.cn/p/1347426
https://e.huawei.com/cn/videolist/networking/f121e706628a4313a06ab3634fb1d704
https://www.sohu.com/a/468587054_133140
We don't have much working history on IPFS/Filecoin. Our IoMT data is fairly large, in Petabyte. We don't mind to store either public data or private data with Filecoin, as long as the storage is safe. We don't have any sensitive or illegal contents.
We don't have much preferences in locations/miners. Other than the P/L consideration, efficiency, simplicity, effectiveness are the key items we take into consideration.
This is the first time we do it; somehow the same request goes to multiple notaries. We probably have clicked the wrong button. Thank you for taking your time feedback our request; none of other notaries replied yet.
I can't think of why not. We could post real transactions on Github.

Hi,@dalzellng sorry for my late answer.
Your organization is not in North America.
According to our allocation strategy(https://github.com/filecoin-project/notary-governance/issues/27), you wait for seven days.
I will do client due diligence for you quickly.

Hi, @dalzellng
According to our allocation strategy, we will grant you 3TiB.
Please ensure the following informations.
Scoring Result:

The Address：f1crhsa6czawwislz35lcwt3zke2cr2vy5rmdmt3y

Hi, @dalzellng According to our allocation strategy, we will grant you 3TiB. Please ensure the following informations. Scoring Result:  The Address：f1crhsa6czawwislz35lcwt3zke2cr2vy5rmdmt3y

Very logical scoring mechanism. Thanks! We'll try it out.

Maybe you should wait for a period, because there are some approval problems should be solved by governance.

Maybe you should wait for a period, because there are some approval problems should be solved by governance.

Thanks for the heads up. Let's wait for the governance.

@dalzellng f1crhsa6czawwislz35lcwt3zke2cr2vy5rmdmt3y has 3.0 TiB of DataCap left.

@dalzellng f1crhsa6czawwislz35lcwt3zke2cr2vy5rmdmt3y has 3.0 TiB of DataCap left.

We had the 3.0Tb used up. Sorry about taking quite some time to have it done. Could we have a bit more this time?


Add pavelkrizek as maintainer

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

thanks, I accept this role with honor!


Fix purchases tab for broken orders

Some orders in the database table have no total specified and will show no value in the Purchases table.

Coverage increased (+0.003%) to 41.259% when pulling e4d56ed3e127988a75b7d97b4d90b23157847d43 on brian.fixpurchasestab into 20bb278a964d231c1fbb258e7cbd0028d8398806 on master.


How do I specify a custom triplet in a solution-wide props file?

I have created custom triplets x86/64-windows-custom. I have shown this works when set in Visual studio on a per-project basis, under the vcpkg project properties GUI section. It overrides the default triplets as expected.
I then removed this and and tried to add it to our main Custom.props file, which is used across our solution:
  <PropertyGroup Label="Globals">
    <VcpkgTriplet Condition="'$(Platform)'=='Win32'">x86-windows-custom</VcpkgTriplet>
    <VcpkgTriplet Condition="'$(Platform)'=='x64'">x64-windows-custom</VcpkgTriplet>
  </PropertyGroup>

When I do this, it reverts to using the default triplets e.g.x86-windows. I have hundreds of projects so how should I be setting this up, I know the docs say I can but I haven't used props files much.

Also, from vcppkg.targets, how come I never see any of these messages in my VC++ build output?
  <Target Name="VcpkgTripletSelection" BeforeTargets="ClCompile">
    <Message Text="Using triplet "$(VcpkgTriplet)" from "$(VcpkgCurrentInstalledDir)""
             Importance="Normal" Condition="'$(VcpkgEnabled)' == 'true'"/>
    <Message Text="Not using Vcpkg because VcpkgEnabled is "$(VcpkgEnabled)""
             Importance="Normal" Condition="'$(VcpkgEnabled)' != 'true'"/>
    <Message Text="Vcpkg is unable to link because we cannot decide between Release and Debug libraries. Please define the property VcpkgConfiguration to be 'Release' or 'Debug' (currently '$(VcpkgConfiguration)')."
             Importance="High" Condition="'$(VcpkgEnabled)' == 'true' and '$(VcpkgNormalizedConfiguration)' == ''"/>
  </Target>

@ras0219-msft, any suggestions?


Advanced Option of Paragraph Spacing (Before After and Line spacing)

Hi Brent,
How are you? Hope you're doing great! If we could enhance the pack with the advanced options of paragraph spacing (paragraph spacing before and after and different line spacing options), PptxGenJS would be fully comprehensive.
Right now the line spacing options only have the exact spacing...
Many many thank Brent. You're the best! :-)
Kind regards,
Ps: Could you leave your email address, please.

+1 for additional features of paragraph styling. This is a great library and I managed to get beautiful results by playing with it just couple of hours, but I also quickly realised that there are couple features that would be necessary for fine tuning.

Paragraph spacing as mentioned
Paragraph indentation: I attached the image before and after changing Indentation (before text and hanging) from default 0.95cm to 0.3 cm.

Hi Guys,
There are now two options for paragraph spacing: paraSpaceBefore and paraSpaceAfter.
var pptx = new PptxGenJS();
var slide = pptx.addNewSlide();

slide.addText(
    'Paragraph spacing - before:12pt / after:24px',
    { x:1.5, y:1.5, w:6, h:2, fill:'F1F1F1', paraSpaceBefore:12, paraSpaceAfter:24 }
);

pptx.save('PptxGenJS-ParaSpacing');

Docs: Text API

Awesome, thank you!
Now that you are working on it, indentation options would be super super addition to API :)

I also really need to control "Indentation" -> Special: "Hanging" By: some "n" value.


no seriesId

Hi, great module! But I have one question and would be happy if you can help)
There are series without seriesId identifier, for example
https://www.eia.gov/opendata/browser/international?frequency=monthly&data=value;&facets=countryRegionId;&countryRegionId=ARE;&sortColumn=period;&sortDirection=desc;
Let's say I wand to get "Crude oil, NGPL, and other liquids" (2nd page), productId=55.
How can I do it?
Thank you!

I have added this functionality to the latest version of myeia pip install myeia==0.4.0

@MikeMike13 did this resolve your question?

pip install myeia==0.4.1

super cool) yes, it works, thank you!

Awesome :) glad it works


Bug plotting map data for Grid 209.

There is a bug when plotting global map data for NCEP grid 209.  The portions of Russia which straddle the international date line extend off the image.

The following commands on dakota can be used to reproduce the behavior:

/usr/local/met-5.1/bin/regrid_data_plane \

/d3/projects/MET/MET_test_data/unit_test/model_data/grib1/gfs/gfs_2012040900_F012.grib \

G209 g209.nc -field 'name="TMP"; level="Z2";'

/usr/local/met-5.1/bin/plot_data_plane \

g209.nc g209.ps 'name="TMP_Z2"; level="(*,*)";'

The resulting image is attached to this ticket.

[MET-570] created by johnhg

Original JIRA attachment location:
https://sdg.rap.ucar.edu/jira/browse/MET-570?filter=12903


Add 'Contacts' Feature : Find Contacts by Tag

Codecov Report

Merging #65 (36513fb) into master (b082545) will increase coverage by 0.19%.
The diff coverage is 90.00%.

@@             Coverage Diff              @@
##             master      #65      +/-   ##
============================================
+ Coverage     66.96%   67.15%   +0.19%
- Complexity      499      508       +9
============================================
  Files            91       92       +1
  Lines          1671     1693      +22
  Branches        163      166       +3
============================================
+ Hits           1119     1137      +18
  Misses          491      491
- Partials         61       65       +4

Impacted Files
Coverage Δ
Complexity Δ

...tionote/logic/parser/EditContactCommandParser.java
92.30% <ø> (ø)
11.00 <0.00> (ø)

...te/model/contact/TagsContainKeywordsPredicate.java
80.00% <80.00%> (ø)
5.00 <5.00> (?)

...tionote/logic/parser/FindContactCommandParser.java
90.00% <90.00%> (ø)
4.00 <4.00> (?)

.../dictionote/logic/commands/FindContactCommand.java
91.66% <91.66%> (ø)
7.00 <7.00> (?)

...java/seedu/dictionote/commons/util/StringUtil.java
95.65% <100.00%> (+0.91%)
8.00 <1.00> (+1.00)

...eedu/dictionote/logic/parser/DictionoteParser.java
86.36% <100.00%> (ø)
15.00 <0.00> (ø)

...e/model/contact/NameContainsKeywordsPredicate.java
100.00% <100.00%> (ø)
8.00 <3.00> (+1.00)

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 b082545...36513fb. Read the comment docs.


[consensus] construct genesis from end-epoch LedgerInfo

Motivation
Construct the new genesis block and its QuorumCert deterministically from end-epoch LedgerInfo.
It's still equivalent to the hard coded value until we read the real genesis from storage.
Have you read the Contributing Guidelines on pull requests?
Y
Test Plan
Existing tests.
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

Looks good!
@bors-libra delegate+

:v: @zekun000 can now approve this pull request

@bors-libra r=dmitri-perelman

:pushpin: Commit dc19793 has been approved by dmitri-perelman

:hourglass: Testing commit dc1979337bb0ef576378b2b05c2c21b486eda514 with merge fbffdc650e6a6f41651760ee441bcf1d43f49ed8...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=dmitri-perelman

:bulb: This pull request was already approved, no need to approve it again.

This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.

:pushpin: Commit dc19793 has been approved by dmitri-perelman

:hourglass: Testing commit dc1979337bb0ef576378b2b05c2c21b486eda514 with merge 717b137ae2c9767fe8b421ac6a04354181905677...

@bors-libra retry

:hourglass: Testing commit dc1979337bb0ef576378b2b05c2c21b486eda514 with merge 2efacc458b365f3e2ef35524ddcf90e508cde73e...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: dmitri-perelman
Pushing 2efacc458b365f3e2ef35524ddcf90e508cde73e to master...


debug with dotenv

Note: This is purely informational and I am documenting this so that it may help someone.
The TLDR snippet (in ESM/Typescript):
import Debug from 'debug'
import dotenv from 'dotenv'

// Save the current DEBUG environment variable if needed
const DEBUG = process.env.DEBUG

// Call Debug.disable() if needed/wanted
Debug.disable()

// Do dotenv things
dotenv.config({ path: 'my.env' })
dotenv.config({ path: 'my.env.development.local' })

// Parse environment
if (process.env.DEBUG != null) {
    // Update with new variable if set
    Debug.enable(process.env.DEBUG)
} else if (DEBUG != null) {
    // Fallback to previous DEBUG environment variable if it existed
    Debug.enable(DEBUG)
}

Quick background/facts:

enable calls save, which saves the namespace argument into process.env.DEBUG.
Don't call disable, because it will call enable with an empty string argument, causing process.env.DEBUG to be empty.
But if  you want to make sure that process.env.DEBUG is clear, we need to make sure that we call disable BEFORE we do anything with the environment (i.e. dotenv).
The ideal way to load the DEBUG variable would be to use Debug.enable(Debug.load()), but Debug.load() is not properly documented in the TS types and will cause validation errors.

I'll see if I can make a useful PR for this.

I'm going to close this since it's not really an 'open' issue but if I see more issues filed w.r.t. dotenv in the future I'll pin this for visibility.

Just my $0.02. Hardcoding anything about the environment into your source directly rarely works out for you in the long run.

In my case, I was trying to emulate the behaviour from the create-react-app, which I believe was based on the behaviour of the Ruby gem1 that existed before the JS dotenv project came to exist.
It worked by trying to load different .env files according to the detected environment.
So in my example, the // Do dotenv things section would rather look something like this:
import { existsSync } from 'node:fs'
import { cwd } from 'node:process'
import path from 'node:path'

...

// Do dotenv things
const nodeEnv = process.env.NODE_ENV ?? 'development'

const envFiles = [`.env.${nodeEnv}.local`, '.env.local', `.env.${nodeEnv}`, '.env']
    .filter((envFile) => existsSync(path.resolve(path.join(cwd(),envFile))))

for(const envFile of envFiles) {
    dotenv.config({ path: envFile })
}

As an example scenario, it would allow me to easily switch or (selectively) override (debug) settings.
Which could handy in case you have a generic .env file included in a Docker build and want to override only particular variables in a specific environment, or want or need to tune them. This is a safe(r) escape hatch without having to manage full environment variables and the potential discrepancies this might bring. (Which is obviously why dotenv-vault came to rise.)
Though, you are absolutely correct, this would ideally be implemented using a preload script that provides this functionality.


Location flags are awkward to access

When getting input from the controllers through SpaceLocation and SpaceVelocity, in order to implement a logical default position to account for lack of tracking, it's necessary to check the SpaceLocation.location_flags, to see whether the input is a extrapolation from no tracking, or whether it's live input. Using binary operations  to do this is extremely awkward. In my case, I only wanted to update the state of my system based on the input from the controllers if the location and the orientation was both valid and tracked, so I used the code (input.0.location_flags.into_raw()&0b1111)^0b1111 == 0. This is quite awkward. I'm unsure what a better implementation would be, and certainly, even with what's currently present, I could've written a cleaner implementation (for example,
let bit_mask = SpaceLocation::OrientationValid | SpaceLocation::PositionValid | SpaceLocation::OrientationTracking | SpaceLocation::PositionTracking
(input.0.location_flags.into_raw()&bitmask)^bitmask == 0 would be a more robust implementation).
I haven't actually checked whether OrientationTracking implies OrientationValid, but if so, the best implementation would probably be to be able to access all of these values individually as bools from the SpaceLocation object, and then a bool for both OrientationValid and PositionValid, and finally a bool for OrientationTracking and PositionTracking

this is fixed now, location flags are now a component on entities with an XrSpace or in hand joints


[Enhancement] Add type hinting in pyAnsys Libraries

It would be beneficial to have type hinting in all libraries of pyAnsys.
We could choose a compatibility with typing features from Python 3.7 (or maybe 3.6?).
For example:
    def set_domain_result_file_path(self, path, domain_id):
        """Add a result file path by domain.

        This method is used to handle files created by a
        distributed solve.

        Parameters
        ----------
        path: str
            Path to the file.
        domain_id: int, optional
            Domain ID for the distributed files.

        Examples
        --------
        >>> from ansys.dpf import core as dpf
        >>> data_sources = dpf.DataSources()
        >>> data_sources.set_domain_result_file_path('/tmp/file0.sub', 0)
        >>> data_sources.set_domain_result_file_path('/tmp/file1.sub', 1)

would be
    def set_domain_result_file_path(self, path: str, domain_id: Optional[int]):
        """Add a result file path by domain.

        This method is used to handle files created by a
        distributed solve.

        Parameters
        ----------
        path: str
            Path to the file.
        domain_id: int, optional
            Domain ID for the distributed files.

        Examples
        --------
        >>> from ansys.dpf import core as dpf
        >>> data_sources = dpf.DataSources()
        >>> data_sources.set_domain_result_file_path('/tmp/file0.sub', 0)
        >>> data_sources.set_domain_result_file_path('/tmp/file1.sub', 1)

Don't hesitate if you want some additional manpower ;)

hi @jfthuong thanks for this suggestion, yes please go ahead an create a PR for this.

@rlagha   PR?? I have not done any modification yet :)

typing support starts in Python 3.5 (typing)

@PProfizi Yes indeed, but typing has evolved along the versions with some great additions in particular in 3.8 and 3.10.
But I saw that you want pyAnsys to support 3.5 so we are good to go (and we could also use typing-extensions (https://github.com/python/typing/blob/master/typing_extensions/README.rst) to add features if needed [bonus: typing-extensions is a dependency of mypy that we could use to check the type hinting]

Following-up on this:
pyansys libraries now all officially support Python 3.7-10, so we might not need typing-extensions .
Also while we have started to implement type-hinting along in most of our current developments (at least the public APIs), I do not think we plan on reworking everything in one session.
This might be more a change in best-practices than a whole separate work, yet everyone is welcome to improve the current code when time permits.


Replace core-foundation dependency to core-graphics-types

core-graphics-types is a smaller dependency, which I think we can accept to depend on across the stack.
core-foundation doesn't appear to be necessary.

r? @grovesNL or @scoopr


Add minimal Cypress tests for integrations

Description
Adds two Cypress tests for the Integrations plugin, taken from the dashboards-observability repository.
Issues Resolved
Resolves #989
Check List

[X] Commits are signed per the DCO using --signoff

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

Blocked by #981

@Swiddis @derek-ho FYI, added backport 2.x label based on https://github.com/opensearch-project/opensearch-dashboards-functional-test/pull/981

Blocked by #981

Hi @Swiddis, could you confirm if it's ok to merge this PR mow?

Yep, should be good to go


Question: How to write styles with a deep structure in react native?

I really like styled-components, it is great, thank you @mxstbr for a this module.
I'm trying to use it with react native, but cannot find a way to describe this case:
style: {
  transform: [
    { perspective: 850 },
    { translateX: - Dimensions.get('window').width * 0.24 },
    { rotateY: '60deg'},
  ],
}

export default styled.View`
  transform: ???;
`;

Is it possible? Thank you in advance.

Huh, that's interesting, I didn't know that was possible in ReactNative! I don't think we support this right now – what would that look like in CSS?

In CSS I think this would look like:
perspective: 850;
transform: translateX(-123) rotateY(60deg)

Where perspective is a valid stand-alone CSS property and translateX sand rotateY are both function values that are composed with a space.

I don't know all the cases in RN since I just started working with it, but I see that there is also:
shadowOffset ReactPropTypes.shape(
  {width: ReactPropTypes.number, height: ReactPropTypes.number}
)

Here is more info:
https://facebook.github.io/react-native/docs/shadow-props.html#props
https://facebook.github.io/react-native/docs/transforms.html#props
Could be nice to have perspective as a 1st level prop, in that case it can be reused in react for web as well. But seems like there are many cases possible, so can be like:
transform-perspective: 850;
transform-rotate: 60deg;
shadow-offset-width: 1;

This way we have a clean logic how to write those styles without learning and remembering all those expectional cases, but just perspective: 850; looks better and reusable in this particular case.

I have an implementation here. @mxstbr suggested a separate module for this, and I agree. If you want to set up the repo, I wouldn’t mind helping out. (Or I can set up the repo—whatever’s easiest for you)

Will do!

Closing in favor of #210, which will add support for this!


Kconfig: Switch to improved globbing statements (+ document a small Kconfig extension)

Commit messages say it all:
Kconfig: Switch to improved globbing statements

A design flaw of 'gsource' is that there's no way to require at least
one file to match the glob pattern. This could lead to silent errors.

Switch to a new design, where a plain 'source' is globbing and requires
at least one file to match. A separate 'osource' (optional source)
statement is available for cases where it's okay for a pattern (or plain
filename) to not match any files.

'orsource' combines 'osource' and 'rsource' (relative source).

This commit search-replaces 'gsource' with 'source', but backwards
compatibility with 'gsource' is still maintained by making it an alias
for 'osource' (and by making 'grsource' an alias for 'orsource').

The three Kconfig files arch/{nios2,posix,xtensa}/Kconfig source
arch/{nios2,posix,xtensa}/soc/*/Kconfig, which doesn't match any files.
Use 'osource' for those. The soc/*/Kconfig files seem to be for
additional SoC-specific symbols, only none exist yet on those ARCHes.

Also use 'osource' for the source of $ENV_VAR_BOARD_DIR/Kconfig in
boards/Kconfig, which doesn't exist for all boards.

Kconfig: Document new def_{int,hex,string} extensions

These work like def_bool, setting the type and adding a default at the
same time. This extension fixes some Kconfig inconsistency.

CC @nashif @dbkinder

@dbkinder
There are some doc changes in the glob commit too btw (just in case you missed it).

@ulfalizer : I have no problem with the changes themselves. But weren't you trying to run away from the "globbing" source in #7402.


Edit file structure and package.json

Separate the project into two parts with a package.json for each one

client
server

Convert the components folders name to a capital letter ( due to react doc. classes start with a capital letter )
add .gitignore file in the client folder
edit the scripts in the server package.json
Delete the yarn.lock don't use yarn and npm together
Delete all commented code in the client and the favicon and edit the title in index.html
Edit the app.js in the server

Please add "Logo" component
New file structure

The app isn't a component either so it shouldn't be in the components folder. I was my version of a compromise as you didn't want it in root


Script System crash

When a c# script that inherits from Scriptable doesn't override Init and Update the script system crashes. I haven't investigated from where the problem comes from, should start somewhere after loading the client defined script assembly.

This used to be an issue due to very hastily and poorly written code. But since switching from mono to dotnet8 and rewritting the script system it seems the problem is resolved


Devise doesn't let me signup using username and a blank email

Seeing the instructions here, I set up devise as my authentication module. However, upon accessing the signup form and filling in the fields, I get the error username is invalid and the server logs show the transaction to roll back citing user_exists (but the database is currently empty). Apparently, devise is running it's own authentication.
If it's of any importance, I leave my email field blank .

The wiki is maintained by the community. So if there aren't any up to date instructions, we recommend you to explore the solution yourself and hopefully contribute your findings back!


Fix quote symbols used in README.md

This PR contain following changes in README.md

replace tabs with 4 spaces
replace quote symbols in README

You can take a look on new version of  document here - https://github.com/napetrov/daal/tree/fix_63

Make sense to address \_ here as well.

make test

Replace \_ "Built libraries are located in the \_\_release\_{os_name}/daal directory"

Updated in 8899ca1


Need to be able to run trace call

For the wallet to estimate gas needed for contract interactions, the connector needs an interface for trace_call
eg:
{"method": "trace_call", "params": [objCall, ["stateDiff", "trace", "vmTrace"]]}

This method call works only with parity, not wih geth.

@splix do we need to add support also for the geth and do you know how it can be done?

Geth has undocumented eth_traceCall method, which returns amount of gas for a tx

With similar parameters, we should support it too?

I think we should support Geth's standard, and make this method official. It's actually simpler than parity's trace.
For geth it's:
eth_traceCall with parameters:

Object - The transaction call object (from/to/gas/gasPrice/value/data)
QUANTITY|TAG - integer block number, or the string "latest", "earliest" or "pending"

returns:
{
	"jsonrpc": "2.0",
	"id": 1,
	"result": {
		"gas": 22680,
		"returnValue": ""
	}
}

Will be done after #14.


accelerator.gather() for non-tensor inputs?

Can I use gather() to merge two non-tensor inputs? For example:
One process has a list of string like [ ['a', 'aa'], ['b', 'bb'] ], another has a list like [ ['c', 'cc'], ['d', 'dd'] ].
Is there any way to merge these two lists into [ ['a', 'aa'], ['b', 'bb'], ['c', 'cc'], ['d', 'dd'] ]?
I think it's necessary when evaluating the model, only gathering the logits and labels may not be enough sometimes.

There is no way to gather strings inputs without going through integers and a tensor, AFAIK. What is your use case? We have distributed evaluation working for summarization and translation in Transformers using Accelerate.

Thanks for your reply! My case is like that:
for inputs, targets, xxxx in validation_dataloader:
    predictions = model(inputs)
    # Gather all predictions and targets
    all_predictions = accelerator.gather(predictions)
    all_targets = accelerator.gather(targets)
    # Example of use with a `Datasets.Metric`
    custom_metric.add_batch(all_predictions, all_targets, xxxx)

xxxx is another non-tensor input (list or nested list) like [ ['a', 'aa'], ['b', 'bb'] ].
accelerator.gather() can help the tensors inputs and targets (with size batch_size) merge from all processes, and yields the tensors all_predictions and all_targets with sizes of batch_size * num_processes, but after the line of accelerator.gather(), non-tensor variable xxxx remains the length of batch_size, which may cause some difficulty to the following metric calculating process.
My final solution is just converting the xxxx to tensor according to some vocabs, and it works.

Hi, @antct  do you find a way to gather non-tensor variables? could you share your solution? Thanks!


Add callback rawfeatures rate support

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: 丁静:x: bruceding丁静 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Typescript type for all id's in the generated sprite

Hi 👋,
I recently started using this project, wich is great to build sprite with no hassle!
I don't have any issue, it's more of an idea.
In my project I use React and Typescript.
I created a Icon component which takes a name prop which should be the id of the svg in the sprite I want to use.
interface IconProps {
  name: string
}

const Icon = ({ name }: IconProps) => {
  return (
    <svg>
      <use href={`icons.svg#${name}`} />
    </svg>
  )
}

And it works great, but miss one thing. Using typescript it would be amazing to be able to generate a type declaration that would contain all of the id of the svg in the sprite so I would get autocompletion for my name prop and I would be able to create my interface like this:
interface IconProps {
  name: IconIdInSprite
}

What do you think ?

Hello. The thing is that all icons and icons names are generated in runtime. On the other hand, TS is an superset of JS, the type checking takes place on compilation time.
You can store somewhere set of all svg names, get enum from that (IconIdInSprite), then manually add them to sprite
https://github.com/svg-sprite/svg-sprite/blob/main/docs/api.md#svgspriteraddfile--name-svg-
https://github.com/svg-sprite/svg-sprite/blob/main/docs/api.md#svgspritercompile-config--callback-

@Kreeg But I think what he wants is generating the interface at runtime, so he will have autocomplete inside the ide. That should be quite easy. @AlexisWalravens  This package does it but doesn't have all the features of svg-sprite


Feedback: Local fonts and env for the footer

Hi folks,
I have two suggestions for explorer so that other projects can host their explorer.

Fonts
It would be very nice and e.g. also useful for data protection if the fonts could be integrated directly into the explorer (locally). This way you would not have to change the code manually to prevent the fonts from being loaded by third parties (webassets.iota.org).

Footer
It would be great if the footer or individual areas of it (imprint, social) could be read out via some kind of configuration.

I think this would make it much easier for people who also want to host a "copy" of Explorer to load (e.g. git pull & build) and use new features.

Would you be willing to do the changes you want yourself and open up a PR ?
Then we can check it and incorporate it.

Sorry, I'm not a developer in that regard and can't create a PR for it. However, I would like to make an alternative host (Explorer) available to the community as part of my project, which is why the changes would also simplify the whole thing.


UWP.SQLITE, How can i set Posts Properties in Blog Model

This issue tracker is for documentation
For product issues, use https://github.com/aspnet/EntityFramework/issues
I am debugging uwp sample now.
why Posts Properties in Blog class is always null ??
Is it a problem or my mistake?
i did edit source code.

You need to include related data to have navigation properties populated. Read the article at https://docs.efproject.net/en/latest/querying/related-data.html

thank you for your answer
i can find a  that lazy loading is not implemented


It does not allow to download purchased course if you disconnect while downloading

I was downloading udemy course. Due to some reason i have to disconnect downloading. Now I am trying to download again but facing some problem.

[-] Unable to extract login-form form
Traceback (most recent call last):
File "udemy-dl.py", line 936, in
main()
File "udemy-dl.py", line 725, in main
udemy.ExtractAndDownload()
File "udemy-dl.py", line 303, in ExtractAndDownload
self.login()
File "udemy-dl.py", line 40, in login
extract_info.login(self.username, self.password)
File "/opt/udemy-dl/udemy/_extractor.py", line 147, in login
login_form      = self._fill_login_form(login_popup, username, password)
File "/opt/udemy-dl/udemy/_extractor.py", line 98, in _fill_login_form
login_form = self._form_hidden_inputs('login-form', webpage)
File "/opt/udemy-dl/udemy/_extractor.py", line 88, in _form_hidden_inputs
return _hidden_inputs(form)
File "/opt/udemy-dl/udemy/_utils.py", line 80, in _hidden_inputs
html = re.sub(r'<!--(?:(?!', '', html)
File "/usr/lib/python3.4/re.py", line 179, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or buffer

I'm getting this same error, but my internet connection wasn't disconnected.... it is working ok

@masifpak80 i 'm closing this with duplicate & will discuss about this error in #126 as both are same.


-- Configuring incomplete, errors occurred!

-- Configuring incomplete, errors occurred!
See also "/home/karthik/seasocks/build/CMakeFiles/CMakeOutput.log".
See also "/home/karthik/seasocks/build/CMakeFiles/CMakeError.log".

Please provide suitable information like operation system, compiler, build logs and steps to reproduce.


infer_discriminator

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
We should have a config setting which causes Pydantic to try to infer union discriminators.
It's shouldn't try to do anything too clever, it should just look for:

fields on all members of the union with the same name
where all fields are literals or enums
and none of the allowed values overlap

If so, generate a discriminator.
Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[ ] JSON Schema
[ ] Dataclasses
[X] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

I guess we make the setting:

False - don't infer, current behaviour
simple - literals only
exhaustive - try all the things we can reasonably think of to create a discriminator

Since this method will be on GenerateSchema , any more complex semantics can be implemented by uses.

@samuelcolvin Hey, I'd like to pick this up if it's still available

@samuelcolvin @dmontagu Hey guys, I started working on this and I started thinking what should be the behavior incase of errors? Should I create a new kind of error/exception?
For example, what should happen if no discriminator could be inferred? Or perhaps the other way around, what if more than one field could be a valid discriminator, should an exception be raised? Or should the first one found be picked?


No more .github/PULL_REQUEST_TEMPLATE.md

It seems that https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/commit/9870760c24d98d4108fe53721ab54d7cb6b98617 deleted it. Do we need an exception somewhere in smithy?
CC @beckermr

Let's reopen to figure out how deleting the template can be avoided going forward; might need work in smithy

Maybe this?
https://conda-forge.org/docs/maintainer/conda_forge_yml/#skip-render


added support for options.kind for actions

resolving issue #9

Thanks for submitting this, good addition.
Can you add some unit tests to the PR to verify this functionality?

I've now reviewed the code base and realised this is already supported, see #9 for details.
I'm pushing changes to move the default nodejs version to 'default' as per @rabbah's suggestion.


Compile-time regex for smaller WASM binary size

I would like to once again raise the question of compile-time regular expressions. They were once provided by regex-macros crate, but are no longer supported.
If I understand correctly, compiled-time regular expressions were deems unnecessary because their primary use-case was compile-time pattern verification, which can now be achieved by other means, like invalid_regex Clippy lint or lazy-regex crate.
But there is another reason one might want to avoid including a regex compiler into the application, and that is binary size. This becomes especially important with WASM targets. The increase in WASM binary size from the regex crate is very noticeable. In my experiments it varies from ~200 KiB to ~600 KiB depending on the features. I made a small demo, check it out to see for yourself: https://github.com/amatveiakin/regex-wasm-demo
Even 200 KiB is a lot for a web app, and should best be avoided. And I don't think there is a better way to do this than building the regex at compile-time. What do you think?

compiled-time regular expressions were deems unnecessary because their primary use-case was compile-time pattern verification

Hmmm, I'm not sure that's quite accurate. I deemed them mostly unnecessary for the use case of wanting them to be statically verified, but I don't think I meant to say that the primary use case of compile time regexes themselves was "just" verification. In particular, when I originally added regex!, I was far more interested in its perf advantages. We can go all the way back to 2014 where I posted benchmarks comparing "dynamic" regexes with "natively compiled" or "compile time" regexes: https://github.com/rust-lang/rfcs/pull/42#issuecomment-40782864

But there is another reason one might want to avoid including a regex compiler into the application, and that is binary size.

I agree that this would substantially reduce binary sizes in a large number of cases. Do note though that it isn't that hard to write a regex that, when compiled, would itself be bigger than the entire regex crate. It doesn't even require writing a pathological regex because Unicode really bloats things up.
But the good news is that this is possible to do today, although the flow for doing it has not been streamlined yet. Specifically, see:

https://docs.rs/regex-automata/latest/regex_automata/dfa/index.html
https://docs.rs/regex-automata/latest/regex_automata/dfa/dense/struct.DFA.html#method.from_bytes

bstr generates DFAs and embeds them into the binary. When you build bstr, you only need to bring in the regex runtime, not the compiler. Do note though that bstr uses regex-automata 0.1 and the docs linked above are for regex-automata 0.2. And ucd-generate only works for regex-automata 0.1. So if you want to use regex-automata 0.2, you'll need to write your own little CLI generator, but it shouldn't be too hard to port it from the regex-automata 0.1 generator in ucd-generate.
All of this stuff is a WIP which is why it's a bit of a mess right now. This use case will be fleshed out a bit more with better tooling and less confusion Real Soon Now.
It's also worth pointing out that the compile time regexes that once existed didn't really reduce binary size. In particular, those compile time regexes were "just" a specialization of the PikeVM. It avoided some runtime costs in the "dynamic" PikeVM, but it still relied on the the NFA internals and all that. The way regex-automata works, it builds full DFAs, which are just a chunk of bytes. The regex runtime needed for reading and searching the DFA is indeed quite small.

And I don't think there is a better way to do this than building the regex at compile-time. What do you think?

It really really depends. One can build a much smaller regex library by giving up some things, notably, perf and failure modes. For the sake of argument, if I said I could hand you a regex engine that was an order of magnitude smaller (say, 20KB) but was also an order of magnitude slower, would you be happy about that?

I don't think I meant to say that the primary use case of compile time regexes themselves was "just" verification. In particular, when I originally added regex!, I was far more interested in its perf advantages. We can go all the way back to 2014 where I posted benchmarks comparing "dynamic" regexes with "natively compiled" or "compile time" regexes: rust-lang/rfcs#42 (comment)

I see, thanks for the clarification! The benchmark results look impressive.

Do note though that it isn't that hard to write a regex that, when compiled, would itself be bigger than the entire regex crate. It doesn't even require writing a pathological regex because Unicode really bloats things up.

Interesting. In theory one could always measure, of course. In practice it means we cannot claim that always using compile-time regexes is a safe default :/ Maybe this could be mitigated by a compiler warning “this regex compiled to more than n KiB”?

This use case will be fleshed out a bit more with better tooling and less confusion Real Soon Now.

I guess I'll wait then :)

It's also worth pointing out that the compile time regexes that once existed didn't really reduce binary size. In particular, those compile time regexes were "just" a specialization of the PikeVM.

Oh, I didn't realize compile-time regexes were not compiled to native code. Do you think this would make sense? I guess besides smaller binary size it could also be even faster than the once existing (semi)compiled implementation.

Another approach would be just compiling the NFA

Sorry, I'm not following. We are talking about compiling a regex fully to native code: no regex compilers, no VMs, no NFA to DFA converters, no nothing, right? I understand how DFA can be turned into a straightforward native implementation. But how would you do it for NFA?

if I said I could hand you a regex engine that was an order of magnitude smaller (say, 20KB) but was also an order of magnitude slower, would you be happy about that?

For my particular case — yes. But I don't know if this answer is representative. How much work do you think it would require?
Also it just occurred to me that for WASM code executed in the browser there might be another solution: just delegate regex to JS! There will be some overhead for passing the strings back and forth, but matching itself could potentially be even faster, because it will be implemented in native code, while WASM is executed in a VM.

To clarify something: there is definitely no way that Regex::new is going to magically use compile time regexes under any circumstances. The best possible thing that could happen there is that Regex::new could become const at some point in the future. But doing that requires most or all of the Rust language (including dynamic memory allocation and interior mutability) to be const. And that's just compiling an existing regex at compile time. It is not actually building out a full DFA.
For the compile time regexes you're after, it would have to be a separate API.

Oh, I didn't realize compile-time regexes were not compiled to native code. Do you think this would make sense? I guess besides smaller binary size it could also be even faster than the once existing (semi)compiled implementation.

It was compiled to native code. The native code was a specialization of the PikeVM.
It's not obvious to me that compile time regexes will be faster. The problem here is that a regex search is far more complicated than a simple "let's do a DFA traversal." There are literal optimizations, and capturing groups and reverse searches and all sorts of other things. When I think of a compile time regex, I think of a very low level "let's build this DFA offline and embed it into our program so we can use it at runtime without needing to build it or bring in the machinery required to build it." It presupposes that you don't need the perf tricks of the full regex engine search.

Sorry, I'm not following. We are talking about compiling a regex fully to native code: no regex compilers, no VMs, no NFA to DFA converters, no nothing, right? I understand how DFA can be turned into a straightforward native implementation. But how would you do it for NFA?

OK, so when you say native code, it sounds like you're thinking about something that builds a DFA and then converts that DFA into a state machine with Rust enums and a match statement, right? If so, I don't personally have any plans to work on that any time soon, and if you want something like that, I think you'd be far better off using something like re2c or Ragel.
The compile time regexes that exist in regex-automata today build table based DFAs. The search runtime involves reading and traversing the table based DFA. The nice thing is that the same search runtime can be used for many DFAs, so the overall binary size of this approach is likely far superior than the "native code" approach I described above.
From there, it's perhaps easier to see how a compile-time NFA would work. You just need a slightly chunkier search runtime that knows how to interpret the NFA and run the PikeVM. It is chunkier, but only slightly so. You don't need the regex parser (which is, currently, a big chunk of the binary size), you don't need a compiler. You just need an NFA, the code to interpret it and the PikeVM. The PikeVM is itself quite small.
Here's the problem: "native code regex" and "compile time regex" and "const fn regex" are all kind of referring to the same idea, but there are actually many many different ways those ideas can be executed. The design space here is huuuuuge.

For my particular case — yes. But I don't know if this answer is representative. How much work do you think it would require?

#656 needs to get done first. Once that's done, the next step would probably be to write a parser that converts concrete syntax to a regex_syntax::hir::Hir directly. The parser would want to be written in a way that minimizes binary size, so you'd forget about error handling and maybe some other things. Once that exists, it'd be possible to build a smaller version of regex-syntax, then build regex-automata with just the PikeVM and supporting infrastructure and you'd be off to the traces. Now, it's not quite the most minimal thing you could possibly do, so I don't actually know if it would be enough. But it's the path I would try. The alternative is just go out and build your own regex engine while making trade offs that minimize binary size at every turn.
The key to understand is that the current regex crate was built without much attention to binary size, because failure modes and perf end up mattering more of the time to most people. I did add crate features to disable a lot of stuff, but they only take you so far.

Also it just occurred to me that for WASM code executed in the browser there might be another solution: just delegate regex to JS! There will be some overhead for passing the strings back and forth, but matching itself could potentially be even faster, because it will be implemented in native code, while WASM is executed in a VM.

Yes. To be honest, I assumed that you had already considered this and dismissed it for one reason or another. :P

But this API could be a drop-in replacement where you change Regex::new to, say, regex! and all (or most) things just work, right?

If that were the case, it would imply that compile time regexes support things like capture matches. If you fix that as a requirement, that has quite a large implication on what exactly is being built at compile time. And if you're copying the existing API instead of providing something much more low level, my guess is that users of said API are going to assume that the compile-time API would be at least as fast at searching in all cases. That in turn implies that literal optimizations and basically the full regex engine and all its nooks and crannies are available at compile time. This would in turn negate a lot of the binary size advantage (although not all), and is also a very very very large task.
The thing is, building a data structure that is only used at runtime and building a data structure that can also be loaded cheaply at compile time are two very very different things. I did exactly that for DFAs in regex-automata (of which you are encouraged to peruse the source code), and it adds probably an entire order of magnitude of complexity to the code that wouldn't have otherwise needed to be there without the "compile time" use case. More to the point, a lot of that code requires unsafe.
This sort of design (which AFAIK is required to support "compile time API that is a drop-in replacement for the current API") just infects everything from how you read your data types to how you design your data types themselves. I do think it might be nice to do, but it is an enormous under-taking. We're not even just talking about regex internals either, both the memchr and aho-corasick crates would need to be overhauled to support it as well.
The comparatively simpler thing is to provide lower level compile time APIs. regex-automata does that for fully compiled DFAs. But what you can use them for is limited when compared to a full blown regex. And since their execution model is "just use a DFA," they don't have the literal optimizations that often speed up searches by an order of magnitude (or more).

Yes, that's what I meant. Sorry if this sounds naive. My understanding of regex engines is based on a university course on formal grammars, so I have limited intuition of the real-word trade-offs involved :)

Yeah so this and "drop in replacement for current API" are for the most part incompatible ideas. The former requires handling capture groups and start-of-match reporting. But a "state machine in code using enums" is just as powerful as the table-based DFAs that regex-automata builds today. Which is to say, the only thing it gives you is the end location of a match. (To get the start of a match, you need to build a second separate reverse DFA and use that to do a second scan.) Capturing groups require something more expressive than a DFA.

Out of curiosity, have you tried benchmarking re2c against the existing compile-time regex implementation?

No. It would be nice to do it, but it's nowhere near my priority. I would expect them to be competitive.

Second, there is the feature-parity problem. I'm writing a library that is used both server-side and client-side. The server side is pure Rust compiled to native code, so it uses the regex crate implementation. Suppose we delegate client-side regexes to JS. The problem is, JS and Rust support different sets of regex features. For example, JS regexes allow backreferences and I don't think there is a way to disable this. The resulting setup would be error-prone, because it opens the door to cases where a piece of code tested on the client starts mysteriously failing on the server or vice versa.

Indeed, if you require both regex engines to behave the same, then you either need to use a Javascript-regex compatible regex engine in the backend, or you need to bite the bullet on binary size with the regex crate for the foreseeable future.

Thanks for the detailed answers! This was insightful.

my guess is that users of said API are going to assume that the compile-time API would be at least as fast at searching in all cases.

Not if it's positioned as a binary-size optimization (like "-Os"). But I understand that this use-case is rather niche. The two cases that come to mind are web and embedded.

The comparatively simpler thing is to provide lower level compile time APIs. regex-automata does that for fully compiled DFAs. But what you can use them for is limited when compared to a full blown regex. And since their execution model is "just use a DFA," they don't have the literal optimizations that often speed up searches by an order of magnitude (or more).

I've checked what happens if you do DFA::from_bytes plus re.find_leftmost_fwd(...). WASM binary is indeed much smaller than the regex crate even in the minimal configuration: 46 KiB vs 214 KiB uncompressed size. But of course there is a long way from find_leftmost_fwd to capture support, as I understand now.

Out of curiosity, have you tried benchmarking re2c against the existing compile-time regex implementation?

No. It would be nice to do it, but it's nowhere near my priority. I would expect them to be competitive.

I've benchmarked regex crate against re2c on regex-dna benchmark, and the regex crate came out much faster even without compilation. Probably this is due to literal and other optimizations that you've talked about.
To sum up. There doesn't seem to be any obviously superior solution for reducing the binary size of an application that needs to parse regexes. I've tried to list all the options that we discussed.
Solutions on regex crate side:
R1. Add a feature flag to make regex crate even smaller at the expense of execution speed (blocked on #656).
R2. Compile NFA to byte code. Requires an NFA, the code to interpret it and the PikeVM, which is quite small.
R3. Compile DFA to native code. Minimal overhead for the execution machinery, but: requires huge amounts of work to implement the full regex interface with capture support; code size may grow exponentially; is likely much slower than the run-time version (or requires to embed many optimizations, which reduces the binary size improvement).
Solutions on the user side:
U1. Produce the compiled regex via re2c, Ragel or flex. Requires a lot of manual work: not all tools support Rust output; they complicate the build pipeline; some tools rely on a custom syntax which is not exactly regex; things like capture groups may require additional efforts.
U2. For WASM: delegate regexes to JS. Works only for a fraction of build targets and cannot be made 100% compatible with Rust regex syntax, but could be a viable solution for a client-only library.
U3. Replace regexes with manual parsers. This is feasible if the regexes are few and simple.
(Frankly speaking, I'm inclined to go with U3 for now, because everything else seems surprisingly complicated)
Is this an accurate summary of this discussion? Do you think it makes sense to prioritize something like this for the regex crate in the near future?

Add a feature flag to make regex crate even smaller at the expense of execution speed

This already exists and it sounds like you've already taken advantage of it. And note that it isn't just about execution speed. You can disable Unicode too. That isn't about speed, but about functionality. If you keep Unicode around, then there's not much that can be done about binary size with just crate features. It might be possible to get a little smaller, but there's not really much left to pursue in this avenue.

Compile NFA to byte code. Requires an NFA, the code to interpret it and the PikeVM, which is quite small.

I think the better way of framing this is to "provide constant time deserialization APIs from &[u8] to NFA, and its dual serialization API that converts an NFA to a Vec<u8> that can be deserialized." If you have that, then everything else falls into place.

Compile DFA to native code. Minimal overhead for the execution machinery, but: requires huge amounts of work to implement the full regex interface with capture support; code size may grow exponentially; is likely much slower than the run-time version (or requires to embed many optimizations, which reduces the binary size improvement).

The "compile DFA to native code" bit is probably not something I plan on pursuing personally. regex-automata, today, already provides the deserialization APIs I mentioned above for NFAs, but for DFAs. So you already can build a DFA offline and then execute a search with it.
The latter half of your paragraph doesn't really follow. The latter half of your paragraph is basically: "provide constant time deserialization APIs from &[u8] to Regex, and its dual serialization API that converts a Regex to a Vec<u8> that can be deserialized." That requires the NFA deserialization routines, and doing that for all internal data structures and regex engines.

Do you think it makes sense to prioritize something like this for the regex crate in the near future?

I don't get paid to work on this. I don't schedule my time this way. And depending on what "something like this" is referring to, you're talking about man-years of effort. There is no "near term" here I think.

Also, the other part of this is that I don't know whether I want to do some of these things at all. And I don't mean "not work on them" (I am actually personally interested in the work), but rather, whether they're a good fit. The biggest concern I have is that providing those constant time deserialization APIs (which is ultimately what you need to be able to execute regex searches without pulling in the full regex compilation machinery) creates a huge amount of code complexity and requires quite a bit of unsafe to do if you have any hope of not sacrificing search speed. Those are non-trivial downsides, and it may mean that the regex crate is just never something you can use if minimizing binary size is the only thing you care about.
I'm not saying anything for sure at the moment, but I just wanted to make it clear that the ideas themselves are not necessarily unambiguous good directions to head in.

I'm going to close this because I don't really think there is anything meaningfully actionable here. Basically what this issue boils down to is that the regex crate binary size is "big" for some sense of "big," and particularly in contexts where size might matter for. For example, in WASM. The regex crate already exposes a number of features to trim its binary size down considerably, but the end result is still kind of big. I don't think there's really much more that can be done here, other than building a regex-lite, as described in #961.
In theory, as discussed in this issue, another way out is to make it possible to build regexes into a serialized form, and then provide a way to use the regex's search runtime only along with the deserialization APIs. This could lead to considerably smaller overall binary size, but the complexity (as discussed above) in doing this is enormous. It isn't going to happen any time soon, and I'm not even sure it should happen. In particular, it opens up a huge can of worms with respect to maintaining a stable binary format for regexes, which in turn makes evolution of the implementation itself far more precarious.

it opens up a huge can of worms with respect to maintaining a stable binary format for regexes

Is a stable binary format really necessary? If the serialized form is produced by a proc macro (regex!), then it should be possible to guarantee that the parser and the executor are always updated together.
Still, I see that building a compile-time regex parser (however one defines compile-time) is a huge effort which increases maintenance burden and has serious downsides. So closing the issue seems fair.
A regex-lite crate sounds great! Thanks for considering this.

it's almost certain that people will use it anyway

Hmm. Yeah, that sounds plausible.

AIUI in order for something like regex! to work, that format will need to be exposed in some way

I think so too. IIUC you'll have to put the macro into a separate public crate due to Rust/Cargo limitations. And then you can't stop people from using that crate directly.

I think so too. IIUC you'll have to put the macro into a separate public crate due to Rust/Cargo limitations. And then you can't stop people from using that crate directly.

Right, although to be clear here, what I'd expect would need to happen is that regex would need to expose some kind of API that can be called by that macro crate. And since the macro crate is just another crate, the API exposed by regex would be callable by anyone. I would of course slap a #[doc(hidden)] on it, but it's very likely people will find it and use it. Because having a binary format you can serialize and store of a regex and then load later is an incredibly useful and flexible thing.


ci: Update the mobile_release workflow with the changed config options

The mobile Bazel options were updated in
https://github.com/envoyproxy/envoy/pull/28856, but the mobile_release workflow wasn't updated to use mobile-release-android. It was probably not caught by CI because it is a scheduled workflow that is run once a week as opposed to running on every PR.

/retest


AppendCertsFromPEM fails on go1.10rc1

When testing fabio with go1.10rc1 I've stumbled over a failing test (https://github.com/fabiolb/fabio/issues/434)
I've traced it down to a call to AppendCertsFromPEM failing with a certificate that works fine in go1.9.2. The cert was created using the HashiCorp Vault PKI backend. I've included one of the certs in a full test case below.
I've checked for a note in https://tip.golang.org/doc/go1.10#library but couldn't find anything obvious. Please let me know if I missed something.
What version of Go are you using (go version)?
go1.10rc1
Does this issue reproduce with the latest release?
yes, checked master a0222ec518
What operating system and processor architecture are you using (go env)?
darwin_amd64 on macOS 10.13.3
What did you do?
see test case
package main

import (
	"crypto/x509"
	"fmt"
	"log"
)

const cert = `-----BEGIN CERTIFICATE-----
MIIDOzCCAiOgAwIBAgIUaFacnWI+18PkzWw3L1ZhDyWE6/UwDQYJKoZIhvcNAQEL
BQAwGDEWMBQGA1UEAxMNRmFiaW8gVGVzdCBDQTAeFw0xODAyMDYwMjA0MTNaFw0x
ODAyMDYwNDA0NDNaMBgxFjAUBgNVBAMTDUZhYmlvIFRlc3QgQ0EwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIBohqz/hHEN6y2emMDG/fgsggbAXzrIkw
58orFVbK/+hGFMUPpBTZ15r5rYW5nNhIf/tyecLN1CSy/12HLbpx7ebpvMOj2i7b
/VgiadSpTklJEGUIt+nYPeLT+8qLXqiOQA4CwsES/UgQ3h+QMtwjAdcaloho1Ara
RDctRLlEf/VvBYVozPqYfbKRh4ofmqLo9KJFF8yMAOgkFsSmP8/Pv8Cii2fThyGB
v4J56uPUxHW5ROuy1WGu25rEB7Txuvqgpl9m7lN/oqkUhHrUMwFUx5kcG0fWPc2t
Rv/mePw+cDh/5P8IsBLgYGpjGKUGgQduE4LHjjRyUf/xnzuW8jOrAgMBAAGjfTB7
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTIDU8u
KA3PavIxercuzYTMDcSDcTAfBgNVHSMEGDAWgBTIDU8uKA3PavIxercuzYTMDcSD
cTAYBgNVHREEETAPgg1GYWJpbyBUZXN0IENBMA0GCSqGSIb3DQEBCwUAA4IBAQBr
0Nn+msFZjAA4gpHxt/7EvyfbUTjNmvXKALvhuX6z0qgdlFWVFYutNIkbKPF3a06H
gVW7zIvnKg2BX+bkhM/C/IC3oZsD3gK56A4Q71tK9q8QG0cWcqCyfqtG458Q1i8A
05t9rJ1V6ppN9VWe11tvTgEz5FK0e7jnQQEXH8hNjAXQXX7sbQzI+5GagUA3/ZT4
7bl/lkWg9yZCl/lM8UbFxlaRow4sVX5080ilrGlbCn29Ob6kFzWEv7rXs7BXrNgN
YgWDKTrsa4uD7NTuMmoJvsIw7FLkE8XgNNwuURVLsJ4/+TPbfdbVsZW8qO0s0dR+
AEFqi3JlxPWFVBU01oys
-----END CERTIFICATE-----`

func main() {
	p := x509.NewCertPool()
	ok := p.AppendCertsFromPEM([]byte(cert))
	fmt.Printf("p: %#v\n", p)
	if !ok {
		log.Fatal("AppendCertsFromPEM failed")
	}
}

$ ~/go1.9.2/bin/go run main.go
p: &x509.CertPool{bySubjectKeyId:map[string][]int{"\xc8\rO.(\r\xcfj\xf21z\xb7.̈́\xcc\răq":[]int{0}}, byName:map[string][]int{"0\x181\x160\x14\x06\x03U\x04\x03\x13\rFabio Test CA":[]int{0}}, certs:[]*x509.Certificate{(*x509.Certificate)(0xc4200a4000)}}

$ ~/go1.10rc1/bin/go run main.go
p: &x509.CertPool{bySubjectKeyId:map[string][]int{}, byName:map[string][]int{}, certs:[]*x509.Certificate(nil)}
2018/02/06 03:57:46 AppendCertsFromPEM failed
exit status 1

Update 1: updated the test app to be git bisect friendly

This looks like the commit that changed the behavior:
commit 9e76ce70701ceef8fbccfb953b33a2ae7fe0367c
Author: Adam Langley<EMAIL_ADDRESS>Date:   Sat Sep 9 17:05:41 2017 -0700

    crypto/x509: enforce all name constraints and support IP, email and URI constraints

    This change makes crypto/x509 enforce name constraints for all names in
    a leaf certificate, not just the name being validated. Thus, after this
    change, if a certificate validates then all the names in it can be
    trusted – one doesn't have a validate again for each interesting name.

    Making extended key usage work in this fashion still remains to be done.

    Updates #15196

    Change-Id: I72ed5ff2f7284082d5bf3e1e86faf76cef62f9b5
    Reviewed-on: https://go-review.googlesource.com/62693
    Run-TryBot: Adam Langley<EMAIL_ADDRESS>    TryBot-Result: Gobot Gobot<EMAIL_ADDRESS>    Reviewed-by: Russ Cox<EMAIL_ADDRESS>
found with git bisect and then manually confirmed that the preceding commit a4aa5c3181 works.

AppendCertsFromPEM hides errors. The actual error is cannot parse dnsName "Fabio Test CA", as shown in:
bradfitz@gdev:~$ cat x.go
package main

import (
        "crypto/x509"
        "encoding/pem"
        "fmt"
        "log"
)

func main() {
        const cert = `-----BEGIN CERTIFICATE-----
MIIDOzCCAiOgAwIBAgIUaFacnWI+18PkzWw3L1ZhDyWE6/UwDQYJKoZIhvcNAQEL
BQAwGDEWMBQGA1UEAxMNRmFiaW8gVGVzdCBDQTAeFw0xODAyMDYwMjA0MTNaFw0x
ODAyMDYwNDA0NDNaMBgxFjAUBgNVBAMTDUZhYmlvIFRlc3QgQ0EwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIBohqz/hHEN6y2emMDG/fgsggbAXzrIkw
58orFVbK/+hGFMUPpBTZ15r5rYW5nNhIf/tyecLN1CSy/12HLbpx7ebpvMOj2i7b
/VgiadSpTklJEGUIt+nYPeLT+8qLXqiOQA4CwsES/UgQ3h+QMtwjAdcaloho1Ara
RDctRLlEf/VvBYVozPqYfbKRh4ofmqLo9KJFF8yMAOgkFsSmP8/Pv8Cii2fThyGB
v4J56uPUxHW5ROuy1WGu25rEB7Txuvqgpl9m7lN/oqkUhHrUMwFUx5kcG0fWPc2t
Rv/mePw+cDh/5P8IsBLgYGpjGKUGgQduE4LHjjRyUf/xnzuW8jOrAgMBAAGjfTB7
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTIDU8u
KA3PavIxercuzYTMDcSDcTAfBgNVHSMEGDAWgBTIDU8uKA3PavIxercuzYTMDcSD
cTAYBgNVHREEETAPgg1GYWJpbyBUZXN0IENBMA0GCSqGSIb3DQEBCwUAA4IBAQBr
0Nn+msFZjAA4gpHxt/7EvyfbUTjNmvXKALvhuX6z0qgdlFWVFYutNIkbKPF3a06H
gVW7zIvnKg2BX+bkhM/C/IC3oZsD3gK56A4Q71tK9q8QG0cWcqCyfqtG458Q1i8A
05t9rJ1V6ppN9VWe11tvTgEz5FK0e7jnQQEXH8hNjAXQXX7sbQzI+5GagUA3/ZT4
7bl/lkWg9yZCl/lM8UbFxlaRow4sVX5080ilrGlbCn29Ob6kFzWEv7rXs7BXrNgN
YgWDKTrsa4uD7NTuMmoJvsIw7FLkE8XgNNwuURVLsJ4/+TPbfdbVsZW8qO0s0dR+
AEFqi3JlxPWFVBU01oys
-----END CERTIFICATE-----`

        block, _ := pem.Decode([]byte(cert))
        if block == nil {
                log.Fatal("no block")
        }
        if block.Type != "CERTIFICATE" || len(block.Headers) != 0 {
                log.Fatalf("Bogus: %#v", block)
        }

        _, err := x509.ParseCertificate(block.Bytes)
        if err != nil {
                log.Fatalf("ParseCertificate: %v", err)
        }
        fmt.Println("ok")
}

bradfitz@gdev:~$ GOROOT=$HOME/go1.9 go run x.go
ok

bradfitz@gdev:~$ go run x.go
2018/02/06 06:16:21 ParseCertificate: x509: cannot parse dnsName "Fabio Test CA"
exit status 1

bradfitz@gdev:~$ go version
go version devel +a0222ec Tue Feb 6 00:25:23 2018 +0000 linux/amd64

This is probably working as intended. @agl?

@bradfitz Yes, changing the name to a DNS pattern like fabio-ca.com fixes it. Thx a lot
Maybe add something to the release notes? Feel free to close this.

PEM, in general, tries to pull out certificates or private keys embedded in basically anything. Thus it'll blow through all sorts of PEM syntax errors looking for something valid.
In that vein, AppendCertsFromPEM also ignores certificate parsing errors and carries on to try and find something valid. That may have been a bridge too far and I can certainly see that, once we find a valid PEM block with the correct type, errors should be bubbled up.
If others agree, I can cook up that change. (Although it's someone else's call whether it makes 1.10.)
But, otherwise, it's unfortunate that we allowed invalid DNS names to survive for so long. But, to make the name constraints code sane, an invariant was needed that DNS names in parsed certificates look vaguely DNS-like.


Choose Element and When with disparate conditions?

It's not clear from the doc if the Choose element will evaluate When elements in order and stop at the first evaluated true statement (like a whole if/else block) OR if it'll evaluate each When block and execute ALL of the ones with matching conditions.
It only clearly states that Otherwise is evaluated if all others evaluated to false, which is ambiguous to determining the behavior of the When blocks as I asked above.
(The complete example at the end also doesn't clarify the behavior as it's checking for two different values on Configuration across the two When blocks.)
Clarity on exactly how many When blocks will be executed in a Choose would be nice to have in this docset, thanks!

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: c729230e-ecb1-4f74-b4b0-71837eceb031
Version Independent ID: 8235a255-0c64-0154-e262-4e6d40e5229e
Content: Choose Element (MSBuild) - MSBuild
Content Source: docs/msbuild/choose-element-msbuild.md
Product: visual-studio-windows
Technology: msbuild
GitHub Login: @ghogen
Microsoft Alias: ghogen

Looks like this is called out in the parent doc: https://learn.microsoft.com/visualstudio/msbuild/msbuild-conditional-constructs
But would be nice to have re-iterated in this doc again as well.


Display info bar when PDF contains attachments

When a PDF contains attachments, no indication is given that there are attachments available. Users have to manually toggle the sidebar and switch to the attachments tab. Instead, a notification bar should be shown to indicate that attachments are available, and maybe a button that opens the sidebar in attachment view.
PDF document: http://www.jasnapaka.com/bugs/aaa.pdf
OS: Windows 7 64 bit
pdf.js: Firefox 42 (32bit, release), PDF.js: ?

Given that this issue is basically about the same thing as #5961, I don't think that it's necessary to keep both of them open; hence I'm closing this one as a duplicate.


NoSuchEntityExistsError despite TS compiling when calling EntityManager.create

Hey, thanks for an awesome library!
/* eslint-disable new-cap */
import "reflect-metadata";
import { Attribute, Entity, Table } from "@typedorm/common";
import { createConnection, getEntityManager } from "@typedorm/core";
import { v4 } from "uuid";

@Entity({
  name: "AccountState",
  primaryKey: {
    partitionKey: "{{accountId}}",
  },
})
class AccountState {
  @Attribute({ unique: true })
  accountId!: string;

  @Attribute()
  flag!: boolean;

  constructor({ accountId, flag }: { accountId: string; flag: boolean }) {
    this.accountId = accountId;
    this.flag = flag;
  }
}

const accountStateTable = new Table({
  name: "AccountStateTable",
  partitionKey: "accountId",
});

createConnection({
  table: accountStateTable,
  entities: [AccountState],
});

(async () => {
  const accountId = v4();
  const accountState = new AccountState({ accountId, flag: true });
  const entityManager = getEntityManager();
  await entityManager.create<AccountState>(accountState); // works
  await entityManager.create<AccountState>({ accountId, flag: true }); // fails
})();

The above code compiles with no TS errors, but running it throws:
Error: No such entity named "Object" is known to TypeDORM, make sure it is declared at the connection creation time.
    at Connection.getEntityByTarget (/Users/mishabruml/packages/core/src/classes/connection/connection.ts:158:13)
    at DocumentClientRequestTransformer.toDynamoPutItem (/Users/mishabruml/packages/core/src/classes/transformer/document-client-request-transformer.ts:115:63)
    at EntityManager.<anonymous> (/Users/mishabruml/packages/core/src/classes/manager/entity-manager.ts:148:55)
    at Generator.next (<anonymous>)
    at /Users/mishabruml/*********
    at new Promise (<anonymous>)
    at __awaiter (/Users/mishabruml/******
    at EntityManager.create (/Users/mishabruml/******
    at /Users/mishabruml/******
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

I think this problem could be solved with some more checks, maybe an instanceof typeguard here https://github.com/typedorm/typedorm/blob/9ae116dd042edaa1c151d00a29099a19df99ee58/packages/common/src/utils/get-entity-definition.ts#L8
Happy to make a PR?
Cheers,
Misha

Hi @mishabruml
Great find. PRs are always welcomed.
Can I suggest that you follow the Conventional Commits when you commit the code upstream?
These commit messages are VERY important as they are used to figure out what will be the next release (patch, minor, major) as well as are used for generating the release notes.
I will try to also set up a contributing guide to the repo, sometime this week.

Hey @whimzyLive cool, thanks. Does the code I've linked to look like the right place to resolve this?
RE: conventional commits, no probs. If desirable, its possible to enforce this via husky or similar. I can PR that too?


Update minimist dependency and .npmignore

The dependency on minimist was out of date.
Resolve #42.
Please npm publish in case you accept this PR.

@substack friendly reminder

Updated this ... after more than a year :astonished:

minimist is now 1.2.0, ping @substack

Closing this PR out of frustration.