Body picks up speed instead of stopping on static body (Bug)

It seems like there's a bug in the following set-up, reproducible by with the default settings and Step(1/60f, 8, 8) (not the test-bed settings):
b2Vec2 gravity;
gravity.Set(0.0f, -10.0f);
m_world = new b2World(gravity);
b2ChainShape chainShape;
b2Vec2 vertices[] = {b2Vec2(-5,0), b2Vec2(5,0), b2Vec2(5,5), b2Vec2(4,1), b2Vec2(-4,1), b2Vec2(-5,5)};
chainShape.CreateLoop(vertices, 6);

b2FixtureDef groundFixtureDef;
groundFixtureDef.density = 0;
groundFixtureDef.shape = &chainShape;

b2BodyDef groundBodyDef;
groundBodyDef.type = b2_staticBody;

b2Body *groundBody = m_world->CreateBody(&groundBodyDef);
b2Fixture *groundBodyFixture = groundBody->CreateFixture(&groundFixtureDef);

b2CircleShape ballShape;
ballShape.m_radius = 1;

b2FixtureDef ballFixtureDef;
ballFixtureDef.restitution = 0.75f;
ballFixtureDef.density = 1;
ballFixtureDef.shape = &ballShape;

b2BodyDef ballBodyDef;
ballBodyDef.type = b2BodyType::b2_dynamicBody;
ballBodyDef.position = b2Vec2(0, 10);

b2Body *ball = m_world->CreateBody(&ballBodyDef);
b2Fixture *ballFixture = ball->CreateFixture(&ballFixtureDef);
ball->ApplyForceToCenter(b2Vec2(-1000, -400), true);

As you'll see the ball at the end is meant to stop and in fact, if you choose the ground to be dynamic body instead of static, the ball will stop, but when it's dynamic and the ball is supposed to stop it will pick up speed. Doesn't seem related to the recent changes with density zero improvement. I was able to repro it even in previous commits to that.

I couldn't reproduce it in C# so I copied it into the testbed (and changed the Position iterations to 8) and I still can't reproduce it:

Sure the ball bounces off a little at the end and rolls away very slowly, but I don't see it picking up speed.

That's reproducing right there, but you are cutting the video right when it's about to pick up speed, the pick up in speed is very minimal, right when you cut it the ball will keep on rolling at that very slow speed until it reaches the other side, and it'll be about 0.0001 mps faster at the end. The body never actually sleeps.

Does it continue to pick up speed, or does it just pick up speed at that moment and then maintain a constant velocity? I ask because I can't see any increase in speed over time.
I see the same with 3 Position Iterations as I do with 8.
This might be explained by the fact that you have a circle with some inertia against a surface with some friction. You can, for example, drop a high friction polygon onto a circle placed on a low friction surface, such that the circle will spin against the low friction surface and spin contrary to its direction of travel. If there's not enough rotational force, the friction will take over and while the circle will stop rotating for a moment, it will immediately start rotating in the direction of travel.

Looks to me like it just bounces off that left hand edge. You can see the long spike when it makes contact - that's the Contact Impulse.

yes, it does bounce off but it is just after that bounce of that the object never stops, and if after that bounce you log the velocity until the object reaches the other side, you'll notice the velocity gain

So it bounces and you want it not to bounce? Bear in mind your "wall" is also at an angle, and the ball is not touching the "floor" when it hits the "wall", so you have gravity contributing too.

No, I don't want it not to bounce, the bouncing is fine, what I think it should do like any other rigid body is to eventually slow it's velocity due to the friction but that's not happening correctly. as the speed is increasing (very slightly but still increasing). Isn't this a non-physical effect?

Well you have no friction on any of your objects, and in any case I don't think that would help here since friction applies to two surfaces moving against each other (see my GIF with the circle changing direction). What you really want is Rolling Resistance, but that's not a feature of Box2D (as it stands). Try setting an Angular Damping value on the body, that should give you the effect you're looking for.

There is friction, they are the default 0.2f friction which should be enough to stop the ball from rolling. Changing angular damping will probably stop this but it's not realistic to change that property.

OK, you're right about the default Friction
	b2FixtureDef() 	{ 		shape = nullptr; 		userData = nullptr; 		friction = 0.2f; 		restitution = 0.0f; 		density = 0.0f; 		isSensor = false; 	}
However, Friction won't slow down a circle rotating in the "right" direction because there is no friction between two solid surfaces. This is like rolling a glass bead on a marble floor - except that we're also not measuring losses from air resistance or energy turned into sound, so the loss as far as Box2D is concerned is zero. The friction you get with a car wheel on tarmac, for example, is in the flexing of the tyre. The friction between the rubber and the road is still small - you can pick tyre rubber with your finger nails, but we still get tens of thousands of miles out of that rubber even in contact with rough road surfaces.

I understand that, why is the behavior different when you switch the ground body type to be dynamic instead of static? in that case, the ball actually stops rolling.
Also, your point makes sense but it still doesn't explain why the ball's velocity would increase, if there was no energy loss at all from friction or air resistance or any other external factors, at best the velocity would remain the same but not increase.

I thought we'd established that the increase in speed was from the ball bouncing off the wall, and/or that it only increases at that point? My theory about the ball having some 'backwards' rotation I think still holds water there.
I don't know why you get different behaviour with a dynamic body, since b2CollidePolygonAndCircle doesn't check body types. However, I would expect that the bodies are interacting differently and therefore having a different effect on each other: static body position & velocity constraints are skipped, because that's what static means. A dynamic body will have those calculated, which means there are body forces at play. Even if your "ground shape" is still (not static), it will continue to push away from the ball as the ball collides with it.
The tiny, tiny values don't mean a lot, and Box2D is neither guaranteed nor even intended to produce perfect results. Different IEEE FP implementations will give results different enough that Box2D can't be guaranteed to give the same answers between two architectures. Even in C# compiling a debug build and running with the debugger produce two different outcomes, which are each different to the optimised code. Erin put a link to an article called, I think, "How to break the IEEE Floating Point standard" which basically takes a lot longer to say the above.

Actually upon further inspection, the speed is actually slowing down just very slowly.
And yes, there is some negative angular velocity still in the object.
Another thing I noticed is that the angular velocity happens to be almost the exact same (except in the opposite direction) and maybe that's causing this artifact, but friction should take care of it as a coefficient of 0.2 friction should be enough to break the movement at this speed, am I wrong? (Please watch the whole video attached)
test.mov.zip

Negative angular velocity is clockwise. I was more interested in the angular velocity just before it hits the wall.

When ground body is dynamic:

		b2Vec2 gravity;
		gravity.Set(0.0f, -10.0f);
		m_world->SetGravity(gravity);
		b2ChainShape chainShape;
		b2Vec2 vertices[] = { b2Vec2(-5,0), b2Vec2(5,0), b2Vec2(5,5), b2Vec2(4,1), b2Vec2(-4,1), b2Vec2(-5,5) };
		chainShape.CreateLoop(vertices, 6);

		b2FixtureDef groundFixtureDef;
		groundFixtureDef.density = 0;
		groundFixtureDef.shape = &chainShape;

		b2BodyDef groundBodyDef;
		groundBodyDef.type = b2_dynamicBody;  // difference

		b2Body* groundBody = m_world->CreateBody(&groundBodyDef);
		b2Fixture* groundBodyFixture = groundBody->CreateFixture(&groundFixtureDef);

		b2CircleShape ballShape;
		ballShape.m_radius = 1;

		b2FixtureDef ballFixtureDef;
		ballFixtureDef.restitution = 0.75f;
		ballFixtureDef.density = 1;
		ballFixtureDef.shape = &ballShape;

		b2BodyDef ballBodyDef;
		ballBodyDef.type = b2BodyType::b2_dynamicBody;
		ballBodyDef.position = b2Vec2(0, 10);

		b2Body* ball = m_world->CreateBody(&ballBodyDef);
		b2Fixture* ballFixture = ball->CreateFixture(&ballFixtureDef);

		ball->ApplyForceToCenter(b2Vec2(-1000, -400), true);

Please look at #617
The ball is rolling without sliding and keeping constant kinetic energy to a high precision. Surface friction in Box2D does not provide rolling resistance. This could be added as an enhancement.
Please re-open if I missed anything.


Question about tags

Is there any way to have octocatalog-diff do the opposite of --ignore-tags?  I'd like to be able to specify one or more tags and have octocatalog-diff only compare resources containing those tags?  This would help predict the behavior of running puppet with those tags.

@hbarina That seems like a reasonable feature. I'd be happy to accept a PR for it!

I do have a working patch, just need to update the spec tests and
documentation.
On Wed, Oct 30, 2019 at 6:50 PM Andrew Hayworth<EMAIL_ADDRESS>wrote:

@hbarina https://github.com/hbarina That seems like a reasonable
feature. I'd be happy to accept a PR for it!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/github/octocatalog-diff/issues/209?email_source=notifications&email_token=ADNBUMUUB6NKHFCVLBZHY6LQRIFRXA5CNFSM4G7MGSYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWASVI#issuecomment-548145493,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADNBUMSG4UGIFIGSXHBGLHTQRIFRXANCNFSM4G7MGSYA
.

Sounds great, I look forward to it!


PR Helper fails when attempting to assign reviewer who is not a collaborator on Repo

Bug Report
Current Behavior
The PR Helper is configured to add reviewers based on specific YAML front-matter. This can also include a configuration lookup file. The issue is that the person being added needs to be a collaborator on the repository. In the event that you remove that persons access you will receive an error and the PR Helper will fail to complete, thus blocking the PR from being merged and requiring manual intervention.
In the event that the addition of the reviewer fails for that reason then it should just be logged and not block the rest of the processing.
To Reproduce
Steps to reproduce the behavior:

Grant someone access to the repo
Set them as a MD file owner in appropriate YAML front-matter
Configure PR Helper as appropriate
Create a PR
See error

Expected behavior/code
In the event that the addition of the reviewer fails for that reason then it should just be logged and not block the rest of the processing.
Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

Text based error
Error: Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the ABC/XYZ repository.

Releasing in v1.3.1


Fix: ENI's prevent SecGrps from being destroyed on tf destroy

Description
Please explain the changes you made here and link to any relevant issues.

sorry it's error from me.


Unnecessary /* fake(empty) types */ for nested imports; here: missing tRPC types

The @trpc/client package imports successfully, but the loaded types lack some information that is loaded from a subfolder of @trpc/server. These types missing lead to lack of type inference, killing the main benefit from the whole package, see the code below. This bug might affect other libraries relying on similar imports for their exported types.
You can use the below code to reproduce this, following the type definition of trpc.getCount.query in the client file, where the count variable incorrectly gets inferred as any.
@trpc/client is importing types from @trpc/server as well as @trpc/server/shared here.
While the former get resolved correctly to 'https://esm.sh/v102/<EMAIL_ADDRESS>the latter resolves to https://esm.sh/v102/<EMAIL_ADDRESS>with shared and dist in the incorrect order. As they are not found, the modules are replaced as /* fake(empty) types */.
Reproduction steps
// server.ts
import { initTRPC } from "https://esm.sh/<EMAIL_ADDRESS>import { z } from<EMAIL_ADDRESS>
const t = initTRPC.create();

