create address on Ethereum L2 like Polygon?

Was looking through the code to see if we can designate an RPC Url and Chain ID to create an address and wallet on different EVM blockchains, like Polygon.

I need to specify a chain id too in Polygon.

Ethereum Addresses are the same across all EVM based chains.

Ah yes I guess I wanted to also interact with the address for getting the balance and so forth. So assumed we need to be able to specify network.
I am trying to use the library in my flutter app but have had issues generating the public address.
I will paste it here.

@timfong888 Please paste your code

@TheGreatAxios
Here is what I wrote, and I get an error:
import 'package:web3dart/web3dart.dart';

Future<String> getPublicAddress(String privateKey) async {
  // Add your function code here!

  final credentials = EthPrivateKey.fromHex(privateKey);
  final address = credentials.address;

  print(address.hexEip55);
}

The error: undefined name "EthPrivateKey"

@timfong888 Technically, that should be the correct code. Looks like it is cookie cutter of the docs/examples.
Can you please send the error code in here so I can see a bit more detail.
I had thought that the EthPrivateKey was a top level import from web3dart, however, you could try
instead of importing web3dart the following
import 'package:web3dart/credentials.dart
That direct import may solve your issue, if it does please let me know and I will dig a bit deeper into the library to see if there is a reason it is not being resolved at the top level.

I need to specify a chain id too in Polygon.

@jvinai Did you figure out how to specify a network yet?

@TheGreatAxios thanks, yes, it looked right to me.  I just copied the docs/examples, but can't get it to work or compile.
I'll add the import line.  I assume I need the entire web3dart library or just credentials?

@TheGreatAxios I ran, i get an undefined name as above, but also error running "flutter pub get" -- please check dependencies in pubspec.yaml.
I have seen this before where the dependencies of the library, such as web3dart, collide with other common dependencies.  But I don't see from the error what those are.

An entire library generally provides access to all the modules.
It is good practice to only import what you need by choosing specific files and then modules:
Example
import 'package:web3dart/credentials.dart' show EthPrivateKey
This should get you the exact module you need.
If it is not showing up then the package is not installed properly.
Please provide any errors you can here. It may make this process easier to find you a solution.

This is the error that I get, so I am guessing that it has to do with a dependency that is used.

@TheGreatAxios I found the dependency conflict. Not sure if we can work around it. It references code that must be part of flutter because I haven't written it.
Because every version of flutter_test from sdk depends on async 2.8.2 and web3dart >=2.4.0 depends on async ^2.9.0, flutter_test from sdk is incompatible with web3dart >=2.4.0.
So, because assembly depends on both web3dart ^2.4.0 and flutter_test from sdk, version solving failed.

That makes sense, I agree.
@xclud Ive never tried this, but for conflict dependencies can we make it a range in order to meet both requirements?

I am trying to build with the following: flutter update-packages --force-upgrade
This would force change the async version for flutter_test...not sure what will happen though.

I get another error: Because every version of flutter_test from sdk depends on collection 1.15.0 and web3dart >=2.4.0 depends on collection ^1.16.0, flutter_test from sdk is incompatible with web3dart >=2.4.0.
So, because assembly depends on both web3dart ^2.4.0 and flutter_test from sdk, version solving failed.
I am forcing upgrades in my pipeline, but thought I would share this back out.

Hi everyone,
I just updated the dependencies. Version 2.4.1 should solve the conflict issue.

@timfong888 Please upgrade and give a test, then this can be closed if it works.
Thanks @xclud


feat: allows JWT tokens to have extra attributes specified.

Pull Request Checklist

[x] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

Description
Without this fix, the user most override the Token and the decode method if the JWT token contains parameters not defined.  This fix moves any extra attributes on the token to an _extras attribute.
Close Issue(s)

I think this covered all of the open items on this.  It's ready for a final review.


Queryable Unified Inventory API

This pull request encapsulates a proposal for an Inventory API for Sponge. At the core it is based upon #242 by @gratimax but is revised and expanded to include the proposition outlined below. Please read all of this document before commenting on design specifics within this PR.
This is my first PR to the API side of things so be gentle.
Design Proposal for a Queryable Unified Inventory API
Many of the proposed systems for dealing with inventories in Sponge have been very close to the underlying Minecraft implementation of inventories, there are a number of drawbacks with this model:

Inventory topology is bifurcated into "Inventories", generally describing an actual container (the Model), and "Containers" which present a code-facing view of one or more "Inventories" (the ViewModel). Which has its own problems:
Generally the physical layout of the Inventory and the physical layout of the Container are not contractually linked in any meaningful way.
The terminology when referring to one or other of these constructs gets very wooly very quickly (especially with Containers that have a 1:1 mapping of "slots" to underlying Inventory position).

The View in this instance (taking MVVM as our template) is a client-only user-facing object responsible for displaying the Container to the user.

Working with different types of inventory requires prior knowledge of the inventory's internal layout (interface is coupled invisibly to implementation) because there is no way to obtain meta information about a specific Inventory or Container. This means that:
consumers have to deal with the characteristics of specific inventories, and any code which wants to deal with different types of inventory must do so by handling each inventory type directly
This makes the API extremely brittle and not particularly extensible, since any types of inventory which are not known about in advance cannot be efficiently interacted with
Code which consumes the inventory API is forced to make assumptions which must then be forcibly invalidated (for example by throwing an exception) should the underlying behaviour of a particular inventory change. eg. the same brittleness applies to "built in" inventories as to mod-provided inventories over time and there is no way to deal gracefully with this.
In other words, assumptions have to be made, but there is no programmatic way for a consumer to validate those assumptions prior to operation
Because of the blurring of the distinction between Inventory and Container, functionality is cross-contaminated between the two concepts, and this lack of separation of concerns tends to (in turn) pollute any API which tries to faithfully replicate it.

Design Goals
The aim of this proposal is to address these shortcomings in the following ways:

Devise an API where describing an Inventory is a core aspect of interacting with an Inventory, essentially making Inventories aspect-oriented.
Provision for extensibility by allowing consumers to query an Inventory for the particular aspect they are interested in, and manipulate the inventory via the results of their queries.
Create a clear separation between Inventory and Container concepts but acknowledge their overlaps, by making Container essentially another aspect that an Inventory can have.

Starting Assumptions
As Morpheus famously said to Neo: "free your mind".
To begin talking about a new structure for Inventory interaction, it's necessary to forget everything you currently understand about Inventories. Done that? Okay, let's start with the basic concepts.
Common Inventory Operations
If we make no other assumptions about an inventory, we can essentially begin by declaring that, in many ways an Inventory exhibits the same behaviour as a Queue in that we can add items to the Inventory, consume items from the Inventory, and get the underlying capacity of the Inventory.
interface Inventory {
	/**
	 * Get and remove the first available stack from this
	 * Inventory
	 */
	public abstract Optional<ItemStack> poll();

	/**
	 * Get without removing the first available stack from this
	 * Inventory
	 */
	public abstract Optional<ItemStack> peek();

	/**
	 * Try to put an ItemStack into this Inventory. Just like
	 * Queue, this method returns true if the Inventory accepted
	 * the stack and false if not, the size of the supplied
	 * stack is reduced by the number of items successfully
	 * consumed by the Inventory.
	 */
	public abstract boolean offer(ItemStack stack);

	/**
	 * The number of stacks in the Inventory
	 */
	public abstract int size();

	/**
	 * The maximum number of stacks the Inventory can hold
	 */
	public abstract int capacity();
}

Note that our base implementations of poll and offer don't provide any position information, this is because we are not making any other assumptions about the structure of the Inventory at this point. While this might seem like an odd baseline, it begins to make sense when we consider that with a query-based Inventory API, we will be returning inventories which fall into one of the following three categories:

Empty Inventory - to provide for a fluent interface we don't want to return null, the Empty Inventory will be our representation of an empty result set.
Single-Stack Inventory - an Inventory with a single stack is effectively a Slot. By keeping the Inventory interface simple enough that a Slot can reasonably extend it, we have simple unified way of a query returning anything from an entire Inventory, to a specific set of matching slots, to a single slot containing an Item we're looking for.
Multi-Stack Inventory - other inventories which can contain more than a single stack.

Basis and Purpose of Queries
Before we look at how queries can work, let's first take a look at a simple use-case to understand the purpose of queries in the first place.
The PlayerInventory class actually encompasses several groups of inventory slots we may be interested in. These groups are internally (physically) separated into two arrays: the Main Inventory and the Armour Inventory. The Main Inventory comprises both the hotbar area (the 9 inventory slots always displayed on the screen) and the rest of the player's main inventory. Representing this as a basic Venn Diagram we see:

When working directly with Minecraft, the two inner inventory arrays are available directly as public members of the InventoryPlayer class. However some additional functionality is available which supports both the ViewModel-esque contract required by Containers and also some additional convenience functions for working with only the hotbar slots. Some notable drawbacks with this mixing of concerns is that the following become apparent when working with the PlayerInventory:

Some methods treat the slots within the inventory as a contiguous set, and treat the Armour Inventory as indices beyond the Main Inventory indices whereas other code does not, this presents an inconsistent external interface.
Conversely, some methods only deal with the hotbar slots, and not the rest of the Inventory
No distinction is made between any positions in the inventory, thus external code has to "know" the meaning of slot indices within the Inventory in advance. (A problem not confined to the InventoryPlayer class)

It should be noted that this scenario is far from unique amongst inventories, and only gets worse when dealing with Containers. For example let's take a look at a container which you're likely to be very familiar with, ContainerPlayer:

This container presents a View of 3 separate Inventories (essentially ViewModels) which in turn represent 4 distinct underlying arrays of slots (essentially the underlying Models).
You may find yourself asking "so what the hell does all this have to do with queries?" and that's a fair question. Ultimately we have 3 ways of dealing with this mess in order to improve it from the point of view of API consumers:

Abstract the hell out of things. Provide "sensible" external interfaces and break everything down into small logical units which hide the underlying horribleness.

Pros:

easy to work with from a consumer's point of view
hides all the horrible internals

Cons:

nasty to maintain (if anything in the implementation changes then the abstraction could get more and more complex)
hard to extend (mod inventories and and kind of custom inventory are hard to work into this model because the abstractions themselves are "hard coded")
makes simple operations more complex than they need to be (consumers need to explicitly dig through layers of abstraction to get to what they want)
doesn't actually add any value, just hides all the nastiness

Expose the underlying horribleness but provide a metadata system which assigns meaning to the exposed data structures, such as allowing a "range" of slots to be described.

Pros:

doesn't add much overhead
keeps people who are used to the old system happy
provides added value in terms of some meta information about the meanings of slots

Cons:

just as brittle as the underlying impementation
doesn't provide any useful abstraction

