Cocoapods version of AssetImportKit: Xcode 10 - linker error: ld: symbol(s) not found for architecture armv7 arm64

Hi Eugene,
First thank you very much for awesome framework.
Last days I reconfigured my project to use AssetImportKit framework from Cocoapods. My project is IOS application (Xcode 10 based).
The latest version of AssetImportKit in Cocoapods is v1.0.3.
After I updated from v1.0.1 to v1.0.3 My Xcode always throws linker error. Below you can see the details:
ARMV7 linker issue:
ld: warning: ignoring file /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a, file was built for unsupported file format ( 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E 0x20 0x68 0x74 0x74 0x70 0x73 0x3A 0x2F 0x2F ) which is not the architecture being linked (armv7): /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a

ld: warning: ignoring file /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libIrrXML-iOS.a, file was built for unsupported file format ( 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E 0x20 0x68 0x74 0x74 0x70 0x73 0x3A 0x2F 0x2F ) which is not the architecture being linked (armv7): /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libIrrXML-iOS.a

Undefined symbols for architecture armv7:
  "_aiGetMaterialTexture", referenced from:
      AssetImportKit.TextureInfo.checkTextureType(for: Swift.UnsafeMutablePointer<__C.aiMaterial>, with: __C.aiTextureType, in: __C.aiScene, atPath: __C.NSString, imageCache: AssetImportKit.AssimpImageCache) -> () in TextureInfo.o
  "_aiGetMaterialIntegerArray", referenced from:
      (extension in AssetImportKit):__C.SCNMaterial.loadBlendModeProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + BlendMode.o
      (extension in AssetImportKit):__C.SCNMaterial.loadCullModeProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + CullMode.o
      (extension in AssetImportKit):__C.SCNMaterial.loadLightingModelProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + LightningModel.o
      (extension in AssetImportKit):__C.SCNMaterial.loadShininessProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + Shininess.o
  "_aiImportFile", referenced from:
      function signature specialization <Arg[0] = Exploded> of AssetImportKit.AssetImporter.importScene(filePath: Swift.String, postProcessSteps: AssetImportKit.PostProcessSteps) throws -> AssetImportKit.AssetImporterScene in AssetImporter.o
  "_aiGetMaterialTextureCount", referenced from:
      AssetImportKit.TextureInfo.checkTextureType(for: Swift.UnsafeMutablePointer<__C.aiMaterial>, with: __C.aiTextureType, in: __C.aiScene, atPath: __C.NSString, imageCache: AssetImportKit.AssimpImageCache) -> () in TextureInfo.o
  "_aiReleaseImport", referenced from:
      function signature specialization <Arg[0] = Exploded> of AssetImportKit.AssetImporter.importScene(filePath: Swift.String, postProcessSteps: AssetImportKit.PostProcessSteps) throws -> AssetImportKit.AssetImporterScene in AssetImporter.o
  "_aiGetErrorString", referenced from:
      function signature specialization <Arg[0] = Exploded> of AssetImportKit.AssetImporter.importScene(filePath: Swift.String, postProcessSteps: AssetImportKit.PostProcessSteps) throws -> AssetImportKit.AssetImporterScene in AssetImporter.o
  "_aiGetMaterialString", referenced from:
      function signature specialization <Arg[4] = Dead> of AssetImportKit.AssetImporter.makeMaterials(for: __C.aiNode, in: __C.aiScene, atPath: Swift.String, imageCache: AssetImportKit.AssimpImageCache) -> [__C.SCNMaterial] in AssetImporter.o
      function signature specialization <Arg[5] = Dead> of AssetImportKit.TextureInfo.init(aiMaterial: Swift.UnsafeMutablePointer<__C.aiMaterial>, textureType: __C.aiTextureType, in: __C.aiScene, atPath: __C.NSString, imageCache: AssetImportKit.AssimpImageCache) -> AssetImportKit.TextureInfo in TextureInfo.o
  "_aiGetMaterialColor", referenced from:
      AssetImportKit.AssetImporter.applyMultiplyProperty(for: Swift.UnsafePointer<__C.aiMaterial>, with: __C.SCNMaterial) -> () in AssetImporter.o
      (extension in AssetImportKit):__C.SCNMaterial.loadMultiplyProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + Multiply.o
      AssetImportKit.TextureInfo.extractColor(for: Swift.UnsafeMutablePointer<__C.aiMaterial>, with: __C.aiTextureType) -> () in TextureInfo.o

ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

linker command failed with exit code 1 (use -v to see invocation)

ARM64 linker issue:
ld: warning: ignoring file /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a, file was built for unsupported file format ( 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E 0x20 0x68 0x74 0x74 0x70 0x73 0x3A 0x2F 0x2F ) which is not the architecture being linked (arm64): /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a

ld: warning: ignoring file /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libIrrXML-iOS.a, file was built for unsupported file format ( 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E 0x20 0x68 0x74 0x74 0x70 0x73 0x3A 0x2F 0x2F ) which is not the architecture being linked (arm64): /Users/sergeymuravev/workspace/prj/vipahelda/configwise/bto-rb-ipd-ios/Pods/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libIrrXML-iOS.a
Undefined symbols for architecture arm64:
  "_aiGetMaterialTexture", referenced from:
      AssetImportKit.TextureInfo.checkTextureType(for: Swift.UnsafeMutablePointer<__C.aiMaterial>, with: __C.aiTextureType, in: __C.aiScene, atPath: __C.NSString, imageCache: AssetImportKit.AssimpImageCache) -> () in TextureInfo.o
  "_aiGetMaterialIntegerArray", referenced from:
      (extension in AssetImportKit):__C.SCNMaterial.loadBlendModeProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + BlendMode.o
      (extension in AssetImportKit):__C.SCNMaterial.loadCullModeProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + CullMode.o
      (extension in AssetImportKit):__C.SCNMaterial.loadLightingModelProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + LightningModel.o
      (extension in AssetImportKit):__C.SCNMaterial.loadShininessProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + Shininess.o
  "_aiImportFile", referenced from:
      function signature specialization <Arg[0] = Exploded> of AssetImportKit.AssetImporter.importScene(filePath: Swift.String, postProcessSteps: AssetImportKit.PostProcessSteps) throws -> AssetImportKit.AssetImporterScene in AssetImporter.o
  "_aiGetMaterialTextureCount", referenced from:
      AssetImportKit.TextureInfo.checkTextureType(for: Swift.UnsafeMutablePointer<__C.aiMaterial>, with: __C.aiTextureType, in: __C.aiScene, atPath: __C.NSString, imageCache: AssetImportKit.AssimpImageCache) -> () in TextureInfo.o
  "_aiReleaseImport", referenced from:
      function signature specialization <Arg[0] = Exploded> of AssetImportKit.AssetImporter.importScene(filePath: Swift.String, postProcessSteps: AssetImportKit.PostProcessSteps) throws -> AssetImportKit.AssetImporterScene in AssetImporter.o
  "_aiGetErrorString", referenced from:
      function signature specialization <Arg[0] = Exploded> of AssetImportKit.AssetImporter.importScene(filePath: Swift.String, postProcessSteps: AssetImportKit.PostProcessSteps) throws -> AssetImportKit.AssetImporterScene in AssetImporter.o
  "_aiGetMaterialString", referenced from:
      function signature specialization <Arg[4] = Dead> of AssetImportKit.AssetImporter.makeMaterials(for: __C.aiNode, in: __C.aiScene, atPath: Swift.String, imageCache: AssetImportKit.AssimpImageCache) -> [__C.SCNMaterial] in AssetImporter.o
      function signature specialization <Arg[5] = Dead> of AssetImportKit.TextureInfo.init(aiMaterial: Swift.UnsafeMutablePointer<__C.aiMaterial>, textureType: __C.aiTextureType, in: __C.aiScene, atPath: __C.NSString, imageCache: AssetImportKit.AssimpImageCache) -> AssetImportKit.TextureInfo in TextureInfo.o
  "_aiGetMaterialColor", referenced from:
      AssetImportKit.AssetImporter.applyMultiplyProperty(for: Swift.UnsafePointer<__C.aiMaterial>, with: __C.SCNMaterial) -> () in AssetImporter.o
      (extension in AssetImportKit):__C.SCNMaterial.loadMultiplyProperty(from: Swift.UnsafePointer<__C.aiMaterial>) -> () in SCNMaterial + Multiply.o
      AssetImportKit.TextureInfo.extractColor(for: Swift.UnsafeMutablePointer<__C.aiMaterial>, with: __C.aiTextureType) -> () in TextureInfo.o

ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

linker command failed with exit code 1 (use -v to see invocation)

Before, I was using v1.0.1 of your framework (from Cocoapods also) - so, there were NO such linker issues.
Can you please check thi out - maybe any advices from you ?

Thank you for noticing the problem, I'll check that out

Unfortunately I cannot reproduce this issue. Please, try to

clean  derrived data

pod deintegrate

pod cache clean --all

pod  install

Unfortunately I still cannot reproduce this issue. Here's the proof:

And here's the v1.0.3 project with installed pods.

I also tried to install AssetImport on other machines, everything seems to be ok.

Hi Eugene,
Can you please share your Xcode version, Xcode command line tool version and pod tool version (what you use in your environment) ?

Hi, here's what I've got

Hi Eugene,
Thank you very much for this info - if possible, let's keep this issue open in your tracker - perhaps I know the reason - I have to make couple of experiments to make sure I'm on right way - then I will share results and recommendations what might be fixed in project configurations to avoid issues what I got in my Xcode - maybe this info will be useful for other guys who get the similar issues in their development environments.
Once again - thank you very much for your assistance.
Regards,
Sergey

@smuravev did you ever figure this out, I get similar linker errors?

Hi @smuravev!
Here's the info you wanted:

Also there's one thought that came to my mind not long time ago. What if you don't have Git LFS on your machine? Please check the size of the static libraries that come with the pods, it has to be more than 100 mb for iOS and for macOS targets as well. The assimp static libraries were uploaded with the help of git-lfs, so if you don't have it installed you won't be able to download the full binaries of the libraries.
You can install git-lfs with the following command:
brew install git-lfs

Thank you for your help!

@eugenebokhan your suspicion seems to be partly right. I did not have git lfs to begin with (new computer), but after installing, deleting the Pod cache and Pods folder, the static libraries still do not appear to download.
The Pods directory contains:
./AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/macOS/libassimp-macOS.a
./AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a

Where the static files are the git lfs references:
version https://git-lfs.github.com/spec/v1
oid sha256:80d08cfdbe300173ca6b084a331cfe117af5ba662cac150b1d109f2e581c449f
size 165413080