let count = 0;

const appRouter = t.router({
  getCount: t.procedure.input(() => {}).query(() => {
    return { count };
  }),
  increment: t.procedure.input(z.object({ amount: z.number().optional() }))
    .mutation((req) => {
      count += req.input.amount ?? 1;
    }),
});

export type AppRouter = typeof appRouter;

// client.ts
import {
  createTRPCProxyClient,
  httpBatchLink,
} from "https://esm.sh/<EMAIL_ADDRESS>import type { AppRouter } from "./server.ts";

export const trpc = createTRPCProxyClient<AppRouter>({
  links: [httpBatchLink({ url: "/api/trpc" })],
});

const res = await trpc.getCount.query();
export const count = res.count; // ⛔ this has type any, but should have type number

v104 removes the fake types, just returns 404 instead. Can you pls try again? thanks

Thanks for the update. Like you said, the types are still missing because imports from directories inside modules are resolved incorrectly.

@trpc/client imports types from @trpc/server/shared
The import is resolved to'https://esm.sh/v104/<EMAIL_ADDRESS>but should be'https://esm.sh/v104/<EMAIL_ADDRESS>The nested folder should be appended after, not before the /dist
missing types kill the benefits of the whole package
This bug might break packages, that import code from other packages this way

the wrong dts path may have been cached, i will release v105 soon

Just checking in again. With v120 & the latest tRPC version, the types inferred correctly. Thank you!


Tune the job queue GC to be a bit more aggressive

We might need to do this? Since #265, there are more jobs going through. And it is only set to GC jobs after they've been around (& completed) for 1 hour. They are left around for a little bit for debugging (which I'm questioning the practicality of).
We should consider tightening this up, or adding a criteria of "run a GC if there are > X finished jobs".

Note: this isn't currently causing any issues, just a tidiness thing.

They are left around for a little bit for debugging

Also so that people can abandon long-running jobs and come back to see what happened later -- for this reason, if anything one hour is a little short!

No longer relevant.


Move Buildr support to separate gem

This will enable a explicit dep to Buildr and allow for Buildr specific tests

created separate gem at https://github.com/mguymon/lock_jar-buildr


[bug] re-run tauri dev get permission denied

Describe the bug
When run npm run tauri dev at second time, got error,
><EMAIL_ADDRESS>tauri /Users/kaichaosun/github/holo/launcher
> tauri "dev"

 app:spawn Running "/Users/kaichaosun/github/holo/launcher/node_modules/@tauri-apps/cli/bin/tauri-cli tauri dev" +0ms

Error: `Permission denied (os error 13)`

Caused by:
    Permission denied (os error 13)

 app:spawn Command "/Users/kaichaosun/github/holo/launcher/node_modules/@tauri-apps/cli/bin/tauri-cli" failed with exit code: 1 +0ms

The command works again if I remove target folder in src-tauri. It seems rebuild didn't work.
On mac m1 pro, with rust version,
rustc 1.56.1 (59eed8a2a 2021-11-01)
binary: rustc
commit-hash: 59eed8a2aac0230a8b53e89d4e99d55912ba6b35
commit-date: 2021-11-01
host: aarch64-apple-darwin
release: 1.56.1
LLVM version: 13.0.0

Reproduction

Go to https://github.com/holochain/launcher/blob/main/dev-setup.md
npm run dev for 2 times, not sure if depends on machine.

Expected behavior
No response
Platform and versions
><EMAIL_ADDRESS>tauri /Users/kaichaosun/github/holo/launcher
> tauri "info"

 app:spawn Running "/Users/kaichaosun/github/holo/launcher/node_modules/@tauri-apps/cli/bin/tauri-cli tauri info" +0ms

Operating System - Mac OS, version 12.0.1 X64

Node.js environment
  Node.js - 14.16.1
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 6.14.12
  yarn - 1.22.17

Rust environment
  rustc - 1.56.1
  cargo - 1.56.0

App directory structure
/node_modules
/tests
/.cargo
/public
/scripts
/.github
/src-tauri
/.git
/src

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - target/webpack_dist
  devPath - target/webpack_dist
  framework - Vue.js (Vue CLI)
  bundler - Webpack

Stack trace
No response
Additional context
No response

you have your webpack output inside the target, can you change that to be outside of it and try again ?

Can you try making a minimal repro ? the repo you linked is huge which will make it harder to spot the bug.

It's resolved in latest release, thanks!


Make Message object safe

Not clear what the best way to do this is, but being able to use Message as an object is indespinsable.

Current near-term plan is to transition Message away from taking Buf/BufMut generic types, and towards Bytes/BytesMut.  This is less flexible in terms of inputs, but it will allow the trait to be object safe.

Message has been made object-safe as of a7265930ddebb2b983674838d94ad5a51c2382cc.  The core encoding and decoding methods have Self: Sized bounds, so they can't be used from trait objects, but there is a clean workaround: applications can define their own Message-like trait which is specialized to a specific buffer type (example).  Credit goes to @SpaceManiac for pointing out this workaround.


Doesn't show messages if channel name has uppercase characters

Describe the bug:
If the channel name has uppercase letters in it, no messages are loaded.
To Reproduce:

Either provide a channel with uppercase letters in it in the config or with -c
Run twt
See bug

Screenshots:

Left side is twt -c xqc, right side is twt -c xQc
System:

Twitch-tui version: tested on 1.6.0, 2.0.0-alpha.11

Operating System: Arch Linux w/ kernel 5.19.11-xanmod1-1-x64v2

Terminal: alacritty 0.10.1

Shell: zsh 5.9

Additional context:
I pipe this script to see which channels that I follow are online into dmenu to open twt and streamlink. The channel name given by that script is the name that shows up on twitch, so it might have uppercase letters. It's not a big deal, I just convert the uppercase letters to lowercase in my dmenu script, but I was wondering what causes this issue, because in the logs it says that it connected to the irc channel and it even shows the info (like follower mode, slow mode etc.)

Very interesting, I'll see what's causing this problem.

According to this Twitch developers forum post, when joining an IRC channel, the characters have to be lowercase.
I'll make a hotfix, and it'll be put out in the next release (very soon).

According to this Twitch developers post, when joining an IRC channel, the characters in a channel name have to be lowercase.

I thought it might be something along those lines.
Thanks for the quick reply!

No problem.
In terms of frontend, do you think that the channel title at the top of the window should reflect Twitch's IRC channel rule, or should it reflect what the user inputs?

I've gone with the option of lowercase channels in the title. This was implemented in ab6f2af0c78def0b7c95f450325f5dd118020f24.
This hotfix is included with the state tabs feature in release v2.0.0-alpha.12.
Thank you for catching this issue, have a good one!


Allow for  --dependencies flag under the function update command

kubeless version: 0.3.0
Hello,
first, thank you for this awesome project.
Kubernetes is quite the uncharted territory for me, and I'm happy to see the barrier lower down thanks to this project.

summary
I've attempted to deploy update a function with a dependency that I've installed.
but I got the following response in the shell
edit: At the moment, the --dependencies flag is not supported under the function update command
✦ ➜ kubeless function update hello-world --runtime nodejs8 --from-file hello.js --handler hello.foo --trigger-http --namespace kubeless --dependencies package.json
Error: unknown flag: --dependencies
Usage:
  kubeless function update <function_name> FLAG [flags]

Thanks in advance

Hi @adnasa,
If that is the first time you deploy a function you should use kubeless function deploy so your command should be something like:
kubeless function deploy hello-world --runtime nodejs8 --from-file hello.js --handler hello.foo --trigger-http --namespace kubeless --dependencies package.json

Anyway, it is true that there isn't a good reason for not allowing to specify the --dependencies when updating a function.

ah I see. this only works under the deploy command?
but yes, I agree. I don't think it makes sense to discard or warn about the flag under the update command.
That sounds like a lacking feature?
One problem with this "limit" is that even when dependencies were specified during the deploy, the package.json would update over time.

Yes, it sounds like a legitimate usage.

all right. I'll rename the title and update the description accordingly

done

👍 thanks @adnasa

Fixed @adnasa the flag will be available in the next release


After using smart wait for the first time the tests start lagging

When we execute a step which support smart wait, it:

Sets implicit timeout in WebDriver to smart wait duration.
Performs whatever it needs to perform.
Resets implicit timeout.

Example from WebDriverIO.js:
async _locate(locator, smartWait = false) {
    if (!this.options.smartWait || !smartWait) return this.browser.elements(withStrictLocator.call(this, locator));
    this.debugSection(`SmartWait (${this.options.smartWait}ms)`, `Locating ${locator} in ${this.options.smartWait}`);

    await this.defineTimeout({ implicit: this.options.smartWait });
    const els = await this.browser.elements(withStrictLocator.call(this, locator));
    await this.defineTimeout({ implicit: 0 });
    return els;
  }

The line await this.defineTimeout({ implicit: 0 }); should reset the timeout. Only it does not. In fact, there are 2 problems with it:

