fixed guest authors loading

Issue
First, I had like to thank you for the great plugin!
I found a bug in the co-authors-plus integration. For instance, the code below displays only co-authors using a Wordpress account but it doesn't show guest-authors.
{% for author in post.authors %}
    {{ author.name }}
{% endfor %}

It seems that the User class fails to create init its fields when created from a guest-author.
Solution
Create a CoAuthorsPlusUser class which extends Timber\User, and make CoAuthorsPlus decide which User class to represent each author.
Considerations
As guest-authors may have a linked account and can have use a featured image as an avatar, I added options to rule co-authors-plus integration.
// guest-author information is loaded from user if he exists
Timber\Integrations\CoAuthorsPlus::prefer_gravatar = false;
 //edit: Use instead
 //global $coathors_plus
 // $coathors_plus->force_guest_authors = true;

// guest-author gravatar takes precedence to its featured image
Timber\Integrations\CoAuthorsPlus::prefer_gravatar = true;

Testing
I manually tested to dump post.authors in single.twig for those situations:

normal author: dumps an User object
guest author not having linked account: dumps a Timber\Integrations\CoAuthorsPlusUser
guest author having linked account:
- prefer_guur == false: dumps a Timber\User
- prefer_user == true: dumps a Timber\Integrations\CoAuthorsPlusUser
guest author having featured image:
- prefer_gravatar == false && have_featured_image:  author.avatar displays the image image
- prefer_gravatar == true  && have_featured_image: author.avatar displays a gravatar image
- prefer_gravatar == true  && !have_featured_image: author.avatar displays a gravatar image

Coverage decreased (-0.03%) to 95.193% when pulling df48e25fc255039fa7261832a1e2a10cc1ce8a2a on motia:fix_coauthor_integration into 19c58fd0926fa1ce1ed264d58b0e0b082f4dad11 on timber:master.

Current coverage is 95.51% (diff: 66.66%)

Merging #1239 into master will decrease coverage by 0.02%

@@             master      #1239   diff @@
==========================================
  Files            43         43
  Lines          3184       3186     +2
  Methods         424        424
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           3042       3043     +1
- Misses          142        143     +1
  Partials          0          0

Powered by Codecov. Last update 19c58fd...df48e25

Coverage decreased (-0.03%) to 95.193% when pulling d5b49c757bfb0e45a3da709c58f7d126ed7c5155 on motia:fix_coauthor_integration into 19c58fd0926fa1ce1ed264d58b0e0b082f4dad11 on timber:master.

Coverage decreased (-0.007%) to 95.218% when pulling 8da3c5ce129c3f46a64e9fc7f5443feb1c2efb58 on motia:fix_coauthor_integration into 19c58fd0926fa1ce1ed264d58b0e0b082f4dad11 on timber:master.

Coverage increased (+0.03%) to 95.253% when pulling d79de553e521ddac21982251a23cf4dd1caf2361 on motia:fix_coauthor_integration into 19c58fd0926fa1ce1ed264d58b0e0b082f4dad11 on timber:master.

Coverage increased (+0.03%) to 95.253% when pulling 1cbd8dd8493d6ba984778db1a9ab421bdd53754f on motia:fix_coauthor_integration into 19c58fd0926fa1ce1ed264d58b0e0b082f4dad11 on timber:master.

Coverage increased (+0.03%) to 95.253% when pulling 3b7785fad2bb20b1d4ae8bddf0262603f2b0b123 on motia:fix_coauthor_integration into 11ede67c5d148e5aa28a3a619fccae0b13084a9c on timber:master.

Current coverage is 95.51% (diff: 66.66%)

Merging #1239 into master will decrease coverage by 0.53%

@@             master      #1239   diff @@
==========================================
  Files            43         43
  Lines          3162       3186    +24
  Methods         422        424     +2
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           3037       3043     +6
- Misses          125        143    +18
  Partials          0          0

Powered by Codecov. Last update e595d0e...d5b49c7

Thanks @motia! I noticed you were still updating some tests. Will you have some time in the next few days to fix the TestTimberIntegrationsCoAuthors::testGuestAuthorAvatar test? Thanks again!

Coverage increased (+0.04%) to 95.825% when pulling f4611445a8b5fb3bfba8bb460da52c3fdc931630 on motia:fix_coauthor_integration into e595d0e01f5e0521b87f5c59a5da2e0ff635bff8 on timber:master.

Coverage increased (+0.04%) to 95.825% when pulling f4611445a8b5fb3bfba8bb460da52c3fdc931630 on motia:fix_coauthor_integration into e595d0e01f5e0521b87f5c59a5da2e0ff635bff8 on timber:master.

Coverage increased (+0.04%) to 95.825% when pulling 4ea219182feb3bbbf960ef70a0e2988ac7002925 on motia:fix_coauthor_integration into e595d0e01f5e0521b87f5c59a5da2e0ff635bff8 on timber:master.

@jarednova , I finished fixing the tests. Please, let me know if I need to make any change.

Coverage increased (+0.04%) to 96.15% when pulling cd7995d2719cd940fac9a8b5a02b1e67b35a0d00 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage increased (+0.04%) to 96.15% when pulling cd7995d2719cd940fac9a8b5a02b1e67b35a0d00 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage decreased (-0.5%) to 95.643% when pulling cd7995d2719cd940fac9a8b5a02b1e67b35a0d00 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage increased (+0.04%) to 96.15% when pulling cd7995d2719cd940fac9a8b5a02b1e67b35a0d00 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage increased (+0.04%) to 96.15% when pulling cd7995d2719cd940fac9a8b5a02b1e67b35a0d00 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage increased (+0.03%) to 96.14% when pulling f09e12f441f0236be505fa3aeacc9c604491a371 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage increased (+0.03%) to 96.14% when pulling eeaec237fad7fd9522f30206e34a0135e4f508f8 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Coverage increased (+0.03%) to 96.14% when pulling eeaec237fad7fd9522f30206e34a0135e4f508f8 on motia:fix_coauthor_integration into 7271542f422ef80278dc8d328de0e32530edd416 on timber:master.

Thanks so much @motia — I added another test (and mucked with the spacing a bit), but this is 🎉 fantastic 🎉 . Thanks so much for carefully considering the usage/implications and providing tests. Anything else you're thinking of improving/fixing?


On contexts, keys and context hierarchies

Note: I need to expand on these points but just didn't want to lose the stuff I'd already written
This issue tracks various pain points that need to be resolve or design decisions that need to be made w.r.t. our internal implementation of app contexts and context keys.
Contexts should live on the app
Currently, our application maintains three separate context objects, each as an attribute on the internal object we deemed semi-relevant to the context's keys:

The ViewerModel context seems to be empty, so it's not clear why it is currently being defined here. Potentially, this should be the root context that we use to define the others?
The LayerList context contains all keys that maintain information about the layerlist or its current selection
The QtMainWindow context which currently contains a single context key related to the Debug menu trace functionality

As initially noted by Talley when creating the LayerList and the ViewerModel contexts, keeping these contexts on the individual objects is a leaky abstraction - these objects shouldn't have to know about, track or update contexts. Rather, the app should manage these contexts, by connecting to relevant events on the object the context is tracking state for. See #7106 for an example of an issue that may have been caught earlier if the contexts lived and died with the app.
Hierarchical contexts
Contexts in app-model can be hierarchical. Each of the contexts mentioned above is rooted in a custom SettingsAwareContext which is given as a default root_class to our create_context function. Other than this root_class, each of our three contexts are independent from each other, and contain different sets of keys.
This means that when we're updating the state of our application based on the values of specific context keys, e.g. updating the enabled/disabled state of menu items, we have to pass the correct context to the update method, and this context has to contain all keys that will be queried.

We now have three different flavours of context keys but no guiding principles as to when we should use which
Contexts should exist in a hierarchy that ensures that higher level keys are available to lower level contexts as required

The other aspect of this is how these contexts are updated. This has been previously discussed in
#6965, but I just want to document everything here for easier reading and completeness.
3 different context types
Contexts can be updated in 3 different ways:

'normal' : ContextNamespace.update of these contexts are connected to the appropriate events and they are always up to date (as they get updated when the relevant object changes).

Example: LayerList context keys defined in _layerlist_context.py

'function': These context keys are not ContextKey instances but are instead a callable that returns the 'context key' value. The callable is called when we use get_context (which creates a new ContextMapping, whose __getitem__ method calls the callable). In use, we call get_context then use it in update_from_context, thus the values are only up to date just before we access them.

Example: valid_spatial_json_clipboard

'hybrid' : We define a ContextKey that is connected to an event. The ContextKey getter function returns a function, which gets called on get_context as above. Note that we need to connect to an event to pass the correct object to the function that is returned. Similar to function context keys, these are only up to date before we access them.