I encountered the same issue, so I used version 1.0.1 (works great thx 👍 ) which is the last version that compiles without errors (I have git-lfs and updated it just to be sure).
Maybe you have something else on your computer that makes your version compile. My step to reproduce is very simple: I downloaded master, opened .xcworkspace, selected scheme AssetImportKit-iOS and cmd+B

@Kelmatou as I understood you are Not able to build the framework from master?

Yes that’s it but I didn’t have time to investigate further on what is causing the problem.

@Kelmatou Please tell me the size of assimp static libs in your downloaded directory.

@smuravev @FreakTheMighty @Kelmatou Please check the latest version (1.0.6). I've reduced the size of the static lib and it was uploaded without usage of git-lfs.

Ok so, I've clone master, run cmd+B on scheme AssetImportKit-iOS and still the error
ld warning: ignoring file
/Users/antoineclop/Downloads/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libIrrXML-iOS.a,
file was built for unsupported file format ( 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E 0x20 0x68 0x74 0x74 0x70 0x73 0x3A 0x2F 0x2F )
which is not the architecture being linked (armv7):
/Users/antoineclop/Downloads/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libIrrXML-iOS.a

ld warning: ignoring file
/Users/antoineclop/Downloads/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a,
file was built for unsupported file format ( 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E 0x20 0x68 0x74 0x74 0x70 0x73 0x3A 0x2F 0x2F )
which is not the architecture being linked (armv7):
/Users/antoineclop/Downloads/AssetImportKit/AssetImportKit/AssetImportKit/Dependencies/Assimp/lib/iOS/libassimp-iOS.a

I don't think this is related to git-lfs since static lib is present, but it does not contain symbols for targeted architecture (I've tried with generic iOS device and simulator)
By the way the size of libassimp-iOS.a is 65.1 MB and libIrrXML-iOS.a is 288 KB

@eugenebokhan maybe use prebuild script on pod (s.prepare_command) , which will compile assimp? For iOS 11 and 12 , we need fat binary for 3 archs: (arm64, arm64e, x86_64). I have built fbx-only assimp , and fat binary is 150 mb.
Also if you don't won't to compile assimp on pod install , we can use lipo on s.prepare_command , it works so fast , this will help us to have up to 100 mb for each platform


Azure.Core API Cleanup

I took a look at the most recent Azure.Core and here are some API cleanup suggestions:

[ ] HttpPipelineUrlBuilder shoiuld be moved to Azure.Core namespace. The root namespace should contain types that are used by SDK users. Azure.Core is for people implementing SDK clients. The exception to the rule is probably Request, as it needs to be in the same namespace as response (for parity).
[ ]  HttpPipelineUrlBuilder: would the two append methods be better as extensions on UriBuilder?
[ ] Why is UriBuilder a property of the Request? If we want it to simply be a mutable URL, maybe we should just call it Url (the type and property)
[ ] Might be better to move AzureSdkClientLibraryAttribute to Azure.Core namespace. I don't think it's worth having a namespace for one type.
[ ] I think HttpHeader should be in Azure.Core namespace. Some APIs there use it.
[ ] Why do we need HttpPipelineMethodConverter to be public?

HttpPipelineUrlBuilder shoiuld be moved to Azure.Core namespace. The root namespace should contain types that are used by SDK users. Azure.Core is for people implementing SDK clients. The exception to the rule is probably Request, as it needs to be in the same namespace as response (for parity).

Will do.

HttpPipelineUrlBuilder: would the two append methods be better as extensions on UriBuilder?

No, having a type allows us to optimize string allocations a lot, extension methods do not allow us to do the same.

Why is UriBuilder a property of the Request? If we want it to simply be a mutable URL, maybe we should just call it Url (the type and property)

I don't have a strong opinion about this but Url feels like a very generic type name to take especially considering almost no one has to instantiate it.

Might be better to move AzureSdkClientLibraryAttribute to Azure.Core namespace. I don't think it's worth having a namespace for one type.

Will do

I think HttpHeader should be in Azure.Core namespace. Some APIs there use it.

SDK users might use it too, it's very similar to Request/Response.

Why do we need HttpPipelineMethodConverter to be public?

Used in AppConfig auth policy.

HttpPipelineUrlBuilder shoiuld be moved to Azure.Core namespace. The root namespace should contain types that are used by SDK users. Azure.Core is for people implementing SDK clients. The exception to the rule is probably Request, as it needs to be in the same namespace as response (for parity).

Will do.

HttpPipelineUrlBuilder: would the two append methods be better as extensions on UriBuilder?

No, having a type allows us to optimize string allocations a lot, extension methods do not allow us to do the same.

Why is UriBuilder a property of the Request? If we want it to simply be a mutable URL, maybe we should just call it Url (the type and property)

I don't have a strong opinion about this but Url feels like a very generic type name to take especially considering almost no one has to instantiate it.

Might be better to move AzureSdkClientLibraryAttribute to Azure.Core namespace. I don't think it's worth having a namespace for one type.

Will do

I think HttpHeader should be in Azure.Core namespace. Some APIs there use it.

SDK users might use it too, it's very similar to Request/Response.

Why do we need HttpPipelineMethodConverter to be public?

Used in AppConfig auth policy.

@KrzysztofCwalina ping


prisma deploy --force flag seems to have no effect

Bug Report
I'm currently bootstrapping a new GraphQL server using Prisma. While developing I have breaking changes that need to be deployed, the existing data can be overwritten.
Current behavior
I use prisma deploy -f to force prisma to deploy the changes even if there are data changes as described here
This produces the exact same amount as if i would have used prisma deploy without flags. I have to remove my existing service and re-deploy it.
Reproduction
Make a breaking change to your datamodel.graphql that leads to errors when using prisma deploy. Then used prisma deploy -f to force the changes.
Expected behavior?
prisma deploy -f just overwrites the existing service regardless of the breaking changes

Can you clarify which change exactly exhibits this behaviour?

Sure!
initial datamodel:
type User {
  id: ID! @unique
  firstname: String!
  lastname: String!
  createdAt: DateTime!
  updatedAt: DateTime!
}

Then I insert a user e.g.
mutation {
  createUser(data: {
    firstname: "Test",
    lastname: "User"}
) {
    id
  }
}