The function defineTimeout(timeouts) does nothing if timeouts.implicit is falsy:

  async defineTimeout(timeouts) {
    if (timeouts.implicit) {
      await this.browser.timeouts('implicit', timeouts.implicit);
    }
    ...

Why are we trying to set implicit timeout to 0 anyway? Shouldn't we use the default value specified in the config instead?

Because of (1) the implicit timeout stays equal to this.options.smartWait. After that every attempt to check a non-existing element lags until smartWait timeout runs out.
Details

CodeceptJS version: 1.1.7
NodeJS Version: 8.9.3
Operating System: Win10
WebDriverIO: 4.12.0

By the way this issue also affects selectOption method performance in case of selecting option by value. This caused because of this method first of all locates the select field with enabled smartWait option. Then this method locates options by visible text. And only after all it locates options by value. So after locating the field implicit timeout would be equal to smartWait timeout. And in the case of selecting options by value each call of this.browser.elementIdElements for option check by visible text takes time equal to smartWait timeout (as it not present).


Typo

Under OpenType 1.7: "htmx.htm" should be "hmtx.htm"

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

ID: 58ee5664-1103-604f-752f-428d42acef99
Version Independent ID: 8583ef1a-b9f7-ee4d-5fb1-13544b65b63a
Content: OpenType specification change log - Typography
Content Source: typographydocs/opentype/spec/changes.md
Product: windows
GitHub Login: @PeterCon
Microsoft Alias: PeterCon

Closing as Fixed


Message history or retention period

Is it currently possible to set the history period the messages are kept? I imagine this needs to be somewhere otherwise eventually the server will get slow with thousands of messages. Most chat services have a purging feature which can be configured.

There is currently no way to automatically purge old messages -- many users value the ability to see their message history from years ago, and so that's the default.
There are no material performance issues with storing 50M messages in a single database server's history (though eventually you start to need more disk).
That said, if this feature were desired either to save disk (or just to be able to have one's data eventually go away!), it should be trivial to write, though one we'd want to be very careful about testing since buggy deletion code is a great way to delete all the messages :).

ok, understood

@blablacio is working on this feature!

Here's some notes on how we should implement this feature:

We'll add a retention policy feature for the realm specifying how long messages are kept before being automatically deleted.  Implementation-wise, I'd like to use a model where after the N days the messages are deleted from Message, but added to a new table e.g. ArchivedMessage, and kept there for a week before being deleted finally, so that we have time to catch bugs for data is lost permanently.
I think it will work to create models like 'class ArchivedMessage(Message)' that inherits from Message and a similar table inheriting from UserMessage, and just add to the new table whatever field(s) we need to keep track of when they'll be deleted.  We might need to some set Django meta fields on the classes to ensure that ArchivedMessage rows are only present in the new tables.  That approach should minimize the maintenance involved when we modify the Message tables.
Since bugs in this system would result in data loss, we should make sure to have a really good test suite for this feature.
The command-line tool should be a Django management command that calls library functions inside a new file zerver/lib/retention.py, similar to how zerver/management/commands/fill_memcached_caches.py works.
Eventually we'll add a cron job in puppet/zulip/files/cron to run the management command.
Once we do the Message stuff correctly, we'll need to do corresponding changes in Attachment and MessageReaction to handle this properly.

I'd like to merge incremental pieces of this implementation as we go rather than building the whole thing before we merge anything.   e.g., first add tooling to just determine which messages should be archived with good tests, then add a function to move a set of messages from Message to ArchivedMessage rows with tests, then a function to do the same with ArchivedUserMessage, etc.  Ideally we'd be merging code for this feature every day or two, with good tests, rather than building up a big monolithic implementation.

@timabbott I've done first stage(added tool for getting expired messages). Please review PR https://github.com/zulip/zulip/pull/2119. I need your feedback to continue work on it.

It would be better to use hashes as message identifier do not depend on db ids. It useful when messages are archiving.

Can you explain more what you mean?  Hashes of what?

sorry I mean uid, https://docs.djangoproject.com/en/1.8/ref/models/fields/#uuidfield which is not connected with ids. Ids values can be broken by vacuum or rewriting free ids values but we need to have independent identidier for each message to restore data or put them to archive

I understand the issue, but I'm not sure that using UUIDs is the best solution.
Having thought about this more, I think we probably need to have some mechanism to present IDs from archived objects from being reused.  Because Zulip orders messages by ID in all the UI/display logic, and we don't intend to change that, if a message were to have its ID change through an archive+unarchive process, it would no longer be possible to restore the message the right place in the historical message sort order.  So, we can't allow reuse of IDs for things that have been moved to ArchivedMessage but not yet deleted.
At the moment, nothing is required to do that, since we don't have any features other than the rarely used import tool that would cause Zulip to add new messages with an ID that doesn't construct message IDs via autoincrementing; and we could always just have things that might reuse free message IDs like the import tool (./manage.py export --help for details about that system) check IDs it wants to use against e.g. the ArchivedMessage table before trying to use them.  I doubt we'll ever have features that reuse old message IDs other than the old import tool.
Assuming I'm missing something here, though, why not just use an autoincrement style ID column on the ArchivedFoo tables, that happens to be a different field from e.g. the message IDs, rather than a uuidfield?

Because GitHub makes this a little hard to see automatically: PR #2172 is meant to address this.

Any news on this? I only have 16 GB and i also host files

I think it would be really useful to have retention configurable on the stream level or even the topic level if possible. As mentioned before, some users like being able to search messages from years ago, so it makes sense to be able to keep those forever (e.g. Private messages). But I could also see the case where something like an automated build system is posting messages to a particular stream or topic which is noisy over time and it doesn't make sense to retain thousands of those messages for years and years.
Implementing retention on a topic level is probably too granular (but would be great of possible), but I think the following would work well:

Stream-based retention policy - allows you to configure how long to keep messages in each stream (with the default being infinity)
Admin ability to "empty" a topic - this would be useful where there is a stream that has topics which are actual discussion (which should be retained) and other topics which are automated notifications (which should not be retained).

The plan is definitely for this to support stream-level configuration.

The feature is more or less complete; it's just waiting on some careful testing in a production environment.

Any update on this?

Bump again.
Is there any progress on this? This is one of the big features that we need in the official Julia language Zulip.

If you would like someone to deploy this in a production environment to test it out, we would be happy to test it out in the Julia language Zulip.
We can deploy the feature on two or three streams and see how it goes.
The Julia language Zulip is hosted by Zulip, so I think we'll need help from the Zulip team in order to deploy this feature.

@timabbott
If you would like someone to deploy this in a production environment to test it out, we would be happy to test it out in the Julia language Zulip.
We can deploy the feature on two or three streams and see how it goes.
The Julia language Zulip is hosted by Zulip, so I think we'll need help from the Zulip team in order to deploy this feature.

From the Zulip Zulip:

it remains basically done; just waiting on some final performance and UI testing. I expect we'll do that work as part of finishing the 2.2 release.

OK, the production-side testing for this is complete, and it's working well.  We can enable this feature for specific organizations or streams on request to<EMAIL_ADDRESS>the UI and Help Center documentation should come in the next few days.

The UI for controlling this is being tracked in https://github.com/zulip/zulip/issues/14854.
I'm going to close this issue with the documentation commit that covers it.


Sample not working on Remote Desktop

When I ran the sample (using winsdk build) using a remote desktop connection (client Win8.1, server Win8.1), the cube is not shown. Also the magnifier is lagging from the cursor very much.

We had to do a lot of changes to how we render to D3DImage when running remote desktop / WARP.
Also animations should be reduced to avoid locking up the window (we remove fading and reduce framerate to 30fps - according to the RDP team, somehow frozen windows caused by heavy animation is by design).
I doubt most of the RDP work has been done here yet.

Thanks for the information.
The problem I reported above is when I connected the RDP client at my home to the server at my office separated by approx. 15ms internet latency. Today I brought the same RDP client PC to the office and tried again. Now the cube is showing normally.
Once the cube is showing, then I  minimized the RDP window, then restored it again. Now the cube disappeared again ! And nothing can bring it back, except by relaunching the application. This is reproducible 100% (also tried with another Win7 RDP client).
Do these issues lie on D3DImage layer or do they just due to some bugs inside the new D3D11Image implementation ?

D3DImage works in RDP, so it must be the implementation used here.

I have the same problem. It appears to be working intermittently over RPP, and I can't see that any of the DirectX calls are failing, it just doesn't draw anything.
There hasn't been any checkins for a couple of years, is this project still alive? Is there another way to integrate DX11 with WPF?

Is there another way to integrate DX11 with WPF?

See my comment here:  https://github.com/Microsoft/WPFDXInterop/issues/21
"I finally wrote my own interop class, taking example from http://jmorrill.hjtcentral.com/Home/tabid/428/EntryId/437/Direct3D-10-11-Direct2D-in-WPF.aspx and http://marcangers.com/category/direct3d/ to meet my performance requirements. Still, it is slow when used from remote desktop due to the fallback to software rendering. "

@tseval Try Helixtoolkit SharpDX if it is what you are looking for.


HTTP allocation failed

This is more sort of a question.
For some models I see the following error getting triggered: HTTP allocation failed for type... by
https://github.com/NVIDIA/tensorrt-inference-server/blob/e053b65fcda8981dbe1d01a743ebd78143dbff5f/src/servers/http_server.cc#L365
Reading through the documentation left me clueless about how I could resolve this error and how big of an error it is.
The error occurs for TRT models only so far. Do I need to change my model or the (python) client?

Can you share the console log where you are seeing this error, and also the version of TRTIS you are using. Those messages are just verbose log messages, not errors. We can change the message to sound less like an error.

As @deadeyegoodwin mentioned, this is a verbose log instead of an error.
To elaborate more on what is going on, this conditional will be hit when a backend supports GPU outputs (i.e. Libtorch, TensorRT). In that case, the backend will "prefer" to store the outputs as close to the model instance as possible (i.e. same GPU device). But since HTTP / GRPC needs to transfer the data via network, the output will need to be stored in system memory.
The backend's "preference" is taken into the consideration for reducing overhead in ensemble. For instance, if all models are deployed in GPU 0, then the data transfer between host and device may be minimized.

Fixed by #845.

Thank you all for the clarification.


Listening to Leave & Join events

Hey, is it possible to listen to leave and join events by using the webhook?

Thanks for the suggestion, @pm-12
implemented here: #182 and will be released in v1.20


Is it possible to print the given query ?

Hello,
Just to be sure my queries are correctly made, I would like to print the given SQL instead of analysing the query AST. Is it possible ?
Thanks !

Ktorm prints SQLs at DEBUG log level, you need to configure your logging framework to enable it.
See https://ktorm.liuwj.me/en/connect-to-databases.html#Logging

@vincentlauvlwj oops, I missed that, thanks !


Fix unique key prop

This is a minor fix only, but I always feel kind of annoyed by spammed console outputs. Maybe other people feel the same.
It removes the "Warning: Each child in a list should have a unique "key" prop." from the console.log.
I also tried to fix the "Warning: Prop className did not match. Server: " but was not successful.

@lujakob maybe the key should be "method" instead of i, but this is fine. Thanks, I will merge it :-)

I realized this was already fixed. My local repo must have been on a really old commit. I will close this.


0.13 error (in desc) but v 0.12 works

Bevy version
The release number or commit hash of the version you're using.
0.12.1 - This version works.
0.13.0 - Does not work. Terminal shown below.
[Optional] Relevant system information
If you cannot get Bevy to build or run on your machine, please include:

the Rust version you're using (you can get this by running cargo --version)
1.77.2 on Windows 11