(Using queries) Make metadata an intrinsic part of the API and allow consumers to stipulate exactly what part of an inventory they mean by accessing inventory via the metadata using queries:

Pros:

All the advantages of both option 1. and 2. (the underlying representations without metadata are still accessible via casting down - see implementation details below)
Consumers only ask for what they need, they never need to care about what type of Inventory or Container they're dealing with, only the results of a query
Intrinsically extensible - the nature of queries makes it easy for third-party extensibility without removing the ability to do simple instanceof-and-cast operations which would have been required before.

Cons:

May be difficult for consumers to adjust to the new model (although the nature of the implementation means that stick-in-the-muds can still use the old model if they're foolhardy enough)
Underlying implementation is more complex than other systems (however it should be noted that all the complex logic will be handled in the initial implementation, and that ongoing maintenance of the system will actually be simpler)

Presented with the options it's clear that option 3, using queries has merit.
Goals for a Query-based implementation
Fundamental to the concept of querying Inventories is the basic premise that:

An Inventory is a View of one or more "sub inventories"
An Inventory and its sub inventories exist in a parent-child relationship
An Inventory is thus a View of Views with arbitrary depth

In the InventoryPlayer example above, the relationship of the Inventory to its notional sub-inventories is as follows:

The main idea of queries is that given an unknown Inventory instance, it should be possible to query for any sub-inventory or combination of matching sub-inventories, with the query returning either all sub-inventories which match the query, or an empty set if no sub-inventories matched the query.
It's useful to bear in mind that our above definition of Inventory essentially means that everything can be represented as an Inventory right down to Slot (defined as an Inventory with only a single position) and thus a more helpful representation when considering what can be returned by a query is the following:

We're now in a position to specify what a query should actually return:

A Query should return all Sub Inventories of the Inventory which match the supplied criteria
If a sub inventory is included in the results set, its parent will not be
A query will never return a null result, it will return an Empty Inventory object.
A query will never return duplicate entries

Which produces as a consequence some assumptions for Inventory itself:

The result of a query is always an Inventory
An Inventory is Iterable<Inventory> and the returned iterator traverses the child nodes of the Inventory's hierarchy
An Inventory's leaf nodes should also be traversable via a method which returns an Iterator

To give some examples, based on the hierarchy above:

A query for an imaginary Hotbar.class should return the Hotbar inventory
A query for ItemTypes.TNT should return an Inventory with all of the slots containing TNT
A query for the imaginary InventoryRow.class should return each row in the Main Inventory and the Hotbar

Which produces the following assumptions:

When performing a query, if an Inventory matches the query directly, it should return itself
When performing a query, an Inventory should perform a depth-first search of its hierarchy. A matching child node will remove its parent from the results set if present.
If no children match the query, the query should return an EmptyInventory.
If all direct children match the query, the query should return the parent (eg. if all InventoryRow children within an InventoryGrid match the query, then the InventoryGrid is returned)

We now have enough information to begin formulating our query interface.
Inventory methods for query results
Since the result of a Query will always be an Inventory, we add some decoration and methods to our Inventory interface. Firstly, we have the Inventory extend Iterable<Inventory> as planned. Next we add a method for iterating the leaf nodes of our Inventory and a convenience function for checking whether the Inventory has no slots:
interface Inventory extends Iterable<Inventory> {
	//
	// ... code code code (see above) ...
	//

	/**
	 * Returns an iterable view of all slots, use type specifier to
	 * allow easy pseudo-duck-typing
	 */
	public abstract <T extends Inventory> Iterable<T> slots();

	/**
	 * Returns true if this Inventory contains no children
	 */
	public abstract boolean isEmpty();
}

Depending on requirement, we may also wish to add some convenience methods to work with Inventorys which are result sets, for example
	/**
	 * Return the first child inventory, effectively the same as
	 * Inventory::iterator().next() but more convenient when we are
	 * expecting a result set with only a single entry. Also use type
	 * specifier to allow easy pseudo-duck-typing. If no children, then
	 * returns this.
	 */
	public abstract <T extends Inventory> T first();

	/**
	 * Return the next sibling inventory, allows traversing the inventory
	 * hierarchy without using an iterator. If no more children, returns
	 * an EmptyInventory.
	 */
	public abstract <T extends Inventory> T next();

Inventory methods for executing queries
It is anticipated that the full scope and possibilities of queries will only become apparent in time, and also that the initial system should be sufficiently extensible to support quite a wide scope of potential queries. However the basic query types which should be in the initial release are:
Query by type
public abstract <T extends Inventory> T query(Class<?>... types);

Query for sub-inventories matching the specified interfaces/concrete classes (effictively an instanceof check). Multiple classes can be specified and logical OR will be applied.
Example 1:
Inventory inv = ...; // An unknown inventory
PlayerInventory pinv = inv.query(PlayerInventory.class).first();

Example 2: Logical AND (querying the result of a query)
Inventory inv = ...; // An unknown inventory
HotBar hotbar = inv
	.query(InventoryRow.class)
	.query(HotBar.class).first();

Query by contents
public abstract <T extends Inventory> T query(ItemTypes... types);

Query for slots containing ItemStacks with items of the specified type. A logical OR applied between query operands.
Example:
Inventory inv = ...; // An unknown inventory
Inventory slotsWithTNT = inv.query(ItemTypes.TNT);
if (!slotsWithTNT.isEmpty()) {
    // found slots with TNT!
}

Query by property
As well as defining a (possibly multi-dimensional) hierarchy of sub-inventories, it is anticipated that some sub-inventory types will tag their members with additional data which can be used to include them in queries. For example, let's assume that we have a GridInventory interface:
/**
 * MetaInventory(?) stores arbitrary properties for child inventories
 */
interface MetaInventory extends Inventory {
	/**
	 * Get a property defined in THIS inventory for the specified
	 * (immediate) sub-inventory.
	 */
	public abstract <T extends InventoryProperty> getProperty(Inventory child, Class<T> property);
}

/**
 * This type of inventory arranges its children in a grid.
 */
interface GridInventory extends MetaInventory {
	/**
	 * Get the number of rows in the grid
	 */
	public int getRows();

	/**
	 * Get the number of columns in the grid
	 */
	public int getColumns();

	/**
	 * Get the X/Y position of the specified slot. The InventoryPos
	 * class extends InventoryProperty and thus this method is just a
	 * convenience method which effectively calls:
	 *
	 *    this.getProperty(slot, InventoryPos.class);
	 */
	public abstract InventoryPos getSlotPos(Inventory slot);
}

Assuming that InventoryPos extends some ficticious base class InventoryProperty, we now have a mechanism for querying by any arbitrary properties we care to define:
public abstract <T extends Inventory> T query(InventoryProperty... props);

Query for sub-inventories where the specified property is set and .equals() the supplied properties. Logical OR is applied between operands.
Example:
Inventory inv = ...; // An unknown inventory
Inventory slots = inv.query(new InventoryPos(2, 2)).first();

Query by name
Since in the real world, Inventory classes are always nameable, we can use a String overload to query by name:
public abstract <T extends Inventory> T query(String... names);

Query by arbitrary operands
To promote extensibilty, even where completely unknown Inventories are in play, we should also include a general query interface which will allow arbitrary queries to be executed:
public abstract <T extends Inventory> T query(Object... args);

Query for sub-inventories using an arbitrary check defined by the inventory class in question.
Example:
Inventory inv = ...; // An unknown inventory
SomeObject someObject = ...; // Something
Inventory result = inv.query(someObject); // ???

Multi-Dimensional Query Model
So far, for simplicity we have outlined a straightforward hierarchical model of the inventory. However it is not the intention that underlying implementations should adopt such a simple model. To facilitate querying by dimensions, we can represent underlying sub-inventories in as many different dimensions as we like, and allow queries to return corresponding views. For example we can expand our simple example above to allow the Inventory to be queried by column:

In this example the InventoryGrid contains both row and column sub-Inventories. This is by no means the limit of what can be represented by further dimensions. However note that one tree should always be considered the master view (a notional appellation), a traversal of which visits each leaf node in a deterministic order which is the iteration order as experienced by slots().
Essentially every Inventory should have a deterministic spanning tree, whose depth-first traversal will be the primary iteration order of the leaf nodes. This order is left to implementors to decide upon. Here is an example for the inventory structure shown above.
Example Spanning Tree for the Player Inventory

Example traversal of the Spanning Tree

Implications for Intended Usage
So far we have seen how queries can work in general, the main goals of incorporating queries into the API are to change the general way that consumers interact with Inventories. Without queries, a typical interaction with an Inventory might take place as follows:

Consumer obtains an Inventory instance from an API object. The inventory is of a known type - eg. a PlayerInventory is obtained from a Player because it is advertised by the object.
Knowing the type of inventory, the consumer performs some operations on the inventory: for example moving items from the main inventory to the hotbar, or consuming items from the inventory.

Now if the same code wishes to interact with a different type of Inventory, the code has to be adapted or rewritten, even if the other inventory has substantially the same behaviour or characteristics.
With a query-based approach, the interaction takes place as follows:

Consumer obtains an Inventory instance from an API object. The inventory is not a specialised type, the return type of the getter is simply Inventory.
The consumer queries for the inventory characteristics it requires, for example it queries for all InventoryRows
The consumer interacts with the returned rows, or can simply skip processing if the query returns an empty set.

If the same code wishes to interact with a different type of Inventory, it can do so as long as the Inventory has InventoryRow children.

SIDE NOTE
Consider porting of old code. Old code may simply (as a stop-gap) wish to obtain the PlayerInventory and manipulate it directly, without any queries. With queries this is still supported as long as PlayerInventory is provided as an interface in the API. Consumers wishing to perform legacy interactions can either:

Query directly for the InventoryPlayer interface (this works because of assumption 1 of queries - if an inventory matches a query it simply returns itself)
Use an instanceof check followed by a type cast

This provides a convenient way for legacy code to be ported quickly to the new system, and transition to a full query-based implementation at the convenience of the plugin author.

Taking the intended usage into account, we can deduce some additional characteristics our API should have:

Any API object which has an Inventory should simply return Inventory, with no requirement to return a particular subinterface

Consumers should always obtain Inventory subclasses by querying for them (either directly or via instanceof check)

Specific Inventory subinterfaces should still be provided within the API in order to satisfy queries, however they should not generally be returned and different implementations are therefore at liberty to select whichever interfaces they wish to implement - in other words there is no hard rule that says a PlayerInventory must have InventoryRows as children for example, the query model means that this is purely optional and the only negative effect would be that consumers expecting such a structure would not be able to perform their operations.

This works in both directions however, and while it is expected that all implementations will likely follow similar conventions (in order that queries can be relied upon across platforms), it's also possible that some implementations will be able to innovate, and extend their capabilities without in any way breaking backward compatibility.
The implication of all this is that the shape and design of the underlying Inventories is thus free to follow a logical representation of the underlying game without at any point breaking backward compatibility.

This in turn leads us to the conclusion that the number of "specific" inventories should be kept to a minimum, and general-purpose Inventory interfaces should be used wherever possible. The general-purpose Inventory interfaces should essentially represent characteristics of inventories, with little regard for specific Inventory types.

Relationship with Containers
It should be clear by now that a query-based model also solves the Container problem. By acknowledging that the line between Inventory and Container can often be blurry, we can treat Containers as Inventories for the most part (since we have essentially turned Inventory into a ViewModel at this point anyway, and all a Container really is is a ViewModel) and simply have them exist as yet another type of SubInventory interface.
Features not included within this PR
Taking a longer view, the following features are worthy of consideration

Inventory Transactions - basically SQL transactions but for Inventories allowing commit and rollback operations

Aggregate Inventory Operations - basically SQL join for queries, such that a logical union of inventories can be created and subsequently queried and operated upon as if it were a single inventory. This isn't too hard to do I just don't have sufficient time to flesh it out.

Atomic Multi-Inventory Operations - as a poor second choice to full-blown transactional behaviour, having atomic operations (get-stack-from-first-inventory, deposit-in-second) would still be useful.

Cookies - congratulations, if you read this far you get a cookie (Not a real cookie, an imaginary one. What? You think I'm made of cookies or something?)

Cookies - congratulations, if you read this far you get a cookie (Not a real cookie, an imaginary one. What? You think I'm made of cookies or something?)

Can I have a cookie for being patient and waiting for this PR to be made?

@gabizou no you may not.

Some small notes to the code style:

We don't use any redundant modifiers on interface methods to keep the interfaces clean, so we need to remove the public abstract prefixes in some of the interfaces here.
Some classes are missing Javadocs and some methods are missing @param and @return tags.
The normal Javadoc description should have an period at the end, the description of the tags shouldn't.

I've also noticed a few events in here that are already in the SpongeAPI.

We don't use any redundant modifiers on interface methods to keep the interfaces clean, so we need to remove the public abstract prefixes in *some* of the interfaces here.

Okay that's fair enough, this is my first contribution to the API so I expected their would be style differences. I always use the modifiers just because it seems more readable but I can remove them no problem.

Some classes are missing Javadocs and some methods are missing @param and @return tags.

To be honest the plan was to flesh out the javadoc later, I wanted to wait until all the I's were dotted and T's were crossed but I've been too busy and @Zidane was probably going to murder me if I took any longer. Basically take a view that if there is some Javadoc, it'll get fixed later when I have two seconds to rub together, either that or someone else can beat me to it.

The normal Javadoc description should have an period at the end, the description of the tags shouldn't.

This isn't anywhere in the style guide, I'm not sure how I was supposed to know this.

I've also noticed a few events in here that are already in the SpongeAPI.

Likely because @gratimax already added them before they were added to the API. I'm sure redundant events can be removed. Any ideas which ones?

@Mumfrey Wasn't sure if the PR was already ready to be reviewed on code style, so I just thought I do that so we can fix them. :)

This isn't anywhere in the style guide, I'm not sure how I was supposed to know this.

Some more things are mentioned in our contribution guidelines although it's not complete. I guess you were not able to know this, but now you do. ;)

Likely because @gratimax already added them before they were added to the API. I'm sure redundant events can be removed. Any ideas which ones?

I've commented on the (possibly) duplicate events above.

@Mumfrey Wasn't sure if the PR was already ready to be reviewed on code style, so I just thought I do that so we can fix them. :)

Personally I tend to focus on the important aspects of code style (readability, wrapping, stuff having some kind of javadoc rather than none) and deal with the more fiddly parts in a second pass, at this point as long as it builds then people can review the structure of the PR and other issues can be mopped up going forward.

Some more things are mentioned in our contribution guidelines although it's not complete. I guess you were not able to know this, but now you do. ;)

I was including the contribution guidelines in my above assertion, there is no mention of full stops other than specifically mentioning they should be omitted on at clauses.

I've commented on the (possibly) duplicate events above.

I'll leave that one for @gratimax to take a view on. I've removed the public abstract modifiers and added javadoc to two classes which were missing it. The rest can wait for a second pass because there are more pressing things that need work.

First off, glorious pull request.
How, in this new system, would you go about taking X amount of items from a given inventory? I imagine you would you create a query for the ItemType, but then what? Iterate over that inventory, removing item stacks until you've removed enough?

First off, glorious pull request.
How, in this new system, would you go about taking X amount of items from a given inventory? I imagine you would you create a query for the ItemType, but then what? Iterate over that inventory, removing item stacks until you've removed enough?

Yes, because remember that your result set is an Inventory. So basically if you want to consume a specific item from anywhere in the inventory you query for slots containing the inventory and then peek to get the first stack. Although now you ask it's given me an idea that maybe you could instead poll with a limit argument to allow you to consume items up to a set amount.
You need not iterate over the inventory because you can consume items directly from the query result (since it's an Inventory) so basically to consume a single item (eg to consume a arrow when you fire it).
Inventory arrows = player.getInventory().query(ItemTypes.ARROW);
if (arrows.isEmpty()) {
    // boo, no arrows
    return;
}

ItemStack quiver = arrows.peek().get(); // We know it's present so calling get() is safe
quiver.setQuantity(quiver.getQuantity() - 1);

However, I think a nicer way (which I will add now you mention it) would be:
Inventory arrows = player.getInventory().query(ItemTypes.ARROW);
if (arrows.isEmpty()) {
    // boo, no arrows
    return;
}

ItemStack arrow = arrows.poll(1).get(); // Consume a stack of 1 array from the result

This is awesome in all of its definitions, what led you to come up with a system so different?

@modwizcode there's honestly nothing really outlandish in this proposal, it's more the fact that everyone is so entrenched in the existing Inventory architecture (which, let's face it, is bloody awful) that nobody has really taken a step back and said "wait a minute, how should this work?" So much interaction with inventories to date has required far to much prior knowledge of the internals of the inventory in question, I simply tried to come up with a more expressive way of interacting with inventories.

Quick comment because I'm on my phone and can't really look through the code: instead of new InventoryPos(x, y), I think InventoryPos.of(x, y) would be cleaner.

@kitskub they're just the interfaces, how they're implemented is up to the implementation.

@Mumfrey okay. Sorry, like I said: can't read the code at the moment.

@kitskub It might be nice to have some concrete implementations in the API but I'm not sure what format that kind of thing is taking and it's up to @Zidane et al. to figure out the best way to factory these objects that's consistent with how things are done elsewhere in the API.

Well done. 2 things:

Also add a peek(int limit) method
Add a way to count the number of single items contained in the inventory

And a simple question:
How can I place an item stack (e.g. a server rule book) into the first slot of the hotbar, even if the slot is filled with an existing item?
My Solution:
First, get the Inventory of the slot:  playerInv.query(Hotbar.class).query(new InventoryPos(0,0)
Then offer the book item stack to the slot. If it was rejected, poll the existing item stack from the hotbar slot.
Then offer the book item stack to the hotbar slot again.
Then offer the replaced item stack to the playerInv.
If it was rejected. revert everything so that no items are lost (and drop the book).
Does it work like this?

Also add a peek(int limit) method

Hmm. Interesting. What's the use-case just for my curiosity?

Add a way to count the number of single items contained in the inventory

Okay.

And a simple question:
How can I place an item stack (e.g. a server rule book) into the first slot of the hotbar, even if the slot is filled with an existing item?

ItemStack rulebook = ...;
inventory.query(Hotbar.class).first().set(rulebook);

for other slots:
Inventory result = inventory.query(Hotbar.class);
if (!result.isEmpty()) { // check the query actually succeeded
    Hotbar hotbar = result.<Hotbar>first();
    hotbar.set(3, rulebook); // Hotbar is an OrderedInventory so we can use positional set
}```

or using a fully query-based version:

```java
inventory.query(Hotbar.class).query(new SlotIndex(3)).set(rulebook);

First of all: Awesome API! (And nice and complete description with descriptive images)
@Mumfrey I guess @boformer tried to add an ItemStack to the Hotbar Slot 0. And moves any existing Item at that slot to the normal player inventory. (including later slots in the hotbar?
I have three question myself.

in one of the pictures you displayed above you specified the iteration order to iterate over the InventoryRows, but it is possible to iterate over InventoryColumns as well?
If the Inventory that is queried is a PlayerContainer as you called it (with the crafting slots), will they be included in the iteration as well?
How do i set the active hotbar index/slot?

@ST-DDT I assume it would be like this:
inventory.query(Hotbar.class).query(new SlotIndex(/* selected slot here */)).set(rulebook);

@kenzierocks IMO this will replace the item at the given slot, removing it from the inventory, instead of moving it to another slot. (This is what i expect the method to do)

@Mumfrey
How much more do you want to change of this before I can pull this into master?

@Zidane I'm going to change the specific properties into concrete classes because I've realised that having them as interfaces doesn't serve any purpose since they can still be extended by implementors and their behaviour is actually fixed.
Other than that all that needs to happen is @gratimax needs to take a view on the duplicate events.

@mumfrey all names are using US English in the API

Actually we use non US spellings for Canceled i.e: "Cancellable"

@Mumfrey What is your plan for the transaction operations?

This doesn't provide a way to add items to an inventory as far as I can tell. Unless I'm missing something, I cannot find a way to actually get an ItemStackBuilder.

@modwizcode there is Game.getRegistry().getItemBuilder() that returns a  ItemStackBuilder

Ah ok.

A few suggestions:

Clarify the behavior of Inventory#getProperty when multiple InventoryPropertys could be returned

This could occur if two subtypes of, for example, IntPropery, are sent, and getProperty(IntProperty.class) is called

Allow multiple properties of the same class (or with a common ancestor) to be set. This is related to the above point
Allow querying an Inventory with a specific InventoryPropery class, as opposed to a particular instance.

Clarify the behavior of Inventory#getProperty when multiple InventoryPropertys could be returned

An InventoryProperty is never returned, only used to match

This could occur if two subtypes of, for example, IntPropery, are sent, and getProperty(IntProperty.class) is called

That's not how matching with properties work. If there are multiple IntProperty then they must have different keys, and thus the keys for the supplied matching properties will be different.

Allow multiple properties of the same class (or with a common ancestor) to be set. This is related to the above point

You can as long as they have different keys

Allow querying an Inventory with a specific InventoryPropery class, as opposed to a particular instance.

This doesn't make sense, you need an instance for a query by property to be meaningful in any way, testing for the presence of a property doesn't have any meaning.

An InventoryProperty is never returned, only used to match
It's returned here

It's returned here

Ooooh! I see what you mean. Yes, that method needs an override which accepts the key, well spotted.

@Aaron1011 fixed

@Zidane as far as I'm concerned this is ready to roll, if you get @gratimax to just take a look and remove/change those duplicated events then it's good to go.

I think there should be a list of standard keys for GameDictionary since there may be issues where a plugin registers something under "wood" but another plugin uses "planks".
GameDictionary only supports items, should it be called ItemDictionary instead? Or what about extending it's functionality to supporting BlockTypes an possibly other game objects too.

@simon816 If i got the concept of the GameDictionary right, it will contain all stuff that can be registered by plugins. Achievements, Statistics, BlockTypes, ItemTypes, (EntityTypes), ...
Otherwise the Achievement PR would not be pending due to this PR.

Is this PR mergeable?

So how would you backup an entirw inventory with this system? Oh, and could you make inventories serializable by default?


Support of Unicode OutputDebugStringW()

I see that DebugView++ does not show Unicode output as this moment when using OutputDebugStringW().
According to MS there is a configuration call required to handle this (WaitForDebugEventEx())
https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-outputdebugstringw
Will this be added to future versions of DebugView++?

Debugview++ does not support this new behaviour and there are no plans to
support it.
The reason is that all strings in Debugview++ are std::strings' that do not
specify a specific encoding.
There is however a way to make it display UTF-8 encoded strings correctly
by enabling this windows feature:
I've tested this with chinese UTF-8 strings and it worked well, see
screenshots below.
I hope this can help.
Greetings,
Jan
[image: image.png]
[image: image.png]
On Thu, Jan 6, 2022, 08:34 Roger van Valen @.***> wrote:

I see that DebugView++ does not show Unicode output as this moment when
using OutputDebugStringW().
According to MS there is a configuration call required to handle this
(WaitForDebugEventEx())
https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-outputdebugstringw
Will this be added to future versions of DebugView++?
—
Reply to this email directly, view it on GitHub
https://github.com/CobaltFusion/DebugViewPP/issues/378, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNITBAMTMFV5QXHMREIIU3UUVAYFANCNFSM5LLWQ3EA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thank you for your quick response.
Good to know.
Unfortunately the github ticket does not show me the images - it shows [image: image.png] instead.
But I'll give UTF-8 a try.
The issue can be closed,
Best regards,
Roger.

Thanks!


wfnews-2102

storybook coming

These tabs can be pulled out into a component and do not need to be in the page. I would also like to see the component be reusable so we can pass in a collection of tabs and a function for tab change.
Storybook also missing

Thanks, separated tabs component out. Storybook added


Set Cabal version to 3.0 when set notation is used in tested-with field

Cabal >= 3.0 allows set notation in the tested-with field, such as
tested-with: GHC == { 8.6.3, 8.4.4, 8.2.2, 8.0.2, 7.10.3, 7.8.4, 7.6.3, 7.4.2 }

When we use set notation in the tested-with field in package.yaml, the field is copied to the .cabal file, but the cabal-version is not set to >= 3.0 as needed. This results in the following error when we try to cabal build using the generated cabal file:
unexpected version set syntax used. To use this syntax the package needs to specify at least 'cabal-version: 3.0'. Alternatively, if broader compatibility is important then use a series of single version constraints joined with the || operator: ==8.6.3 || ==8.4.4 || ==8.2.2 || ==8.0.2 || ==7.10.3 || ==7.8.4 || ==7.6.3 || ==7.4.2

   20 | tested-with:
   21 |     GHC == { 8.6.3, 8.4.4, 8.2.2, 8.0.2, 7.10.3, 7.8.4, 7.6.3, 7.4.2 }
      |                                                                       ^                                   ^

There are two things here:

Should hpack accept.
How should hpack render it.

Regarding (1), should hpack accept something like:
tested-with:
  GHC:
    - 8.6.3
    - 8.4.4
    - ...

Regarding (2), we could still always render this as tested-with: GHC == 8.6.3, GHC == 8.4.4, ... for maximum compatibility.  Or is there a reason not to?
Finally, for your original request, when tested-with is given as a string, then I'm not eager to look at it and pass it through transparently.  In that case it would be the responsibility of the user to adjust the cabal-version as needed.

Regarding (1), that seems reasonable to me to accept. Regarding (2), that also seems like a reasonable way to render it. It also makes sense to just pass through tested-with transparently when it's passed as a string.
Also, as I think about it more, I think the current option of writing
tested-with:
  - GHC == 8.6.3
  - GHC == 8.4.4
  - ...

seems like an acceptable workaround (though a little less aesthetically pleasing).

Regarding (1), that seems reasonable to me to accept.

PRs welcome.


split up unit and integration tests

(still waiting for the integration tests to come through)

https://jenkins.vgt.vito.be/job/openEO/job/openeo-gfmap/view/change-requests/job/PR-163/
integration tests are passing

@VincentVerelst ready for re-review

integration tests are failing, will look into it


Rendering inserts with unknown attributes

Needed for not crashing on review comments when rendering for non-staff, e.g. invitees.
See https://github.com/nadar/quill-delta-parser/issues/20.

Can we not fix this by applying a listener which hooks into ReviewComments and treats it as regular text instead? That would remove some complexity from this fork.

Not needed anymore, since we already created a listener for ReviewComments and chose to not reveal any details about the comment in the preview render.


Some typos

(p109) In figure 17-3, "next-sentence prediction" should be "next-word prediction".
(p121, p122) In figure 18-6 and 18-7, "Fully connected layer" box that follows "Multihead self-attention" box should be removed.
(p129) In 2nd equation of perlexity, $\sum$ on the second line should be removed.
(p129, 132) 2nd line from the bottom, "q15-text-augment subfolder" should be "q19-evaluation-llms subfolder"
Thanks! :)

Thanks for sending these along, Haesun, I really appreciate it!

(p109) In figure 17-3, "next-sentence prediction" should be "next-word prediction".

Yes, this should definitely be "next-word prediction" or "next-token prediction"

(p121, p122) In figure 18-6 and 18-7, "Fully connected layer" box that follows "Multihead self-attention" box should be removed.

Ah yes, this is one box too much here. Good catch!

(p129) In 2nd equation of perlexity, $\sum$ should be removed.

Yes, in the 2nd row of the second equation, that sum shouldn't have been there. Probably a copy & paste error.

(p129, 132) 2nd line from the bottom, "q15-text-augment subfolder" should be "q19-evaluation-llms subfolder"

Ah yes, I am not sure how q15 got here. Thanks!
I will add those to the errata and share them with the publisher for when there is the possibility for incorporating these suggestions into a reprint edition.

Added them here: https://github.com/rasbt/MachineLearning-QandAI-book/tree/main/errata


[4.5] CLOUDSTACK-9000: logrotate cloudstack-agent out and err logs

Adds logrotate rules for cloudstack-agent.{err,out} log files
cc @remibergsma @wido @wilderrodrigues and others

Why only RPM and not for DEB?
Keep in mind though that with systemd this is no longer valid

@wido fixed now. Do you mean with systemd, there is no point in using logrotate?

@bhaisaab With systemd we no longer write a out and err file. We did this with JSVC, but now it's send to stdout and stderr which is then picked up by journald.


Always swipes left

I think i create a new issue for this.
I got the script to run, but it just left swipes. i am not sure if the european height is the problem or my config.
My config looks like this:
`dealbreakers:
familyPlansv2: 0.2
dealmakers:
drinkingv2: 0.9
throttle_ratio: 0
age:
18: 1
19: 1
20: 1
21: 1
22: 1
23: 1
24: 1
25: 1
26: 1
27: 1
28: 1
cannabisv2:
never: 0.5
socially: 0.5
frequently: 0.3
drinkingv2:
never: 0.8
sober: 0.8
rarely: 0.8
socially: 0.8
frequently: 0.4
educationv2:
high school: 0.8
trade/tech school: 0.7
in college: 0.6
undergraduate degree: 0.5
in grad school: 0.4
graduate degree: 0.3
exercisev2:
sometimes: 0.6
active: 0.3
almost never: 0.6
never: 0.6
familyPlansv2:
want someday: 1
don�t want: 0.3
have and want more: 0.1
have and don�t want more: 0.1
not sure yet: 0.6
have kids: 0.1
open to kids: 0.8
genderv2:
woman: 1
woman and nonbinary: 1
cis woman: 1
heightv2:
min: 5.0
max: 7.0
bufferMax: 8.0
intentionsv2:
relationship: 1
something casual: 0.5
don�t know yet: 0.8
marriage: 1
Politicsv2:
apolitical: 1
moderate: 1
liberal: 0.8
conservative: 1
religionv2:
agnostic: 0.9
christian: 1
catholic: 0.8
hindu: 0.6
muslim: 0.1
jewish: 0.1
other: 0.7
spiritual: 0.8
atheist: 1
buddhist: 0.5
smokingv2:
socially: 0.6
never: 0.8
regularly: 0.4`
My log looks like this:
2023-12-26 23:12:08,689 | Value "don’t know yet" not handled for attribute "intentionsv2" 2023-12-26 23:12:08,709 | Attribute "starSignv2" not handled. Found value "taurus" 2023-12-26 23:12:08,719 | Value "left" not handled for attribute "Politicsv2" 2023-12-26 23:12:08,752 | {"heightv2": "174 cm", "exercisev2": "active", "educationv2": "in college", "drinkingv2": "rarely", "smokingv2": "never", "intentionsv2": "don\u2019t know yet", "familyPlansv2": "not sure yet", "starSignv2": "taurus", "Politicsv2": "left", "bio": "w\u00e4re sweet, wenn mir jemand bass beibringen k\u00f6nnte :)", "prompts": {}, "throttle_ratio": 0.0} | 0.4987181504336566 2023-12-26 23:12:10,991 | Value "don’t know yet" not handled for attribute "intentionsv2" 2023-12-26 23:12:11,009 | Attribute "starSignv2" not handled. Found value "taurus" 2023-12-26 23:12:11,065 | {"heightv2": "169 cm", "exercisev2": "active", "drinkingv2": "socially", "smokingv2": "socially", "genderv2": "woman", "intentionsv2": "don\u2019t know yet", "familyPlansv2": "not sure yet", "starSignv2": "taurus", "bio": "insta: schreibercecilie", "prompts": {}, "throttle_ratio": 0.0} | 0.4987181504336566 2023-12-26 23:12:13,507 | Attribute "starSignv2" not handled. Found value "aries" 2023-12-26 23:12:13,540 | {"heightv2": "171 cm", "exercisev2": "sometimes", "drinkingv2": "socially", "genderv2": "woman", "intentionsv2": "relationship", "familyPlansv2": "want someday", "starSignv2": "aries", "bio": "ISFP-T", "prompts": {}, "throttle_ratio": 0.0} | 0.4987181504336566
Edit: Found out, it was indeed the height, after deleting the code block for height, since i am not carying for height anyway, it works.
But it seems he doesnt like the special character for that:
Value "don’t know yet" not handled for attribute "intentionsv2"
i tried in the config file as:
don\u2019t know yet:
or as
don’t know yet:
Which both didnt work

Thank you for the bug report. I'm glad to see you find this useful.
Don't know yet should be copy/psate'd from the log. I did not know that was a valid value when I built this, so it needs to be added to the config. I'll push that in the next update.
The height issue is due to the fact that you have height in cm (169 cm, in the case of the example in your log), and the max height is set to 7.0, which would correspond to 7 cm (I think you perhaps wanted it to mean 7m, which is not how it is interpreted).
I'll push a new update with these fixes soon

Closed by ca8bcfe


eventHandler -> reflectable, and require annotations on all JsProxy f…

…ields/methods which you want to expose

fyi, I am actually going to push this to a new 1.0.0-rc.2 branch instead of merging into the 1.0.0-rc.1 branch, since it is a breaking change.

otherwise lgtm!

Just pushed to 1.0.0-rc.2


Tool does not delete temp files

Hi again,
I noticed that your tool doesn't seem to delete the temp files that it creates in the user directory. Is it possible that you could add, so that it does that?
Example:

So these files should be deleted after the video is produced. Where are these files being stored? Are they in the bin folder or are they in the same directory where the video is produced?

So these files should be deleted after the video is produced. Where are these files being stored? Are they in the bin folder or are they in the same directory where the video is produced?

The files are being made in my user directory.

Okay so I tested it a bit this afternoon and the files do delete when everything succeeds, although its temperamental. I'll probably switch to temporary file storage at some point anyways. For now there's a new branch, that I won't merge in, but it has a method for cleaning out the existing temp files.
Just run -clean and it should clean out the directory.


Provide a test to replicate issue #102

This is a test to replicate #102 thanks to @keynmol's great example on the ticket

Hmm FWIW @keynmol I actually get the same result here even if sbt-tpolecat is removed from plugins.sbt - -scalajs is not present in the scalacOptions. Am I missing something?
sbt:scalajs> show Compile/scalacOptions
[info] * -Xplugin:/Users/davidgregory/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-js/scalajs-compiler_2.13.8/1.10.1/scalajs-compiler_2.13.8-1.10.1.jar
[success] Total time: 0 s, completed 28 Jul 2022, 14:36:56
sbt:scalajs> show Test/scalacOptions
[info] * -Xplugin:/Users/davidgregory/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-js/scalajs-compiler_2.13.8/1.10.1/scalajs-compiler_2.13.8-1.10.1.jar
[success] Total time: 0 s, completed 28 Jul 2022, 14:37:14
sbt:scalajs> show Runtime/scalacOptions
[info] * -Xplugin:/Users/davidgregory/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-js/scalajs-compiler_2.13.8/1.10.1/scalajs-compiler_2.13.8-1.10.1.jar
[success] Total time: 0 s, completed 28 Jul 2022, 14:37:19
sbt:scalajs> show scalacOptions
[info] *
[success] Total time: 0 s, completed 28 Jul 2022, 14:37:32
sbt:scalajs>

I've realised now that this -scalajs option is for Scala 3.x only

The latest commit attempts to resolve the problem by dropping derived settings and switching to configuration filters.
The immediate problem with this was that manipulating unscoped settings no longer worked, e.g. the following manipulation no longer contributed to Compile/tpolecatReleaseModeOptions:
tpolecatReleaseModeOptions ++= {
  ScalacOptions.optimizerOptions("**") +
    ScalacOptions.release("8") +
    ScalacOptions.privateBackendParallelism(8)
}

This prompted me to try appending to tpolecatReleaseModeOptions in the sbtTpolecatSettings, which unfortunately breaks the ordering of options that we got from using ListSet within the plugin:
    tpolecatDevModeOptions ++= ScalacOptions.default,
    tpolecatCiModeOptions ++= tpolecatDevModeOptions.value + ScalacOptions.fatalWarnings,
    tpolecatReleaseModeOptions ++= tpolecatCiModeOptions.value + ScalacOptions.optimizerMethodLocal,

I'm afraid it did not resolve the problem in any case as we still see settings duplication in the modePerConfiguration test in Test/scalacOptions regardless of whether ++= is used in the tpolecat*Options.

No longer needed due to #126


RFC: Nuxt3 Support

I use graphql capabilities provided by urql in nuxt3。
It can work normally on the client side, but server side，because useClient, useClientHandler must be under the vue instance。
code show as below

I think this is not well，for example, I need to get user information and check permission in beforeEach router, it can not work well。
I provide urql client instance to nuxtApp,
so i think urql support server side case is well.

useQuery、useMutation check server side/client side to auto inject client (agree on a name， like $urql)
useClientHandler no more check vue instance, when i set client instance by manual

code show as below
import {createGraphqlClient} from "~/modules/api-service";
import {Client} from "@urql/core";

const SSR_KEY = '__URQL_DATA__'
export default defineNuxtPlugin((nuxtApp) => {
    const {vueApp, $config} = nuxtApp
    const {client, ssr} = createGraphqlClient({
        url: $config.apiServer.graphqlUrl,
        subscriptionUrl: $config.apiServer.subscriptionUrl,
        batchEnabled: $config.apiServer.batchEnabled,
        ssrEnabled: false
    });
    if (process.client && ssr) {
        nuxtApp.hook('app:created', () => {
            ssr.restoreData(nuxtApp.payload[SSR_KEY]);
        })
    }
    if (process.server && ssr) {
        nuxtApp.hook('app:rendered', () => {
            nuxtApp.payload[SSR_KEY] = ssr.extractData();
        })
    }
    const graphqlClient = ref<Client>(client);
    nuxtApp.provide("urql", graphqlClient);
    vueApp.provide("$urql", graphqlClient);
});

import useAuthStore from "~/modules/auth/store/auth";

export default defineNuxtPlugin((nuxtApp) => {
    const {$urql, $router} = nuxtApp;
    const authStore = useAuthStore();
    $router.beforeEach(async (to: object, from: object, next: Function) => {
        //TODO check current user permission use authStore
        next()
    })
});

import {defineStore} from "pinia";
import useTokenStore from "~/modules/auth/store/token";
import {AccessToken, User} from "~/modules/api-service/types";
import MeGQ from "./me.graphql";
import {useQuery} from "@urql/vue";
import {useNuxtApp} from "#app";

const useAuthStore = defineStore('auth', () => {
    const tokenStore = useTokenStore();
    const user = useState<User>('user');
    useQuery({query: MeGQ})
        .then(response => {
            user.value = response.data.value.me;
        });
    return {
        user,
        signIn
    };
});

export default useAuthStore;

https://github.com/FormidableLabs/urql/issues/2121

https://github.com/FormidableLabs/urql/issues/1596

I found that vue-appollo's useQuery will determine whether the current environment is on the server side or the client side.
https://github.com/vuejs/apollo/blob/v4/packages/vue-apollo-composable/src/useQuery.ts

This doesn't quite follow the RFC format we outline, and unfortunately we don't know enough about Nuxt 3 to continue here on our own, so without replies, I must unfortunately close this issue 🙏
In general, Vue's use* patterns are that these functions should only ever be called in setup() methods, so the solution of just determining "any client" that's suitable for a request isn't quite what would work here. Especially, due to potential request leakage during SSR.
As can be seen by next-urql, integration into frameworks isn't always super simple. https://github.com/FormidableLabs/urql/tree/main/packages/next-urql
So, I'm not quite sure how Nuxt 3 solves the SSR cases, but as far as I understood the intention of async setup() was also to kind of help with SSR cases? So if that's the case a solution like with next-urql is definitely possible, but outside of our reach if the RFC doesn't quite help us more in determining how we could approach that. Sorry!
We've got some details on why we typically need a bit more help when it comes to Vue and Svelte :v: https://github.com/FormidableLabs/urql/pull/2119#issuecomment-1041046423


false positive on ++ and -- in operator-no-unspaced

Input:
a {
  width: ++1;
}

Require:
a {
  width: + + 1;
}

Expected (no errors):
a {
  width: ++1;
}

Thanks! Would you have any other examples for the bug? I don't think that it would be very common to write ++1 as the value as it is turned to just 1 by Sass.

Want to also add to this that unary negation is also a false positive here, and -$margin-offset also throws the error, which seems more likely to use.

I ran straight into this issue with the unary minus when adding stylelint to a project :)

@clarfonthey finally managed to get this fixed.
@fluidsonic I did not fix your example since it seems that either parens or interpolation is needed to make the negation to work when using multiple variables.
https://github.com/stylelint-scss/stylelint-scss/releases/tag/v6.3.2

Thanks, I noticed it behaves very differently in SASS than in other languages, and from what I'd expect. So the problem is with SASS and the warning here just highlights that it's an odd case, which is good 👍

Hmm, are you sure this is fixed? I'm still getting this error; here's a minimal repro:
$lhs: 1;
$rhs: 2;
@if $lhs <= -$rhs {}

Hmm, are you sure this is fixed? I'm still getting this error; here's a minimal repro:
$lhs: 1;
$rhs: 2;
@if $lhs <= -$rhs {}

@kristerkari

@clarfonthey The operator-no-unspaced rule uses a custom made parser to figure out if the operators should have spacing or not. This means that there are a lot of false posivites, and your example is probably one of them.
I'll try to fix the example that you provided 👍
For anyone else that wants to report more false positives, please open a new Github issue with an example 🙇


feat: Add mattn/efm-langserver

#4878 mattn/efm-langserver: General purpose Language Server

Added packages:

mattn/efm-langserver

Thank you for your contribution.

Released. https://github.com/aquaproj/aqua-registry/releases/tag/v3.14.0


prefix lua scripts according to service

Context
Redis uses lua scripts for some operations. Some of these scripts may be common across services and therefore should be prefixed. Note: the nonce service should not be prefixed. It's important that the nonce be able to be changed independent of the service.
Follow Up
This follows from #349

Not needed with the current set of scripts


hana-setup-cloud Warning does not link to anything

In hana-setup-cloud, the warning at the top of the tutorial says:

...do not follow this tutorial. Click here to sign up for the account, and then proceed to the next tutorial. [emphasis added]

But there is no link in the message.

Thanks for catching that!


Update from-travis.md

Change rust installation instructions to use rustup and not apt-get. rustup is the defacto rust toolchain manager. Additionally, installing just rustc from apt-get does not install the cargo build tool which is needed for building and testing projects.

@rylev : Thanks for your contribution! The author, @ethomson, has been notified to review your proposed change.

@ethomson Could you review the proposed changes? Thanks.

@ethomson Could you review this pull request? Thanks.

@KathrynEE - Hi Kathryn, are you available to review this PR from April 2019? Thanks.

@steved0x - Steve this has been in the queue for a while, please review.
@ktoliver - Steve is a more appropriate reviewer for pipelines.

#sign-off

@steved0x: I'm sorry - only the author of this article, @ethomson, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Swarm Environment Any detail document about how rancher deploy swarm/mesos internally?

Rancher Version: lastest version
Docker Version: lastest version
OS and where are the hosts located? (cloud, bare metal, etc): azure
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node
Environment Type: (Cattle/Kubernetes/Swarm/Mesos) Swarm
Steps to Reproduce: Follow instructions from deploy swarm environment
Results:
Expected:

We currently don't have any documentation on this. With the new swarm support in Docker 1.12, we are refactoring the framework of how we handle different container orchestration types, so any documentation will need to be after this refactor is completed.

@deniseschannon thank you, : ）


kernel-resin.bbclass: Update aufs-standalone revisions

We update to latest upstream for kernels between 4.4 and 4.13
Change-Type: patch
Changelog-entry: Update aufs for kernel versions from 4.4 to 4.13
Signed-off-by: Florin Sarbu<EMAIL_ADDRESS>

Build finished.

@resin-jenkins retest this please

Build finished.

@resin-jenkins retest this please

Build finished.


[typescript-graphql-files-modules] doesn’t work if no documents are specified

Hello!
typescript-graphql-files-modules doesn’t seem to work for backend-only projects, i.e. projects with no document specified (because there’s only a schema, but no queries or mutations). I think it should still generate output under these conditions.
Thanks!

@lensbart If this is still relevant, please share a reproduction or expand the description with an example.


Fixing Julia LTS pipeline

Now, the pipeline is failing when we send the information through HTTP.jl. The entire log is here.

This strange behavior just occurs in our CI pipeline. Locally, everything is working well.
Tested using julia version 1.6.7 and macOS 13.4.1 22F82 x86_64.

Removing multi-threading from the CI pipeline solves the problem for Julia 1.6 (changes: c51341c).


The pod memory of kubectl top and grafana queries is inconsistent.

What kind of request is this (question/bug/enhancement/feature request):
k8s/clusters/c-4kdjk/api/v1/namespaces/cattle-prometheus/services/http:access-grafana:80/proxy/d/XSOTSYxiz/pods?orgId=1&var-namespace=web&var-pod=demo-f68d5db87-gdfd2&var-container=All
Steps to reproduce (least amount of steps as possible):
kubectl top pod demo -n web
Result:
The pod memory of kubectl top and grafana queries is inconsistent.
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
rancher/rancher:stable  v2.3.5
Installation option (single install/HA):
single install

Cluster information

Cluster type Custom；
Machine type Aliyun and specifications (CPU 4Core/memory 8GB):
Kubernetes version (use kubectl version):
v1.16.3

(paste the output here)

Docker version (use docker version):
18.09.0

(paste the output here)

[Pod memory used]
Cattle-Grafana-WRONG: /k8s/clusters/clusters/c-4kdjk/api/v1/namespaces/cattle-prometheus/services/http:access-grafana:80/proxy/d/XSOTSYxiz/pods?orgId=1&var-namespace=web&var-pod=demo-f68d5db87-gdfd2&var-container=All
RESTFUL API: /k8s/clusters/c-4kdjk/api/v1/namespaces/cattle-prometheus/services/http:access-grafana:80/proxy/api/datasources/proxy/1/api/v1/query_range?query=sum by(container_name) (container_memory_working_set_bytes{namespace="web",container_name!="",container_name=~".*",container_name!="POD",pod_name="demo-f68d5db87-gdfd2"})&start=1584008175&end=1584008475&step=15
Cattle-Grafana-RIGHT
RESTFUL API: /k8s/clusters/c-4kdjk/api/v1/namespaces/cattle-prometheus/services/http:access-grafana:80/proxy/api/datasources/proxy/1/api/v1/query_range?query=sum by(container_name) (container_memory_working_set_bytes{namespace="web",container="demo",id="",pod_name="demo-f68d5db87-gdfd2"})&start=1584008175&end=1584008475&step=15

same to me.
Portainer:

Rancher:

rancher version: 2.3.5
k8s: v1.17.2
docker: v19.3.5

This problem also exists in older versions, such as: v2.2 v2.1

For the double usage issue,  it's a bug in monitoring 0.0.6 and 0.0.7 when you are using k8s 1.16+. It's fixed in https://github.com/rancher/rancher/issues/25539. It will be fixed in monitoring 0.0.8 chart. https://github.com/rancher/system-charts/commit/d8cffef0ae7e6a420f9909047738a45e5b5b9ffc
For the original issue, the Rancher's expression of memory usage is different from metrics server's expression.  https://github.com/rancher/rancher/blob/master/pkg/controllers/user/monitoring/metricExpression.go#L4169

Upgrade Rancher to version 2.4.0-rc3, the problem is fixed

This is fixed in monitoring 0.0.8, which was renamed to 0.1.0 when 2.4 was released and is available in 2.3.7. For 2.3.8+, monitoring chart 0.1.1 is available.


Game logic

Key actions have been added and tested. And everything else seems to work like it should, Can someone just check that what I've done hasn't changed the networking stuff?

Looks good to me

Pulling


Random ConcurrentModificationException crash while exploring.

Hi,
Describe the bug
Randomly (we still trying to find when, exactly) when exploring the world, the Minecraft client crash with a ConcurrentModificationException error.
To Reproduce
Steps to reproduce the behavior:

Explore the world, but, well... this is very random.

Screenshots
None.
Crash Report
https://pastebin.com/raw/vrtT5maT
Rendering Glitches
Are you using Optifine?
Yes. OptiFine_1.12.2_HD_U_E3.
Additional context
Our world is generated using the mod Painted Biomes.
Crashes

Are you running the latest version of Dynamic Trees?
Yes (1.12.2-0.9.5).
If you are using the DT Biome O' Plenty Add-on do you have the latest version?
Yes (1.12.2-1.4.1e).
If you are using the DT Thaumcraft Add-on do you have the latest version?
No.

We're also using the DT PHC Addon-on versiong 1.12.2-1.4.2.
Mods List
Included in the crash report.
What version of Forge are you running?
Forge 1.12.2-<IP_ADDRESS>38

Fixed. Same as #373


Initialization failure after upgrading from 0.0.30 to 0.0.32

System Health details
System Information

version
core-2024.7.3

installation_type
Home Assistant Container

dev
false

hassio
false

docker
true

user
root

virtualenv
false

python_version
3.12.4

os_name
Linux

os_version
6.1.0-22-amd64

arch
x86_64

timezone
Asia/Jerusalem

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
4818

Installed Version
1.34.0

Stage
running

Available Repositories
1400

Downloaded Repositories
25

AccuWeather

can_reach_server
ok

remaining_requests
38

Dashboards

dashboards
2

resources
14

views
14

mode
storage

Recorder

oldest_recorder_run
August 6, 2024 at 6:42 PM

current_recorder_run
August 21, 2024 at 5:19 AM

estimated_db_size
636.64 MiB

database_engine
mysql

database_version
10.11.9

Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
2024-08-21 05:22:09.499 ERROR (MainThread) [custom_components.iec.coordinator] Unexpected error fetching Iec data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/iec/coordinator.py", line 423, in _async_update_data
    total_kva_price, estimated_kwh_consumption = await self._estimate_bill(contract_id, device.device_number,
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/iec/coordinator.py", line 659, in _estimate_bill
    power_size = await self._get_power_size(connection_size)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/iec/coordinator.py", line 195, in _get_power_size
    power_size = await self.api.get_power_size(connection_size)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/iec_api/iec_client.py", line 527, in get_power_size
    return await static_data.get_power_size(self._session, connection)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/iec_api/static_data.py", line 126, in get_power_size
    power_size = connection_to_power_size_map[connection]
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: '40'

Note that I current pay for electricity from Pazgas, if that matters.
Reproduction steps

Upgrade

Debug logs
See https://termbin.com/c975

Diagnostics dump
No response

FWIW, 0.0.31 was also broken for me, with a different error (I don't care about this, but just for helping to figure out when it happened):
2024-08-21 05:33:55.441 ERROR (MainThread) [custom_components.iec.coordinator] Unexpected error fetching Iec data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/iec/coordinator.py", line 423, in _async_update_data
    total_kva_price, estimated_kwh_consumption = await self._estimate_bill(contract_id, device.device_number,\
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/iec/coordinator.py", line 640, in _estimate_bill
    if not is_private_producer or not last_meter_read:
                                      ^^^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'last_meter_read' where it is not associated with a value

I've gone back to 0.0.30 for now

same problem described in issue 154

https://github.com/GuyKh/py-iec-api/pull/130

@mikeage  try with 0.0.33 (currently in Pre-Release)

Looks good (there's a new exception that I didn't remember from before, but it's not relevant). I'll open a new issue for that one


编译错误：error: catching polymorphic type ‘class std::exception’ by value [-Werror=catch-value=]

你好，Ubuntu 18  下编译出错：
2019-11-15 编译源码出错，错误信息如下：
[[ 97%] Built target eventfilter
Scanning dependencies of target initializer
[ 98%] Building CXX object libinitializer/CMakeFiles/initializer.dir/BoostLogInitializer.cpp.o
[ 98%] Building CXX object libinitializer/CMakeFiles/initializer.dir/GlobalConfigureInitializer.cpp.o
[ 99%] Building CXX object libinitializer/CMakeFiles/initializer.dir/Initializer.cpp.o
[ 99%] Building CXX object libinitializer/CMakeFiles/initializer.dir/LedgerInitializer.cpp.o
[ 99%] Building CXX object libinitializer/CMakeFiles/initializer.dir/P2PInitializer.cpp.o
[100%] Building CXX object libinitializer/CMakeFiles/initializer.dir/RPCInitializer.cpp.o
[100%] Building CXX object libinitializer/CMakeFiles/initializer.dir/SecureInitializer.cpp.o
[100%] Linking CXX static library libinitializer.a
[100%] Built target initializer
Scanning dependencies of target fisco-bcos
[100%] Building CXX object fisco-bcos/main/CMakeFiles/fisco-bcos.dir/main.cpp.o
In file included from /~/~/app/FISCO-BCOS/FISCO-BCOS/fisco-bcos/main/main.cpp:25:
/~/~/app/FISCO-BCOS/FISCO-BCOS/libdevcore/FileSignal.h: In static member function ‘static void dev::FileSignal::callIfFileExist(const string&, std::function<void()>)’:
/~/~/app/FISCO-BCOS/FISCO-BCOS/libdevcore/FileSignal.h:51:31: error: catching polymorphic type ‘class std::exception’ by value [-Werror=catch-value=]
catch (std::exception _e)
^~
cc1plus: all warnings being treated as errors
make[2]: *** [fisco-bcos/main/CMakeFiles/fisco-bcos.dir/build.make:63：fisco-bcos/main/CMakeFiles/fisco-bcos.dir/main.cpp.o] 错误 1
make[1]: *** [CMakeFiles/Makefile2:2417：fisco-bcos/main/CMakeFiles/fisco-bcos.dir/all] 错误 2
make: *** [Makefile:152：all] 错误 2

编译器把warning当成错误了。编译时设置一下参数，忽略告警

OK 问题解决。


etap2_students

[x] text is in C# and use .NET
[x] build succeeded
[x] all UT are green
[x] layers are clearly stated using language terms only
[x] Data API is abstract and contains object model representing process data, which must be clearly stated
[x] prove that the data integration is implemented.
[x] Logic uses only the abstract Data layer API
[x] Communication between the client and the server should be made using the Web Socket
[x] reactive and interactive communication are used
[x] client API must be clearly stated
[x] Unit Test - layers are tested independently using abstract API
[x] Dependency injection (additional framework is not required)
[x] Mock is used for testing purpose (expected but not required)

done


both admin account and account create from webpage can modify tasks

I found that both admin account and account create from webpage can modify tasks, assign handlers. It seems it is an bug .How can I manage the account using admin ?

@yxftju
Hi, thanks for the report. It looks a duplicate of https://github.com/opencv/cvat/issues/1030.
We are going to fix it in the nearest future.

At the moment as workaround is possible to set reduce_task_visibility to True here https://github.com/opencv/cvat/blob/develop/cvat/settings/base.py#L424 to remove public access to unassigned tasks. The new permission system will be introduced in future releases.

目前，可以在reduce_task_visibility此处将解决方法设置为 True https://github.com/opencv/cvat/blob/develop/cvat/settings/base.py#L424以删除对未分配任务的公共访问权限。新的权限系统将在未来版本中引入。
I have modified the cvat/cvat/Settings/base. Py of reduce_task_visibility is True, then the up - d more new but doesn't work, everyone can see the task


constexpr

I recently contributed to https://github.com/fastfloat/fast_float to make the from_chars implementation there constexpr from C++20.
I think making to_chars constexpr is equally possible. Would efforts to do this be welcome here?
I see that to_chars is currently defined in a .cpp file, which could make this challenging without making the library header-only.

Hi, that would be great.
I was also planning to do that at some point, but there are several issues.
First of all, as you pointed out, the library is currently not header-only. My original intention was to move as many things as possible into a separate TU to reduce compile time, but at this point I think maybe the portion dragonbox_to_chars.cpp takes might be tiny compared to dragonbox.h in terms of compile time. But I still wanted to be sure about that so planned to do some benchmark but never did it yet.
The second issue is the language standard. I think it is probably close-to-impossible to make everything constexpr without performance regression within C++17, so my plan was to support constexpr only in C++20 and further. I anyway wanted to support C++11/14, so the plan was to introduce some macros depending on the language version, e.g., something like
#if __cplusplus >= 202300L // Don't know the precise value
#define JKJ_DRAGONBOX_IS_CONSTANT_EVALUATED  if consteval
#elif __cplusplus >= 202002L
#define JKJ_DRAGONBOX_IS_CONSTANT_EVALUATED  if (std::is_constant_evaluated())
#endif

But robust handling of these stuffs might be tricky for number of reasons, for instance:

Some compiler might report __cplusplus to be high enough but still lacks some features. And the proper support of feature testing macros had been quite messy among older versions of the compilers.
MSVC reported a wrong value of __cplusplus for quite a while, maybe we need to introduce a yet another level of indirection here.
I am not quite sure how to edit my CI to properly test various language versions.

Oh, I just realized you made a PR about this. I will make some comments on that. Thanks a lot!

2. MSVC reported a wrong value of __cplusplus for quite a while, maybe we need to introduce a yet another level of indirection here.

MSVC still reports the wrong value, you have to use a switch for the correct value. The workaround is this:
#if __cplusplus >= 201703L || (defined(_MSVC_LANG) && _MSVC_LANG >= 201703L)

@alugowski Ah, thanks for the info!

I recently contributed to https://github.com/fastfloat/fast_float to make the from_chars implementation there constexpr from C++20.
I think making to_chars constexpr is equally possible. Would efforts to do this be welcome here?
I see that to_chars is currently defined in a .cpp file, which could make this challenging without making the library header-only.

It's possible, I have an implementation of it from an old fork in JSON Link

@beached Hi Darrell,
After https://github.com/jk-jeon/dragonbox/pull/42, now dragonbox::to_decimal is already constexpr in C++20+. The remaining issue is that dragonbox::to_chars isn't constexpr, which is essentially because the implementation lives in a separate .cpp file. (Technically testing and other stuffs are also not constexpr but I don't find any reason to make them constexpr anyway.)
I don't really want to make to_chars feature header-only, and also don't want to have a configuration macro for header-only/compiled dual support. (Welcome to ODR hell!)
What I'm thinking is that maybe we can test if consteval (or std::is_constant_evaluated) inside dragonbox::to_chars and if that's the case, then call another implementation living in a header file which just does the naive no-brain digit printing without doing any jeaiii nonsense. So in a sense, it's header-only in the constexpr context, and is compiled otherwise.
What hinders me at this point is that,

@leni536 said he has a trick for constexpr-ifying dragonbox::to_chars but didn't come back so far,
I don't want to copy-paste all the language version testing macros and such stuffs from dragonbox.h into dragonbox_to_chars.h. Then I have to either leak some of the macros into the user's code, or have to have some more support headers, so that now the premise of being single header is broken. For the first point, I personally hate libraries leaking many implementation detail macros and I believe that ideally the only macros exposed to the users are the header guards and interface macros that are explicitly intentionally exposed to the users. For the second point, I guess I will eventually break down dragonbox.h into several headers anyway as the project has grown beyond my initial expectation, but I am still indecisive of what would be the best splitting.

Nice! I'll add that to my list to look at as I don't use to_chars but just to_decimal and do a custom formatting for JSON.

to_chars is now constexpr, by the recent commits (0d273a1, 7962a9a, 2e66efa, 32ebc1f, 37b8090). I just ended up copy-pasting language feature detection boilerplate. Maybe we should refactor it later.


Stop pulling all of simple-icons in on contact page

I use simple-icons for the contact page, due to it being super simple to implement and having nearly everything I needed. The problem is, whenever you navigate to the Contact page, it pulls in the whole package of SVGs (2MB or so). (See components/ContactMethod, line 22.)
It works fine on my connection (and should be like that for most people) but slower connections still exist. This type of thing is generally frowned upon in webdev for that reason.
Maybe I could use some sort of inline require? Will probably try that soon. I used an inline require but it still seems to pull in the full package. If someone who knows their way around this knows what to do, please help me out here. Thanks.

i am uhh hstupid

i do have a slight idea of how to solve the issue now. using webpack's ContextReplacementPlugin it's definitely possible. however figuring it out is the hard part, even hardcoding the names of the icons i import just completely causes the contact page to not work (and with errors of 'cannot find module').

moving this to #44, doing a huge backend refresh and might as well shoot this down as part of that


Fixes #1678. Added parentGC argument to the call MAPL_AddChildFromDSO…

…meta

Description

Added parentGC argument to the call MAPL_AddChildFromDSOmeta
Related Issue

Motivation and Context

This fixes a bug resulting in multiple "root" components in the MAPL hierarchy and cause wrong connections
How Has This Been Tested?

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)

Checklist:

[ ] I have tested this change with a run of GEOSgcm (if non-trivial)
[x] I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
[x] I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

I'm putting a blocker on this until I can test with MOM6. Give me a moment...

Also, I fixed up the changelog and cmakelists for a release if all goes well.


added stock photo resource

Added https://broadlygenderphotos.vice.com/ to the stock photos resource list
Checklist

[x] I made something good today 💐.
[X] I put links in the correct format: [Tool](link) — description.
[X] My description starts with the lower-case letter and ends with the full stop.
[X] I put the tool in the alphabetical order.

Optional

[X] I added the appropriate labels: free, open-source or mac.
[X] I put the tool only to one category.
[x] I followed Contribution Guidelines.

@desirottman Desi, thank you so much for bringing more diversity to our list 😍


Lots of typos

A couple of the changes aren't highlighted properly in GitHub's interface for some reason. For those, you can see the associated commit message to see what was fixed.

Wow, amazing we had so many! Thank you @NoahAndrews!
I'd love to send you some LBC for this. Please DM me as kauffj on our chat or email me at<EMAIL_ADDRESS>with an address.
Thanks!

@NoahAndrews - thanks again for your contribution, look forward to more in the future. Replied back with your reward from our email box.

Thank you! :)


feat: cdk.json could use poetry run

Is your feature request related to a problem? Please describe.
Currently cdk.json requires the cdk dependencies to be installed or run within poetry shell
Describe the solution you'd like
Changing the cdk.json to the following will allow cdk to run without extra streps.
{
  "app": "poetry run python app.py"
}

NOTE: pip install will no longer be needed in the github workflow
https://github.com/ran-isenberg/aws-lambda-handler-cookbook/blob/936588d277a05bba630fc44c46cda050eeec621c/.github/workflows/serverless-service.yml#L35
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

resolved in #621
Thx for opening the issue.


Introducing auto moderation

Pull Request Etiquette

[x] I have checked the PRs for upcoming features/bug fixes.
[x] I have read the contributing guidelines.

Changes

[x] Internal code
[x] Library interface (affecting end-user code)
[x] Documentation
[ ] Other: _____

Closes Issue: NaN
Description
Discord introduced auto moderation and the addition of it in the docs can be found here https://discord.com/developers/docs/change-log#auto-moderation.
Example
To create an auto mod rule you would do
AutoModerationRule rule  = AutoModerationRule.MessageSend.preset("name", TriggerType.KEYWORD).setKeywordPresets(KeywordPresetType.SLURS, KeywordPresetType.PROFANITY).build();

or

AutoModerationRule rule  = AutoModerationRule.MessageSend.keyword("name", TriggerType.KEYWORD).setKeyword("butts", "*cats").build();

and then

guild.createAutoModerationRule(ruke).queue();

Got the point, and will clean it up tomorrow or today

Shall i apply the changes for this https://discord.com/developers/docs/change-log#message-content-in-automod-events

Please do not add the message content intent in this PR. It is completely out of scope.

@Chew @CheesyGamer77 Can you re review this pr please.

There's a button to request a re-review...

There's a button to request a re-review...

I press and nothing happens. Only works for Minn.

@Chew can you do another review please.

@MinnDevelopment Planning on working on this pr now. Is there any point or shall I wait

I won't have time to look into automod any time soon. But we might be interested in making a new PR from scratch in the future. Can't make any promises right now.

Thank you for your effort, but we've decided on a different design. This PR will be superseded by #2429.


[qt5]Fix build failure in linux

Now we don't need to use qmake_all to build qt5 and other modules in linux, it seems to break the disabled parameters during the build. See documentation.

@Rastaban PR-Eager does not seem to work, and ports that have changed have not been rebuilt.
Can you have a look?

/azp run

Forcing a full rebuild under https://dev.azure.com/vcpkg/public/_build/results?buildId=5553.  The CI system will cache results so on later runs if there are no changes beyond what was already tested it just pulls the cached results instead of rebuilding the ports.  This caching is global so identical changes in separate PRs will also be found.  My guess is that it found results from the windows static build PR and did not actually rebuild everything in this one.  Forcing a full rebuild gets around that (although some of the failures may be unrelated flaky ports)

@Rastaban Yeah, I guess that is the reason. It might be better to set a cache for each PR.

@Rastaban Qt5 and its components were built successfully. And 4 ports failed to build(no dependency with qt5):

bond: shell hash changed. Fix PR: #7293.
ogdf: the ci system cannot download source.
vxl: file conflict with qt5-location.
itk: cannot repro.

@JackBoosY we have discussed making a separate cache for each PR, but it would cause a full rebuild on the first run which would would mean the test would take 19 hours to complete.  Also flaky ports (such as bond/ogdf/vxl/itk) would show up in too many unrelated PRs.
This looks good,  Sorry it took so long for me to finish looking at it.


Fix changing light/dark mode dismisses AdaptiveBottomSheet

Fixes: https://github.com/MohamedRejeb/Calf/issues/133
The sheet state should be created outside the condition that shows the sheet.

Looks like this is only solving the problem for the games description sheet.

It looks like showDatePicker is being reset to false on changing the theme which hides the sheet. I tried with material3 ModalBottomSheet and I got the same result, also I can't reproduce the issue in calf samples.

That's very strange that it's getting reset 🤔

Issue was this! https://github.com/ZacSweers/FieldSpottr/pull/26#discussion_r1704522725


Create testing suite for qhub

shared folder working
dask gateway working

I will close this for now in favor of making individual issues if there is anywhere we want to strengthen our testing.


Fix mentioned Windows Server version in text

Because this document describes Windows Server 2016.

@tksh164 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#assign:dknappettmsft


fix(typo): correct typo in examples/app-crm-minimal

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://refine.dev/docs/guides-concepts/contributing/#commit-convention

fixes (#6213)

Thanks @Anonymous961, can you change this one too, please?

Thank you for the contribution @Anonymous961 🙏

Happy to contribute and be a part of this. 😊🙏


p-value and some t-stat calculations differ from R fixest

Some more toying around, and I'm getting different p-value calculations from the original fixest, even in cases where estimates and t-stats match:
With clustering, the t-stats match but p-values are different:
from causaldata import restaurant_inspections
import pandas as pd
import pyfixest.pyfixest as pf

res = restaurant_inspections.load_pandas().data

fixest = pf.Fixest(data = res)
fixest.feols('inspection_score ~ Weekend', vcov = dict({'CRV1':'Year'}))
fixest.summary()
# ### Fixed-effects: 0
# Dep. var.: inspection_score
#
#            Estimate  Std. Error    t value  Pr(>|t|)
# Intercept 93.627262    0.321288 291.412047  0.000000
#   Weekend  2.096548    0.862544   2.430656  0.015072

library(fixest)
library(causaldata)

data(restaurant_inspections)

feols(inspection_score ~ Weekend , data = restaurant_inspections, vcov = ~Year)

# OLS estimation, Dep. Var.: inspection_score
# Observations: 27,178
# Standard-errors: Clustered (Year)
# Estimate Std. Error   t value  Pr(>|t|)
# (Intercept) 93.62726   0.321288 291.41205 < 2.2e-16 ***
#   WeekendTRUE  2.09655   0.862544   2.43066  0.029106 *
#   ---
#   Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
# RMSE: 6.25408   Adj. R2: 8.241e-4

With IID and HC1, the t-stats and p-values differ by very small amounts
fixest = pf.Fixest(data = res)
fixest.feols('Year ~ Weekend', vcov = 'iid')
fixest.summary()
# ### Fixed-effects: 0
# Dep. var.: Year
#
# Estimate  Std. Error      t value  Pr(>|t|)
# Intercept 2010.343815    0.036224 55497.059216  0.000000
# Weekend   -0.862863    0.412097    -2.093833  0.036275

feols(Year~Weekend, data = restaurant_inspections)
OLS estimation, Dep. Var.: Year
Observations: 27,178
Standard-errors: IID
               Estimate Std. Error     t value  Pr(>|t|)
(Intercept) 2010.343815   0.036226 55495.01719 < 2.2e-16 ***
WeekendTRUE   -0.862863   0.412112    -2.09376  0.036291 *
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
RMSE: 5.94874   Adj. R2: 1.245e-4

fixest = pf.Fixest(data = res)
fixest.feols('Year ~ Weekend', vcov = 'HC1')
fixest.summary()
# ### Fixed-effects: 0
# Dep. var.: Year
#
# Estimate  Std. Error      t value  Pr(>|t|)
# Intercept 2010.343815    0.036181 55562.889684  0.000000
# Weekend   -0.862863    0.471032    -1.831856  0.066973

feols(Year~Weekend, data = restaurant_inspections, vcov = 'hc1')
# OLS estimation, Dep. Var.: Year
# Observations: 27,178
# Standard-errors: Heteroskedasticity-robust
# Estimate Std. Error     t value  Pr(>|t|)
# (Intercept) 2010.343815   0.036182 55561.86747 < 2.2e-16 ***
#   WeekendTRUE   -0.862863   0.471041    -1.83182  0.066989 .

Hi, after taking one more close look at the fixest docs, I have just recalled that the fixest default is to compute p values for clustered standard errors based on a t(G-1) distribution, not on the normal distribution (which is what I do in pyfixest). I'll change that.
I should in general add tests for pvalues, which I currently don't do. =)
I am still investigating the errors with iid and HC1. I don't think it's only small sample adjustments. Fixest uses (N-1)/(N-k) for both, and pyfixest does the same for HC1.

I spent slightly too much time trying to get standard errors and pvalues to match correctly. Here is what fixest seems to be doing:

iid errors: small sample corrections as described in the vignette, i.e. if adj = TRUE, multiply with (N-1) / (N-k), with k set according to the fixef.K specification. p-values via a t(N-k) distribution
heteroskedastic errors: id adj = TRUE, a small sample adjustment of N / (N-k) is applied (not (N-1)/(N-k) as suggested in the vignette. If adj = FALSE, a ssc of N / (N-1) is applied. p-values via a t(N-k) distribution
clustered errors: ssc as in the vignette, p-values via a t(G-1) distribution

Inference should now match exactly, for all supported types (iid, HC1, CRV1):
from causaldata import restaurant_inspections
import pandas as pd
import pyfixest as pf
res = restaurant_inspections.load_pandas().data

fixest = pf.Fixest(data = res)
fixest.feols('Year ~ Weekend', vcov = 'iid')
fixest.summary()

# ###
#
# model: feols()
# fml: Year ~ Weekend
# ---
# ###
#
# Fixed effects:  0
# Dep. var.:  Year
# Inference:  iid
#
#              Estimate  Std. Error      t value  Pr(>|t|)
# Intercept 2010.343815    0.036226 55495.017194  0.000000
#   Weekend   -0.862863    0.412112    -2.093756  0.036291

And via fixest:
OLS estimation, Dep. Var.: Year
Observations: 27,178
Standard-errors: IID
               Estimate Std. Error     t value  Pr(>|t|)
(Intercept) 2010.343815   0.036226 55495.01719 < 2.2e-16 ***
WeekendTRUE   -0.862863   0.412112    -2.09376  0.036291 *
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
RMSE: 5.94874   Adj. R2: 1.245e-4

For HC1 errors:
             Estimate  Std. Error      t value  Pr(>|t|)
Intercept 2010.343815    0.036182 55561.867471  0.000000
  Weekend   -0.862863    0.471041    -1.831822  0.066989

and again for fixest:
OLS estimation, Dep. Var.: Year
Observations: 27,178
Standard-errors: Heteroskedasticity-robust
               Estimate Std. Error     t value  Pr(>|t|)
(Intercept) 2010.343815   0.036182 55561.86747 < 2.2e-16 ***
WeekendTRUE   -0.862863   0.471041    -1.83182  0.066989 .
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
RMSE: 5.94874   Adj. R2: 1.245e-4

This is now also properly tested =)


Add vary on authorization to protected_resource_view

This fixes upstream/#343

Love it
Can we merge it?

It'll be merged into this fork, yes. There is a plan to try to upstream the changes from this fork, but I haven't been able to get hold of the maintainer.
If I can't get hold of them soon I'll create an upstream issue detailing the plans for this fork.

For the moment you're welcome to use the develop branch, which should be stable, but we won't be cutting any releases until we know the relationship with upstream.

LGTM


Keep a list of middleware resolvers

Fixes #15 by unrolling the generator into a list.

Coverage remained the same at 96.746% when pulling 4d03e85f9dd1b61e72d35dfb1010af97a09db0e8 on patrys:patch-1 into f6b078bddae4dd8a48ebf878a6fd5fbbac52bd1b on graphql-python:master.

Coverage remained the same at 96.746% when pulling 4d03e85f9dd1b61e72d35dfb1010af97a09db0e8 on patrys:patch-1 into f6b078bddae4dd8a48ebf878a6fd5fbbac52bd1b on graphql-python:master.

Thanks a lot. We also need to add a regression to graphql-core-next/tests/execution/test_middleware.py that is failing without this fix. If you like, you can add one, otherwise I will do it when I will look into this later this week.


Version 0.3.X Changes

Here are the changes for the next release.
Breaking Changes:

Client Connection Changes:

Replaced the auth_pass option with password.
Replaced the unix_socket option with path.

Changed minimum redis client version to 2.6.2

New Features

Added support for the redis client retry_strategy option. See issue #17 (jbpin)
Added options: 'string_numbers', 'retry_unfulfilled_commands', 'disable_resubscribing', 'rename_commands'
Added the url option for connections.

Fixes

Fixed an issue with an extra select statement being sent on client connect when the db option is set.
Removed deprecated options: 'parser', 'socket_nodelay', 'retry_max_delay', 'connect_timeout', 'max_attempts'

Published 0.3.0 to npm.

Just published version 0.3.1 which now includes connection tracking.
You can now access a tracking value for each client using client._sol_cid or the cid value in several events. I also added two different strategy examples for users wanting to change the default reconnection behavior.


feat: async pruning enabled

Updated cosmos-sdk to enable async pruning: https://github.com/neutron-org/cosmos-sdk/pull/39

https://github.com/neutron-org/neutron-tests/actions/runs/10527141661