now I want my user to have a gender which is required.
modified datamodel:
type User {
  id: ID! @unique
  firstname: String!
  lastname: String!
  gender: Gender!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Gender {
  id: ID! @unique
  gender: String!
  createdAt: DateTime!
  updatedAt: DateTime!
}

If I run prisma deploy now it displays
Deploying service `default` to stage `default` to server `local` 21ms

Errors:

  User
    ✖ You are creating a required relation, but there are already nodes that would violate that constraint.

I expected this output and use prisma deploy -f to just override my existing user. The result is the same as shown above, the deployment fails.
Am I misunderstanding the purpose of --force?

Ah ok, that's interesting!
I think it is justified that --force doesn't work in this situation, because here it would lead to an inconsistent schema - after the deployment, the service schema + data wouldn't be valid because a user with null as Gender exists.
I already suggested an improvement for adding required fields to the schema with existing data here: #2323 🙂
I'll leave this issue open, as we certainly should improve the error message:
If a deployment would result in an inconsistent schema, we should not recommend to use --force.

Alright, changing the error message sounds like a good idea to avoid misunderstanding.
What would be the best solution for my use case when bootstrapping the server and doing inconsistent changes to the schema?
Just deleting the service and re-deploy?

Yep, or migrate existing data to be conformant with the contraints that you are about to introduce.

Still getting this issue. Has anyone solved it?
Warning:
User
! You already have nodes for this model. This change will result in data loss.

Ya, this definitely needs to be resolved. Maybe add a data-loss flag? I imagine there are a lot of people who don't care about losing data if they're doing a force deploy

Yep, or migrate existing data to be conformant with the constraints that you are about to introduce.

Hi how could this be done properly? with a script or with manual mutations?

As I'm just in development, I really don't care about the constraints right now.  I realize that a field needs to be introduced, and it has to be required.....so I have to lose all my test data to put the new field in?  I suppose I can introduce it as not required, then populate the data, then require it...

If you're using prisma with docker. You can always just delete the volumes which will destroy your database.
E.g. docker-compose down -v.
Then running prisma deploy should generate the new schema for you without any errors.


Fix #608

What's this PR do?
Adds context menu to previously ignored letter server icons.
Any background context you want to provide?
#608 and #599 should help understand the issue. Just a simple context menu addition.
You have tested this PR on:

[x] Windows
[x] Linux/Ubuntu
[ ] macOS

P. S. My Sublime Text plugin changed the formatting of the code a bit. Please let me know if that's a problem for Zulip.

Can you take care of the linting first? Also, push changes related to this fix only.

Of course.

Push changes related to this fix only.

Sorry. I'll keep that in mind next time.

I've evidently messed up a lot of stuff in this branch. Sorry about that. Closing this PR in favour of https://github.com/zulip/zulip-electron/pull/619.


New TileMap editor: Can't draw a pattern using 2x2-sized tiles

Godot version
a8fb450
System information
W10
Issue description
I have a tileset with some 2x2 tiles

Seems like they still use 1x1 grid and I can't draw a pattern properly. Instead of this

I get this

Steps to reproduce

Have a TileSet with some bigger tiles
Select the big tiles and enable "Place Random Tile" option
Try drawing a rectangle/line

Minimal reproduction project
ReproductionProject.zip

But if I select 4 tiles at once, I can't draw random patterns. I want the big tiles to be selected randomly.

Ah yeah. This requires another feature then, randomly drawing TileMap patterns is not supported.
We discussed with reduz the possibility to create a pattern palette, where you could store patterns to paint.
Having probabilistic painting there could work. But that might be a difficult problem to solve, as patterns may have different size and shapes.
For now, you can either try to use big tiles and erase one column/row out of two (you may want to change the texture_origin property to align them to grid though), or you do without randomization.
I guess you could make an editor plugin too, there's already a TileMapPattern class to help with patterns that should be exposed. It might simplify the work.

I worked it around with a script that goes through used cells and randomizes the patterns. That's enough for me, so if the issue is not going to be resolved then it's fine to close it.

I'll work on TileMap patterns soon, I'll see if such a feature is easy to implement or not.
If so, I see no problem in adding it.


callOnce run multiple times in client-only components

Environment

Operating System: Linux
Node Version:     v18.18.0
Nuxt Version:     3.9.3
CLI Version:      3.10.0
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/github-6wtgz2?file=app.vue
Describe the bug
The reproduction contains a client-only component. This component calls callOnce on setup.
The problem is when multiple instances are rendered the callbacks of callOnce are all executed.
I'm not sure if this is intentional or an issue with reactivity.
Additional context
No response
Logs
No response

What would be the expected behavior? That the callOnce just run once (in the first component) because the key is the same for all instances?

Yes I think that.

If you return a non-nullish value that should work. e.g.
await callOnce('key-1', () => {
  called.value = true;
  return 1
});

If you return a non-nullish value that should work. e.g.

Unfortunately this didn't solve the issue. After debgging this seems to be related to the await executed before registering the callOnce's key.
https://github.com/nuxt/nuxt/blob/44fcacba846a6cdf33e1475fc8413f6ae49d1fe4/packages/nuxt/src/app/composables/once.ts#L29

I faced this issue in a project I'm working on. The return value didn't solve the issue in contrast to the await fix. Maybe I should make another reproduction. This issue is simple, I will create a PR for this with test.

I misplaced return 1 previously, I'm sorry for that. Your solution works perfectly!


Proposal: Removing Sig with overlapping instances.

Sig arises because we might have different instance implementations for e.g.
instance (KnownNat n, Prime p)
  => MultiplicativeSemigroup (UInt n (Zp p))

instance (KnownNat n, PrimeField a)
  => MultiplicativeSemigroup (UInt n (ArithmeticCircuit i Par1 a))

instance PrimeField a
  => MultiplicativeSemigroup (ArithmeticCircuit i (UInt n) a)

We can fix this situation by using overlapping instances like so:
instance {-# OVERLAPPABLE #-} (KnownNat n, SymbolicField a)
  => MultiplicativeSemigroup (UInt n a)

instance {-# OVERLAPPING #-} (KnownNat n, PrimeField a)
  => MultiplicativeSemigroup (UInt n (ArithmeticCircuit i Par1 a))

instance (KnownNat n, PrimeField a)
  => MultiplicativeSemigroup (ArithmeticCircuit i (UInt n) a)

-- single circuit (*)
timesUInt
  :: (KnownNat n, PrimeField a)
  => ArithmeticCircuit (UInt n :*: UInt n :*: i) (UInt n) a

Sig is no longer needed if we can generalize Zp p to SymbolicField.
When the field is a circuit space, the instance will resolve
to this more specific case, which in turn will wrap the optimized
single-circuit computation with desolder/solder.
Rewrite rules can be used to fuse away solder/desolder compositions,
so that e.g. compile (*) gets rewritten to timesUInt (hopefully).
User code won't need to include Sig in the context, only SymbolicField.
I conjecture that all the instances we need for Sig can be resolved,
that is generalized from Zp p to SymbolicFields.

For functions that we don't have or want to create a type class for, we can use the {-# SPECIALISE #-} pragma. If we are clever about using {-# SPECIALIZE #-}, {-# INLINE #-} and {-# REWRITE #-}, I believe we can accomplish performance and cleanliness.

Now that I properly understood the proposed solution, I have a question.
Suppose there is a function f :: SymbolicField a => UInt n a -> Bool a which uses the * as defined above. Wouldn't the instance resolution always resolve to the first instance? Otherwise it should error out and force the user to defer the instance resolution, hence the Sig problem.

The instance resolves to the more specific instances (the non-error instances). See documentation

An example I tried to cook up:
{-# OPTIONS_GHC -Wno-redundant-constraints #-}

module ZkFold.Symbolic.Data.Example where

import ZkFold.Base.Algebra.Basic.Class
import GHC.TypeLits (KnownNat)
import ZkFold.Base.Algebra.Basic.Field (Zp)
import ZkFold.Symbolic.Compiler (Arithmetic, ArithmeticCircuit)
import GHC.Generics (Par1)
import GHC.IO (unsafePerformIO)
import Data.Functor (($>))
import System.IO (putStrLn)

data Example a = None

instance {-# OVERLAPPABLE #-} FiniteField a => AdditiveSemigroup (Example a) where
  _ + _ = unsafePerformIO (putStrLn "finite field instance" $> None)

instance {-# OVERLAPPING #-} KnownNat p => AdditiveSemigroup (Example (Zp p)) where
  _ + _ = unsafePerformIO (putStrLn "zp field instance" $> None)

instance {-# OVERLAPPING #-} Arithmetic a => AdditiveSemigroup (Example (ArithmeticCircuit a Par1)) where
  _ + _ = unsafePerformIO (putStrLn "arithmetic field instance" $> None)

add :: FiniteField a => Example a
add = None + None

This throws the following error on usage of + in add:
• Overlapping instances for AdditiveSemigroup (Example a)
    arising from a use of ‘+’
  Matching instance:
    instance [overlappable] FiniteField a =>
                            AdditiveSemigroup (Example a)
      -- Defined at /home/turtle/zkfold-base/src/ZkFold/Symbolic/Data/Example.hs:16:31
  Potentially matching instances:
    instance [overlapping] KnownNat p =>
                           AdditiveSemigroup (Example (Zp p))
      -- Defined at /home/turtle/zkfold-base/src/ZkFold/Symbolic/Data/Example.hs:19:30
    instance [overlapping] Arithmetic a =>
                           AdditiveSemigroup (Example (ArithmeticCircuit a Par1))
      -- Defined at /home/turtle/zkfold-base/src/ZkFold/Symbolic/Data/Example.hs:22:30
  (The choice depends on the instantiation of ‘a’
   To pick the first instance above, use IncoherentInstances
   when compiling the other instance declarations)
• In the expression: None + None
  In an equation for ‘add’: add = None + None (typecheck -Wdeferred-type-errors)

Basically the same error because of which we had to introduce Scale a a in multiple places: until all variables are instantiated, instance resolution might cause incoherence so GHC tries to be conservative in order to be coherent; thus we have to defer the instance resolution to the caller of a generic function.

You can use incoherent instances if you really want that example to compile but it's not a more specific example and does not really illustrate what I'm proposing.

It still doesn't compile with incoherent instances, sadly

does not really illustrate what I'm proposing
What would be an illustrative example?

If I understood @TurtlePU correctly, we could reduce Sig to Symbolic c, where c is the context (a circuit or a structure like Vector). I think it may be good enough for now.

Proposal doesn't seem to work bc GHC cannot defer the instance resolution.


wiki.qatools.re not reachable

The website http://wiki.qatools.ru/display/AL/Allure+Commandline won't load.
It's been giving me a 504 Gateway Timeout - Error since last week.

Please make your wiki reachable!

all the docs moved to docs.qameta.io/allure/2.0/ .
PS README updated


Play from position in Safari 15

Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
3.1.1
Please ask your question
We've noticed a change in behaviour from Safari 14 to Safari 15 regarding playback position.
We have a use case with a dynamic manifest for an ongoing recording, with a seekable range, that we want to play from the start of the seekable range (startover). Shaka (Safari) defaults to playing this from the live edge, since it is an ongoing recording, so our previous solution was to listen to the canplay-event, and programmatically set videoElement.currentTime to 0.
This no longer works in Safari 15.
As a workaround our current best solution is to listen for the durationchange-event and set up a setInterval which checks for an update to videoElement.currentTime (it will be 0 for a while, and eventually be set to what the live position is in the ongoing recording) - after we have the updated currentTime, we will do a seek to 0 by setting videoElement.currentTime to 0.
This works about 80% of the time, the other times there is no seek, and the stream continues playing from the live point.
Part two of this question, somewhat related, is that we have another scenario, in which we have a live channel with a DVR window. When we play such a channel, we want to play from the live edge. on Safari 14 we could set a currentTime of Infinity but in Safari 15 this causes the stream to play from the beginning of the DVR window. We currently have a workaround for this by setting currentTime to 0 in this case, which seems to solve the issue, and the stream plays from the live edge.
To summarize:
We're seeing the opposite of the expected behaviour going from Safari 14 to Safari 15
live streams with DVR window play from the beginning when the should play from the live edge
ongoing recordings play from the live edge when they should play from the beginning.
We understand that shaka hands over the controls to Safari when using native HLS playback, but thought you might have some insights into what is happening in this situation.
The manifests in question:
Live channel with DVR window, solved in safari 15 by setting currentTime to 0 instead of Infinity
Live channel with DVR window
Dynamic manifest for ongoing recording, in Safari 14 we could wait for the canplay event and set currentTime to 0, same fix does not work in Safari 15.
Dynamic manifest for ongoing recording

We will see if we can configure the manifest with #EXT-X-START to indicate where the stream should start, perhaps we won't need any workarounds.


Update allowed MQTT channel regex

Coverage remained the same at 92.079% when pulling ec584674fbefc0c40f9d0d57e8d67731e7a48c60 on RickCarlino:mqtt_updates into 60111d0ce255dad0e7373f32ed30043450937757 on FarmBot:staging.


Upgrade 4.5 (4.5.0-0.okd-2020-10-15-235428)  to 4.6 (4.6.0-0.okd-2021-01-23-132511)

Discussed in https://github.com/openshift/okd/discussions/927

Originally posted by jamallorock October 18, 2021
Hello,
Tried updating the development cluster from 4.5.0-0.okd-2020-10-15-235428  to 4.6.0-0.okd-2021-01-23-132511. The entire update was successful (upgrade of FCOS and K8S versions), but two operators are degraded : authentication and console. The logs of the pod and services show that:

E1017 19:32:11.522398 1 reflector.go:127] github.com/openshift/router/pkg/router/controller/factory/factory.go:125: Failed to watch *v1.Route: failed to list *v1.Route: the server is currently unable to handle the request (get routes.route.openshift.io)
E1017 19:32:44.542298 1 reflector.go:127] github.com/openshift/router/pkg/router/controller/factory/factory.go:125: Failed to watch *v1.Route: the server is currently unable to handle the request (get routes.route.openshift.io)

I1017 19:23:40.140208 1 named_certificates.go:53] loaded SNI cert [0/"self-signed loopback"]: "apiserver-loopback-client@1634498619" [serving] validServingFor=[apiserver-loopback-client] issuer="apiserver-loopback-client-ca@1634498618" (2021-10-17 18:23:38 +0000 UTC to 2022-10-17 18:23:38 +0000 UTC (now=2021-10-17 19:23:40.140201639 +0000 UTC))
I1017 19:24:11.437171 1 client.go:360] parsed scheme: "passthrough"
I1017 19:24:11.437204 1 passthrough.go:48] ccResolverWrapper: sending update to cc: {[{https://<IP_ADDRESS>:2379 <nil> 0 <nil>}] <nil> <nil>}
I1017 19:24:11.437211 1 clientconn.go:948] ClientConn switching balancer to "pick_first"
I1017 19:24:11.437428 1 balancer_conn_wrappers.go:78] pickfirstBalancer: HandleSubConnStateChange: 0xc001fda290, {CONNECTING <nil>}
I1017 19:24:11.450083 1 balancer_conn_wrappers.go:78] pickfirstBalancer: HandleSubConnStateChange: 0xc001fda290, {READY <nil>}
I1017 19:24:11.452452 1 controlbuf.go:508] transport: loopyWriter.run returning. connection error: desc = "transport is closing"
I1017 19:24:13.306465 1 client.go:360] parsed scheme: "passthrough"