Example: _empty_shapes_layer_selected - this is connected to layerlist events, just like 'normal' context keys, and this updates the selected layer that is passed to the function that is returned. We then get the value. The reason we need to call the function is because changes to the layer properties affects this context key but does not cause layerlist to emit any events that we can connect to (this https://github.com/napari/napari/issues/7024 issue)

Context ( :sweat_smile: ) and history
We realised that there are some context keys where there technically is an event to connect to but:

the event gets updated very often (e.g., layer data changes) and we would need to throttle it if we did choose to connect to an event
the event would be awkward to connect to (e.g., valid_spatial_json_clipboard, we could connect to a clipboard changed event but where do we keep the context?)

We originally asked Talley if he was interested in supporting callable context keys in app-model (https://github.com/pyapp-kit/app-model/issues/196#issuecomment-2114978480 and https://github.com/pyapp-kit/app-model/pull/199) but he was not keen in the end.
@Czaki then suggested we can implement cachable context mapping that also evals functions and that was implemented in: #6965
There was some discussion in #6965 on the complexity of the 3 contexts and that the way 'hybrid' contexts worked was not very transparent.
cc @jni as you originally asked for clarification on this.

Lucy and I met and talked about point 1: Contexts should live on the app.
They key issue as we see it is that in order to create contexts within the app, we need the app to be "aware" of objects before they're created, and "wait" for them to be ready, so that it can connect to the appropriate events on the objects. For example, we want to move the LayerList context onto the app, which means the app needs to know when the LayerList has been created, so that it can connect to its events.
I can imagine the app tracking a registry of "potential" contexts, that become instantiated when the objects are created, but the object would still need some way to signal to the app that it's ready to go. The closest concept that comes to mind for me is some kind of Future type thing, where when the app is first instantiated, we create a ContextRegistry with (roughly...) Future[Context] objects. That way the contexts can be created only when the result is set, and therefore when the object the context belongs to is available. However then, the object would need to set this result, and that feels like just as leaky an abstraction. Perhaps the object's only task would be to emit a ready event of some sort, and then a middleman (WHO??) takes that event and sets the Future's result, which creates a context, which connects to the correct object events...? But how can you connect to the ready event of an object that doesn't exist yet...?
Another question: where is the app living so that it can access all the different objects that it may need and where is it accessing these from? It can't live on a qt object because we want it available headless, but some of the contexts might be on qt objects, so again we're meeting this idea of a "potential" context.


KTOP Maintainer Permissions

Hello @ErikSchierboom, although @kotp has been given approval to become a maintainer for the Zig track #50, he does not have the typical maintainer permissions on this repo, for instance please refer to PR #52's comments. What are the methods to navigate towards giving him maintainer permissions, such as pr merging, and the like?

Aha, I know what to do: call in backup! @iHiD Could you give @kotp the right permissions?

Done.


[Task] Add MerkleKeyCollection support to Account

Description
Their is currently no account support for adding a Merkle Key Collection, without going through the low-level API. Merkle Key Collections are a critical part of functionality that we expect to be used frequently. Adding the logic to the Account API will be crucial yet also challenging due to its flexible and complex behavior. The API should be able to add a collection, remove collection, revoke keys and sign with a key from a collection.
To-do list
Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

[ ] Design new API
[ ] Implement new API
[ ] Account Example

Change checklist
Add an x to the boxes that are relevant to your changes, and delete any items that are not.

[ ] The feature or fix is implemented in Rust and across all bindings whereas possible.
[ ] The feature or fix has sufficient testing coverage
[ ] All tests and examples build and run locally as expected
[ ] Every piece of code has been document according to the documentation guidelines.
[ ] If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
[ ] If the feature is not currently documented, a documentation task Issue has been opened to address this.

There's a myriad of issues to solve before @abdulmth and I can start the implementation, so I'm hoping we can fix at least a direction of how to approach it.

KeyCollection fundamentally assumes that it holds the private keys, which is completely incompatible with private keys living in storage in the account.
The known issue of not being able to call an async remote signature implementation, like RemoteEd25519 from a sync trait like Signer.
IotaVerificationMethod::create_merkle_key taking a KeyCollection, which is not going to work out of the box if we have to add a second RemoteKeyCollection type.
Account::sign taking only the fragment for a method to sign with, leaving the key with which to sign unclear in the case of a key collection.
MethodType::MerkleKeyCollection2021  not specifying what signature the key from the collection is actually using, or what hash.
The size of the collection is unknown when creating it from storage.

To address these, this is just a proposal, feel free to comment and suggest alternatives.

Don't make storage implementations support key collection directly, because that would require storage impls to duplicate a lot of code. Instead, since a collection is just a bunch of keys, like Ed25519, that storages like stronghold already handle, we build on top of that.
The KeyCollection type from the core crate holds the private keys directly, and because of that will not work with remote keys, i.e. those stored in storage. Instead, introduce a RemoteKeyCollection that has probably just a reference to storage (&dyn Storage or Arc<dyn Storage>). The merkle root can be lazily computed by retrieving all the public keys from storage. This might be fairly bad for large collections, so that has to be tested. The alternative is to compute the root once on creation, since it stays the same for the duration of any given key collection, and cache it in storage. Not terrible, but requires additional management of that state, like deriving a location for it and deleting it at some point. Storing arbitrary data in a storage is also not supported currently, so we either add that functionality or add a dedicated storage method for storing that root. Because of that, I'd prefer to lazily compute it, if performance allows for it.
Introduce an async RemoteSign trait, which only RemoteEd25519 implements (for now). The existing traits in core are simply not suitable for the account, because they take private keys as parameters.
Change IdentityState::sign_data to take a &dyn RemoteSign, instead of a KeyLocation and &dyn Storage, mostly to delegate the concrete sign implementation to RemoteSign rather than deciding on that in sign_data.
Account::sign delegates to sign_data like before, but returns an error if the passed fragments resolves to a verification method with MethodType::MerkleKeyCollection2021. This is necessary, because of problem 4.
Introduce Account::sign_from_collection (or something) that has the same signature as Account::sign, but also takes an index: usize that identifies one key in the collection. If the type of the resolved method is anything but MethodType::MerkleKeyCollection2021, it returns an error. We extract the tag from the merkle key to get the signature and hash types, and instantiate the corresponding RemoteSign implementation. For now, we only need to map MerkleSignatureTag::ED25519 to RemoteEd25519, and then produce a key collection signature. This will involve calling the RemoteSign impl and creating a new RemoteKeyCollection to compute a proof of inclusion for the public key that was used (index).
In order to create a verification method that uses a key collection, we likely have to refactor IotaVerificationMethod::create_merkle_key, to take an encoded merkle key instead of a KeyCollection. This merkle key is currently a Vec<u8>, but because we don't want to take a Vec<u8> here, we can consider refactoring the existing MerkleKey to be a thin wrapper around Vec<u8>.

There's a somewhat related issue. Deriving KeyLocations as planned in #508 does not work exactly like that for key collections. The proposal, in short, is to use {fragment}{hash(method_data)} as the key location. While we can use a similar approach, we also need to add the index of each key, because each key is going to be at an individual location. So basically {fragment}{publicKeyMultibase}{key_index}. This way, we only need to know an index and can derive the location for that key.
Technically, we don't need to know the size of the collection, as we could start iterating from 0 and look up public keys until we no longer find any, and if the total size is not a power of 2, return an error. But that seems pretty hacky. I would prefer storing the size of the collection. To do so, we could:

Keep the size of a key collection in the storage.
Add size property as a verificationMethod field.
Encode the size into the publicKeyMultibase like we do with the hash and signature type: U8(log2(KEY-COLLECTION-SIZE)) || U8(SIGNATURE-TAG) || U8(DIGEST-TAG) || BYTES(MERKLE-ROOT)). (We could get away with just an additional byte, as long as we're comfortable enforcing collection sizes to be powers of 2 in the future, which I think we are?)

2 and 3 would be the stateless options, and would not require invoking storage to create a KeyLocation. As long as revealing the size of the collection is not considered an information leak, this seems like a good way to go. 2 however seems like a way to break encapsulation, because now the IotaVerificationMethod needs to parse that field, but it's only relevant for key collections. So 3 is my preference.
This also requires a refactor of KeyLocation, because key collections would have different inputs to their location, so ideally we simply have two constructors for KeyLocation, one for regular keys and one for key collections.
Lastly, if we implement all this before #508, then we can probably just abuse the KeyLocation::generation field as the index of the key.
Sooo, any thoughts on this? If no one has the time to dive deep into this, from my point of view, it's also fine to just start with this and see where we get. Most likely, more issues will come up anyway.

@abdulmth would like to get started with this issue, so here's a more helpful first part to implement.
pub struct RemoteKeyCollection {
    storage: Arc<dyn Storage>,
    fragment: Fragment,
    len: usize,
}

This type should mimick the KeyCollection API as closely as possible. Good first methods to implement are: KeyCollection::{new, public, merkle_root, merkle_proof, encode_merkle_key}. Any methods that return a private key like KeyCollection::{private, keypair, iter_private} are not possible to port.

To implement the merkle_* methods, it will make sense to re-use the functionality from the core crate like compute_merkle_root and compute_merkle_proof.
To implement the new method, we will have to generate new keys. Examples for key generation in the storage are in identity_account::updates::update::Update::process in the implementation arm for CreateMethod.
To store the keys, we need to create a KeyLocation. The MethodType can be ignored for the initial implementation, e.g. we can use MethodType::MerkleKeyCollection2021, even though that makes no sense (that key alone is not a collection).
We can generate the fragment and generation for the KeyLocations based on the index of the key we're generating, e.g. KeyLocation::new("key-collection-fragment".to_owned(), Generation::from_u32(index)).

Hopefully that helps getting started.

Might be made irrelevant by https://github.com/iotaledger/identity.rs/issues/715.

No longer an issue: MerkleKeyCollection was removed in #715.


New helper interface

New Utility functions
Utility functions are provided to access your generated stylesheet:
import { styles } from '@enhance/arc-plugin-styles'

styles.getLinkTag()   // a <link rel="stylesheet"> tag
styles.getStyleTag()  // a <style> tag for inline styles
styles.getPath()      // root-relative path to the .css file

getAll() is also available to create an object with each result:
import { styles } from '@enhance/arc-plugin-styles'

const myStyles = styles.getAll()
myStyles.link    // a <link rel="stylesheet"> tag
myStyles.style   // a <style> tag for inline styles
myStyles.path    // root-relative path to the .css file

Experimental build
npm i<EMAIL_ADDRESS>

Having used this interface in a branch over on enhance-dev/arc-plugin-enhance#48 I'm wondering if this change would be more ergonomic
import { getStyles } from '@enhance/arc-plugin-styles'

getStyles.linkTag()   // a <link rel="stylesheet"> tag
getStyles.styleTag()  // a <style> tag for inline styles
getStyles.path()      // root-relative path to the .css file

I really wanted to keep "get" in the interface name so it's clear that you can't set anything here. Also now I can author something like this and actually use the const name style
const styles = getStyles.styleTag()


Unable to run as package chashes.

Failed to require the main module of 'atom-live-server' because it requires one or more incompatible native modules (binding, binding, binding, binding, binding, binding).
Run apm rebuild in the package directory and restart Atom to resolve.

There is no entry for (logically)

Try launching live-server from top menu: Package -> live-server -> Start Server to see if it works.

What will happen when rebuilding all?

/Users/clemens/.atom/packages % apm rebuild --help
Usage: apm rebuild [ [ ...]]
Rebuild the given modules currently installed in the node_modules folder
in the current working directory.
All the modules will be rebuilt if no module names are specified.

apm rebuild did not help. With or without atom-live-server package only

#57

Thanks for the XREF!


resolve pyoxidizer compatible issue

Type of changes

[ ] Bug fix
[ ] New feature
[ ] Documentation / docstrings
[ ] Tests
[x] Other

Checklist

[x] I've run the latest black with default args on new code.
[ ] I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
[ ] I've added tests for new code.
[ ] I accept that @willmcgugan may be pedantic in the code review.

Description
Hi,
The error occurs when using pyoxidizer to packaging python application depends on rich. It seems below import can't be handled in pyoxidizer:
from .__init__ import something

The related pyoxidizer issue: https://github.com/indygreg/PyOxidizer/issues/317

Thanks


DSC Feature Flags / Optional Units

Description of the new feature / enhancement
When writing a DSC file, there may be both common workflows (the ideal use case for DSC) as well as optional workflows that may be necessary for various development areas. Take winget-dsc as an example - users working on any DSC resource in that repository will need some standard set of tools, which are currently installed by the configuration.dsc.yaml.
If working on the NpmDsc resource, then Node.js should also be installed. However, not all contributors will be contributing to that resource and may not want Node.js installed if it is not necessary for their contributions. The same could be said about Python - users may already have a specific version installed and not want the latest, or may not want Python at all, if they are not working on that DSC resource.
It would be beneficial if there were a way to specify steps in a DSC yaml file as optional. Inspiration could be taken from Rust's features implementation, where the defaults can be set by the author of the resource, and consumers can use --no-default-features to disable all optional configuration units, and/or --features [<feature>] to enable specific optional modules if they are not specified as a default feature
Proposed technical implementation details
No response

Parameters can be used in the latest (DSC v3) configuration schema to handle some of this, but I hadn't thought about the use of parameters to drive optional pieces of a configuration. I think this warrants some discussion in terms of what WinGet would show for the configuration to be run and how to reason about conditional behaviors in a configuration.


Crashes instantly upon placing integrated circuit

MC version 1.19.2
Modpack: StaTech Industry
Mod version: 1.1.1
latest.log containing the crash (starts at line 10750)
https://gist.github.com/dhasial/bb8cb9e7539148f22bde81337d27677b

There is a crashfix file uploaded to the 1.1.1 release of the mod: https://modrinth.com/mod/integrated-circuit/version/1.1.1
It should work if you swap that out

Does it work with only the integrated circuit mod without any other mods?

It does not. I made a quick 1.19.2 instance with the same Fabric loader version; same behaviour.


Error: Command line operation failed with code 1.

I am trying to generate the docs using the solidity-docgen. Earlier it was working fine but suddenly it is behaving very weird.
getting this error

Error: Command line operation failed with code 1.
at handleErrorCode (/usr/local/lib/node_modules/solidity-docgen/lib/index.js:133:11)
at parseProject (/usr/local/lib/node_modules/solidity-docgen/lib/index.js:123:3)
at exports.default (/usr/local/lib/node_modules/solidity-docgen/lib/index.js:20:23)
at Command.program.version.arguments.option.action (/usr/local/lib/node_modules/solidity-docgen/bin/solidity-docgen:32:5)
at Command.listener (/usr/local/lib/node_modules/solidity-docgen/node_modules/commander/index.js:315:8)
at Command.emit (events.js:180:13)
at Command.parseArgs (/usr/local/lib/node_modules/solidity-docgen/node_modules/commander/index.js:653:12)
at Command.parse (/usr/local/lib/node_modules/solidity-docgen/node_modules/commander/index.js:474:21)
at Object. (/usr/local/lib/node_modules/solidity-docgen/bin/solidity-docgen:44:9)
at Module._compile (internal/modules/cjs/loader.js:654:30)

@satyamakgec the error seems to be happenning as part of parseProject, which invokes the solidity compiler. Make sure you have a working version of solc (with version greater than 0.4.21), and that your set of contracts do compile ok.
I'm afraid that info on errors is not very clear atm.

@spalladino Thanks for the prompt answer. Yes, I do have the solc version greater than the 0.4.21. My version is 0.4.24.
My contracts are compiling ok but some of the warnings occurred because of compiler version My contract suite have the oraclize.sol which was built on 0.4.18 solc version. But in a whole I am using 0.4.24 solc compiler.
is oraclize.sol will be the cause of the failure? I tried after removing the oraclize and its dependent contract but still, I am getting the same error.  Is there any way to ignore those contracts? I tried to use the -excludes flag but it seems it generates a document for them.

Yes sure @spalladino. Thanks!

Thanks for reporting @satyamakgec! Closing this issue as it does not apply to v0.2 (still in alpha, see #23 for details).


Support for UITextView

Can you add support for UITextView ?

Hi there, I'll look into it.

@nimati Did you get any news about this? I wanna to make the message content scrollable :D


Animation and Scene now also contain Timeline and Player interacts with it

All of the rendering is now based on dt and timeline positions instead of global time;
Improved controls;

Yet needs some tests, please do not merge.


Copyright date in footer

show current year
also added permalink to posts

Wrong button

pulled the copyright year commit


Testing signup api

curl -d '{"email":"test0", "password": "password"}' --verbose -H "Content-Type: application/json" -X POST https://council-tag.herokuapp.com/api/signup/
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to council-tag.herokuapp.com (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Heroku, Inc.; CN=*.herokuapp.com
*  start date: Apr 19 00:00:00 2017 GMT
*  expire date: Jun 22 12:00:00 2020 GMT
*  subjectAltName: host "council-tag.herokuapp.com" matched cert's "*.herokuapp.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
> POST /api/signup/ HTTP/1.1
> Host: council-tag.herokuapp.com
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 41
>
* upload completely sent off: 41 out of 41 bytes
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Server: gunicorn/19.7.1
< Date: Tue, 24 Apr 2018 02:06:01 GMT
< Content-Type: text/html
< X-Frame-Options: SAMEORIGIN
< Content-Length: 27
< Vary: Cookie
< Via: 1.1 vegur
<
* Connection #0 to host council-tag.herokuapp.com left intact
<h1>Server Error (500)

did i curl correctly?

they both work or one or another?

They both work


Yolov4?

Hi!
Are there any plans to support yolov4 which just came out?
All the best!

I would also love to use yolo-V4

I used v3 with downloading 3 files and changing target text but now it runs at v2-tiny, I can't change it. How do you use yolo v3?

Good question. Any plans to move to the new tech? V4 seems to be quite an improvement.

Is there any confirmation if this repo works for Yolo v4 from AlexeyAB?

I can say that it did not work for a yolov4-custom.cfg network trained with my yolo-V4 build from  https://github.com/AlexeyAB/darknet.git 25.05.2020 Commit hash e6469eb071521a4ff5be8c0e9cceb524d0a65a95: detection takes some time, but nothing is detected.
Also on this commit it does not work out of the box to build a new yolo_cpp_dll_cpu.dll and yolo_cpp_dll_gpu.dll, which would be the first step (but not the last) to update this framework. But it looks doable.

I can say that it did not work for a yolov4-custom.cfg network trained with my yolo-V4 build from https://github.com/AlexeyAB/darknet.git 25.05.2020 Commit hash e6469eb071521a4ff5be8c0e9cceb524d0a65a95: detection takes some time, but nothing is detected.
Also on this commit it does not work out of the box to build a new yolo_cpp_dll_cpu.dll and yolo_cpp_dll_gpu.dll, which would be the first step (but not the last) to update this framework. But it looks doable.

I was also looking at compile „yolo_cpp_dll_gpu.dll“ from latest darknet build... can you confirm, that this is not working @ the moment? Or should i give it a try?

Yolo v4 pretrained dataset works for me without problems out of the box! No need to compile yolo_cpp_dll_gpu.dll from darknet

YOLOv4 is 2x slower then V3 on my test.
https://github.com/AlexeyAB/darknet/issues/6630 https://github.com/AlexeyAB/darknet/issues/6630#issuecomment-691101182

V4 default network size is 608, v3 default network size was 416. If you don't change the network size in the cfg file, that will definitely cause inferencing to require more time.

@LueTheShoe Can you share some more  details what you did to make it work? Did you see any improvements from v3?
Best
Christian

I can say that it did not work for a yolov4-custom.cfg network trained with my yolo-V4 build from https://github.com/AlexeyAB/darknet.git 25.05.2020 Commit hash e6469eb071521a4ff5be8c0e9cceb524d0a65a95: detection takes some time, but nothing is detected.
Also on this commit it does not work out of the box to build a new yolo_cpp_dll_cpu.dll and yolo_cpp_dll_gpu.dll, which would be the first step (but not the last) to update this framework. But it looks doable.

@LueTheShoe some networks seem to be backwards compatible and work fine, some don't.
Here are some notes what I did; the darknet patches should be applicable to https://github.com/AlexeyAB/darknet; the Alturos.Yolo changes should be straight forward enough to do manually. There probably are better ways to do it, but it seems to do the trick for me and I hope it helps.
Adjust-Alturos.Yolo-wrapper-for-YoloV4.zip
For trouble-shooting it was extremely useful to be able to debug into yolo_cpp_dll_cpu.dll etc, so I suggest to store .pdb files along with the .dll files.
Finally an observation: compiling with CUDA 10.1, cuDNN 8 and OpenCV 4.5.0 resulted in significantly lower performance. Detection was about three times slower on a net of size 608x608. Reverting back to cuDNN 7 DLL solved this.


Add tests for persisted name links in lists

It works well for changing the name of an entity but only when this entity is not part of a RealmList.

I interpreted this like:
class Parent {
    var children: RealmList<Child> = realmListOf()
}

@PersistedName("RenamedChild")
class Child {
    var name: String = ""
}

But that is also part of the test. In my test I am just also renaming the children property, but should still show that the parent can have a list of Children even though Child is renamed.

Arg, I only read the incoming changes 🤦🏻♂


5.0.0 package net46 incorrect version number

Within the version 5.0.0 nuget package, the net46 version appears to have the version number 4.2 rather than 5.0.0.
This is causing me errors when taking your library as a 2nd level dependency which is expecting a 5.0.0

Thank you for catching this.
I'm away on vacation the next week's, but feel free to do a PR and I might be able to process it remotely.

I'm also on vacation for 2 weeks 😂
Plus I'm not sure what the update needs to be and where as I can't find a match for the version number in the DLL in the codebase.

OK. Will look at it when back then 😉

Perfect thanks!
Enjoy your vacation 🙂

@1iveowl just had a look at the versions and think everything is ok in the codebase, though this doesn't match the contents of the package...so maybe it just needs a rebuild and publish to fix?

To clarify the issue, it's the PCL lib which is the wrong version.

There was an issue with the build script. It have been fixed with version 5.0.1.


Google Maps: App Security issues found in GMS for iOS

Environment details

Google Maps
iOS
Maps version 8.2.0

Our dynamic app security scan provider, Data Theorem, identified that

[GMS uses] the CC_MD hashing functions, which leverage hashing algorithms (including MD2 and MD5) that are proven to be vulnerable to collision attacks, and are unsuitable for modern use.
Apple has officially deprecated these APIs in the iOS 13.0 SDK. They state in the CommonCrypto headers:
"These functions are cryptographically broken and should not be used in security contexts. Clients should migrate to SHA256 (or stronger)."

If CC_MD hashing functions are used in a security context, are there plans to update the SDK with use of stronger algorithms with better collision resistance properties, such as SHA-256 or SHA-512?
If CC_MD is not being used in a security context, can you confirm so?
Thank you!
Stack trace
-[GMSx_GNSStreamProviderImpl outputStreamToBuffer:capacity:]
-[GMSx_GNSStreamProviderImpl outputStreamToMemory]
-[GMSx_CCTClearcutCounters initWithClock:]

-[GMSx_CCTClearcutLogEvent initWithLogSource:isAnonymous:clock:]
-[GMSx_CCTClearcutLogEvent initWithLogSource:isAnonymous:]
-[GMSx_CCTClearcutLogEvent initWithLogSource:]
@"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x"

-[GMSx_PHTSnapshot emptyConfiguration:]
-[GMSx_PHTSnapshot isValidFlagsHashInSnapshot:]
-[GMSx_PHTURL sharedDirectoryWithError:]
-[_OBJC_CLASS_$_NSMutableArray init]

-[GMSx_PHTSnapshot emptyConfiguration:]
-[GMSx_PHTSnapshot isValidFlagsHashInSnapshot:]
-[GMSx_PHTURL sharedDirectoryWithError:]
-[_OBJC_CLASS_$_NSMutableArray init]

-[GMSx_PHTSnapshot emptyConfiguration:]
-[GMSx_PHTSnapshot isValidFlagsHashInSnapshot:]
-[GMSx_PHTURL sharedDirectoryWithError:]
-[_OBJC_CLASS_$_NSMutableArray init]

Thank you for reporting this. Since it is about the Maps SDK for iOS and not the Swift Package delivery of the SDK, please file it on the Maps SDK for iOS issue tracker so it gets the proper attention.


Failed to show when using Patchwork operators in layout

Describe the bug
Failed to show when using Patchwork operators in layout
To Reproduce
In Pluto
using TidierFiles, TidierData, TidierPlots
using WGLMakie
WGLMakie.activate!()

ads = read_csv("../data/advertising.csv")

p1 = ggplot(ads, @aes(x = TV, y = sales)) +
     geom_point(color=:red) +
     geom_smooth(method=:lm, linewidth=3, alpha=0.5)
p2 = ggplot(ads, @aes(x = radio, y = sales)) +
     geom_point(color=:red) +
     geom_smooth(method=:lm, linewidth=3, alpha=0.5)

p1 + p2

link
Expected behavior
Show a combined figure.
Screenshots

Additional context
Paste the output of Pkg.status() here:
  [c9fd44ac] BetterFileWatching v0.1.5
  [13f3f980] CairoMakie v0.12.7
  [a80b9123] CommonMark v0.8.12
  [0c46a032] DifferentialEquations v7.13.0
  [31c24e10] Distributions v0.25.110
  [f6369f11] ForwardDiff v0.10.36
  [38e38edf] GLM v1.9.0
  [708ec375] Gumbo v0.8.2
  [ac1192a8] HypertextLiteral v0.9.5
  [682c06a0] JSON v0.21.4
  [8ac3fa9e] LRUCache v1.6.1
  [736d6165] MarkdownLiteral v0.1.1
  [c03570c3] Memoize v0.4.4
  [961ee093] ModelingToolkit v9.33.1
  [8b842266] PalmerPenguins v0.1.4
  [c3e4b0f8] Pluto v0.19.46
  [0ff47ea0] PlutoHooks v0.0.5
  [0ff47ea0] PlutoLinks v0.1.6
  [2fc8631c] PlutoSliderServer v0.3.31
  [7f904dfe] PlutoUI v0.7.59
  [33c8b6b6] ProgressLogging v0.1.4
  [1fd47b50] QuadGK v2.10.1
  [ce6b1742] RDatasets v0.7.7
  [37e2e3b7] ReverseDiff v1.15.3
  [0c5d862f] Symbolics v6.3.0
  [ac1d9e8a] ThreadsX v0.1.12
⌅ [fe2206b3] TidierData v0.15.2
  [8ae5e7a9] TidierFiles v0.1.3
  [337ecbd1] TidierPlots v0.7.8
  [fce5fe82] Turing v0.33.3
  [5c2747f8] URIs v1.5.1
  [276b4fcb] WGLMakie v0.10.7
  [ddb6d928] YAML v0.4.12
  [04572ae6] Deno_jll v1.33.4+0
  [56ddb016] Logging
  [44cfe95a] Pkg v1.10.0
  [4ec0a83e] Unicode

Tried CairoMakie, though the figures display, they pop up.
I attempt to use return value
p13 = (p1 + p2 + p3 + plot_layout(ncol=3, nrow=1, widths=[2, 2, 2], heights=[1]));

p13 returns p13.plots (3-element vector) and p13.grid, no the combined figure.

There was a missing show method for GGPlotGrids in Pluto - this will be added in the next update but for now you can put the following in a pluto cell and it will work:
function Base.show(io::IO, ::MIME"text/html", x::TidierPlots.GGPlotGrid)
	show(io, MIME"text/html"(),
        with_theme(x.plots[1].theme) do
            draw_ggplot(x)
        end
    )
end

in dev as of https://github.com/TidierOrg/TidierPlots.jl/commit/773b5f01d893dafbe28e42255bc96f18ea8ae1cf

Thank you for your effort!


Routing api v2 info

This PR is for adding routing_endpoint to /v2/info.
Pivotal tracker story: https://www.pivotaltracker.com/story/show/100974596
Regards,
@atulkc and @leochu

Looks good, merged locally.


Globe edge bounce

see snapshot. the edge will bounce will rotate:

Please check up the last master!


Minor documentation improvements

Changes for https://github.com/scrapy/scrapy/pull/3881

Thanks @Gallaecio! 😄


logging: When strings are stripped keep source name pointers

90ab94f61dd added a change that source name pointers were not stored in the const data structure associated with a logging source. That was done because those string pointers were invalid (on purpose pointing to non-existing memory) and reading those strings could lead to a fault. However, those pointers are used by scripts which are building the dictionary database and after this change script was no longer able to retrieve source names from elf file and database was incomplete.
This patch brings back storing of source name string pointers but in API for reading those source names guards are added to not return invalid addresses.

Without this change database fails to retrieve source name. Source names entries in log_database.json looks like "source_id": 2, "name": "unknown".


Set-CsTenantDialPlan fails when trying to work with NormalizationRules

Issue
Error thrown when attempting to run cmdlet Set-CsTenantDialPlan to CRUD Normalization Rules on Version 4.0.0 and 4.1.0 of the MicrosoftTeams module. Error Message below:

Unable to cast object of type 'System.Management.Automation.PSCustomObject' to type 'Microsoft.Rtc.Management.WritableConfig.Policy.Voice.NormalizationRule'.

PowerShell Output
# Create Dummy Arrays for CRUD Operation
$existingRules = @()
$newRules = @()

# Create Rule and add to $newRules Array
$rule1 = New-CsVoiceNormalizationRule -Identity 'MyLittleTest/0' -Pattern '^(\d+)$' -Priority 10 -Translation '+$1' -InMemory
$newRules += $rule1

# Attempt Set-CsTenantDialPlan cmdlet
Set-CsTenantDialPlan -Identity MyLittleTest -NormalizationRules @{Remove=$existingRules; Add=$newRules} # Failure occurs here

# Confirm Variable Type (Created by MicrosoftTeams Module)
$rule1.GetType()|FL IsPublic, Name, BaseType

Output:
IsPublic : True
Name     : PSObject
BaseType : System.Object

I don't believe the issue is the actual object created by New-CsVoiceNormalizationRule, but more how the Set-CsTenantDialPlan cmdlet handles the call. To make this more interesting, this doesn't affect all tenancies!
My workaround so far has been to rollback to 3.1.1 in which it will run without error for all tenancies that I have confirmed problematic and non-problematic so far.

@sagius-pingco Thanks for the feedback! I tried below on TPM 4.1.0 on both PS 5.1.22000.282 and 7.2.2 and it worked for me.
`# Create Dummy Arrays for CRUD Operation
$existingRules = @()
$newRules = @()
Create Rule and add to $newRules Array
$rule1 = New-CsVoiceNormalizationRule -Identity 'Test1/1' -Pattern '^(\d+)$' -Priority 10 -Translation '+$1' -InMemory
$newRules += $rule1
Attempt Set-CsTenantDialPlan cmdlet
New-CsTenantDialPlan TestDP
Set-CsTenantDialPlan -Identity TestDP -NormalizationRules @{Remove=$existingRules; Add=$newRules}
`

Hi @pbafna03,
Thanks for the update. Will test today and advise. Most appreciated.

@sagius-pingco was this fixed for you?

@sagius-pingco was this fixed for you?

Hi @JensTrier, the issue has not reoccurred, so I would say it has been resolved. Thank you!


Audio never gets past the downloading stage.

After pasting in a valid YouTube URL, right clicking the jukebox, and receiving the 'downloading music, please wait a while...' notification, no second notification is given and no audio is played. This is occurring on 1.20.1.

on which operating system did you use the mod and what was the youtube URL? if it was Linux or a playlist URL, it should be fixed with the next Mod version


add a keybindings popup

Resolves #47.
Currently the content of the popup is just a paragraph. It might be worthwhile to change this, so that it uses the Table widget. However, to do this I'd need a bit more time, as I currently don't really understand how that would work.
I'm also thinking about adding a build script to extract the keybindings table from the README.md, so the information doesn't get out of sync.
I added the popup shortcuts at the top to give them the best chance of being visible in a small terminal.

I am impressed, thank you 🥇
I have following ideas in mind (sorted by "priority"):

it would be cool to have any key pressed closing the help popup (maybe with title on a bottom saying "Press any key to close...")
you could calculate popup area dynamically by checking the length of the longest line in a text and also the number of lines and use it directly (with respect to window size) rather than percentages. This way the text in a popup would seem centered.
add "header" line to the popup with bolded and centered "igrep v1.2.0" (can be built using CARGO_PKG_NAME and CARGO_PKG_VERSION env variables) - this needs some experiments to see if it looks good or not

Build script for extracting the text from README sounds great, but you can always do it in a separate PR if you fancy for a challenge :)
Let me know if you have time and interest in applying my suggestions, I can always merge it as is (cause it does its job!) and do it in the future.

Added the "any key to close" behavior. Should that line specify that scrolling keys aren't affected?
The popup now uses as much space as it needs. It still is capped at 80% on small terminals, so that it is always identifiable as a popup.
I added the the igrep v1.2.0 to the title of the popup. I don't think it looks good as part of the popup content.
Extraction via build script is now implemented.

There is one bug in your scrolling implementation. If you scroll down to the very bottom and then press "j" or "down" a number of times, then you need to press "k" or "up" the same number of times before it starts scrolling back :)
The rest looks great!

Scrolling should be fixed now


Python: Functions

Description 📜
In this audio i have explained what are functions, uses of function, function definition, syntax for declaring and calling the function, default arguements and returning from function and examples.
Fixes #569

Type of change 📝

[ ] Audio (Should be in mp3 format Includes speech clarity, Concise ,Low distortion)
[ ] Vi#deo (Animations, screen-recordings, presentations and regular explanatory films are all possibilties etc)
[ ] Documentation (Content Creation in the form of codes or tutorials)
[ ] Other (If you choose other, Please mention changes below)

Domain of Contribution 📊

[ ] Android Dev #(Flutter)
[ ] Android Dev #(Java)
[ ] Android Dev #(Kotlin)
[ ] Backend Dev #(Java)
[ ] Backend Dev #(.NET)
[ ] Backend Dev #(PHP)
[ ] Backend Dev #(Python)
[ ] C/#CPP
[ ] Competitive #Programming
[ ] Cyber #Security
[ ] DS#A
[ ] Data#base
[ ] Datascience with #Python
[ ] Datascience with #R
[ ] Frontend Dev #HTML/CSS/JS
[ ] Frontend Dev #React/Angular/Vue
[ ] Go#lang
[ ] Interview #Prep
[ ] Java_#Domain
[ ] JavaScript_#Domain
[ ] ME#RN
[ ] Machine #Learning
[ ] Open #Source
[ ] Python_Domain
[ ] Ru#st
[ ] Statis#tics
[ ] UI/#UX

Checklist ✅

[x] I have performed a self-review of my own code or work.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor
[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have commented my code, particularly in hard-to-understand areas.

/assign


Get/Print the Cypher query AST in Morpheus

Hello,
I'm asking is there a way to get/print the AST of the passed cypher query in Morpheus as a string or an object.
Thanks in advance for your reply!

Hi Mohammed,
there are different system properties that can be set to pretty print intermediate stages of the query execution. For example:
ir.explainIr
morpheus.explain
cora.explainRelational
cora.explainOptimizedRelational

Named very inconsistently tbh ..
I think there is no flag to print the AST, if you just want a string representation, you could output the statement in org/opencypher/okapi/relational/api/graph/RelationalCypherSession.scala:146.


Visualizing New Robot

Hi Alexander,
First of all, thank you for making towr and xpp available to the public.
I've successfully added my robot in towr and visualized it in xpp using my custom visualizer (a modified version of Hyq's). Here's a screenshot after a successful optimization using towr. Although the motion plan looks good as all the ee moved as specified in the kinematic/dynamic constraints, the robot seems to be always suspended in the air.

I compared Hyq's URDF with mine and realized that the links are rotated differently.

Just wondering if I have to rotate my robot's links/joints to be the same as Hyq's for the visualizer to work or am I missing something here? Thank you in advance.
My setup is as follows:
Ubuntu 16.04 - ROS Kinetic
xpp and towr were built from source

Closing this now. Solved by reworking on the inverse kinematics library to match my links/joints’ orientation. Thank you!


Make hangman more better

So what you want me to do is make the code more better so splitting up the code into functions?

yes

Don't mind what I did

@andrewthederp Why don't you add dependabot?

will resolve merge conflicts and merge it before next release


Retrying signing challenge doesn't work

Describe the bug
I use public func confirmSignIn(challengeResponse: String, options: AuthConfirmSignInRequest.Options? = nil) to login, and when I type incorrect code I receive this error:
AuthError: Incorrect username or password.
Recovery suggestion: Check whether the given values are correct and the user is authorized to perform the operation
  ▿ notAuthorized : 3 elements
    - .0 : "Incorrect username or password."
    - .1 : "Check whether the given values are correct and the user is authorized to perform the operation"
    - .2 : nil

then I type correct code and receive a different error:
AuthError: Invalid session for the user.
Recovery suggestion: Check whether the given values are correct and the user is authorized to perform the operation
  ▿ notAuthorized : 3 elements
    - .0 : "Invalid session for the user."
    - .1 : "Check whether the given values are correct and the user is authorized to perform the operation"
    - .2 : nil

Steps To Reproduce
1. Use `public func confirmSignIn(challengeResponse: String, options: AuthConfirmSignInRequest.Options? = nil)` to submit incorrect code
2. Use `public func confirmSignIn(challengeResponse: String, options: AuthConfirmSignInRequest.Options? = nil)` again to submit correct code

Expected behavior
Typing correct code the second time should authenticate the user successfully.
Amplify Framework Version
2.33.3
Amplify Categories
Auth
Dependency manager
Swift PM
Swift version
5
CLI version
12.10.1
Xcode version
15.3
Relevant log output
<details>
<summary>Log Messages</summary>

INSERT LOG MESSAGES HERE

```
Is this a regression?
Yes
Regression additional context
No response
Platforms
No response
OS Version
17.2.1
Device
iPhone 15
Specific to simulators
No response
Additional context
No response

@almasios Did you get a chance to the share the details I asked for?

Sorry not yet, still working on it. Verbose logs print too much sensitive info, I need to clean them up.


feature: implement foreground service for reliable VoIP call handling

Add option to select notification type for incoming calls or background socket handling

https://app.clickup.com/t/86964vjz4


Trouble loading templates

We are using the ngtemplate-loader, but cannot get it to work even after following the example in the readme. Could you help? https://github.com/ronnross/angular-webpack-example

Hi @ronnross, thanks for trying it out.
The main issue is that ngtemplate loader has a dependency on HTML or Raw loader.
The was also a mistake in the Read Me which I am fixing now.
ngtemplate loader tries to do the bare minimum, it just takes the HTML it's given and loads it into the cache. That way you can you use any other loader you like to do the image url resolution, minifying etc.
That said, I do like that ng-cache uses the global module 'ng' which reduces the config, I think I'll borrow/steal that idea :)


Support Windows builds in release/2.1 up to Core-Setup

This issue is to support Windows builds up to Core-Setup (Microsoft.NETCore.App), add it to AzDO CI, and flow the work through to release/2.2 and master. We have non-Windows-only change debt, and want to get ahead of it before the more dramatic build flow changes coming soon.
master currently has a Windows build, but it is a special case causing difficulties when auto-merging and upgrading.
A few things that can be built on top of this, but aren't included:

Build the SDK. We know we have some issues to work through in the submodules before we can do this.
https://github.com/dotnet/source-build/issues/904 Smoke-test support. (Requires a full SDK/CLI build, right now. Maybe we could work around it to use the tooling SDK with source-built Runtime.)
Building a tarball that can build (offline) on Windows. This doesn't address any known real-world scenario. The only thing I can think of is it would potentially be a convenience for Microsoft devs to work with the offline build flow while on Windows, if they aren't used to Linux.

Closing, merged into 2.1. New issues: #904 (smoke-test) #907 (prebuilt baseline)


macOS Big Sur (11.0.1) - Errors when running middleman commands

Since upgrading to macOS Big Sur (11.0.1) I've been unable to init projects or run bundle exec middleman server. Below are two outputs I receive from both commands. From first glance, maybe this is a ruby version issue? I have included execJs in the gem file on an existing project, so not sure if that would be an issue.
middleman init prejectName
        Traceback (most recent call last):
	16: from /usr/local/bin/middleman:23:in `<main>'
	15: from /usr/local/bin/middleman:23:in `load'
	14: from /Library/Ruby/Gems/2.6.0/gems/middleman-cli-4.3.11/bin/middleman:49:in `<top (required)>'
	13: from /Library/Ruby/Gems/2.6.0/gems/middleman-cli-4.3.11/bin/middleman:49:in `new'
	12: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/application.rb:263:in `initialize'
	11: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/application.rb:263:in `new'
	10: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extension_manager.rb:12:in `initialize'
	 9: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:125:in `load_settings'
	 8: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:125:in `each'
	 7: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:127:in `block in load_settings'
	 6: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:91:in `load'
	 5: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/core_extensions/rendering.rb:11:in `block in <top (required)>'
	 4: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:65:in `require'
	 3: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:65:in `require'
	 2: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/renderers/coffee_script.rb:2:in `<top (required)>'
	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:117:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:117:in `require': cannot load such file -- coffee_script (LoadError)
	23: from /usr/local/bin/middleman:23:in `<main>'
	22: from /usr/local/bin/middleman:23:in `load'
	21: from /Library/Ruby/Gems/2.6.0/gems/middleman-cli-4.3.11/bin/middleman:49:in `<top (required)>'
	20: from /Library/Ruby/Gems/2.6.0/gems/middleman-cli-4.3.11/bin/middleman:49:in `new'
	19: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/application.rb:263:in `initialize'
	18: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/application.rb:263:in `new'
	17: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extension_manager.rb:12:in `initialize'
	16: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:125:in `load_settings'
	15: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:125:in `each'
	14: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:127:in `block in load_settings'
	13: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/extensions.rb:91:in `load'
	12: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/core_extensions/rendering.rb:11:in `block in <top (required)>'
	11: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:65:in `require'
	10: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:65:in `require'
	 9: from /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/renderers/coffee_script.rb:2:in `<top (required)>'
	 8: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:34:in `require'
	 7: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:130:in `rescue in require'
	 6: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:130:in `require'
	 5: from /Library/Ruby/Gems/2.6.0/gems/coffee-script-2.4.1/lib/coffee_script.rb:1:in `<top (required)>'
	 4: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:65:in `require'
	 3: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:65:in `require'
	 2: from /Library/Ruby/Gems/2.6.0/gems/execjs-2.7.0/lib/execjs.rb:4:in `<top (required)>'
	 1: from /Library/Ruby/Gems/2.6.0/gems/execjs-2.7.0/lib/execjs.rb:5:in `<module:ExecJS>'
/Library/Ruby/Gems/2.6.0/gems/execjs-2.7.0/lib/execjs/runtimes.rb:58:in `autodetect': Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)

bundle exec middleman build
bundler: failed to load command: middleman (/usr/local/bin/middleman)
ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes.
  /Library/Ruby/Gems/2.6.0/gems/execjs-2.7.0/lib/execjs/runtimes.rb:58:in `autodetect'
  /Library/Ruby/Gems/2.6.0/gems/execjs-2.7.0/lib/execjs.rb:5:in `<module:ExecJS>'
  /Library/Ruby/Gems/2.6.0/gems/execjs-2.7.0/lib/execjs.rb:4:in `<top (required)>'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:74:in `require'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:74:in `block (2 levels) in require'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:69:in `each'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:69:in `block in require'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:58:in `each'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:58:in `require'
  /Library/Ruby/Gems/2.6.0/gems/bundler-2.1.4/lib/bundler.rb:174:in `require'
  /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/load_paths.rb:35:in `setup_bundler'
  /Library/Ruby/Gems/2.6.0/gems/middleman-core-4.3.11/lib/middleman-core/load_paths.rb:15:in `setup_load_paths'
  /Library/Ruby/Gems/2.6.0/gems/middleman-cli-4.3.11/bin/middleman:10:in `<top (required)>'
  /usr/local/bin/middleman:23:in `load'
  /usr/local/bin/middleman:23:in `<top (required)>'

Any thoughts on what's going on here and how to fix it?

ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes.

Usually means installing Node. Or therubyracer gem (however, I heard that gem is currently broken on Big Sur as well). Apple used to include their own option by default called JavaScriptCore, but they may have stopped that for Big Sur.

Thanks for quick reply. I'll see if installing Node fixes anything. That's a bummer on the exclusion from Apple. Another year and another hurdle from macOS lol.

Okay, I installed Node. I can confirm, installing the latest version of Node fixed this issue.


Error encountered while using the toInt function

Hello,
I encountered a problem while using the bigints library. When I tried to use the toInt function to convert a value of type BigInt to type int, the following error message appeared:
template/generic instantiation of `toInt` from here
Error: cannot instantiate: 'T'

Here is my code snippet:
# 示例
var charset = "abc"
let length = 2
let startFrom = "ab"
let endAt = "bc"
let startNumber: BigInt = getStartNumber(startFrom, charset, length)
let endNumber: BigInt = getEndNumber(endAt, charset, length)

for i in startNumber..endNumber:
  echo fromDecimal(charset, i.toInt, length)

My Nim version is nim-1.6.4 and the bigints library version is bigints-1.1.0.
How can this problem be solved? Thank you!

You need to specify the specific integer type you want to convert to, e.g. i.toInt[:int] or toInt[int](i).


Made Rule & Rule Type management global

Why you made the change:
I did this so that it would more easily model having rule shared across
across registries within the same code.

looks reasonable 👍


[Feature] Alternative Option For AI support

It would be better to have g4f support. Alternative to GPT API Key.

Hi @khengyun, thanks for sharing this! I'll take a look at implementing this into the tool.
Thank you,
Eli

Hi, @eli64s I would like to contribute on this feature.

Hi @skfrost19. Thanks for your interest in contributing to readme-ai. Do you have any specific idea of how you'd like to contribute to this feature?
For additional context, the goal here is to add support for additional LLM APIs in addition to the current implementation of only the OpenAI API. This would give users more flexibility and potentially help grow the project. I need to spend more time working out the details on how to refactor the current codebase and integrate this solution. If you have any initial thoughts or ideas please go ahead and share them.
Thank you,
Eli

@eli64s Yeah sure, we can add 2 other options - Google Gemini API (free) and use of offline quantized models LLaMa2 or OpenChat3.5 for the text generation.
Now the offline models will take more time for the readme generation but it will get the job done. Thanks.

@skfrost19 Thanks for sharing, I think integrating any free API such as Google Gemini is a good starting point.
Are you familiar with the LiteLLM project? It allows you to interface with many providers using the same methods that OpenAI uses. I need to spend some more time learning about LiteLLM but it may be an interesting option to explore as well.

@eli64s i am not familiar with the project but will look into it and get back to you.
Thanks

another open source project : https://jan.ai/


Create new Exception node type

Added at https://github.com/cbilgili/boun-swe-599/commit/3e533c8e7412d571170168b040e1f563a539e9af


Feature/auth handling

Hey @nicktaras,
These commits aim to move integration logic out of the authenticator.js library and into TN.
In detail:

Move attestation postMessage functionality out of authenticator.js library and into auth-handler.ts.
Create a mechanism to show iframe modal in client when requested by attestation.id. Outlet will make the iframe visible and pass a response back to the client to show its iframe in a modal.

I think a lot of this functionality could be consolidated in the messaging.ts class eventually but this is a good intermediate step, as it allows errors from attestation.id to flow back to the client and show in the popup.

Seems origin is actually checked in postMessageAttestationListener.


Error [ERR_PACKAGE_PATH_NOT_EXPORTED] in prisma-adapter

I am attempting to use @next-auth/prisma-adapter with prisma v2.23.0 and next-auth v3.24.0. I get the following error in the terminal when navigating to the login page:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/lib/errors' is not defined by "exports" in /workspace/node_modules/next-auth/package.json
    at new NodeError (node:internal/errors:363:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:321:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:546:3)
    at resolveExports (node:internal/modules/cjs/loader:478:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:518:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:927:27)
    at Function.mod._resolveFilename (/workspace/node_modules/next/dist/build/webpack/require-hook.js:4:1784)
    at Function.Module._load (node:internal/modules/cjs/loader:774:27)
    at Module.require (node:internal/modules/cjs/loader:1013:19)
    at require (node:internal/modules/cjs/helpers:93:18) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

When I call the signIn('github') function I get a different error:
Unhandled Runtime Error
TypeError: Cannot use 'in' operator to search for 'github' in null

Call Stack
_callee7$
node_modules/next-auth/dist/client/index.js (335:0)
tryCatch
node_modules/regenerator-runtime/runtime.js (63:14)
Generator.invoke [as _invoke]
node_modules/regenerator-runtime/runtime.js (293:0)
Generator.eval [as next]
node_modules/regenerator-runtime/runtime.js (118:0)
asyncGeneratorStep
<EMAIL_ADDRESS>(3:0)
_next
<EMAIL_ADDRESS>(25:0)

next-auth config:
export default NextAuth({
  providers: [Providers.GitHub(envConfig.get('gitHub'))],
  adapter: PrismaAdapter({ prisma }),
  session: { jwt: true },
})

Please search the old issues before opening a new one. #105 #115


Build warnings in the Windows Meson build we should fix

@Smit-create here are all the relevant build warnings from today's Windows build against numpy 1.21.5. Could you look into these?
[325/1557] Compiling C object scipy/sparse/linalg/_dsolve/libsuperlu_lib.a.p/SuperLU_SRC_cmemory.c.obj
../scipy/sparse/linalg/_dsolve/SuperLU/SRC/cmemory.c: In function 'cStackCompress':
../scipy/sparse/linalg/_dsolve/SuperLU/SRC/cmemory.c:649:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  649 |     Glu->stack.used -= (long int) fragment;
      |                        ^
../scipy/sparse/linalg/_dsolve/SuperLU/SRC/cmemory.c:650:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  650 |     Glu->stack.top1 -= (long int) fragment;
      |                        ^

The above one also happens in dStackCompress and the s/z variants.
[357/1557] Compiling C++ object scipy/special/_ufuncs_cxx.cp39-win_amd64.pyd.p/meson-generated__ufuncs_cxx.cpp.obj
scipy/special/_ufuncs_cxx.cp39-win_amd64.pyd.p/_ufuncs_cxx.cpp:659: warning: "_USE_MATH_DEFINES" redefined
  659 |   #define _USE_MATH_DEFINES
      |
<command-line>: note: this is the location of the previous definition
In file included from C:\hostedtoolcache\windows\Python\3.9.9\x64\lib\site-packages\numpy\core\include/numpy/npy_math.h:8,
                 from ..\scipy\special/_complexstuff.h:5,
                 from scipy/special/_ufuncs_cxx.cp39-win_amd64.pyd.p/_ufuncs_cxx.cpp:694:

[516/1557] Compiling C object scipy/stats/_unuran/unuran_wrapper.cp39-win_amd64.pyd.p/.._..__lib_unuran_unuran_src_methods_mvtdr.c.obj
In file included from ../scipy/_lib/unuran/unuran/src/methods/mvtdr.c:330:
In function '_unur_mvtdr_etable_new',
    inlined from '_unur_mvtdr_triangulate' at ../scipy/_lib/unuran/unuran/src/methods/mvtdr_init.h:978:11:
../scipy/_lib/unuran/unuran/src/methods/mvtdr_init.h:1760:17: warning: argument 1 value '18446744073709551608' exceeds maximum object size<PHONE_NUMBER>854775807 [-Walloc-size-larger-than=]
 1760 |   GEN->etable = malloc( size * sizeof(E_TABLE*) );
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ..\scipy\_lib\unuran\unuran\src/unur_source.h:71,
                 from ../scipy/_lib/unuran/unuran/src/methods/mvtdr.c:50:
../scipy/_lib/unuran/unuran/src/methods/mvtdr_init.h: In function '_unur_mvtdr_triangulate':
c:/rtools40/ucrt64/x86_64-w64-mingw32/include/stdlib.h:531:17: note: in a call to allocation function 'malloc' declared here
  531 |   void *__cdecl malloc(size_t _Size);
      |                 ^~~~~~

[564/1557] Compiling C object scipy/special/cython_special.cp39-win_amd64.pyd.p/meson-generated_cython_special.c.obj
scipy/special/cython_special.cp39-win_amd64.pyd.p/cython_special.c:645: warning: "_USE_MATH_DEFINES" redefined
  645 |   #define _USE_MATH_DEFINES
      |
<command-line>: note: this is the location of the previous definition
In file included from C:\hostedtoolcache\windows\Python\3.9.9\x64\lib\site-packages\numpy\core\include/numpy/ndarraytypes.h:4,
                 from C:\hostedtoolcache\windows\Python\3.9.9\x64\lib\site-packages\numpy\core\include/numpy/ndarrayobject.h:12,
                 from C:\hostedtoolcache\windows\Python\3.9.9\x64\lib\site-packages\numpy\core\include/numpy/arrayobject.h:4,
                 from scipy/special/cython_special.cp39-win_amd64.pyd.p/cython_special.c:681:

scipy/signal/_upfirdn_apply.cp39-win_amd64.pyd.p/_upfirdn_apply.c: In function '__pyx_fuse_1__pyx_pw_5scipy_6signal_14_upfirdn_apply_21_apply':
scipy/signal/_upfirdn_apply.cp39-win_amd64.pyd.p/_upfirdn_apply.c:14631:14: warning: '__pyx_v_row_size_bytes' may be used uninitialized in this function [-Wmaybe-uninitialized]
14631 |       (void)(memset(__pyx_v_output_row, 0, __pyx_v_row_size_bytes));
      |             ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/signal/_upfirdn_apply.cp39-win_amd64.pyd.p/_upfirdn_apply.c:14056:10: note: '__pyx_v_row_size_bytes' was declared here
14056 |   size_t __pyx_v_row_size_bytes;
      |          ^~~~~~~~~~~~~~~~~~~~~~

Many warnings like:
[936/1557] Compiling Fortran object scipy/sparse/linalg/_eigen/arpack/libarpack_lib.a.p/ARPACK_SRC_sgetv0.f.obj
../scipy/sparse/linalg/_eigen/arpack/ARPACK/SRC/sgetv0.f:404:32:

  367 |           call svout (logfil, 1, rnorm0, ndigit,
      |                                 2
......
  404 |          call svout (logfil, n, resid, ndigit,
      |                                1
Warning: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-1)

These rank mismatch warnings should be silenced by using -fallow-argument-mismatch, see the TODO comment in the top-level meson.build.
Also recording this one, but needs someone who speaks Fortran:
[999/1557] Compiling Fortran object scipy/stats/_mvn.cp39-win_amd64.pyd.p/mvndst.f.obj
../scipy/stats/mvndst.f:233:39:

  233 |       DOUBLE PRECISION COV(NL*(NL+1)/2), A(NL), B(NL), Y(NL)
      |                                       1
Warning: Array 'cov' at (1) is larger than limit set by '-fmax-stack-var-size=', moved from stack to static storage. This makes the procedure unsafe when called recursively, or concurrently from multiple threads. Consider using '-frecursive', or increase the '-fmax-stack-var-size=' limit, or change the code to use an ALLOCATABLE array. [-Wsurprising]

Not sure what the deal is with this one:
[1025/1557] Linking target scipy/stats/_biasedurn.cp39-win_amd64.pyd
Warning: corrupt .drectve at end of def file
Warning: corrupt .drectve at end of def file
Warning: corrupt .drectve at end of def file

../scipy/odr/__odrpack.c: In function 'odr':
../scipy/odr/__odrpack.c:1121:21: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'npy_intp' {aka 'long long int'} [-Wformat=]
 1121 |           printf("%ld %lld\n", PyArray_DIMS(work)[0], (long long)lwork);
      |                   ~~^          ~~~~~~~~~~~~~~~~~~~~~
      |                     |                            |
      |                     long int                     npy_intp {aka long long int}
      |                   %lld
../scipy/odr/__odrpack.c:1121:21: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'npy_intp' {aka 'long long int'} [-Wformat=]
 1121 |           printf("%ld %lld\n", PyArray_DIMS(work)[0], (long long)lwork);
      |                   ~~^          ~~~~~~~~~~~~~~~~~~~~~
      |                     |                            |
      |                     long int                     npy_intp {aka long long int}
      |                   %lld

Let's prioritize this one, since currently linprog (which uses HiGHS) is segfaulting:
[1474/1557] Compiling C++ object scipy/optimize/_highs/libhighs.a.p/.._..__lib_highs_src_mip_HighsImplications.cpp.obj
../scipy/_lib/highs/src/mip/HighsImplications.cpp: In member function 'bool HighsImplications::runProbing(HighsInt, HighsInt&)':
../scipy/_lib/highs/src/mip/HighsImplications.cpp:167:46: warning: 'implicsdown' may be used uninitialized in this function [-Wmaybe-uninitialized]
  167 |       if (implicsup[u].column < implicsdown[d].column)
      |

Could you look into these?

Yeah, will look into it.

With reference to this: https://github.com/rgommers/scipy/runs/5123938429?check_suite_focus=true

This is the warning from autogenerated code:

scipy/linalg/_interpolativemodule.c:554:1: warning: 'thread' attribute directive ignored [-Wattributes]
  554 | static F2PY_THREAD_LOCAL_DECL cb_matvect_in_idd__user__routines_t *_active_cb_matvect_in_idd__user__routines = NULL;
      | ^~~~~~

Okay, let's leave that one alone for now then. I think it is fixed in a more recent NumPy version already. At least we fixed one thread-related warning in f2py recently.

1760 |   GEN->etable = malloc( size * sizeof(E_TABLE*) );

This comes from the _unuran submodule. A probable fix for this is:
diff --git a/unuran/src/methods/mvtdr_init.h b/unuran/src/methods/mvtdr_init.h
index 333b693..42ca01e 100644
--- a/unuran/src/methods/mvtdr_init.h
+++ b/unuran/src/methods/mvtdr_init.h
@@ -1757,7 +1757,7 @@ _unur_mvtdr_etable_new( struct unur_gen *gen, int size )
   GEN->etable_size = size;

   /* make root */
-  GEN->etable = malloc( size * sizeof(E_TABLE*) );
+  GEN->etable = malloc(_unur_min(size * sizeof(E_TABLE*),<PHONE_NUMBER>854775807));
   if (GEN->etable==NULL) {
     _unur_error(gen->genid,UNUR_ERR_MALLOC,""); return UNUR_ERR_MALLOC; }

So, do I need to fix that here https://github.com/scipy/unuran.git?

@Smit-create yes indeed, that is the place to make a change. That fix doesn't look correct though (using a hardcoded number like that is almost always a sign of trouble). The problem here seems to be that in this line:
GEN->etable = malloc( size * sizeof(E_TABLE*) );

E_TABLE isn't defined. Searching further in that file:
VERTEX *
_unur_mvtdr_etable_find_or_insert( struct unur_gen *gen, VERTEX **vidx )
...
  E_TABLE *pet, *pet_last;  /* table entry */
  int idx[2];               /* store indices */
  int hidx;                 /* hash number */
...
pet = malloc( sizeof(E_TABLE) );

However, that's the wrong E_TABLE struct. There's a global definition in mvtdr_struct.h:
typedef struct s_edge_table       /* -- hash table for edges --------------- */
{
  int  index[2];                  /* index of incident vertices              */
  VERTEX *vertex;                 /* index of corresponding vertex (=barycenter) */
  struct s_edge_table *next;      /* next entry in list                      */
} E_TABLE;

The code seems to rely on both of these files being included in the correct order in mvtdr.c.
I'm guessing the fix is to use sizeof(E_TABLE) instead of sizeof(E_TABLE*). It's not clear to me though why this code works, and only gives a build warning on Windows.
Cc @tirthasheshpatel, in case this code is familiar to you.

Looks like we've fixed what needs fixing for now (modulo some discussion on the interpolative warnings PR). There's some warnings left, TBD later whether they need silencing. I'll close this.


ECL: Possibility to create Marker ticks asymmetric

In cases, when 2 parallel runways are too close to each other, would be more pleasing to draw Marker tick only on the outer sides of the runways, like that:

+1
We would appreciate having this option to generate realistic centerlines at EDDB.


Default the namespace config to the value of packageDir

These two values will almost always be the same to eliminate verbosity we should default the namespace since packageDir will always be required.
https://github.com/Azure/azure-rest-api-specs/pull/23866/files#diff-b7e75220b6f450282cba2075cfb681c5c83cbb0090b9e5d3784ba768c55a09b5R24

Already implemented in https://github.com/Azure/azure-rest-api-specs/pull/23866


chore(global): update safari user-agent to latest

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Thanks @chenrui333!


Keep original IDs, if unused in target diagram

Is your feature request related to a problem? Please describe.
As a user I'd like to paste contents from another diagram without loosing the original IDs.
Use case: Merge diagrams by pasting conflicting parts from one diagram to the other.
Describe the solution you'd like

[ ] Keep IDs when inserting copied contents, if the IDs are not taken yet in the target diagram

Describe alternatives you've considered
None.

Related to SUPPORT-4777

IDs are explicitly removed via https://github.com/bpmn-io/bpmn-js/blob/develop/lib/features/copy-paste/ModdleCopy.js#L219

We will not be able to deliver this for milestone M50 - I will get in touch with the CSM responsible to inform the customer

Great job @barmac! <3 that we have this

That's confusing :/ Thanks for reporting!

As discussed I created a failing end-to-end test case here: bpmn-js#copy-paste-failing.


updates/tests shortlink string matching

re-did PR #1963

added unit tests
added a more specific RegEx clause to match issue numbers enclosed in parentheses
added a RegEx clause to catch invalid trailing characters. #1900W is considered a match in the current RegEx pattern.

The RegEx is more long-winded than before but easy to test.

Awesome!
Sent with GitHawk

actually this is farting up downstream.. the issue links aren't working when you tap on them, needs more work.


(GH-83) Allow for workspace configuration overrides

This commit introduces workspace configs.
If a pct.yml exists in the template creation directory, it will use those over user config, which is used over template defaults.

Can be used with https://github.com/puppetlabs/baker-round/pull/16

Looking great! We need to update the Overriding Template Defaults section of the README as well so we document the additional override.

PR now up, we had docs a seperate ticket https://github.com/puppetlabs/pdkgo/pull/122

You are correct, I got myself confused. Still need a changing entry here though


Guide for Clarity values

The Clarity Type system is mostly documented in the references. We should better document types in the smart contract category. This guide should include:

[ ] Type description for all types (including string)
[ ] Type declaration / instantiation
[ ] Type samples
[ ] Encoding/Decoding details
[ ] Library support
[ ] Helper methods (cvToString, )

This might be helpful: https://github.com/blockstack/stacks.js/tree/master/packages/transactions#constructing-clarity-values


FAST Templates removing IP address parameter

Environment

FAST RPM Version: 1.23.0
BIG-IP Version: <IP_ADDRESS>

Summary
The default HTTP and IIS fast templates would normally have a parameter for the IP address of the Application's virtual servers.  The option is shown right below the Application name and above the port when DNS is not provisioned.  Provisioning DNS on the device adds the capability to fill in the WideIP name, but it appears that the WideIP is a required field now for the virtual_address parameter to be a part of the template. Also appears on earlier versions like 1.22.
Steps To Reproduce
List the steps to reproduce the behavior:

Verify that Virtual Address is an option on the HTTP template to deploy a new application
Provision DNS to Nominal
Attempt to create a new application using the HTTP template.  The Virtual Address parameter is not shown.
Adding a WideIP name allows you to see the Virtual Address parameter at the top again.
Clearing the WideIP name removes the parameter again

Expected Behavior
Adding the WideIP should be optional behavior on the HTTP application template if DNS is available. Adding a WideIP should not be required to enter a user specified IP address for the application.
Actual Behavior
It appears that the user is unable to specify an IP address for the application via the GUI when a WideIP is not specified and DNS is provisioned.
Using curl and the API calls I was able to deploy an application with a specific virtual_address using the template, but reconfiguration via the GUI removes the custom IP address.
DNS Not Provisioned Template looks normal

DNS Provisioned and using the default HTTP template with no WideIP name

Add a WideIP Name at the bottom of the template

DNS Provisioned with a WideIP Name specified, the box appears again

Upon further looking at it when DNS is provisioned and a WideIP name is filled out the VIP IP box shows up, but it does not appear to have the value in the input at the bottom nor does it change the rendered output.  It looks like DNS provisioning just removes that value from the template.

Thank you for reporting this issue. It is preventing an HTTP template deployment on a device provisioned with GTM unless the DNS FQDN is provided for the Wide IP.
If you do provide the FQDN and then the Virtual Address, a new GSLB_Domain and GLSB_Pool is created, and the Virtual Address would appear in both the GLSB_Pool as the fallbackIP and in the Service_HTTPS as the only Virtual Address.
Is that what you are seeing?
I currently have a fix I am discussing with the Project Manager and some version of it should become available soon. Will you want a temporary EHF or patched RPM, or would you rather opt to wait for FAST v1.24 to be publicly released?

So even filling in the name didn't actually fix it for us.  We tried that used a temporary name and the template showed us the IP address field again, but when we went to deploy the inputs/render at the bottom showed that it was ignoring the IP address we entered.
We can wait for 1.24 as using the API lets use deploy for now, but moving forwards we would want the GUI functionality back.
Thank you.

Oh and the issue also showed up in the IIS Template as well. That makes sense to me since it looks like they're referencing the same libraries underneath.

This issue is being tracked internally with ID, EC-65.

In the next release of FAST, v.1.24.0, there will be two additional templates that have DNS WideIP settings that fix this issue you have reported.
The DNS FQDN will display at the top of the form, right after the virtual address - which you can see and set before the FQDN has a value.
If you deploy one of the new HTTP with Wide IP or IIS with Wide IP templates without setting the FQDN, it will work, but it will also create an unused GSLB_Pool -- which is why we had to create two new templates just for the Wide IP.
Additionally, you can now use IPAM to configure the virtual address and fallbackIP in the two new templates.
If you have deployed applications with the old templates, they will be converted to the new Wide IP version automatically in this new version as well.

Closing.
This issue was resolved with Release 1.24.0.


Only parse json if it's defined in oauth startup test

Fixes the following problem:
When the bouncer does the startup test and the token URL is not reachable the bouncer fails without logging anything:
undefined:1
bouncer_1         | undefined
bouncer_1         | ^
bouncer_1         |
bouncer_1         | SyntaxError: Unexpected token u in JSON at position 0
bouncer_1         |     at Object.parse (native)
bouncer_1         |     at Request.request [as _callback] (/bouncer/index.js:102:21)
bouncer_1         |     at self.callback (/bouncer/node_modules/request/request.js:186:22)
bouncer_1         |     at emitOne (events.js:96:13)
bouncer_1         |     at Request.emit (events.js:188:7)
bouncer_1         |     at Request.onRequestError (/bouncer/node_modules/request/request.js:878:8)
bouncer_1         |     at emitOne (events.js:96:13)
bouncer_1         |     at ClientRequest.emit (events.js:188:7)
bouncer_1         |     at Socket.socketErrorListener (_http_client.js:310:9)
bouncer_1         |     at emitOne (events.js:96:13)
bouncer_1         |     at Socket.emit (events.js:188:7)
bouncer_1         |     at emitErrorNT (net.js:1281:8)
bouncer_1         |     at _combinedTickCallback (internal/process/next_tick.js:80:11)
bouncer_1         |     at process._tickCallback (internal/process/next_tick.js:104:9)

added some bugfixes to allow usage with the o2r-guestlister
update documentation for OAuth configuration and bouncer sessions


Added a 'check_for_empty_taps' function to fix issue #585 and related

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

I've added a new test to the diagnostic.rb file to check for empty tap directories and remove them. This specific problem was discussed in issue #585. Hope this helps :)

I'm uncomfortable with a doctor check that, without any sort of upfront warning, has the potential to take an axe through the Taps directory.
I think we should stick to the standard doctor pattern of nudging users to do it themselves, or extend prune to cover this functionality since this sort of behaviour is more standard to & expected from prune.

I can definitely change the check to do just that, have doctor warn the user and ask them to run brew prune to remove the folders or to do it themselves. I'm not sure how this could really run amok as the directories must be empty. I'm also new to ruby, so it's very possible I missed something.

I can definitely change the check to do just that, have doctor warn the user and ask them to run brew prune to remove the folders or to do it themselves.

That would be ideal 👍. You wouldn't even necessarily need to rope in brew prune there. You could just throw a warning with the empty folders (inject_file_list might work for this) and tell users they should consider executing rm -r them, or such.

I'm not sure how this could really run amok as the directories must be empty for them to be touched, and it's only in that one Taps folder.

It's not necessarily that it could run amok that I'm worried about; I think our diagnostic checks themselves having the power to remove elements is something that would violate the principle of least surprise, and I'm worried about "mission creep" on that if we introduced it. I think our diagnostic checks being advisory rather than mandatory is a sensible path to keep following.

I'm also very new to ruby, so it's very possible I missed something.

I've been doing this for a fair while & I'm still terrible with Ruby. You're doing alright 😃.

Took your advice :), now brew doctor recommends cd $(brew --prefix)/Library/Taps && rmdir * instead of outright removing the files.

Thanks for making a PR for this! Made a few comments.

I think this is better now, thanks for the feedback!

@lewisinc Have you had a chance to look at updating this PR based on the comments? Thanks!

Will review this PR when changes addressed. Thanks!


Release 1.2.3

No review needed.

Coverage increased (+0.007%) to 32.666% when pulling 72392c92f463dbafb69b0b65a88f3b50ec50fc94 on release_1.2.3 into 4ec5b14eb28d7cd3b14221e5e5af165a5b300800 on stable_1.2.


Alltrails map not showing terrian layer

Embed should look like this:
    <iframe
      class="alltrails"
      src="https://www.alltrails.com/widget/trail/us/washington/mount-si-via-old-si-trail?u=i"
      width="100%"
      height="400"
      frameborder="0"
      scrolling="no"
      marginheight="0"
      marginwidth="0"
      title="AllTrails: Trail Guides and Maps for Hiking, Camping, and Running">
    </iframe>

With all trails map in a closed accordion component map layer doesn't show, having accordion open on page load allows it to load properly.


Unable to reproduce results

Hello,
Thank you for your research efforts, your work was very interesting to read, I however have some questions regarding how to replicate the results described in the paper.
Running all default settings with the exception of --map "cologne1" and --behavior_policy "EMP", the resulting model seems to get stuck on a single phase, with the delay time around 20 seconds, because the vehicle flow is stopped. I have also tested on 2lane and had the same results. Is there an issue with the default settings?
Additionally, the yellow phase seems to be broken in the string comparison inside prep_phase, resulting in no yellow phases.
Thank you for your assistance.

Hi,
Thank you for your interest in our project and for taking the time to investigate this issue. I've reviewed the code and tested the model, but I couldn't replicate the problem you described regarding the stuck phase. I've attached a screenshot showing the phase selections, and everything seems to be functioning correctly with the teacher/student and online models.

Regarding the SUMO environment settings, I've utilized the same code as the RESCO benchmark without significant modifications. However, if you could provide more details about the issue you're encountering, and perhaps include some screenshots, it would greatly assist in diagnosing the problem more accurately.

Hey really great repo you got here. I came to know this by reading your paper wonderful research... congrats!.. While going through I got a doubt... In the .rou files you have created for the environments.. How do you calculate the maximum number of vehicles that the network can handle? In my personal project.. while using multi-agent environments.. vehicles get stagnated at the end of a single iteration in sumo. Can you please explain  how to prevent this issue and what method you used?

This issue happens with both MA2C and MAXPRESSURE config policy, as well as IDQN and EMP behavior policy. It appears that once vehicles reach a certain lane density, the agent stops selecting that phase altogether. In this specific screenshot of the teacher model, it happened around 3200 steps and remained the same action for the remainder of the simulation.
Another example with IDQN behavior_policy + MAXPRESSURE config_policy, occuring around 2700 steps and remaining on the N_S phase until the simulation ends

 (teacher model) This issue happens with both MA2C and MAXPRESSURE config policy, as well as IDQN and EMP behavior policy (the only ones I have tested). It appears that once vehicles reach a certain lane density, the agent stops selecting that phase altogether. In this specific screenshot of the teacher model, it happened around 3200 steps and remained the same action for the remainder of the simulation.
Another example with IDQN behavior_policy + MAXPRESSURE config_policy, occuring around 2700 steps and remaining on the N_S phase until the simulation ends  (distillation model)
 (finetune model)
I am curious what is causing this. Thanks!

Thank you for pointing this out. Upon running the code from the clean repository, I encountered some issues that were not present in my local repository. It appears that I may have deleted something by mistake when uploading the clean repository. I have since made the necessary corrections and ensured that the datasets are accurate. I retested the repository for all scenarios and reproduced similar results to those shown in my paper. I hope this resolves your concerns.

Hey really great repo you got here. I came to know this by reading your paper wonderful research... congrats!.. While going through I got a doubt... In the .rou files you have created for the environments.. How do you calculate the maximum number of vehicles that the network can handle? In my personal project.. while using multi-agent environments.. vehicles get stagnated at the end of the simulation in sumo. As a result the waiting time of the system keeps on increasing like a curve. Can you please explain how to prevent this issue and what method you used?

Hey, thanks for your interest. I didn't calculate the maximum number of vehicles the network can handle but adjusted some key args in randomTrips.py to generate a proper route file.