What you did
I tried to run the main fn for the shapes example in 0.13.
It runs fine for version 0.12.1
I have the latest drivers.
What went wrong
C:/Users/user/.cargo/bin/cargo.exe run --color=always --package jasons_caravan --bin jasons_caravan     Finished dev [unoptimized + debuginfo] target(s) in 1.05s      Running target\debug\jasons_caravan.exe2024-04-22T16:46:17.914135Z  INFO bevy_winit::system: Creating new window "App" (0v1) 2024-04-22T16:46:19.304258Z ERROR wgpu_hal::vulkan::instance: enumerate_adapters: A return array was too small for the result     thread 'main' panicked at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_render-0.13.2\src\renderer\mod.rs:141:10: Unable to find a GPU! Make sure you have installed required drivers! stack backtrace:    0: std::panicking::begin_panic_handler              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library\std\src\panicking.rs:647    1: core::panicking::panic_fmt              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library\core\src\panicking.rs:72    2: core::panicking::panic_display              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library\core\src\panicking.rs:196    3: core::panicking::panic_str              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library\core\src\panicking.rs:171    4: core::option::expect_failed              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library\core\src\option.rs:1988    5: enum2$<core::option::Option<wgpu::Adapter> >::expect<wgpu::Adapter>              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\core\src\option.rs:894    6: bevy_render::renderer::initialize_renderer::async_fn$0              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_render-0.13.2\src\renderer\mod.rs:138    7: bevy_render::impl$3::build::async_block$0              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_render-0.13.2\src\lib.rs:292           8: futures_lite::future::block_on::closure$0<tuple$<>,enum2$<bevy_render::impl$3::build::async_block_env$0> >              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\futures-lite-2.3.0\src\future.rs:99         9: std::thread::local::LocalKey<core::cell::RefCell<tuple$<parking::Parker,core::task::wake::Waker> > >::try_with<core::c ell::RefCell<tuple$<parking::Parker,core::task::wake::Waker> >,futures_lite::future::block_on::closure_env$0<tuple$<>,enum2$<bevy_render:              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\std\src\thread\local.rs:286   10: std::thread::local::LocalKey<core::cell::RefCell<tuple$<parking::Parker,core::task::wake::Waker> > >::with<core::cell: :RefCell<tuple$<parking::Parker,core::task::wake::Waker> >,futures_lite::future::block_on::closure_env$0<tuple$<>,enum2$<bevy_render::imp              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\std\src\thread\local.rs:262   11: futures_lite::future::block_on<tuple$<>,enum2$<bevy_render::impl$3::build::async_block_env$0> >              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\futures-lite-2.3.0\src\future.rs:78        12: bevy_render::impl$3::build              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_render-0.13.2\src\lib.rs:312          13: bevy_app::app::impl$5::add_boxed_plugin::closure$0              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_app-0.13.2\src\app.rs:657   14: core::ops::function::FnOnce::call_once<bevy_app::app::impl$5::add_boxed_plugin::closure_env$0,tuple$<> >              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\core\src\ops\function.rs:250   15: core::panic::unwind_safe::impl$23::call_once<tuple$<>,bevy_app::app::impl$5::add_boxed_plugin::closure_env$0>              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\core\src\panic\unwind_safe.rs:272   16: std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<bevy_app::app::impl$5::add_boxed_plugin::closure_env$0>,tuple$<> >              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\std\src\panicking.rs:554   17: hashbrown::map::make_hash<alloc::string::String,core::hash::BuildHasherDefault<ahash::fallback_hash::AHasher> >   18: std::panicking::try<tuple$<>,core::panic::unwind_safe::AssertUnwindSafe<bevy_app::app::impl$5::add_boxed_plugin::closure_env$0> >              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\std\src\panicking.rs:518   19: std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<bevy_app::app::impl$5::add_boxed_plugin::closure_env$0>,tuple$<> >              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\std\src\panic.rs:142   20: bevy_app::app::App::add_boxed_plugin              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_app-0.13.2\src\app.rs:657   21: bevy_app::plugin_group::PluginGroupBuilder::finish              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_app-0.13.2\src\plugin_group.rs:182    22: bevy_app::plugin::sealed::impl$1::add_to_app<bevy_internal::default_plugins::DefaultPlugins>              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_app-0.13.2\src\plugin.rs:147          23: bevy_app::app::App::add_plugins<bevy_app::plugin::sealed::PluginGroupMarker,bevy_internal::default_plugins::DefaultPlugins>              at C:\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_app-0.13.2\src\app.rs:756   24: jasons_caravan::main              at .\src\main.rs:9   25: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\core\src\ops\function.rs:250   26: core::hint::black_box              at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04\library\core\src\hint.rs:334 note: Some details are omitted, run withRUST_BACKTRACE=fullfor a verbose backtrace. error: process didn't exit successfully:target\debug\jasons_caravan.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
Process finished with exit code -1073741819 (0xC0000005)
`

Could you surround the stack trace with triple backtics ``` instead of single backtics `?

Updated 👍

This looks like your GPU cannot be found, either because the supported hardware level is not available, or because your drivers are not up to date. Could you provide some more information there?

I would assume it's not a hardware or driver issue because Bevvy works just fine on version 0.12.

What GPU do you have in your computer? If you don't have a discrete GPU what CPU do you use?

there is a bug with wgpu 0.19,  Validation limits are too high
my old computer works fine with wgpu 0.18, but can't work with wgpu on 0.19 Failed to find an appropriate adapter.
bevy 0.12 use wgpu 0.18
bevy 0.13 use wgpu 0.19

Sounds very similar to the issue we had at #11992. No idea why the author of that issue closed it, one somewhat questionable temporary workaround to this was found, but the problem was never actually resolved. @JasonPaulGithub does the workaround of switching wgpu's backend from vulkan (default) to GL as mentioned in #11992 help you?


Hard-coded gas price may not be enough for some blockchains

Some blockchains have market gas prices usually above 100 gwei, e.g. Polygon: https://polygonscan.com/gastracker
Since this CREATE2 factory contract has a gas price of 100 gwei hard coded in the raw transaction, does this mean that it would not be deployable on a blockchain as long as its market gas prices stay above 100 gwei? Or are there some ways around to still deploy it?

This is correct.  You will need to wait until the baseFee drops below 100 (for chains with dynamic gas prices), or you will need a friendly block builder to accept out-of-band payment for inclusion if there is no on-chain marketplace.  Alternatively, just wait until the gas price drops below 100 if that is something that happens periodically.
Another option is to get the contract included in a hard fork.  Some blockchains have done this for this contract because they don't support legacy transactions at all.

Some blockchains have done this for this contract because they don't support legacy transactions at all.

Do you have specific blockchains that did include it with a fork?

I believe Optimism did this.  I have hard there are others but I don't know which.


iOS 8 support

Thanks for this fantastic editor!  I have been playing with it and found that on iOS 8 beta 5, the keyboard behavior(show / hide) and the toolbar behavior (sliding) are buggy.  The keyboard hides but never comes back up, and the toolbar does not slide at all.

Yes. I am still facing the keyboard issue in iOS8, when pushing the viewController on iphone6 simulator.


Adding FastText Text Classification

Description
Adding FastText classification to gluonnlp
TODO :

Ran only on ag_news and sogou_news, need to run and verify numbers on all datasets.
clean up the code and change print stmts to logging
remove dependency on sklearn and change everything to mxnet.

Checklist
Essentials

[N ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage
[ ] Code is well-documented

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

Job PR-258/3 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-258/3/index.html

@sravanbabuiitm thanks for the contribution. I made some minor edits to the description to utilize the PR task list feature on github. Once you're ready, you can go ahead and check off the items by clicking them.

Next steps once you have verified all the results:

[ ] add a readme in https://raw.githubusercontent.com/dmlc/gluon-nlp/master/scripts/index.rst.
[ ] add commands to reproduce the experiments.
[ ] add experiment log to https://github.com/dmlc/web-data, and link to the log in the script's readme (see nmt or language model scripts for example http://gluon-nlp.mxnet.io/scripts/index.html)

Job PR-258/5 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-258/5/index.html

Job PR-258/9 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-258/9/index.html

Job PR-258/10 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-258/10/index.html

Thank you Sheng :)
Thanks for all the help and suggestions all along!


Mac OS X tests on Travis CI

If we can, we should try and get Mac OSX builds running on Travis CI. This has been done for MDAnalysis and since we don't need conda to build out a decent environment for the dependency-light datreant.core, we could probably lift a lot less from there to get this working.

You can use the ci-helpers from astropy as well. We started now to use it for MDAnalysis

https://github.com/astropy/ci-helpers

since we use only python function this doesn't add much value. Given that OSX testing on Travis also draws a lot of resources for them that they have trouble keeping up with I say linux is enough.


feat(build): Move ucc-ui-lib to a new repo

Because UI lib will be built in a repo outside of ucc-gen. All of the steps required to prep js can be removed.

:tada: This PR is included in version 5.0.0-develop.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 5.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Adding EMCF solver

Unwrapping in time first and then in space
Support for computing residues and flood filling using gradients
Support for including models when computing residues
Example usage can be found in tests/workflows/test_emcf.py

I will leave this branch till @gmgunter gets a chance to take a better look. No rush. The feature branch should be fully functional.

I think the comments here have come in a little too late to address them satisfactorily and not impact the two other PRs that are queued up. I can included them in the last of the PRs that are stringed together. Does that work?

Does that work?

Yeah, that's totally fine with me. I'll continue adding comments as I read through the changes, but they can be addressed in subsequent PRs. I'll approve each of the backlog PRs once I'm finished reviewing it, even if there are remaining comments, until I'm caught back up with you.


IndexError: index out of range in Binary Ninja API code

[Default] Traceback (most recent call last):
[Default]   File "/Applications/Binary Ninja.app/Contents/MacOS/plugins/../../Resources/python/binaryninja/plugin.py", line 361, in _high_level_il_instruction_is_valid
[Default]     return is_valid(view_obj, func_obj[instr])
[Default]   File "/Applications/Binary Ninja.app/Contents/MacOS/plugins/../../Resources/python/binaryninja/highlevelil.py", line 2477, in __getitem__
[Default]     raise IndexError("index out of range")
[Default] IndexError: index out of range

Repro:

Open target
Click on function call in HLIL
Press Escape

Mere presence of a plugin with is_valid handler seems to be enough, it is not needed to execute a plugin command.
Workaround:

Removing is_valid handler from plugin command registration.

Reported a bug upstream:  Vector35/binaryninja-api#6254

Disabled is_valid in 5b80ee5 to work round this issue.

Closing this issue here as 0.4.0 does not use is_valid anymore, avoiding this upstream bug.


Sticky Utility Class

This will allow the fork corner to stay on its position while scrolling.

Added this with version 1.1.0


Integration to HLOC or COLMAP?

Hello Team,
Is there any easy way to integrate Gluestick feature extraction and feature matching outputs to hloc and/or colmap?
I am just curious about it.
PS: This is a great work by the way. Thanks for open-sourcing it.
Thanks.

Hi, currently, GlueStick has not been integrated into hloc or Colmap. The reason is that none of the two use line features, and the point matching alone of GlueStick is very similar to SuperGlue.
However, we have integrated GlueStick into our framework LIMAP, which is a fusion of Colmap and hloc for both points and lines. You might be interested in checking this repo.

Thanks for the prompt response.
Can LiMAP take a set of unposed images and estimate camera parameters (just like the way colmap and hloc produce cameras.txt)?
In other words, I am  trying to estimate camera positions just from a folder of images. I am able to do it with COLMAP and/or HLOC by adding "Superpoint+SuperGlue" into the pipeline. I just wanted to see if I can enhance my existing performance by using Gluestick in the COLMAP pipeline and/or HLOC pipeline?
Thanks!

Currently, LIMAP first runs COLMAP to get the camera poses, so you would not get any improvement initially. It can however improve a bit the camera poses later by introducing lines into the bundle adjustment, and thus adding new information to improve the camera poses. Maybe you can have a look at the documentation of LIMAP to see how to retrieve these refined camera poses, and open an issue in the LIMAP repo if you still have questions.
Note that we are currently working on a version of LIMAP that would not need this initial dependency on Colmap, and that would be able to output the camera poses directly from points and lines. This will not be ready before a few months, however.


Ability to set $id property

Description
According to modelina landing page (https://www.asyncapi.com/tools/modelina) there is a new property (not documented in the spec page) called "$id" and it seems that is used by modelina to set the name of java classes.
I would like to generate a spec file with this property.

Its not AsyncAPI specific, but JSON Schema draft 7


finish-args-unnecessary-${xdg-dir}-access isn't always correct

The xdg-dir permissions are special. They do not only grant read access to a path they actually mount paths in different locations.
For example:
--filesystem=home --filesystem=xdg-config/foo will mount ~/.config/foo to ~/.var/app/$FLATPAK_ID/config/foo.
This is a valuable feature for applications that expect these in $XDG_CONFIG_HOME.
That said it is also often a misused feature. Flatpaks should rarely read host configs, that is usually a mistake. So I'd say it should only be done when that host data is required. I don't think it makes sense to load configs from the same app on the host (they are not necessarily compatible), nor does it make sense to load like gtk-3.0's settings.
So it is a valuable check but it does sometimes have valid usage.

For apps actually using it correctly, we would accept an exception.

nor does it make sense to load like gtk-3.0's settings.

This seem necessary for "bookmarks" in the file chooser.


"allow-batch-downloads" in Configuration doesn't work

Batch downloads are currently always allowed, even if allow-batch-downloads: false is set in the config.yml file. Confirmed on 0.5.56.

Fixed in 0.5.57.


Reworked JSCAD Script Processing

This is a fairly significant change, moving away from code within comments within code. The functionality is now split into jscad-worker.js (ASYNC) and jscad-function.js (SYNC). The code can now be fixed/debugged easily, and enhanced if additional functionality is required.
Note: The old async and sync functions still exist, and should be removed once the new code has been tested completely.
In addition, there are a few small changes to drag and drop to accommodate and streamline processing.
Finally, the strange global variable _includePath is now derived from the URL of script. This global is no longer required.

I just ran through all the Examples, they all work ...

Excellent!


travis: fix test/integration/component/test_public_ip.py

Description
This PR fixes a travis test failure after merging PR #5464.
ROOT admin cannot list public ip address in the vlan ip ranges which are dedicated to other domain/user, we need to fix the issue in another PR.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[x] Major
[ ] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

looks good
Currently running test: component/test_public_ip
/home/travis/.local/lib/python2.7/site-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 2 is no longer supported by the Python core team. Support for it is now deprecated in cryptography, and will be removed in the next release.
  from cryptography.hazmat.backends import default_backend
==== Marvin Init Started ====
=== Marvin Parse Config Successful ===
=== Marvin Setting TestData Successful===
==== Log Folder Path: /tmp/MarvinLogs/Sep_21_2021_13_06_50_S1FGB4. All logs will be available here ====
=== Marvin Init Logging Successful===
==== Marvin Init Successful ====
=== TestName: test_01_list_publicip_root_domain | Status : SUCCESS ===
=== TestName: test_02_list_publicip_domain_admin | Status : SUCCESS ===
=== TestName: test_03_list_publicip_user_domain | Status : SUCCESS ===
=== TestName: test_04_list_publicip_all_subdomains | Status : SUCCESS ===
=== TestName: test_05_list_publicip_user_domain | Status : SUCCESS ===
=== TestName: test_06_list_publicip_user_domain | Status : SUCCESS ===
===final results are now copied to: /tmp/MarvinLogs/test_public_ip_AK5Q6S===
real	0m21.808s
user	0m0.848s
sys	0m0.128s

re-kick the test

Ping for review @rhtyd @sureshanaparti @davidjumani  @shwstppr @Pearl1594 - Travis passing, no further tests needed

@weizhouapache lgtm but doesn't it create an API regression?

@weizhouapache lgtm but doesn't it create an API regression?

@rhtyd as I said in the description of this PR, there is indeed an issue.
ROOT admin cannot list public ip address in the vlan ip ranges which are dedicated to other domain/user (if domain and account are not passed), we need to fix the issue in another PR.
let's merge this pr so travis test passes (it always fails for now).

@weizhouapache alright please submit another PR


Add cores and total_memory parameters

These overlap with (and might possibly replace) the threads and memory
parameters.  I believe that they are more consistent with typcial use.
Now we ask people to specify the cores and total memory of a node.  This
should remain relatively static over time.  Then we allow them to tune
processes as they like independently of other parameters.

This also changes the default processes/threads in the config file to null to imply that we don't have any information.  This seems like a more accurate default.
Alternatively, we could also use multiprocessing.cpu_count() for cores and something similar for memory from psutil.  This would assume that the login node is similar to the worker nodes though, I'm not sure how common this is.

OK, I've also added some non-trivial documentation changes here.  Review of all of this would be welcome.  I like these changes, but they are a significant deviation from current behavior.

In terms of API I agree that this feels more natural to someone already familiar with cluster stuff (and not so familiar with dask). I'll try to look at this one in more details but here is a quick comment:

Alternatively, we could also use multiprocessing.cpu_count() for cores and something similar for memory from psutil. This would assume that the login node is similar to the worker nodes though, I'm not sure how common this is.

I don't see a good way to set the default here so I am fine with null for threads/processes. In particular: the login node has a significantly smaller processing power than the worker nodes (at least in all the setups I have come across). Even if we could somehow use cpu_count and psutil on the worker node, they are not aware of the scheduler constraints passed into the submit command.

When the user doesn't provides cores/memory should we err informatively or
should we not include a resource spec?  Dask will use sane defaults when it
gets to the worker node (using psutil then, which will presumably make more
sense) but the job scheduler won't know what we're asking for.
On Fri, Jun 29, 2018 at 1:21 AM, Loïc Estève<EMAIL_ADDRESS>wrote:

In terms of API I agree that this feels more natural to someone already
familiar with cluster stuff (and not so familiar with dask). I'll try to
look at this one in more details but here is a quick comment:
Alternatively, we could also use multiprocessing.cpu_count() for cores and
something similar for memory from psutil. This would assume that the login
node is similar to the worker nodes though, I'm not sure how common this is.
I don't see a good way to set the default here so I am fine with null for
threads/processes. In particular: the login node has a significantly
smaller processing power than the worker nodes (at least in all the setups
I have come across). Even if we could somehow use cpu_count and psutil on
the worker node, they are not aware of the scheduler constraints passed
into the submit command.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/pull/86#issuecomment-401250508,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszCxQFOUpBuoWIXX5Q5bTKnr0oklhks5uBblIgaJpZM4U7yBU
.

Also, if we felt like making a larger change, we could also replace the use of the term memory from "memory of a single worker" to "memory of a single node".  This would be a confusing breaking change but, given the small number of users today, this might be acceptable.
This would make things, I think, more clear.
cluster = PBSCluster(cores=36, memory="100GB", processes=4)

I would also remove the threads term entirely.

A few comments on the discussion above before review:

the login node has a significantly smaller processing power than the worker nodes

In our case, login nodes are used also for dev purpose and graphical display, so they have bigger processing power 🙂. Anyway, I agree with @lesteve, no good way to setting defaults here.

When the user doesn't provides cores/memory should we err informatively

My point of view is that we should err informatively. Upcomming errors could be much more difficult to analyse. On our cluster, default resources spec (when nothing is specified) is select=1;ncpus=1;mem=5GB. If we start a worker with these resources spec, and it begin using all the cores of the node it runs on, it will get killed few seconds after. Hard to debug for day to day user.

we could also replace the use of the term memory from "memory of a single worker" to "memory of a single node". This would be a confusing breaking change

I'm not sure about that, can't decide yet. Could we at least keep the old memory keyword as a new one for a while? memory_per_worker for example.

I would also remove the threads term entirely

This would prevent from doing "over threading":
cluster = PBSCluster(cores=24, memory="100GB", processes=12, threads=4)

don't know if it is used a lot though.

This would prevent from doing "over threading"

I am probably mistaken here, this will still be possible using resource_spec.

Could we at least keep the old memory keyword as a new one for a while? memory_per_worker for example

We could, but I'm inclined to make a clean break if it's possible.  However, if there is a use case for memory_per_worker then we should keep it.  Is there such a use case?

OK, I've made the node->job switch.  I'm waiting on agreement behind threads/total_memory to make those changes.

I've tenatively removed threads and memory.  I know that we haven't agreed on this yet, but I wanted to see how it would change things.  I've also added an informative error message.

I would like to merge this soon if possible.

Any further comments?

Thanks for the review.  It's been very helpful
On Mon, Jul 2, 2018 at 5:37 PM, Guillaume EB<EMAIL_ADDRESS>wrote:

@guillaumeeb approved this pull request.
LGTM, not sure I will have time to test it before holidays though. Will
try tomorrow.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/pull/86#pullrequestreview-133785848,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszAOacBB17x7omHRFf4zZNIs8OWtBks5uCpKqgaJpZM4U7yBU
.

My pleasure, thanks for the work here (and for dask more generally).

I'd be fine to switch to that. I wouldn't mind it being done in a separate PR though, maybe even just #63

+1

I would like to merge this soon if possible.

+1. I'm good with merging this now.

Found some time to test, works perfectly, nice errors when not properly configured.

Great.  Thanks for the review all.  Merging!


add network policies

What this PR does / why we need it:
add network policies for following direction:

nginx-controller - from/to all

Which issue(s) this PR fixes:
Ref #565 (part of fixing)
Special notes for your reviewer:
cc @dansible
Release note:
Add Network Policy for nginx-controller from/to all traffic.

Thanks @neo-liang-sap and @dansible! :) Have you tried this out already in a shoot?
Also, can you please enhance the release note a bit to explain more what exactly is added?
@mvladev can you please take a look here?

Hi @rfranzke @mvladev
I edited the release notes and i found some issue on my PR, will fix soon
Thanks.
-Neo

Hi @rfranzke , i tested in my local shoot and corrected some typo - sorry for this and thanks for the catch!
Hi @mvladev , i added - namespaceSelector: {} to select all pods in all namespaces, do correct me if i was wrong...Thanks!
  - to:
    - ipBlock:
        cidr: <IP_ADDRESS>/0
    - namespaceSelector: {}

Hi @rfranzke , i've tested in my local shoot, sorry for my typo and thanks for catching!
Hi @mvladev , thanks for the comments, i've modified according to your suggest and do let me know anything wrong, thanks!
-Neo

Add Network Policy for dashboard to API server

I think there is no dashboard related change in this PR, right? Can you update the PR description?

Hi @ialidzhikov , i've changed description according to your comments, thanks!

Hello,
I just commit one new network policy for calico to api server in TCP 443 port, for more detailed info please refer to discussion on https://github.com/gardener/gardener-extension-networking-calico/pull/18#issuecomment-600591743 , to fix https://github.com/gardener/gardener-extension-networking-calico/issues/16
Then i will label calico related components with this network policy
Thanks.
-Neo

thanks @zanetworker , i've fixed the np name

@mvladev isn't the metrics server directly talking to the kubelet, it just needs to be reachable from the API server?

https://github.com/kubernetes-sigs/metrics-server/blob/65b8126df5b4037162e3c696c1216ffea67aaff4/pkg/api/node.go#L74-L110

Hi @mvladev , @zanetworker ,
i've added two np to metrics server so totally there are 3 nps for metrics server, thanks
    networking.gardener.cloud/from-seed: allowed
    networking.gardener.cloud/to-apiserver: allowed
    networking.gardener.cloud/to-dns: allowed

metrics-server talks to the kubelet on port 10250 and the current policy would block this. See:
https://github.com/kubernetes-sigs/metrics-server/blob/65b8126df5b4037162e3c696c1216ffea67aaff4/cmd/metrics-server/app/options/options.go#L93

@mvladev should i add one new networkpolicy like networking.gardener.cloud/to-kubelet for port 10250?

@mvladev should i add one new networkpolicy like networking.gardener.cloud/to-kubelet for port 10250?

Yes, it makes sense.

Also just a note this configuration is tied to a flag and not a fixed value, which means, it needs to be changed if the flag changes kubelet-port.

Also just a note this configuration is tied to a flag and not a fixed value, which means, it needs to be changed if the flag changes kubelet-port.

It doesn't matter for our use - case. It will change only if kubelet changes the default port (it won't)

how can i get this kubelet-port value like an variable? @zanetworker @mvladev

@neo-liang-sap for now just keep it as is I would say.

i added an np for kubelet and label metrics server with it

@rfranzke , thanks! i've squash into one commit.

Thank you @neo-liang-sap for your contribution and all your efforts! :)

welcome @rfranzke !


state-history doc

Temporary home for state-history plugin doc

@tbfleming @lparisc anything here we don't already have documented?

@lparisc and @tbfleming does this need to be kept open?  Do we know what needs to happen?

Closing due to lack of response/activity. Can be reopened if this is still needed.


[WFLY-19489] Upgrade HAL to 3.7.4.Final

https://issues.redhat.com/browse/WFLY-19489

We skipped versions 3.7.1 - 3.7.3 because of issues with deploying them on Maven Central.

Thank you @hpehl will merge once CI completes


Ah, we're not. It's just going to use the default value now. see:
https://github.com/smileidentity/android/blob/dbecee1776fa258ae9d70d7057ea888309f1f601/lib/src/main/java/com/smileidentity/models/PrepUpload.kt#L16


Use os.availableParallelism() to calculate default concurrency

Please consider using os.availableParallelism() to calculate default concurrency.
The API is not available on older versions of Node.js, but I think that is fine. In those cases it can default to 0 or so.
The unlimited concurrency is too eager. Especially in CI. I understand that --concurrency can be set manually, but the value must be guessed. Instead os.availableParallelism() could provide it taking into account available resources.

I'll check compatibility with other platforms.
I think it could be released as a fix:, since in large projects unlimited execution is a concern. Then, if os.availableParallelism() is not available, we could keep as it is.

Note to self

Check for const availableParallelism = os.cpus().length when os.availableParallelism() is not available.

os.cpus().length should be good fallback.
Just to draw your attention, here is how Jest handles number of workers: https://github.com/jestjs/jest/blob/b8c5200451b89bab85e42f5e9a29bcd13d00c894/packages/jest-config/src/getMaxWorkers.ts#L38
It sounds feasible to use only 50% of available core in the watch mode.

Just to draw your attention, here is how Jest handles number of workers: https://github.com/jestjs/jest/blob/b8c5200451b89bab85e42f5e9a29bcd13d00c894/packages/jest-config/src/getMaxWorkers.ts#L38
It sounds feasible to use only 50% of available core in the watch mode.

Thanks for the idea.
I've done something quite similar, but treating it as a polyfill.


How to return error or loading states for function annotated with @riverpod?

Hi, thanks for writing the article on https://codewithandrea.com/articles/flutter-riverpod-generator/. One thing I would like to ask is how to return error or loading states for function annotated with @riverpod [1] as I saw that you were handling the different states on the presentation page [2]. I don't see the states being returned on the pub documentation of the library as well [3].
Thanks!
[1] https://github.com/bizz84/tmdb_movie_app_riverpod/blob/0863d8b7d1124bed31e991c11661de142180e80e/lib/src/features/movies/data/movies_repository.dart#L91-L142
[2]
https://github.com/bizz84/tmdb_movie_app_riverpod/blob/0863d8b7d1124bed31e991c11661de142180e80e/lib/src/features/movies/presentation/movies/movies_search_screen.dart#L53-L55
[3]
https://pub.dev/packages/riverpod_generator

@jeremiahwstan if the code inside the provider body throws an exception, Riverpod will automatically set the state to an AsyncError that contains that exception.
If desired, you can throw your own exceptions, and the same behaviour will apply.


Tweak config app to use env vars

Will fix the tweet issue URL thing with #58

LGTM :)

Pull requests that have a failing status can't be merged from a phone.


Happymh  can't refresh to catch the latest episodes, and  can't read the comics

Source information
Happymh 1.4.14
Source language
Chinese
Steps to reproduce
Open the comic book added to the shelf and pull down to refresh the chapter. At this time, "No chapter" will be displayed and click on the chapter to watch, and no picture can be obtained
Expected behavior
Get the latest chapters normally, and can read comics
Actual behavior
Can't get the latest chapters properly, can't read comics
Mihon/Tachiyomi version
0.16.2
Android version
Android12/Harmonyos 3.0
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

Add a :+1: reaction to issues you find important.

Well I got the same problem before,but now it just tell me can't bypass the cloudflare

你们能看吗，我更新了插件还是看不了


Fixed SOIC fn

Me and @ShiboSoftwareDev  found a bug in the SOIC implementation where pin width is subtracted from the pitch which affected the gap between the pins and the silkscreen, The bug was complicated to figure out and I think it should be fixed now.

I think I can do that

We fixed a bug that doesn't exist, it turned out it was behaving like it should. We just got confused by this test which doesn't make sense.


nitweb: clean existing api

This PR cleans the Quick&Dirty(c) JSON API of nitweb to use the model_json one.
Modified services:

/uml -> /api/um/:entity
/code -> /api/code/:entity
/random -> /api/random
/search -> /api/search

Also do some renaming to match popcorn philosophy.

+1 seems good. I understand that this is mostly refactorization and that new features will be in new PR.
By the way, I think that services that returns a list (search, random, list) should share most modifiers like k or n.

random is actually a subclass of list so they share the same parameters.
I didn't merge search with it, but this is a good idea. I have another PR coming later that works on the search implementation, I suggest to let this as is in this PR.

Reroll for jenkins

Demo: http://nitweb.moz-code.org/


Issue Type: Bug

Open git folder (I have one pulled from GitLab)
Do some changes and use commit message "#NNN ..." where NNN is the issue number on GitLab
Try to commit - nothing happens

This is probably not related to Gitlab at all and it started about 10 days ago.
I must stage the files and then commit in terminal using
git commit -m "#NNN message"
or it works when I use full URL to the gitlab issue in the message
VS Code version: Code - Insiders 1.41.0-insider (fdeb9aa9b8306a2d3da989ccb9d2ad288d0ae347, 2019-11-08T05:28:30.394Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4 x 2496)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.41GB (19.08GB free)

Process Argv
--disable-extensions

Screen Reader
no

VM
0%

Extensions disabled

/duplicate of #84201 Should be fixed in Recovery Release


add mapfoldl init optimization

https://github.com/tkf/Transducers.jl/pull/3#discussion_r244515607

Codecov Report

Merging #4 into master will decrease coverage by 0.79%.
The diff coverage is 54.54%.

@@            Coverage Diff            @@
##           master       #4     +/-   ##
=========================================
- Coverage    67.9%   67.11%   -0.8%
=========================================
  Files           6        6
  Lines         592      599      +7
=========================================
  Hits          402      402
- Misses        190      197      +7

Impacted Files
Coverage Δ

src/core.jl
54.68% <ø> (ø)
:arrow_up:

src/processes.jl
72.38% <54.54%> (-3.13%)
:arrow_down:

src/library.jl
66.9% <0%> (-0.71%)
:arrow_down:

Continue to review full report at Codecov.

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

Awesome PR as always! Thanks a lot.


perf: provide custom implementation for creating UUIDs.

This change yield ~5x performance improvement for UUID generation,
which results in ~30% performance improvement when proxying HTTP/2
traffic on localhost:
Before:
UUIDUtilsTest.benchmark:  2003 ms
h2load -c 100 -n 100000: 26467 req/s
After:
UUIDUtilsTest.benchmark:   408 ms
h2load -c 100 -n 100000: 34099 req/s
As a bonus, this implementation is fully portable and depends only
on BoringSSL's crypto.
Partially fixes #249.

Similar results on CI:
Before (current master):
[ RUN      ] UUIDUtilsTest.checkDistribution
[       OK ] UUIDUtilsTest.checkDistribution (4500 ms)

After (this PR):
[ RUN      ] UUIDUtilsTest.benchmark
[       OK ] UUIDUtilsTest.benchmark (795 ms)
[ RUN      ] UUIDUtilsTest.checkDistribution
[       OK ] UUIDUtilsTest.checkDistribution (860 ms)

@mattklein123 @htuch PTAL. Please note that ASAN test failed to build 1/146 tests because of No space left on device, and that's why it's marked as failed, but all tests that built passed.

(Also, if you merge with master, you should be able to pickup the bazel.asan workaround).

LGTM other than @htuch comments and my comment about disabling the benchmark test.

Bummer, the commit message was removed during merge.
Could we please not do that in the future (or more precisely, could the person merging PR make sure that the commit message is retained)? Thanks.

@RomanDzhabarov please see the nodes on cleaning up the commit message in https://github.com/lyft/envoy/blob/master/CONTRIBUTING.md. The goal is to clean it up but not delete it. Thanks.

@PiotrSikora yeah, sorry that's my bad.


Guidance Requested: Custom Root CA Certificates

I am trying to insert inside boot2docker.iso some custom Root CAs, [Intermediate #2 (SHA-2)] Comodo RSA Domain Validation Secure Server CA because it's missing from installed certs and docker can't pull from a custom registry which uses a TLS certificate issued by the above mentioned Root CA.
I have read the BUILD document and inspected files in rootfs/etc/rc.d.
I couldn't figure it out where should I place certificates so they end up in /var/lib/boot2docker/certs and configured by install-ca-certs rc.d script at machine first boot. All of this via the awesome BUILD mechanism that boot2docker has.
Can someone please shed some light. Thanks :).

#347 is related but it doesn't clarify the above. I would like the Root CA to be inserted at build inside the boot2docker.iso and at startup to be automatically inserted by install-ca-certs.

For other boot2docker-ers out there I will post here a hack to achieve the above. In fact I will post my custom Dockerfile.
FROM boot2docker/boot2docker

# COPY docker/ $ROOTFS/etc/docker/
COPY ca-certificates $ROOTFS/opt/ca-certificates
COPY custom-ca-certificates $ROOTFS/opt/
RUN chmod +x $ROOTFS/opt/custom-ca-certificates \
    && echo "/opt/custom-ca-certificates" >> $ROOTFS/opt/bootlocal.sh \
    && echo "# Custom Root CA Certificates" >> $ROOTFS/opt/bootscript.sh \
    && echo "if [ -e /opt/bootlocal.sh ]; then" >> $ROOTFS/opt/bootscript.sh \
    && echo "    /bin/sh /opt/bootlocal.sh > /var/log/bootlocal.log 2>&1 &" >> $ROOTFS/opt/bootscript.sh \
    && echo '    echo "------------------- ran /var/lib/boot2docker/bootlocal.sh"' >> $ROOTFS/opt/bootscript.sh \
    && echo "fi" >> $ROOTFS/opt/bootscript.sh

RUN /make_iso.sh

CMD ["cat", "boot2docker.iso"]

custom-ca-certificates is a shell script which content can be found at the following gist:  https://gist.github.com/irgeek/afb2e05775fff532f960. I have changed BOOT2DOCKER_CERTS_DIR=/var/lib/boot2docker/certs to BOOT2DOCKER_CERTS_DIR=/opt/ca-certificates.
Happy hacking :).

Small question, what is the content of ca-certificates file?


Prepare for PHPStan 1.0

Hello everyone 👋
I announced today that PHPStan 1.0 is going to be released on November 1st 2021.
I'm approaching you as one of the most popular PHPStan extensions. I'd love if you could prepare your code for PHPStan 1.0 in advance so that it's ready to release on the same day.
Here's a brief guide how to approach the upgrade:

Create a branch 🌴
Update your composer.json to "phpstan/phpstan": "^1.0", add "minimum-stability": "dev" and "prefer-stable": true if necessary.
Update your code with the BC breaks below in mind. 🔧
Fix the code so that it passes PHPStan's analysis 🤓
Wait for PHPStan 1.0 release on November 1st, merge your branch and tag the next major version 👍

Thank you!

Here are the BC breaks. The list is huge but most of those have very little impact.
BC breaks for end-users

Level max is now level 9. Feel free to update max to 8 if your code isn't ready.
Description of some types was updated to match the syntax in PHPDocs. This includes numeric-string (it was previously described as string&numeric), and also array shapes.
Removed baselineNeon error formatter, use --generate-baseline CLI option instead (https://github.com/phpstan/phpstan-src/commit/492cfbcd74b540eda1520e11b67d7be00cbc7c31)
Removed polluteCatchScopeWithTryAssignments config parameter (https://github.com/phpstan/phpstan-src/commit/8933c7e28c2ebb1fd69584c031f579cd53ddf4ae)
Removed deprecated autoload_files parameter - use Discovering Symbols instead (https://github.com/phpstan/phpstan-src/commit/7a21246cae9dd7968bf7bef92223b53f5d681b72)
Removed deprecated autoload_directories parameter - use Discovering Symbols instead (https://github.com/phpstan/phpstan-src/commit/f67b48a71220b295a1704fe9749492e5de9ee18f)
Removed bootstrap parameter - use bootstrapFiles instead (https://github.com/phpstan/phpstan-src/commit/1baa29425d2e170af8ac53e4e579c34c25b640e4)
Moved implicitThrows configuration parameter to exceptions.implicitThrows (https://github.com/phpstan/phpstan-src/commit/96b7c48025dcbd5a709cea71ee4e9e73770e0d54)
Removed --paths-file CLI option (https://github.com/phpstan/phpstan-src/commit/5670cf221723eb652643623ad487351cb187f6c3)
Removed dump-deps command (https://github.com/phpstan/phpstan-src/commit/9c7017c697c29668f8a7c766236e597737f99f91)
Deprecated excludes_analyse option, use excludePaths instead (https://github.com/phpstan/phpstan-src/commit/d25c5e5a6c62a4537d4a108707ff26b5bea687d9)

The following are interesting only if you create a custom ruleset in your configuration file:

Removed DeadCatchRule, replaced by CatchWithUnthrownExceptionRule (https://github.com/phpstan/phpstan-src/commit/4dba60bacbf3ac0efe8627fa32177ee21cdd3eca)
Removed VariableCertaintyInIssetRule, replaced by IssetRule (https://github.com/phpstan/phpstan-src/commit/2e858dee389d4843e4d1a7dc1bc565c264be247f)
Removed MissingClosureNativeReturnTypehintRule, no longer needed thanks to type inference (https://github.com/phpstan/phpstan-src/commit/1c34d8dc855cb5f4cf5c8b033b7155eeed0e277b)
Rename rules with typos (https://github.com/phpstan/phpstan-src/commit/003ab1aea558085cd27636a0b95a4c9f0e062e9a)

BC breaks for extension developers

Removed CompoundTypeHelper (https://github.com/phpstan/phpstan-src/commit/145c4e3af4045b074b1d6e697022a835433cd5f2)
Removed CommentHelper (https://github.com/phpstan/phpstan-src/commit/ebad6f61b9a65b68c200f7ac3a444ce198149396)
Removed DependencyDumper (https://github.com/phpstan/phpstan-src/commit/9c7017c697c29668f8a7c766236e597737f99f91)
Removed PHPStan\Reflection\Generic\ResolvedFunctionVariant, replaced by PHPStan\Reflection\ResolvedFunctionVariant (https://github.com/phpstan/phpstan-src/commit/1cc6c8175a6d92cf717cd553506c9da8a2dd72cc)
Removed ClassReflection::getNativeMethods(), use getNativeReflection() instead (https://github.com/phpstan/phpstan-src/commit/d2c1446b3b0f581502019c522ccb521b37e7dc15)
Removed PhpPropertyReflection::hasPhpDoc(), replaced by hasPhpDocType() (https://github.com/phpstan/phpstan-src/commit/bedd5be99107254f42efb7728c9ce3a7b958e33e)
NodeDependencies no longer iterable (https://github.com/phpstan/phpstan-src/commit/f76875a84d8dcca8f9d67c08b6492c609e9aff98)
Renamed TestCase to PHPStanTestCase (#634), thanks @frankdejonge!
StaticType and ThisType - require ClassReflection in constructor (https://github.com/phpstan/phpstan-src/commit/7aabc848351689f18a1db99598df8d5b4944aa87)
PHPStanTestCase - extensions can no longer be provided by overriding methods from PHPStanTestCase. Use getAdditionalConfigFiles() instead. (https://github.com/phpstan/phpstan-src/commit/65efd93f764e9db076851ef262179fe670f1ab38, https://github.com/phpstan/phpstan-src/commit/239291a91089da6684d8c52e58b9a77ceb178071)
Removed some unused internal helper methods from Broker (https://github.com/phpstan/phpstan-src/commit/d57815103091d8f25347b8441da3ed099f70d7af)
Changed return types of various methods that had |false to |null (https://github.com/phpstan/phpstan-src/commit/629ccf6b02146e1cbf0499982358c595e3d6edd5)
Type generalization precision is now a required argument (https://github.com/phpstan/phpstan-src/commit/65681033ff625c67a478212a0cd6da29cd5ab5fa)
Some constructor parameters are now required (https://github.com/phpstan/phpstan-src/commit/1f4062fe2d0d5406e9b8a782f99b6da61eceafde)
Deprecated BrokerAwareExtension (https://github.com/phpstan/phpstan-src/commit/db2f7fb9e7928de68665ca09a3e1002d8a329b33)
Deprecated PHPStanTestCase::createBroker(). Use createReflectionProvider() instead. (https://github.com/phpstan/phpstan-src/commit/1e5cf58e07446e634803c3be87e7c41fdd903c7c)
Deprecated PHPStan\Broker\Broker. Use PHPStan\Reflection\ReflectionProvider instead. (https://github.com/phpstan/phpstan-src/commit/c7755948c124cfbcb1220ab912a6eaa863cdf5fb)
Deprecated PHPStan\Broker\Broker::getInstance(). Use PHPStan\Reflection\ReflectionProviderStaticAccessor instead. (https://github.com/phpstan/phpstan-src/commit/4e7d60d74b3fda7dc4d3e0c0798b7fd55a7b32f2)

Thanks for testing, this is really valuable feedback and it will make 1.0 much better!
The behaviour you're seeing is because I made a memory optimization - the parser trims the function bodies before caching them. For files that are outside of analysed paths, the function body is not interesting, only the signature and the PHPDoc. I saved around 100 MB on this when analysing PHPStan itself.
The right solution isn't to typehint a different parser, but to configure dependency injection differently. I made this change so it should work out of the box when you update to the latest dev-master of phpstan/phpstan: https://github.com/phpstan/phpstan-src/commit/c5ce0b1bbbc522a1c88555fe8e90e91cfd56c9fa
Also I'm interested - why are you parsing the migrations and what are you reading from them?

About the parser change - let's hope this message will be sufficient:

@ondrejmirtes Looks great! Thank you!


Errors in HTML5 Documents- reviewsection.html, ncent.html

Fixing Errors in reviewsection.html
BEFORE Modification:
Live Code:

 Some Lines Of Code..........

AFTER Modification:
Live Code:

Fixing Errors in ncent.html
BEFORE Modification:
Live Code:

AFTER Modification:
Live Code:

Hi @SauravMukherjee44 . At the Starting of the GSSOC'23 Program, I made a Small Mistake like Directly I made a PR Before Raising Issue. Because of I am New to Open Source Program .Kindly  Review and Merge this Time with add Specific Labels.


Error while importing the Frozen model created in inference_graph folder into tensorflow.js

Dear community members,
I am trying to import the created frozen_inference_graph.pb to create tensorflow.js equivalent model , so as to consume the same in web browser . To do the same , as per the tensorflow.js standard documentation , we have to use the tensorflowjs_converter . On  performing the steps mentioned, I am coming across errors.
tensorflowjs_converter --input_format=tf_frozen_model --output_node_names='detection_boxes,detection_scores,detection_classes,num_detections' C:\tensorflow5\models\research\object_detection\inference_graph\saved_model\saved_model.pb C:/model_conv/inference_graph/web_model
I got below error for the above conversion
Traceback (most recent call last):
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\PunitUpadhyay.conda\envs\tensorflowjs3\Scripts\tensorflowjs_converter.exe_main.py", line 7, in
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflowjs\converters\converter.py", line 671, in pip_main
main([' '.join(sys.argv[1:])])
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflowjs\converters\converter.py", line 675, in main
convert(argv[0].split(' '))
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflowjs\converters\converter.py", line 658, in convert
weight_shard_size_bytes=weight_shard_size_bytes)
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflowjs\converters\tf_saved_model_conversion_v2.py", line 393, in convert_tf_frozen_model
weight_shard_size_bytes=weight_shard_size_bytes)
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflowjs\converters\tf_saved_model_conversion_v2.py", line 134, in optimize_graph
graph.add_to_collection('train_op', graph.get_operation_by_name(name))
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflow\python\framework\ops.py", line 3640, in get_operation_by_name
return self.as_graph_element(name, allow_tensor=False, allow_operation=True)
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflow\python\framework\ops.py", line 3512, in as_graph_element
return self._as_graph_element_locked(obj, allow_tensor, allow_operation)
File "c:\users\punitupadhyay.conda\envs\tensorflowjs3\lib\site-packages\tensorflow\python\framework\ops.py", line 3572, in _as_graph_element_locked
"graph." % repr(name))
KeyError: 'The name "num_detections'" refers to an Operation not in the graph.'
Kindly help me here , as i want to use the trained model in web using tensorflow.js . I also want to know if at all this is feasible , since tensorflow.js is @1.7.4.post1 which I have used and is the latest , which should make it compatible to do the conversion.
Kindly Help !
Thanks & Awaiting Reply from community !

Sa me!  I am trying to do the exact same thing.  Have you made any progress>


timeout does not delete session stored in mongodb after the given time.

Hi,
I found a strange issue where the sessions are not timed out after the specified time.
app.use(session({
	secret: 'jwtsecret',
	resave:false,
	saveUninitialized:true,
	store: sessionstore.createSessionStore({
      type: 'mongodb',
      host: 'localhost',         // optional
      port: 27017,               // optional
      dbName: 'dbName',       // optional
      collectionName: 'sessions',// optional
      timeout: 10000             // optional
  })
}));

sessions are created correctly but are not timed out or deleted according to the given timeout. Can you please help here/

There is a Warning:
Warning: The TTL index does not guarantee that expired data will be deleted immediately. There may be a delay between the time a document expires and the time that MongoDB removes the document from the database.
That's why I've introduced this: https://github.com/adrai/sessionstore/blob/master/lib/databases/mongodb.js#L213


Should THCApply.cuh be using 'long long' instead of 'long'?

In THCApply.cuh, there is:
if (THC_canUse32BitIndexMath(state, a) &&
      THC_canUse32BitIndexMath(state, b) &&
      THC_canUse32BitIndexMath(state, c)) {
    TensorInfo<unsigned int> aInfo(state, a);
    TensorInfo<unsigned int> bInfo(state, b);
    TensorInfo<unsigned int> cInfo(state, c);

    HANDLE_A_CASE(unsigned int, aInfo.dims, bInfo.dims, cInfo.dims);
  } else {
    TensorInfo<unsigned long> aInfo(state, a);
    TensorInfo<unsigned long> bInfo(state, b);
    TensorInfo<unsigned long> cInfo(state, c);

Per https://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os/ , a 'long' is basically a 32-bit int.  This article suggests that if one wants to obtain 32-bit and 64-bit integers, somewhat pseudo-portably, currently one can use the following types:

32-bit integer: int
64-bit integer: long long

(Note: per http://stackoverflow.com/questions/3935858/what-size-are-integers-when-programming-cuda-kernels , the definition of long for CUDA is also platform-specific?)

(Note that I'm starting to move cltorch to using int64 and uint64 typedefs, rather than long and long long, https://github.com/hughperkins/cltorch/commit/6b06f6ffdf20c741bed591cc12ee7c05115826cc , which apparently was sufficient to fix a mac build issue https://github.com/hughperkins/cltorch/issues/3#issuecomment-118125371 )

I agree. Using long is not great. Torch uses it all over the place, probably with the assumption that it's 64-bit (which I believe is true for most modern, i.e. 64-bit, Linux and Mac systems). I'd love to see int64 and uint64 instead.

Ok, sounds good.  I started attempting this, got a bit more than I could chew.  Some things to ponder:

like const-casts, it sort of 'infects' everything, since array of  long long is not compatible with array of long
since trying to change the whole world is inevitably doomed to failure, I'm thinking that maybe the following function could be used at the boundary between int64 areas and long areas:

long *int64ToLong( int64 *val ) {
  if( sizeof(long) == sizeof(int64) ) {
    return (long *)val;
  } else {
    throw std::runtime_error("Incompatible types, 32-bit vs 64-bit int array");
  }
}

anywhere that a long is actually 64-bit, ti works just fine
anywhere that it's not, do we actually want it to start pretending they are?  perhaps better to crash in a somewhat-controlled fashion, and fix it?

that's the first point.
second point is, from the point of view of the user-interface into torch, I think it's well established that Long means 64-bit?  And this is pretty standard, eg java http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html .  its only c/c++ that has some ambiguity about it.
So, maybe LongStorage nad LongTensor stays LongStorage and LongTensor, including when they're used as c/c++ functoin names, structs, classes etc?
Only thing that changes is the underlying c/c++ types "tighten up" a bit, so they dont behave in differnet ways, depending on whether one is on Windows, mac, 32-bit/64-bit linux, etc?
Oh yeah, and one other thing: might need to start in Torch first :-P  eg in cutorch or cltorch, Tensor.c line 1070 calls into THFile_writeLongRaw, passing an array of longs.  However, using the somewhat-hacky function above, this could be manageable, without first modifying Torch?

Hmmm: maybe the first step of having a smooth migraiton of both torch and cu/cltorch would be to ensure that cu/cltorhc can accept IntTensors anywhere they can accept LongTensors.  Then, I think migrating torch itself is fairly smooth, posisbly.
In reality, I'm probalby just going to migrate stuff across as I hit weird build problems and stuff, no major hurry :-)

CUDA uses long long for 64 bit integers so we should probably use that. What size long or long long uses is a compiler-dependent type; I think the only guarantee is that sizeof(int) <= sizeof(long) <= sizeof(long long).
To be truly portable one should use the C99 types int32_t and int64_t:
http://en.cppreference.com/w/c/types/integer

However, CUDA by default (invoking nvcc from the command line, with no args) has sizeof(long) == sizeof(long long) == 8 in whatever configuration that uses but they are different types, hence some typecasts floating around.

The CUDA APIs tend to use long long.

long long would work.  I didnt know about int32_t and int64_t.  Since C++ is not a superset of C99, but a separate fork essentially, I'm wondering whether MSVC C++ supports these?

it's in C++ too, 11 I think officially but I think also in most 98 or 03
installations.
On Wednesday, July 29, 2015, Hugh Perkins<EMAIL_ADDRESS>wrote:

long long would work. I didnt know about int32_t and int64_t. Since C++
is not a superset of C99, but a separate fork essentially, I'm wondering
whether MSVC C++ supports these?
—
Reply to this email directly or view it on GitHub
https://github.com/torch/cutorch/issues/191#issuecomment-126128690.

@soumith I think this was causing problems for your ARM port thing too.
If we don't want to go to the standard int32_t/uint32_t/int64_t/uint64_t, I'd vote for going to a typedef header to define our own types in cutorch, and changing all instances of types in cutorch to point to that.
torch7 likely needs to be addressed in a similar way as well. But cutorch can at least change independently.

But cutorch can at least change independently.

with the proviso of trying not to go down the rabbit hole when you hit https://github.com/torch/cutorch/blob/df463695f0cd387736917e02abaafa63c00bbed3/torch/generic/Tensor.c#L1134-L1137 :
  THFile_writeIntScalar(file, tensor->nDimension);
  THFile_writeLongRaw(file, tensor->size, tensor->nDimension);
  THFile_writeLongRaw(file, tensor->stride, tensor->nDimension);
  THFile_writeLongScalar(file, tensor->storageOffset+1); /* to respect Lua convention */

I got quite far with my initial attempt last year, but sort of gave up trying to solve this bit, I think, seemed like it would need a bunch of coordination, between torch and cutorch, to fix this, perhaps?


stack 1

This change is part of the following stack:

#17 ◀

#18

#19

Change managed by git-spice.


-out-crt and -out-key should be directories

Doing
./nebula-cert sign -name test-node -out-crt test-node/ -out-key test-node/ -ip <IP_ADDRESS>/24
fails because -out-crt and -out-key is supposed to be paths with filenames. However, since we specify the -name argument (that will be the name of the cert and key) -out-crt and -out-key should be the directories where you want the certs to be written to.
I ran in to this issue when working on creating a snap for Nebula. Since I'm aiming for it being run in strict confinement I need to hardcode the directories where certs are created

If you want to write to a folder, just make the filename explicit, like this:
./nebula-cert sign -name test-node -out-crt test-node/test-node.crt -out-key test-node/test-node.key ...

Thank you for answering.
I know that I can use an explicit filename, as in the example above. However, what I would like is to state the directories with -out-crt and -out-key and use the value from -name as the cert and key names.

I'm fairly opposed to this as you have a number of methods to achieve what you are looking for without adding another mode to nebula-cert.

Change directories before running nebula-cert to the directory you want the material to live in.
Since you are already providing a name argument providing the final path in out-crt and -out-key should be fairly simple. Using some automation tool like chef/puppet/ansible should make this a non issue

I certainly realize this would help your specific workflow but adding another mode to how nebula-cert behaves makes the tool even more complex.

Hi,
Apologies for the late response.
To me it seems a bit awkward that you give a name (with -name) for the cert but then you have to give the full path including the name when stating where to place the certs.
My suggestion is not to add another mode but rather change -out-crt and -out-key to be directories and then append -name to it.
In my opinion this would give a little more flexibility, for example when trying to package Nebula as a snap that doesn't require classic confinement ;)