Message: OAuthRouteCheckEndpointAccessibleControllerAvailable: Get "https://oauth-openshift.apps.okdd.domain/healthz": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
APIServicesAvailable: "user.openshift.io.v1" is not ready: 503 (the server is currently unable to handle the request)
OAuthVersionRouteAvailable: HTTP request to "https://oauth-openshift.apps.okdd.domain/healthz" failed: net/http: TLS handshake timeout
Reason: APIServices_Error::OAuthRouteCheckEndpointAccessibleController_EndpointUnavailable::OAuthVersionRoute_RequestFailed

I found related bug : https://access.redhat.com/solutions/5460731, but I was able to do such an update on the test cluster (same OKD builds).
Have any of you met and solved a similar problem?

Lets first sort it out in Discussion

Ok. From specific must gather logs, only the above can be indicated.no other clue


helm lint: This needs a lot of love

helm lint needs the following:

The Chart yaml file should be checked for conformance to the spec

The version field should be parsed with github.com/Masterminds/semver to verify correctness

The values.toml file should (if present) be tested for parseability
The template testing should go through the actual template library

@migmartri and I have been looking into the existing linters in Helm Classic and the chart format docs to get a list of lint rules we can add to Kube Helm.

Chartfile

Chart Name and directory name are the same (E) (#782)
Engine is a supported template engine (E) - this currently isn't part of the Chartfile struct, so we can skip this rule for now
Email is a valid email address (W)
Source and Home are valid URLs (W)

Templates

File names are of the form foo-{kind shortname}.yaml (e.g. cassandra-rc.yaml) (E)
Templates are valid yaml after generating (E)
Required metadata is present and valid

Name, Kind, etc. (E)
Labels: provider, app, heritage (W)

Replication controllers are using a tagged image version (W)
ENV vars are quoted in the compiled templates (W)

Values

Defined values are referenced in the template (W)
Any namespaces have a corresponding dependency fetched under /charts (W)

@technosophos @michelleN: would be great to get your feedback on these.
We may also want to add linter rules for some of the requirements we've defined in our manifest authoring guide, if you're open to that.

After our our discussions we agreed on the implementation of some of the rules pasted above.
In this issue we will tackle only the rules that will prevent the chart to work as expected, in other words, any rule that must raise an error.
There will be another issue to discuss the rules for warning error and suggestions.
General

[ ] Add rules directory
[ ] Rename info into suggestion

Rules
Chart linting (chartfile.go)

[ ] Check that the name of the chart and the directory name are the same.
[ ] Validate that the version is bigger than 0.0.0 using semver comparison instead of string comparison.
[ ] Version is quoted. Semver Build component error might break it

For every element in the charts.yml:

[ ] Validate that it contains a valid object type, for example
[ ] Engine is one of the valid values.
[ ] Each maintainer contains a name
[ ] Email has email format
[ ] Source and home are URL’s (if provided)

Template linting (template.go)

[ ] Validate that the file is a proper yaml file. Currently it just checks that it is go-template parseable. (keep using for client side rendering for now, text/template)
[ ] Environment variable values should be quoted in the compiled templates. @sameersbn, could you elaborate regarding the issue you run into and if it is still a problem?

Yml values linter (values.yaml)

[ ] It is a valid YAML file

Environment variable values should be quoted in the compiled templates. @sameersbn, could you elaborate regarding the issue you run into and if it is still a problem?

kubectl (linter i believe) expects values of environment variables to be specified as strings. If the value of an environment variable begins with a number or has a truth value (yes/no or true/false), YAML will will interpret these as numbers or boolean values respectively which will cause the kubectl linter to throw errors and fail.
For example, any of the following snippets in a manifest file would cause a deployment to fail.
        env:
        - name: MYSQL_PASSWORD
          value: 4ZxK4XBGDVxQHsFw

       env:
        - name: PICK_A_NUMBER
          value: 3306

        env:
        - name: DOES_IT_BLEND
          value: yes

In my experience I found that its just a better practice to always use quotes around values for environment variables.

Will verify it again

Tested, kubectl create fails with errors such as unable to decode "mariadb-rc.yaml": [pos 505]: json: expect char '"' but got char '3'

I actually just ran into a similar, possibly related, issue when I used foo: yes (wanting the string "yes") and got the value foo = true after parsing. That sort of thing would also happen with env vars. So I can see what @sameersbn is talking about here.

Removing this from Alpha.2 because #833 covered the basics of lint for Alpha.2

I am closing this because all of the tasks are complete for Alpha.3. Any additions to helm lint should be filed as separate issues. 🎉


[issue 823] Avoid sending mention DM notifications for comment updates #823

avoid sending notification for update of comments
ticket here
Fixes #823

Hello @sibasankarnayak,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

I think the fix here is just to remove this line:
https://github.com/mattermost/mattermost-plugin-jira/blob/268b3e4f18b67fbe5f9c1d85b2054d50fba3ecd0/server/webhook_parser.go#L349

The PR is currently affecting how the subscriptions feature works, which we want to avoid changing here

Codecov Report

Merging #824 (b1b99ef) into master (268b3e4) will increase coverage by 0.01%.
The diff coverage is 100.00%.

:exclamation: Current head b1b99ef differs from pull request most recent head dea2f0e. Consider uploading reports for the commit dea2f0e to get more accurate results

@@            Coverage Diff             @@
##           master     #824      +/-   ##
==========================================
+ Coverage   34.86%   34.87%   +0.01%
==========================================
  Files          52       52
  Lines        5943     5944       +1
==========================================
+ Hits         2072     2073       +1
  Misses       3660     3660
  Partials      211      211

Impacted Files
Coverage Δ

server/subscribe.go
67.16% <100.00%> (+0.06%)
:arrow_up:

Continue to review full report at Codecov.

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

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @BenLloydPearson @aspleenic

@mickmister Are you fine with merging this PR?


Small typo in readme

written and Go. should be probably written in Go.

Thanks, fixed in<PHONE_NUMBER>c40572be8f6860714f17d5cb870a33


feat(lhs): add register handler

Registers Light House Handler.
Most recent spacecat-dev run, produced an audit for bamboohr.com this appears in our database; showing this was successful :)

Thanks for contributing!

:tada: This PR is included in version 1.10.0 :tada:
The release is available on:

v1.10.0
GitHub release

Your semantic-release bot :package::rocket:


Updated Portuguese (Portugal) translation

Added the missing translation for the new dictionaries.
Reviewed the whole translation file to ensure consistency on formality (tu vs você). For this I've removed the personal pronouns where possible (instead of edit your content -> edit the content) to avoid formality statements. When required, I've used (mostly) the informal pose.

Perfect, thank you


Update Russian and Ukrainian translations

Coverage remained the same at 59.34% when pulling 232d67b2aa45bf91e149770002bc483f4bea2261 on feature/update-ru-uk-po into 1dc0f24786a02a44406f62799ce89e451f99848b on master.


RFM - spicetify-cli

I DON'T Want To Become The Maintainer

[x] I have followed the Package Triage Process and I do NOT want to become maintainer of the package;
[x] There is no existing open maintainer request for this package;

Checklist

[x] Issue title starts with 'RFM - '

Existing Package Details
Package URL: https://chocolatey.org/packages/spicetify-cli
Package source URL: https://github.com/derkalaender/chocolatey-specify-cli
Date the maintainer was contacted (in YYYY-MM-DD): 2021-03-02
How the maintainer was contacted: Contacted him through 'Contact Maintainers' on the package page stating the package is no longer up to date. Have not received a reply.
I contacted the site admins on 2021-03-16 and have also not received a reply.

Hi,
this package is currently out of date, seems to be still abandoned.
If you are looking for a maintainer, I could maintain it.
My chocolatey name is Kubikola

I was added as a maintainer, so I pushed an update that got approved.
This issue can be closed.


Possible Bug: Auto-switching to alphabetic keyboard when space is tapped, locks keyboard switching.

I tested and reviewed your latest commit:
"Auto-switch to alphabetic keyboard when space is tapped in numeric and symbolic keyboards"
https://github.com/KeyboardKit/KeyboardKit/commit/00a6ee97bfbe7346ec8bbf494b3893ace1c618b6
I understand the intention, as most cases will be an alphabetic character after a space.
However, there are cases when a user might want to switch back to numeric and symbolic keyboards or even a custom keyboard, before inputting a character after a space. So I feel it is necessary to allow the user to switch keyboards after an auto-switch to alphabetic keyboard (even if there is still " " suffix only).
At the moment, the only way to switch keyboards after an auto-switch, is to either delete the space, or add a new space/alphabetical character. I don't know if this is a bug or, in my opinion, a bad UX decision.
I also don't know of any way of fixing this personally without forking the repo. In my case, I want the user to be able to freely switch keyboards no matter what characters are inputted, including custom keyboards.
Thank you for your time and keep up the great work!

Hi! I’m not sure I understand the problem you are describing. I think the numeric and symbolic keyboards now behave as the system ones. If you have a scenario where this isn’t true, can you please describe a way for me to replicate it?

Apologizes, I thought about giving you a way to replicate it but I thought I described it well enough and a little bit of edge-case testing will reproduce the issue.
I will explain:

Run the demo app/keyboard
Press the space button
Try pressing the keyboard switch button (ABC).
You will be unable to switch to a new keyboard until the space is either deleted, or a new character is typed.

Here is a screencast/video of the problem in action running on iOS simulator:
https://drive.google.com/file/d/1oAVxXjkoTGd_n6l9AEoMzp81fdJTNNZR/view?usp=sharing
Side notes:

I only tested on simulator, but I assume its the same behavior on device, and looking at the code confirms the issue.
I tested the default keyboard on simulator and don't see the auto-switch feature you are trying to mimic. Maybe it was removed in the latest iOS version or an iPad feature? (I only tested the default keyboard on iPhone simulator)

Great catch, thank you! I will fix it asap!

Thank you! Looking forward to the solution.
I embarrassingly uploaded the wrong video. Even after years of working with Mac I still fail to understand some of its standards. If you still need a recording of it in action, I will reupload the right video.

I have fixed this in 4.0.3 👍


Use "\n" for delimiter instead of "," for multiple user-agents

User-agents can contain the string "," which can lead to malformed
user-agents when using split(","). This commit fixes this issue by
changing the delimiter to a newline ("\n").
Fixes #240.

Codecov Report

Merging #241 (fde7249) into master (e81cffe) will decrease coverage by 0.09%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #241      +/-   ##
==========================================
- Coverage   95.66%   95.56%   -0.10%
==========================================
  Files          21       21
  Lines        3113     3113
==========================================
- Hits         2978     2975       -3
- Misses        135      138       +3

Impacted Files
Coverage Δ

trafilatura/downloads.py
95.85% <100.00%> (ø)

trafilatura/core.py
97.05% <0.00%> (-0.56%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

lgtm


Optimise Javascript

Significant optimisations could be done as there are quite a few instances of DRY code. Performance optimisations can also be made, see : https://www.w3schools.com/js/js_performance.asp

Decided it would be best to split this issue into smaller tasks, PR #38  focused on readability, follow up PRs will be created to solve DRY and Performance Optimisations.

Code base now uses ES Modules but significant improvements can still be made (see #49).


running  error

In the danieldzahka/FAM [98c0045] (https://github.com/danieldzahka/FAM/commit/98c0045315be1f101fa11d0fc518a8f39deb6d59), after properly running cmake and make,  some errors occured when executing the commands ./src/server and make test.
the information is as follow:
(DGL) emc_admin@emcsvr01:~/FAM/build$ ./src/server
[2023-02-20 13:28:51.618] [info] Starting Server
[2023-02-20 13:28:51.619] [info] Server listening on <IP_ADDRESS>:50051
E0220 13:28:51.620015625  109190 completion_queue.cc:254]    assertion failed: queue.num_items() == 0
Aborted (core dumped)
(DGL) emc_admin@emcsvr01:~/FAM/build$ make test
Running tests...
Test project /home/emc_admin/FAM/build
      Start  1: unittests.RPC Consruction
 1/59 Test  #1: unittests.RPC Consruction ........................................................................***Failed    0.02 sec
      Start  2: unittests.RPC Consruction Multi-Channel
 2/59 Test  #2: unittests.RPC Consruction Multi-Channel ..........................................................***Failed    0.02 sec
      Start  3: unittests.RPC PING
 3/59 Test  #3: unittests.RPC PING ...............................................................................***Failed    0.01 sec
      Start  4: unittests.RPC Allocate Region
 4/59 Test  #4: unittests.RPC Allocate Region ....................................................................***Failed    0.02 sec
      Start  5: unittests.Client Create rdma Buffer
 5/59 Test  #5: unittests.Client Create rdma Buffer ..............................................................***Failed    0.01 sec
      Start  6: unittests.rdma Write
 6/59 Test  #6: unittests.rdma Write .............................................................................***Failed    0.01 sec
      Start  7: unittests.rdma mmap
 7/59 Test  #7: unittests.rdma mmap ..............................................................................***Failed    0.01 sec
      Start  8: unittests.rdma mmap multi-channel
 8/59 Test  #8: unittests.rdma mmap multi-channel ................................................................***Failed    0.01 sec
      Start  9: unittests.Vector Read Upper Limit of WRs
 9/59 Test  #9: unittests.Vector Read Upper Limit of WRs .........................................................***Failed    0.01 sec
      Start 10: unittests.Test .idx reading
10/59 Test #10: unittests.Test .idx reading ......................................................................   Passed    0.00 sec
      Start 11: unittests.LocalGraph Construction - NopDecompressor, 0
11/59 Test #11: unittests.LocalGraph Construction - NopDecompressor, 0 ...........................................   Passed    0.02 sec
      Start 12: unittests.LocalGraph Construction - famgraph::tools::DeltaDecompressor, 1
12/59 Test #12: unittests.LocalGraph Construction - famgraph::tools::DeltaDecompressor, 1 ........................   Passed    0.01 sec
      Start 13: unittests.RemoteGraph Construction - NopDecompressor, 0
13/59 Test #13: unittests.RemoteGraph Construction - NopDecompressor, 0 ..........................................***Failed    0.01 sec
      Start 14: unittests.RemoteGraph Construction - famgraph::tools::DeltaDecompressor, 1
14/59 Test #14: unittests.RemoteGraph Construction - famgraph::tools::DeltaDecompressor, 1 .......................***Failed    0.02 sec
      Start 15: unittests.LocalGraph Vertex Table - NopDecompressor, 0
15/59 Test #15: unittests.LocalGraph Vertex Table - NopDecompressor, 0 ...........................................   Passed    0.01 sec
      Start 16: unittests.LocalGraph Vertex Table - famgraph::tools::DeltaDecompressor, 1
16/59 Test #16: unittests.LocalGraph Vertex Table - famgraph::tools::DeltaDecompressor, 1 ........................   Passed    0.01 sec
      Start 17: unittests.Vertex Filter
17/59 Test #17: unittests.Vertex Filter ..........................................................................   Passed    0.06 sec
      Start 18: unittests.Local Filter Edgemap - NopDecompressor, 0
18/59 Test #18: unittests.Local Filter Edgemap - NopDecompressor, 0 ..............................................   Passed    0.03 sec
      Start 19: unittests.Local Filter Edgemap - famgraph::tools::DeltaDecompressor, 1
19/59 Test #19: unittests.Local Filter Edgemap - famgraph::tools::DeltaDecompressor, 1 ...........................   Passed    0.03 sec
      Start 20: unittests.Local Filter Edgemap with Ranges - NopDecompressor, 0
20/59 Test #20: unittests.Local Filter Edgemap with Ranges - NopDecompressor, 0 ..................................   Passed    0.02 sec
      Start 21: unittests.Local Filter Edgemap with Ranges - famgraph::tools::DeltaDecompressor, 1
21/59 Test #21: unittests.Local Filter Edgemap with Ranges - famgraph::tools::DeltaDecompressor, 1 ...............   Passed    0.03 sec
      Start 22: unittests.Remote Filter Edgemap - NopDecompressor, 0
22/59 Test #22: unittests.Remote Filter Edgemap - NopDecompressor, 0 .............................................***Failed    0.01 sec
      Start 23: unittests.Remote Filter Edgemap - famgraph::tools::DeltaDecompressor, 1
23/59 Test #23: unittests.Remote Filter Edgemap - famgraph::tools::DeltaDecompressor, 1 ..........................***Failed    0.02 sec
      Start 24: unittests.Remote Filter Edgemap with Ranges - NopDecompressor, 0
24/59 Test #24: unittests.Remote Filter Edgemap with Ranges - NopDecompressor, 0 .................................***Failed    0.01 sec
      Start 25: unittests.Remote Filter Edgemap with Ranges - famgraph::tools::DeltaDecompressor, 1
25/59 Test #25: unittests.Remote Filter Edgemap with Ranges - famgraph::tools::DeltaDecompressor, 1 ..............***Failed    0.02 sec
      Start 26: unittests.LocalGraph Breadth First Search - NopDecompressor, 0
26/59 Test #26: unittests.LocalGraph Breadth First Search - NopDecompressor, 0 ...................................   Passed    0.02 sec
      Start 27: unittests.LocalGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1
27/59 Test #27: unittests.LocalGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 ................   Passed    0.02 sec
      Start 28: unittests.RemoteGraph Breadth First Search - NopDecompressor, 0
28/59 Test #28: unittests.RemoteGraph Breadth First Search - NopDecompressor, 0 ..................................***Failed    0.02 sec
      Start 29: unittests.RemoteGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1
29/59 Test #29: unittests.RemoteGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 ...............***Failed    0.02 sec
      Start 30: unittests.LocalGraph Kcore Decomposition - NopDecompressor, 0
30/59 Test #30: unittests.LocalGraph Kcore Decomposition - NopDecompressor, 0 ....................................   Passed    0.03 sec
      Start 31: unittests.LocalGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1
31/59 Test #31: unittests.LocalGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 .................   Passed    0.02 sec
      Start 32: unittests.RemoteGraph Kcore Decomposition - NopDecompressor, 0
32/59 Test #32: unittests.RemoteGraph Kcore Decomposition - NopDecompressor, 0 ...................................***Failed    0.02 sec
      Start 33: unittests.RemoteGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1
33/59 Test #33: unittests.RemoteGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 ................***Failed    0.01 sec
      Start 34: unittests.LocalGraph ConnectedComponents - NopDecompressor, 0
34/59 Test #34: unittests.LocalGraph ConnectedComponents - NopDecompressor, 0 ....................................   Passed    0.01 sec
      Start 35: unittests.LocalGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1
35/59 Test #35: unittests.LocalGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 .................   Passed    0.01 sec
      Start 36: unittests.RemoteGraph ConnectedComponents - NopDecompressor, 0
36/59 Test #36: unittests.RemoteGraph ConnectedComponents - NopDecompressor, 0 ...................................***Failed    0.02 sec
      Start 37: unittests.RemoteGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1
37/59 Test #37: unittests.RemoteGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 ................***Failed    0.02 sec
      Start 38: unittests.LocalGraph PageRank - NopDecompressor, 0
38/59 Test #38: unittests.LocalGraph PageRank - NopDecompressor, 0 ...............................................   Passed    0.02 sec
      Start 39: unittests.LocalGraph PageRank - famgraph::tools::DeltaDecompressor, 1
39/59 Test #39: unittests.LocalGraph PageRank - famgraph::tools::DeltaDecompressor, 1 ............................   Passed    0.02 sec
      Start 40: unittests.RemoteGraph PageRank - NopDecompressor, 0
40/59 Test #40: unittests.RemoteGraph PageRank - NopDecompressor, 0 ..............................................***Failed    0.01 sec
      Start 41: unittests.RemoteGraph PageRank - famgraph::tools::DeltaDecompressor, 1
41/59 Test #41: unittests.RemoteGraph PageRank - famgraph::tools::DeltaDecompressor, 1 ...........................***Failed    0.02 sec
      Start 42: unittests.Large Graph LocalGraph Breadth First Search - NopDecompressor, 0
42/59 Test #42: unittests.Large Graph LocalGraph Breadth First Search - NopDecompressor, 0 .......................***Failed    0.01 sec
      Start 43: unittests.Large Graph LocalGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1
43/59 Test #43: unittests.Large Graph LocalGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 ....***Failed    0.01 sec
      Start 44: unittests.Large Graph RemoteGraph Breadth First Search - NopDecompressor, 0
44/59 Test #44: unittests.Large Graph RemoteGraph Breadth First Search - NopDecompressor, 0 ......................***Failed    0.02 sec
      Start 45: unittests.Large Graph RemoteGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1
45/59 Test #45: unittests.Large Graph RemoteGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 ...***Failed    0.01 sec
      Start 46: unittests.Large Graph LocalGraph Kcore Decomposition - NopDecompressor, 0
46/59 Test #46: unittests.Large Graph LocalGraph Kcore Decomposition - NopDecompressor, 0 ........................***Failed    0.01 sec
      Start 47: unittests.Large Graph LocalGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1
47/59 Test #47: unittests.Large Graph LocalGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 .....***Failed    0.01 sec
      Start 48: unittests.Large Graph RemoteGraph Kcore Decomposition - NopDecompressor, 0
48/59 Test #48: unittests.Large Graph RemoteGraph Kcore Decomposition - NopDecompressor, 0 .......................***Failed    0.01 sec
      Start 49: unittests.Large Graph RemoteGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1
49/59 Test #49: unittests.Large Graph RemoteGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 ....***Failed    0.01 sec
      Start 50: unittests.Large Graph LocalGraph ConnectedComponents - NopDecompressor, 0
50/59 Test #50: unittests.Large Graph LocalGraph ConnectedComponents - NopDecompressor, 0 ........................***Failed    0.01 sec
      Start 51: unittests.Large Graph LocalGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1
51/59 Test #51: unittests.Large Graph LocalGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 .....***Failed    0.01 sec
      Start 52: unittests.Large Graph RemoteGraph ConnectedComponents - NopDecompressor, 0
52/59 Test #52: unittests.Large Graph RemoteGraph ConnectedComponents - NopDecompressor, 0 .......................***Failed    0.01 sec
      Start 53: unittests.Large Graph RemoteGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1
53/59 Test #53: unittests.Large Graph RemoteGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 ....***Failed    0.01 sec
      Start 54: unittests.Large Graph LocalGraph PageRank - NopDecompressor, 0
54/59 Test #54: unittests.Large Graph LocalGraph PageRank - NopDecompressor, 0 ...................................***Failed    0.01 sec
      Start 55: unittests.Large Graph LocalGraph PageRank - famgraph::tools::DeltaDecompressor, 1
55/59 Test #55: unittests.Large Graph LocalGraph PageRank - famgraph::tools::DeltaDecompressor, 1 ................***Failed    0.01 sec
      Start 56: unittests.Large Graph RemoteGraph PageRank - NopDecompressor, 0
56/59 Test #56: unittests.Large Graph RemoteGraph PageRank - NopDecompressor, 0 ..................................***Failed    0.01 sec
      Start 57: unittests.Large Graph RemoteGraph PageRank - famgraph::tools::DeltaDecompressor, 1
57/59 Test #57: unittests.Large Graph RemoteGraph PageRank - famgraph::tools::DeltaDecompressor, 1 ...............***Failed    0.01 sec
      Start 58: unittests.Pack and Unpack
58/59 Test #58: unittests.Pack and Unpack ........................................................................   Passed    0.02 sec
      Start 59: unittests.Compress Decompress
59/59 Test #59: unittests.Compress Decompress ....................................................................   Passed    0.26 sec

34% tests passed, 39 tests failed out of 59

Total Test time (real) =   1.17 sec

The following tests FAILED:
	  1 - unittests.RPC Consruction (Failed)
	  2 - unittests.RPC Consruction Multi-Channel (Failed)
	  3 - unittests.RPC PING (Failed)
	  4 - unittests.RPC Allocate Region (Failed)
	  5 - unittests.Client Create rdma Buffer (Failed)
	  6 - unittests.rdma Write (Failed)
	  7 - unittests.rdma mmap (Failed)
	  8 - unittests.rdma mmap multi-channel (Failed)
	  9 - unittests.Vector Read Upper Limit of WRs (Failed)
	 13 - unittests.RemoteGraph Construction - NopDecompressor, 0 (Failed)
	 14 - unittests.RemoteGraph Construction - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 22 - unittests.Remote Filter Edgemap - NopDecompressor, 0 (Failed)
	 23 - unittests.Remote Filter Edgemap - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 24 - unittests.Remote Filter Edgemap with Ranges - NopDecompressor, 0 (Failed)
	 25 - unittests.Remote Filter Edgemap with Ranges - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 28 - unittests.RemoteGraph Breadth First Search - NopDecompressor, 0 (Failed)
	 29 - unittests.RemoteGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 32 - unittests.RemoteGraph Kcore Decomposition - NopDecompressor, 0 (Failed)
	 33 - unittests.RemoteGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 36 - unittests.RemoteGraph ConnectedComponents - NopDecompressor, 0 (Failed)
	 37 - unittests.RemoteGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 40 - unittests.RemoteGraph PageRank - NopDecompressor, 0 (Failed)
	 41 - unittests.RemoteGraph PageRank - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 42 - unittests.Large Graph LocalGraph Breadth First Search - NopDecompressor, 0 (Failed)
	 43 - unittests.Large Graph LocalGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 44 - unittests.Large Graph RemoteGraph Breadth First Search - NopDecompressor, 0 (Failed)
	 45 - unittests.Large Graph RemoteGraph Breadth First Search - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 46 - unittests.Large Graph LocalGraph Kcore Decomposition - NopDecompressor, 0 (Failed)
	 47 - unittests.Large Graph LocalGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 48 - unittests.Large Graph RemoteGraph Kcore Decomposition - NopDecompressor, 0 (Failed)
	 49 - unittests.Large Graph RemoteGraph Kcore Decomposition - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 50 - unittests.Large Graph LocalGraph ConnectedComponents - NopDecompressor, 0 (Failed)
	 51 - unittests.Large Graph LocalGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 52 - unittests.Large Graph RemoteGraph ConnectedComponents - NopDecompressor, 0 (Failed)
	 53 - unittests.Large Graph RemoteGraph ConnectedComponents - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 54 - unittests.Large Graph LocalGraph PageRank - NopDecompressor, 0 (Failed)
	 55 - unittests.Large Graph LocalGraph PageRank - famgraph::tools::DeltaDecompressor, 1 (Failed)
	 56 - unittests.Large Graph RemoteGraph PageRank - NopDecompressor, 0 (Failed)
	 57 - unittests.Large Graph RemoteGraph PageRank - famgraph::tools::DeltaDecompressor, 1 (Failed)
Errors while running CTest
Output from these tests are in: /home/emc_admin/FAM/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:71: test] Error 8

My Installation commands are:
mkdir build
cd build
cmake ..
make

tbb 2021.8.0
gcc 7.5.0
cmake 3.25.2
ubuntu 20.04 x86_64
Looking forward to your solution. Thank you @danieldzahka in advance!

The command to launch the server: ./src/server is failing in the log that you provided, hence the line: E0220 13:28:51.620015625  109190 completion_queue.cc:254]    assertion failed: queue.num_items() == 0. This is causing all of the tests that use RDMA to fail, because the server needs to run concurrently with them to perform tasks like registering memory and setting up connected QPs. What type of NIC do you have on the machine where you are running the command?
I would check:

That you have an Infiniband HCA that supports RC transport
That you have permissions to set up RDMA connections.

My machines  are now connected with the Ethernet that supports  Soft-RoCE . rping works well.
I have sudo permission .
My NIC information :

(DGL) emc_admin@emcsvr01:~$ sudo ethtool eno3
Settings for eno3:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: on
	Supports Wake-on: g
	Wake-on: d
	Current message level: 0x000000ff (255)
			       drv probe link timer ifdown ifup rx_err tx_err
	Link detected: yes

The code has only ever been run on InfiniBand HCAs, so I'm not sure if there are any portability issues with ibverbs when running on RoCE. From googling the error message in your output:
E0220 13:28:51.620015625  109190 completion_queue.cc:254]    assertion failed: queue.num_items() == 0

It appears this is an error from gRPC.
Maybe one of these lines is failing from src/FAM/server.cpp
    ServerBuilder builder;
    builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());
    builder.RegisterService(&service_);
    cq_ = builder.AddCompletionQueue();

    server_ = builder.BuildAndStart();


Edit first paragraph

Edit paragraph one to reorganize information and shorten paragraph length.
Remove certain words to shorten paragraph. Condense some sentences too.
Change order of information to (product uses) --> (download formats) --> (visual types and animation support).
Fixes #16

Hey @jwharrie, thanks for the suggestion! We will think it through.


subscribers.get() Does not return groups as documented

The Docs for the NodeJS SDK indicate that the call to subscribers.get() should return the list of group id's on each subscriber:
https://github.com/mailerlite/mailerlite-nodejs/blob/main/src/modules/subscribers/subscribers.module.ts
However, the groups attribute is not contained in the returned subscriber object:

I think this may actually be an issue with the API which also indicates that subscribers should return a list of group id's but does not either:
https://developers.mailerlite.com/docs/subscribers.html#list-all-subscribers

Fix released in 1.2.2


IOjs v1.0.3 not able to load bcrypt module (Windows)

I am unable to load Bcrypt into an IOjs module. On require('bcrypt'), an error is thrown from bindings. The bcrypt module can be loaded in with nodejs v0.10.33 without issue.
Here is a quick rundown of my specs (can provide more info, if necessary):

Windows 7 x64
IOjs v1.0.3 x64
Bcrypt v0.8.1

Bindings v1.0.0
Nan v1.5.0

Visual Studio 2012 (for gyp)

Here is the error message thrown from require('bcrypt'):
D:\Code\Personal\temp\iojs\bcrypt-test\node_modules\bcrypt\node_modules\bindings\bindings.js:79
        throw e
              ^
Error: Module did not self-register.
    at Error (native)
    at Module.load (module.js:341:32)
    at Function.Module._load (module.js:296:12)
    at Module.require (module.js:351:17)
    at require (module.js:370:17)
    at bindings (D:\Code\Personal\temp\iojs\bcrypt-test\node_modules\bcrypt\node_modules\binding\bindings.js:74:15)
    at Object.<anonymous> (D:\Code\Personal\temp\iojs\bcrypt-test\node_modules\bcrypt\bcrypt.js:3:35)
    at Module._compile (module.js:446:26)
    at Object.Module._extensions..js (module.js:464:10)
    at Module.load (module.js:341:32)

Here is the stdout from a node-gyp rebuild call (note: I used the msvs_version=2012 flag to build, but I believe this output looks exactly the same as with previous versions of bcrypt, including the same warnings about possible loss of data):
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
  blowfish.cc
  bcrypt.cc
  bcrypt_node.cc
..\src\bcrypt.cc(232): warning C4267: '=' : conversion from 'size_t' to 'unsigned char', possible loss of data [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
d:\code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\node_modules\nan\nan_implementation_pre_12_inl.h(156): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data (..\src\bcrypt_node.cc) [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
d:\code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\node_modules\nan\nan_implementation_pre_12_inl.h(165): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data (..\src\bcrypt_node.cc) [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
d:\code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\node_modules\nan\nan_implementation_pre_12_inl.h(183): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data (..\src\bcrypt_node.cc) [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
..\src\bcrypt_node.cc(76): warning C4244: 'argument' : conversion from 'ssize_t' to 'unsigned char', possible loss of data [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
..\src\bcrypt_node.cc(137): warning C4244: 'argument' : conversion from 'const ssize_t' to 'unsigned char', possible loss of data [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
..\src\bcrypt_node.cc(231): warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
..\src\bcrypt_node.cc(232): warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
C:\Users\Dave\.node-gyp\0.10.33\deps\v8\include\v8.h(179): warning C4506: no definition for inline function 'v8::Persistent<T> v8::Persistent<T>::New(v8::Handle<T>)' [D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
          with
          [
              T=v8::Object
          ] (..\src\bcrypt_node.cc)
     Creating library D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\Release\bcrypt_lib.lib and object D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\Release\bcrypt_lib.exp
  Generating code
  Finished generating code
  bcrypt_lib.vcxproj -> D:\Code\clubspeed\temp\passwords\iojs\node_modules\bcrypt\build\Release\\bcrypt_lib.node

Same here, mac 10.8.5, bcrypt 0.8.0, iojs 1.0.4.

I think nan needs to be updated to the latest version to fix this but haven't tested yet.

Same issue here for linux mint
Tried to reinstall bcrypt -><EMAIL_ADDRESS>/<EMAIL_ADDRESS>but did not help

I just tried this on my mac (no windows to work with) and all is good. I'm not sure why you'd be seeing these issues. Maybe try starting fresh with bcrypt (remove node modules and rebuild from source) and see if you get the same errors?

I had this issue on my mac with node v0.12.0

+1 Also have this on Windows 8.1, io.js 1.1.0 and bcrypt 0.8.x.
I tried fresh install by deleting node_modules and calling npm install again but same error. I'll try rebooting machine later and let you know if that fixed it.

After upgrading to the new iojs release I removed the node Modules and made a fresh install.
That worked great for me, but only since I made an update to iojs

@xhallix what versions do you use? I tried rebooting and reinstalling but didn't work

I updated to iojs 1.1.0 and using  "bcrypt"  : "0.8.x" in my package.json

Same here, are you using Windows?

No I am running this on linux mint , sorry

Ok np that means it is probably a windows bug?

It might be solved with a newer nan version https://github.com/rvagg/nan/blob/master/CHANGELOG.md
Will test later

I think I found the problem (for my case).
When installing node and io.js side by side things start failing. The way bcrypt is made is it builds for a specific node version.

e.g. node 0.12.0.
When running npm install node-gyp will build for v0.12.0
If you run your app on node v0.12.0 everything is fine
Now you install io.js and bcrypt errors
This is because bcrypt is not build for io.js
you can then rebuild bcrypt and since io.js is tagged as version 1.1.0 node-gyp will automatically choose the highest version and in this case it will be io.js
Now when you want to go back to node it doesn't work anymore because node version is 0.12.0 and is lower than io.js's version and node-gyp tries to build for version 1.1.0 instead of 0.12.0
only solution I can think of is either using io.js or uninstalling io.js


tf.reduce_mean gives incorrect results on CPU

Please make sure that this is a bug. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Arch Linux
TensorFlow installed from (source or binary): Binary
TensorFlow version (use command below): v2.0.0-rc2-26-g64c3d38 2.0.0
Python version: 3.7.4

Current Behavior
The following script:
import tensorflow as tf
import numpy as np

(x_train, _), (_, _) = tf.keras.datasets.cifar10.load_data()
x_train = x_train.astype('float32')

tf_mean = tf.reduce_mean(x_train, axis=[0, 1, 2], keepdims=False)
np_mean = np.mean(x_train, (0,1,2))
print('channel means:')
print('  tf:', tf_mean)
print('  np:', np_mean)

prints:
channel means:
  tf: tf.Tensor([83.88608 83.88608 83.88608], shape=(3,), dtype=float32)
  np: [125.3069  122.95015 113.866  ]

Note: the numpy results are the correct channel-wise means for CIFAR10.
Expected Behavior
Tensorflow and numpy should give at least vaguely similar results.

I have tried on colab with TF version 2.0  and was able to reproduce the issue.Please, find the gist here. Thanks!.

The results of tf.reduce_mean and np.mean are similar if we use axis = None or axis = [0,1,2, 3]. However, results are very different when axis = [0,1,2]. Here is the Gist.

@kazimuth: I believe the problem here is the TensorFlow is doing the computation with 32-bit float values whereas numpy is using 64-bit floating almost all the time. Even if you change np.mean to use dtype=float32, it still seems to perform the calculation with 64-bit float values. If you want the same behavior I suggest you change x_train to use float64 and then cast to float32 in the very end like so:
import tensorflow as tf
import numpy as np

(x_train, _), (_, _) = tf.keras.datasets.cifar10.load_data()
x_train = x_train.astype('float64')

tf_mean = tf.cast(tf.reduce_mean(x_train, axis=[0, 1, 2,], keepdims=False), dtype=tf.float32)
np_mean = np.mean(x_train, (0,1,2), dtype=np.float32)
print('channel means:')
print('  tf:', tf_mean)
print('  np:', np_mean)


Documentation Inconsistency

In Google.PowerShell/PubSub/GcpsMessage.cs, the first and fourth code examples are the same, but their descriptions are different:
PS C:> Get-GcpsMessage -Subscription "my-subscription"
///   This command pulls down one or more messages from the subscription "my-subscription" in the default project.
PS C:> Get-GcpsMessage -Subscription "my-subscription"
///
///   This command pulls down one or more messages from the subscription "my-subscription" in the default project
///   and sends an acknowledgement for each message.
///

This is now updated with https://github.com/GoogleCloudPlatform/google-cloud-powershell/pull/443.


Added Lenovo plugin deployment instructions

Added Lenovo plugin deployment instructions to Getting Started readme

Lenovoplugin ports information is required to be added

Done


Access an Extension from Another Extension

I'm creating a extension where I want to make use of the Assets Extension.
Is there a way to achieve this?
TA!

Perhaps you can extend that extension?

I would like to have all the available functions in the view, available inside my extension class.
I already finished my extension's first version, I simply copy 'n pasted the methods I needed.

@odahcam Aren't you able to access your extension via the engine variable in your extension?
Or do you want to reuse helper methods from one extension to the other?
If helper methods, then you can use traits or any other OO design patterns to share code

Any word @odahcam

I'm little busy now, but I'll test something soon. I wanna use the Assets extension inside my own extension, now I've copy and pasted the Asset extension code into my extension and I really don't wanna this behavior.

I've started on the 4.0 rewrite, this will not be a feature supported by plates. If you want to extend an extension, use decoration (preferred) or inheritance. But plates won't have any mechanisms supporting this except for maybe a doc reference.

I don't wanna extend anything. I want to use an extension inside my extension to do some jobs using that other extension's features, like URL generation, for example: why should i have to write URL generation methods again for each new extension I will create? I Hope you understand what I'm trying to say here. BTW, I can extend anything just using some brain plus OOP logic, there's no reason for creating an issue for that. 😕
Anyway, if you want to explain better what you'r saying with decorator pattern I would appreciate.

@odahcam Few things

I won't be making any updates to the 3.x branch for this, so extensions will stay as is, If you want to reuse or augment the functionality of URI extension for example, you're only real choice is to extend or it just copy the code.
Now, for 4.x you likely will run into this issue as well because it just depends on how the extensions are written. If the extension class encapsulates the URI logic inside itself, then there's nothing you can do, but if it was written in a way that it uses URI helpers, then you could also utilize those helpers. I'll keep reusability in mind for the 4.x extensions for sure, but I'm not going to necessarily cater to allowing every method in an extension be re-usable.


I think it needs an update

Hey, sup I think League of legends has updated the offsets so you gotta make another release with the new Offsets :P

Hey, sup I think League of legends has updated the offsets so you gotta make another release with the new Offsets :P

program still works for me, what do you mean by that?

When I inject the SkinChanger to the game, The game freezez

Never mind, it worked after I redownloaded it. Closed


docs.rs stuck in Chrome and Chromium

when scrolling the docs.rs in Chrome or Chromium, the web page is stuck, I need to switch the tab to another one and then switch back to make the web page become normal
F12 console doesn't have any warn or error, and the browser everything looks good except this web page, yes event 1 docs.rs web page is stuck the other one may use normally

Hi @Sherlock-Holo,
I can't reproduce this issue in chrome on my machine, I would also assume that if this is a bug for everyone, more users would report it.
Which exact page are you trying?
Also, can you try after disabling eventually active extensions?

I'm closing this since we can't reproduce this and don't get answers.
Feel free to reopen this issue if it still happens!

sorry for the delay reply
I try open a new profile Chromium and there is no stuck any more, however when i switch back to the normal profile, it happens again.
I will try to disable the plugin one by one to find out what plugin cause this problem


wide_n_deep tutorial issues

Please help. Running into an issue running the wide_n_deep.py tutorial.
Tensorflow Version:
$ python -c 'import tensorflow as tf; print(tf.version)'  # for Python 2
=> 0.12.1
wide_n_deep_tutorial.py was downloaded from here: https://raw.githubusercontent.com/tensorflow/tensorflow/master/tensorflow/examples/learn/wide_n_deep_tutorial.py)
Command and output
$ python wide_n_deep_tutorial.py --model_type=wide
=>
Training data is downloaded to /var/folders/7y/s1y_wxt93xj5l784mcn2sf380000gn/T/tmpvWXvU2
Test data is downloaded to /var/folders/7y/s1y_wxt93xj5l784mcn2sf380000gn/T/tmpL4LH0x
model directory = /var/folders/7y/s1y_wxt93xj5l784mcn2sf380000gn/T/tmpFbBGZe
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "sum" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "mean" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "mean" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "mean" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "mean" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "mean" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:The default value of combiner will change from "mean" to "sqrtn" after 2016/11/01.
WARNING:tensorflow:From /usr/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/linear.py:446 in fit.: calling fit (from tensorflow.contrib.learn.python.learn.estimators.estimator) with x is deprecated and will be removed after 2016-12-01.
Instructions for updating:
Estimator is decoupled from Scikit Learn interface by moving into
separate class SKCompat. Arguments x, y and batch_size are only
available in the SKCompat class, Estimator will only accept input_fn.
Example conversion:
  est = Estimator(...) -> est = SKCompat(Estimator(...))
WARNING:tensorflow:From /usr/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/linear.py:446 in fit.: calling fit (from tensorflow.contrib.learn.python.learn.estimators.estimator) with y is deprecated and will be removed after 2016-12-01.
Instructions for updating:
Estimator is decoupled from Scikit Learn interface by moving into
separate class SKCompat. Arguments x, y and batch_size are only
available in the SKCompat class, Estimator will only accept input_fn.
Example conversion:
  est = Estimator(...) -> est = SKCompat(Estimator(...))
WARNING:tensorflow:From /usr/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/linear.py:446 in fit.: calling fit (from tensorflow.contrib.learn.python.learn.estimators.estimator) with batch_size is deprecated and will be removed after 2016-12-01.
Instructions for updating:
Estimator is decoupled from Scikit Learn interface by moving into
separate class SKCompat. Arguments x, y and batch_size are only
available in the SKCompat class, Estimator will only accept input_fn.
Example conversion:
  est = Estimator(...) -> est = SKCompat(Estimator(...))
Traceback (most recent call last):
  File "wide_n_deep_tutorial.py", line 208, in <module>
    tf.app.run()
  File "/usr/local/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 43, in run
    sys.exit(main(sys.argv[:1] + flags_passthrough))
  File "wide_n_deep_tutorial.py", line 204, in main
    train_and_eval()
  File "wide_n_deep_tutorial.py", line 197, in train_and_eval
    m.fit(input_fn=lambda: input_fn(df_train), steps=FLAGS.train_steps)
  File "/usr/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/linear.py", line 446, in fit
    max_steps=max_steps)
  File "/usr/local/lib/python2.7/site-packages/tensorflow/python/util/deprecation.py", line 191, in new_func
    return func(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 355, in fit
    max_steps=max_steps)
  File "/usr/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 690, in _train_model
    features, labels = input_fn()
  File "wide_n_deep_tutorial.py", line 197, in <lambda>
    m.fit(input_fn=lambda: input_fn(df_train), steps=FLAGS.train_steps)
  File "wide_n_deep_tutorial.py", line 159, in input_fn
    for k in CATEGORICAL_COLUMNS}
  File "wide_n_deep_tutorial.py", line 159, in <dictcomp>
    for k in CATEGORICAL_COLUMNS}
TypeError: __init__() got an unexpected keyword argument 'dense_shape'

Running on Mac Sierra

Am having the exact same issue #6591 am on Ubuntu 16.04 LTS x64

Try the example on the v0.12 branch.
https://github.com/tensorflow/tensorflow/blob/r0.12/tensorflow/examples/learn/wide_n_deep_tutorial.py
tf.TensorShape has breaking change in master branch (rename argument shape -> dense_shape. see https://groups.google.com/a/tensorflow.org/forum/?utm_medium=email&utm_source=footer#!msg/discuss/OePXmC9kJ7o/SRErOoYCDQAJ for more other API changes), and the examples catch up these changes. So examples in master branch could not work with 0.12 or older TensorFlow runtime.

@nagachika yes I am able to run with the tutorial code from the v0.12 branch. Thanks!


Lazy Load our Iframes

This will drastically increase the performance of the site. try this!
https://github.com/vvo/lazyload

Need to use lazysizes, has nice debg options, and can control through js

Got this working for soundcloud and bandcamp using https://github.com/thenikso/angular-inview

Finished via b0cbedfcafad17b56962f1f35b5c990d8a7e021f
performance is much better


Complete Section Controllers are hidden

New issue checklist

[X] I have reviewed the README and documentation
[X] I have searched existing issues and this is not a duplicate

General information

IGListKit version: newest
iOS version(s): 11.1
Xcode version: 9.1

I'm missing SectionControllers on the initial .reloadData() from the adapter. I know the data has been loaded and I know that the invisible section controller even loaded the to be shown cell. I can even tap the free space and trigger the detail view. But it won't be shown until I scrolled down and up again.
Any ideas why this is happening?

@Narsail can you run the debugger dump and paste the results here?

It seems that the error was triggered by something else and not the IGListKit. Can be closed!

It seems that the error was triggered by something else and not the IGListKit. Can be closed!

What is the reason? Can you tell me? I had a similar problem. Thank you


444 issue fix

Changed path in README.md description from
~/codeforpoznan/pah-fm/pah_behave
to:
~/codeforpoznan/pah-fm/behave_test_automation/pah_behave

That works fine, thanks. Please work a bit on the git flow approach, because this simple change shouldn't require 8 commits. You've probably forgot to checkout from clean develop?


Build failed with Xcode14.3

When I tried to build this project with Xcode 14.3, the build failed.
I think this error occurred because the deployment target was not specified

Fixed in 0.3.2, thank you.


fontWeight is ignored on iOS

Using the default font, changing the font weight has no change on iOS.  FontWeight.w100 is the same as FontWeight.w900 .  Works fine on Android.  Seems that an old bug has been reintroduced:
https://github.com/flutter/flutter/issues/16853

duplicate https://github.com/flutter/flutter/issues/49492

I had the same problem. No changes from w100 to w900 can be observed on iOS.


Images in "Walled Garden" blogpost

I have a branch here: https://github.com/ssddanbrown/owa-website-lfs/tree/walled_garden_images
Within that I have a commit where I've:

Extracted the images from the PDF, renamed, and added them to the repo using Git LFS.
Updated the "Walled Garden" blogpost with added markdown image references to the image files, with custom written descriptive alt text for accessibility.

There's also a few changes due to adding Git LFS support (logo file change and .gitattributes file for identifying LFS files).
I didn't pay attention to much to the formatting at this time. Will likely need some adjusting to fit/arrange images but didn't want to wonder outside a specific scope at this time, especially as much of the styles are yet to be defined. Some of the images may also need a little cleaning up where they might have been masked/cropped in the PDF.
I've opened this issue, rather than offer a PR, due to one of the most annoying limitations with Git LFS: You can't push git LFS files to a public GitHub fork, only those with write access to the original repo can. Public users/forks should still be able to pull these down fine and push (Non-LFS) changes to public forks. Since I don't have write access to this repo I've therefore pushed to a detched-fork repo. This still could be added as a remote locally, merged by someone (with write access) locally then pushed back up here.
If you don't want to go down the LFS path, just let me know the approach you'd want to take and I can change & re-submit things.

@ssddanbrown Thank you for your contributions! I copied all of your commit changes into a new commit. I had no idea there was that limitation for Git LFS and merging commits. I don't think we'll run into that edge case again :)

Happy to help and thanks for including my changes! Will therefore close this off.

I don't think we'll run into that edge case again :)

Might do if someone wants to add images. Guess they could always just provide images separate (Uploaded to issue/PR via GitHub) for a maintainer to merge. Or create a separated fork as I did.
If provided as a separate fork, you should still be able to officially merge that into the main repo locally (Instead of copying files) using git (Add other repo as another origin, fetch branch from that origin, merge) which would keep contribution and authorship information. I'm not fussed in this case but can sometimes be important.

That is a good call @ssddanbrown. I don't have much experience with merging across separate forks using the Git command line, hence my approach. I'll look into this further.

Hi @capjamesg if you add me to the repo I can fix the commit messages locally to reflect proper attribution, and force push them back up. I think it's important commits are properly attributed. If you want to have a go yourself, you want to do an interactive rebase following the instructions here: https://www.sitepoint.com/git-interactive-rebase-guide. You should be able to pluck @ssddanbrown's commit hash into the history, squashing your version of the commit.

I have completed this process here: https://github.com/aliblackwell/owa-website
It is not a fork due to the issue above (I mean it was originally, but I ended up creating a new repo and pushing the cleaned history up).
I am doing some other bits on the project just to get into it (installing eleventyNavigation, putting pages into their own dir and using markdown), I will upload to this repo and then @capjamesg you can give me access to the repo and I'll force push this repo to overwrite what's there. Thanks!

@aliblackwell That would be excellent. I have just given you access to the repository so you can make the requisite changes. I concur that full and proper attribution is critical. I haven't done enough rebasing to feel confident doing it on a repository with enough collaborators, although I feel inspired to set up a test playground to do so with a private repo on my personal account.

Let's leave this issue open until we fix the attribution :)

That is resolved now, I have force pushed and the history has been re-written.
I have had some issues with Git LFS; I had to re-download all the images manually from @ssddanbrown's repository (right click, save) as when I tried to push it said I had some missing references, and when I went to preview the files on my computer, they didn't show any thumbnails. Downloading everything manually made the image thumbs appear again in my Finder application. A git status showed the files as modified, and then when I did git add -A everything went green - there was no need to commit. I was then able to push.
It might be worth doing a bit more testing of the repo (e.g. clone down, fresh install) to ensure the images don't drop out of people's file systems and prevent them from contributing in future. @ssddanbrown  have you encountered anything like this before? I've attached a zip of all the images to this for future reference. Overwriting the images in the repo with these and then running git add -A has fixed it for me twice. But be good to know it just worked!
walled-gardens.zip

I had to re-download all the images manually from @ssddanbrown's repository (right click, save) as when I tried to push it said I had some missing references
@ssddanbrown have you encountered anything like this before?

Sounds like you just had the pointers to the files, as if git-lfs had not pulled down the files yet.
Can sometimes occur, maybe if lfs is not setup or if you have the repo from before lfs was used.
Think you should be able to use git lfs pull in these scenarios to tell LFS to ensure the require large files are present.
I did just do a quick test of cloning the repo down fresh and that seemed to work as desired, with the images provided, just on the git clone.

I think the workflow and maybe any troubleshooting relevant information for this should be documented since i'm not sure what if any the system requirements are like for using git-lfs or how common it may be for others to already have it setup on their machines.
For example, having just cloned the repo, I am getting this message on macOS.
% git clone git@github.com:OpenWebAdvocacy/website.git
Cloning into 'website'...
remote: Enumerating objects: 220, done.
remote: Counting objects: 100% (220/220), done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 220 (delta 67), reused 220 (delta 67), pack-reused 0
Receiving objects: 100% (220/220), 8.66 MiB | 13.54 MiB/s, done.
Resolving deltas: 100% (67/67), done.
git-lfs filter-process: git-lfs: command not found
fatal: the remote end hung up unexpectedly
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

I'm sure I will be able to figure out pretty quickly and then as I work on #4 I can be sure to capture any info I gathered and from this conversation here in a CONTRIBUTING.md for the repo.  Just something to keep in mind when adding custom workflow steps to a project on behalf of first time contributors, tracking and documenting our steps will be a good habit.

Since the original work has been merged with attribution I'll close this off now.
I've opened PR #13 to expand upon, and provide clarity, with regard to git-lfs.