Test solver against random graphs

Almost all of the tests I've written for gps' solver thus far are geared towards checking some aspect of correctness of the solver. Testing its performance has not been a priority. But the solver is tasked with constraint solving - an NP-hard search problem. Its performance (against real graphs) is something we have to care very much about.
Of course, there's a chicken-or-egg problem there - getting real graphs is difficult when the ecosystem doesn't exist yet for us to test against. Even when it does, though, it would be ideal if we had a way to get out ahead of solver performance issues, rather than having to wait for them to arise.
It seems to me that a potentially good approach to "getting ahead" in this way is to invest in a system for testing the solver against random dependency graphs. It's not trivial to do so - the generator would need to work across several dimensions of variables - but it shouldn't be crazy hard to do, either. The crucial bit will be exporting the generated graphs into valid Go code, probably in the same form used to declare the handcrafted correctness-checking fixtures that exist today.
The basic loop would be something like this:

Generate random graph
Dispatch a solve using the random graph
If solve time exceeds , dump the graph

Support for timing out a solve run would need to be added to the solver. Not hard, and no need to expose that control yet

Repeat 1-3 until we find a graph that causes solving to run for more than X (maybe start with 5) seconds, then dump the templated declaration of it to stdout

This would be a great tool in our arsenal, though I'm not sure when I'd have time to get to it myself. Help would be awesome. I'm happy to add more info here, and generally provide guidance as needed to anyone interested.

One way to construct "worst case DAGs" for version control operations is to generate a graph in the form of a N-dimensional grid or lattice structure. This effectively makes every "non-edge" commit in the DAG a merge commit.
For the dependency resolution problem a similar structure could be used. However, there are some wrinkles.

VCS DAGs are different than the dependency resolution problem. So a different random structure will be needed. This type of structure may be useful to think about when constructing the random graphs.

For 3SAT (and by extension all NP-Complete problems) there is currently no know way to reliably and randomly select a "hard-instance" of a problem. If we could randomly generate hard instances of NP-Complete problems we could construct simple and secure cryptographic systems. However, at present we cannot do this.

However, we do not need to necessarily generate only hard instances. It may be reasonable to simply generate large instances.
From  reading the code it looks like the current testing infrastructure could be used to generate random graphs with some caveats. First, we may not know what the correct solution is but we could ensure only solvable graphs are generated. It could be a secondary test to ensure only non-solvable graphs are generated.

Thanks, I do think this helps frame the problem.

VCS DAGs are different than the dependency resolution problem. So a different random structure will be needed. This type of structure may be useful to think about when constructing the random graphs.

Definitely - defining the structure of the random graphs strikes me as being what will take, by far, the most work. It also demands attention because it will need some design for flexibility - we are likely to add new dimensions to the solver over time, which the random graph generator would need to reflect, if it is to retain its utility.
Whereas that worst-case lattice you describe for VCS operations describes only a single dimension - the is-child-of relation - between vertices, our problem here has a slightly more complex model to consider. In the simple case (and indeed, other package managers can do this), we would ideally treat each "project" - really, a tree of packages - as the vertex. However, the relation that we are trying to satisfy is the imports, and that's a property of individual packages, rather than projects as a whole. Packages can't vary versions independently of their project, though - we enforce the requirement that all packages from a given project must use the same version. (I think the motivation for maintaining that invariant should be clear here, given the reduction in size of the search space it induces). The solver itself more or less treats the projects as vertices and the packages as properties of those vertices, but that doesn't necessarily mean that's the right model for a random generator.
That's the base shape of the graph. Then there's the question of how to model the requirements themselves.

For 3SAT (and by extension all NP-Complete problems) there is currently no know way to reliably and randomly select a "hard-instance" of a problem. If we could randomly generate hard instances of NP-Complete problems we could construct simple and secure cryptographic systems.

Hah, interesting! I've got your paper bookmarked, I'll read through it when I get a chance. But...

However, we do not need to necessarily generate only hard instances. It may be reasonable to simply generate large instances.

This is crucial, and why I was inclined towards a random generator in the first place: I'd go further to say that we expressly don't care about generating hard instances, because I don't think that hard instances have much to do with the shape of real depgraphs.
I suspect - but desperately want evidence - that if we were to analyze the universal Go import graph, we would find it is extremely sparse, with a relatively small number of densely-imported hotspots (e.g., github.com/sirupsen/logrus). I think an ideal approach to this problem would work from aggregate data about the global depgraph, including information like:

Distribution of number of packages per project
Distribution of number of non-stdlib imports per package
Frequency with which new non-stdlib imports are introduced to packages across version changes
Frequency with which existing non-stdlib imports are removed from packages across version changes
Distribution of depgraph width for individual projects

(by no means exhaustive list)
With this kind of information on hand, we might be able to guide the random graph generator towards creating graphs that are more realistic.

From reading the code it looks like the current testing infrastructure could be used to generate random graphs with some caveats.

Great! Though note that the "bimodal" fixtures are probably the better ones to go on, as they incorporate the crucial project/package relationship I described above. The basic ones collapse that distinction - they pretend that all projects have exactly one package.

First, we may not know what the correct solution is but we could ensure only solvable graphs are generated.

If that's a guarantee we can make, it'd be amazing. 👍 👍 👍

@sdboyer That paper is really more about cryptography. Connamacher and Molloy's paper is a better reference.
Doing some examples out by hand, the lattice approach looks promising as you can set it up to be:

As large as you like.
Generate maximum number of version conflicts at every level in the diamond.

However, that might actually be easy to solve. The hardest instances will be when there are many "promising" partial solutions but only one solution which is difficult to find by any heuristics. I will think more about how to model this.

However, that might actually be easy to solve. The hardest instances will be when there are many "promising" partial solutions but only one solution which is difficult to find by any heuristics. I will think more about how to model this.

Great. It's the weird cases in the middle that'll get us.

After giving this some more thought....
So previously we were thinking of dependency resolution as constraint solving and trying to generate conflicts. However, this is not the only way to look at. We can also look at in terms of a slightly wierd form of the subgraph isomorphism problem. This quick post will just go through an example. I am going to work on an actual algorithm maybe tomorrow. I came up with this idea over lunch and I thought I would put it here before I lost the scrap of paper I wrote it on.
Example
Dependencies for project a. Read a : b(1,2) as a depends on project b versions 1 or 2. For simplicity everything will be a project. Versions will be simply numbers. Projects can depend only on specifically listed numbers. So the listing can be viewed as what you would see after expanding the semver constraints.
a    : b(1,2), c(1,2)
b(1) : d(1)
b(2) : d(2)
c(1) : d(2), e(1)
c(2) : d(3), e(1,2)
d(1) : f(1)
d(2) :
d(3) : f(1)
e(1) :
e(2) : f(1)

This leads to the following graph of the dependencies:

To find a solution we need to match (that is find a subgraph isomorphism mapping) the following "grammar." The grammar describes the shape of the possible solutions:
a -> {b, c}
b -> {d}
c -> {d, e}
d -> {}
   | {f}
e -> {}
   | {f}
f -> {}

This leads to 4 candidate graphs to match against the graph of project dependencies

To determine the candidate solutions, match the graphs and find the subgraph isomorphism mappings:

The middle candidate solution is invalid because version e:1 depends on f:1 and it is not in the graph. So it would be removed, leaving 2 solutions:

Just to chime in: I think it's important to generate invalid graphs as well.  Attempts will fail, and it'd be best if they completed in a sane amount of time.

It certainly makes sense that there would be a way to express the problem here as a weird version of subgraph isomorphism - both are NP-complete. The jump I'm not quite clear on is why that's helpful for the random input generation problem; as-is, this reads to me more like a thought on changing the core algorithm itself. Which is a discussion we can have, sure, but not what this issue is for 😄
But let's assume I've just missed a connection there, which is fine. I've got a few thoughts on the basic model you seem to be headed for. First:

So the listing can be viewed as what you would see after expanding the semver constraints.

This is an interesting structural change, because the typical semver range constraints (~1.0.0 aka 1.0.x, or ^1.0.0 aka 1.x.x) are infinite, admitting ℕ in each of those positions. I don't know the significance of this with respect to the problem, but it does trip something in my head.

While the grammar makes sense, it seems potentially a bit lossy in that it's not explicit about whether a vertex itself has to be present - only about the valid sets of connected vertices it must have if it is present. But perhaps it's implicit (as it is in gps' tests) that only the first item is required/is the root.

The third and fourth images are missing key information - the absence or presence of f which from d -> {} | {f}, which also makes it hard to see where you're going here.

Honestly, the last image that really makes much sense to me is the second one. That makes it seem like you're trying for a sort of first-pass check to judge, by shape, as to whether a graph even could be a solution, without having to look at versions at all. But...well, yeah, I'm just not sure where it's going, or how it helps us generate random graphs 😄
Looking forward to seeing more when you have it!

@sdboyer I will do a longer response later but I wanted to address one thing:

So the listing can be viewed as what you would see after expanding the semver constraints.

This is an interesting structural change, because the typical semver range constraints (~1.0.0 aka 1.0.x, or ^1.0.0 aka 1.x.x) are infinite, admitting ℕ in each of those positions. I don't know the significance of this with respect to the problem, but it does trip something in my head.

The selector (eg. ^1.0.0 or ~1.0.0) can only select versions which exist. There are only countable versions for any particular project. Thus, expanding the constraint to the matched versions yields a countable number of nodes. Since, in practice there are a finite number of projects and every project has a finite number of versions there are only a finite number of nodes created. Thus, the graph is finite in size.

Since, in practice there are a finite number of projects and every project has a finite number of versions there are only a finite number of nodes created. Thus, the graph is finite in size.

Sure, ofc, the actual problem we're solving will always be finite. Sounds like this probably isn't significant to our current concerns, then :)
Thanks!

bump :)

This issue was moved to golang/dep#422


Added the word existing

Customers are confused and so added the word 'existing'

@chrisda  could you please approve this for me?

@dhairyya, beware of changing section titles as that can (and in this case did) break links to those sections in other topics.


chore: always generate a repository if not a monorepo

Context in this doc
This PR makes the generation workflow to always get triggered when the target repository is not a monorepo (i.e. handwritten libraries).
This will still respect other changes between baseline and current configurations when it comes to PR description generation, but if no config changes are detected then no PR description will be created, assuming that the PR description of the original PR that will trigger the generation will be informative enough.

In general, I feel this approach creates a tighter coupling between the commit history generation and library generation, which is a direction we don't want to go. Can we try to fork from an earlier place? For example, we can pass none here if the config is not monorepo. Because we would always generate a library if target_library_names is none.

@blakeli0 this approach is simpler, and I agree that it keeps separation of concerns. PTAL again when you have a chance!


Alignment RealEstateCore

Greetings!
I'm Pim, Technical Director of PHYSEE, and we have build a Building Management Platform that optimises buildings using building physics simulations, SENSE. We utilise DigitalTwin technology to store and manage contextual data.
We have been using RealEstateCore for our ontology, mainly as it implements Azure DigitalTwin DTDL models, so it's easy for us to integrate into our architecture. RECv4 has recently been released and is now fully aligned with the Brick ontology.
I'm always happy and sad to see multiple initiatives for alignment on protocols. Happy to see people feel the same need, sad to see that there is so many standards in the industry. I do think no one can 'win the battle alone', and we are both battling for better data models for buildings.
Should there be an initiative to add REC to the OAP alignment? Or is that similar to a REC <> Haystack alignment?

Hi Pim,
Nice to meet you and thanks for your question!
We have laid some groundwork for alignment to Real Estate Core, mostly in terms of spatial modeling. See Breakroom in data/facilities/space.room.yaml  for an example:

This alignment is not part of the API yet, however.


Requiring ProfileColorProperty names to be unique is problematic.

In https://github.com/phetsims/scenery/issues/1257#issuecomment-888366271, @samreid said:

ProfileColorProperty names must be unique, so declaring one in a constructor would throw a runtime assertion.

I agree that the names need to be unique.
But this name must be unqiue across ALL repos. That seems like a big problem.  I'm going to add a new ProfileColorProperty, to common code or my sim. How do I verify that I'm choosing a unique name? Run all sims to find out? And I need to do this every time I add a ProfileColorProperty to my sim?
Are developers going to choose good names? Are they going to be thinking about name conflicts? Do we need a naming convention that helps mitigate conflicts?  Should the naming be hierarchical?  Should we use tandem names, since they also have to be unique? ....
This requires more thought.

Looking ahead...  As the number of ProfileColorProfile instances grows, Color Editor is going to become unusable if the structure is flat -- the same way that the Studio tree would be unusable if it were flat.  We'll need some sort of structure/hierarchy in order to "collapse" things we're not interested in.  For example, if the designer is only interested in sim-sepcific colors, they should be able to hide common-code colors.

Discussed briefly with @samreid on Zoom.  The general idea that we dicussed was:

delete the name parameter to ProfileColorProperty
use tandem name to provide structure and enforce uniqueness of names
use Studio for editing colors
delete Color Editor

The obvious issue with this idea is that colors will only be editable if they are instrumented. And not all sims are instrumented.  So we'll have to run this idea past the team.
The set of ProfileColorProperty instances that PhET designers are interested in may be different than the set that instructional designers are interested in.  But we can address that by using phetioFeatured.

Let's discuss this on Thursday, unassigning until then.

Moving comments from @pixelzoom  from https://github.com/phetsims/scenery/issues/1251#issuecomment-888396151
@pixelzoom said:
Is the tandem strucuture flat for colors, all elements appearing under global.colors?   Or is it hierarchical, with colors grouped under components?
Suppose that we have default colors for Slider, defined as static ProfileColorProperty instances in Slider.js.  Which of these did you have in mind?
// (1)
global.colors.sliderDefaultThumbFillProperty
global.colors.sliderDefaultThumbStrokeProperty
global.colors.sliderDefaultTrackFillProperty
global.colors.sliderDefaultTrackStrokeProperty

// (2)
global.colors.Slider.defaultThumbFillProperty
global.colors.Slider.defaultThumbStrokeProperty
global.colors.Slider.defaultTrackFillProperty
global.colors.Slider.defaultTrackStrokeProperty

// (3)
global.colors.Slider.thumb.defaultFillProperty
global.colors.Slider.thumb.defaultStrokeProperty
global.colors.Slider.track.defaultTrackFillProperty
global.colors.Slider.track.defaultStrokeProperty

(3) makes the most sense to me.
Hierarchical structure is more likely to also avoid name collisions. For example, what if I have a custom Slider, with its own sliderDefaultThumbFillProperty?
A flat structure also has the problem that colors related to "slider" will not be grouped together in the tandem tree, unless you use a "slider" prefix on every tandem name, as I've done in (1) above.

@pixelzoom said:
I'd like to see a convention something like this for instances that are defined at usage sites:
global.colors.{{CLASS_NAME}}.*Property
e.g.:
global.colors.Slider.defaultThumbFillProperty
But that's even problematic, because class names are not unique across all repos. Maybe this?
global.colors.{{REPO}}.{{CLASS_NAME}}.*Property
e.g.:
global.colors.sun.Slider.defaultThumbFillProperty

@pixelzoom said:

Also note in the above example that I've had to duplicate fourieMakingWavesPanelFillProperty three times.  ProfileColorProperty name and tandem name both have the same "uniqueness" requirements. Maybe we should ditch name, use the tandem name, and require all ProfileColorProperty to be instrumented if we want them to show up in ColorEditor?

From today's design meeting:
@pixelzoom: we should not support a flat structure going forward.  There is also opportunity for name collisions, and we have to specify the names twice independently.
@kathy-phet: We do not want all colors to appear in studio, as they do in the Color Editor.  Most colors should not be phet-io instrumented.
Maybe we will have to stick with the current pattern for now, or maybe add prefixes, or maybe add a ProfileColorProperty that auto-prefxes.
@pixelzoom says in the long run we should maybe have different sections be collapse-able in the color editor.

@pixelzoom: we should not support a flat structure going forward. There is also opportunity for name collisions, and we have to specify the names twice independently.

A clarification...  I said we should not do anything that precludes a hierarchical structure going forward.  If we can support a hierarchical structure, we can support a flat structure.   And a hierarchical structure is relevant to the Color Editor only - it's essential to avoiding namespace collisions.

Unassigning and adding a 6 month reminder on my personal calendar to re-evaluate (if it hasn't been requested before then).

Requesting that this be reevaluated now.  Imo it's a mistake to defer addressing this until it becomes a problem. A developer will either need to address it when they hit a name collision, or (more likely) use a non-optimal color name to avoid the name collision.
This could be addressed relatively easily now by changing the constructor signature of ProfileColorProperty to:
  /**
   * @param {string} repoName - name of the repository that this ProfileColorProperty belongs to
   * @param {string} colorName - name of this color, must be unique within the repository
   * @param {Object} colorProfileMap - object literal that maps keys (profile names) to ColorDef
   * @param {Object} [options]
   */
  constructor( repoName, colorName, colorProfileMap, options ) {

For now, ProfileColorProperty can just take repoName and colorName, and concatenate them, with a separator, and register that with colorProfilePropery.  Recommended to use the '.' separator, like tandems.

How would you like to factor out the repoName in simulations?  A repo-specific ColorProfileProperty subclass?

Rather than @param {string} repoName, let's use @param {Namespace} namespace}.  Then in ProfileColorProperty:
const colorProfileName = `${namespace.name}.${colorName}`;

How would you like to factor out the repoName in simulations? A repo-specific ColorProfileProperty subclass?

I would be fine with (e.g. in FMWColors.js):
import fourierMakingWaves from '../fourierMakingWaves.js';
...
const FMWColors = {

  // Background colors for screens.
  discreteScreenBackgroundColorProperty: new ProfileColorProperty( fourierMakingWaves, 'discreteScreenBackgroundColorProperty', {
    default: new Color( 236, 255, 255 )
  } ),
...

I prefer using @param {Namespace} namespace} instead of @param {string} repoName because:

Every .js (expept main.js) has a Namespace import
It avoids the questions of repoName format -- is it 'fourier-making-wave' or 'fourierMakingWaves'?
It avoid potential typos like 'foueir-making-waves'.

And yes, this API may need to change a some time in the future.  But it avoid name collisions by creating a per-repo (per-Namespace) namespace.  And it's unlikely we'll need to change @param colorName arguments, in the future, because they can be chosen to make sense for the repo, not perverted to avoid name collisions.

How would you like to factor out the repoName in simulations? A repo-specific ProfileColorProperty subclass?

A developer could easily create a repo-specific  ColorProfileProperty subclass, e.g:
import fourierMakingWaves from '../fourierMakingWaves.js';
...
class FMWColorProfileProperty extends ProfileColorProperty {
  constructor( colorName, colorProfileMap, options ) {
    super( fourierMakingWaves, colorName, colorProfileMap, options );
  }
}

But I don't think that's necessary. Namespace is conveniently an import in every .js file (expect main.js). I don't think it's worth having a subclass just to avoid 1 constructor param.

Here's a patch that was tested with FMWColors.js.  Note the "TODO" for this.name in ProfileColorProperty.

Patch
Index: scenery/js/util/ProfileColorProperty.js
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/scenery/js/util/ProfileColorProperty.js b/scenery/js/util/ProfileColorProperty.js
--- a/scenery/js/util/ProfileColorProperty.js	(revision cacb390e636c006c8947d9d07cc6a52d8f0540b9)
+++ b/scenery/js/util/ProfileColorProperty.js	(date<PHONE_NUMBER>532)
@@ -7,6 +7,7 @@
  */
 import arrayRemove from '../../../phet-core/js/arrayRemove.js';
 import merge from '../../../phet-core/js/merge.js';
+import Namespace from '../../../phet-core/js/Namespace.js';
 import Tandem from '../../../tandem/js/Tandem.js';
 import scenery from '../scenery.js';
 import SceneryConstants from '../SceneryConstants.js';
@@ -14,24 +15,29 @@
 import ColorProperty from '../util/ColorProperty.js';
 import colorProfileProperty from './colorProfileProperty.js';

+// constant
+const NAME_SEPARATOR = '.';
+
 // static instances are tracked for iframe communication with the HTML color editor
 const instances = [];

 class ProfileColorProperty extends ColorProperty {

   /**
-   * @param {string} name - name that appears in the HTML color editor
+   * @param {Namespace} namespace - namespace that this color belongs to
+   * @param {string} colorName - name of the color, unique within namespace
    * @param {Object} colorProfileMap - object literal that maps keys (profile names) to ColorDef
    * @param {Object} [options]
    */
-  constructor( name, colorProfileMap, options ) {
+  constructor( namespace, colorName, colorProfileMap, options ) {
+
+    assert && assert( namespace instanceof Namespace );
+    assert && assert( typeof colorName === 'string' );

     options = merge( {
       tandem: Tandem.OPTIONAL
     }, options );

-    assert && assert( !!name, 'ProfileColorProperty.options.name is required' );
-
     // All values are eagerly coerced to Color instances for efficiency (so it only has to be done once) and simplicity
     // (so the types are uniform)
     colorProfileMap = _.mapValues( colorProfileMap, Color.toColor );
@@ -54,8 +60,9 @@
       this.value = this.colorProfileMap[ colorProfileName ] || this.colorProfileMap[ SceneryConstants.DEFAULT_COLOR_PROFILE ];
     } );

+    //TODO Should this.name be private? Or have a more descriptive name in case we need to locate usages?
     // @public (read-only)
-    this.name = name;
+    this.name = `${namespace.name}${NAME_SEPARATOR}${colorName}`;

     // On initialization and when the color changes, send a message to the parent frame identifying the color value.
     // The HTML color editor wrapper listens for these messages and displays the color values.
Index: fourier-making-waves/js/common/FMWColors.js
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/fourier-making-waves/js/common/FMWColors.js b/fourier-making-waves/js/common/FMWColors.js
--- a/fourier-making-waves/js/common/FMWColors.js	(revision 9599bcc61de41cb4a6620d80ed2fbba603134c83)
+++ b/fourier-making-waves/js/common/FMWColors.js	(date<PHONE_NUMBER>538)
@@ -15,74 +15,74 @@
 const FMWColors = {

   // Background colors for screens.
-  discreteScreenBackgroundColorProperty: new ProfileColorProperty( 'discreteScreenBackgroundColorProperty', {
+  discreteScreenBackgroundColorProperty: new ProfileColorProperty( fourierMakingWaves, 'discreteScreenBackgroundColorProperty', {
     default: new Color( 236, 255, 255 )
   } ),
-  waveGameScreenBackgroundColorProperty: new ProfileColorProperty( 'waveGameScreenBackgroundColorProperty', {
+  waveGameScreenBackgroundColorProperty: new ProfileColorProperty( fourierMakingWaves, 'waveGameScreenBackgroundColorProperty', {
     default: new Color( 236, 255, 255 )
   } ),
-  wavePacketScreenBackgroundColorProperty: new ProfileColorProperty( 'wavePacketScreenBackgroundColor', {
+  wavePacketScreenBackgroundColorProperty: new ProfileColorProperty( fourierMakingWaves, 'wavePacketScreenBackgroundColor', {
     default: new Color( 255, 250, 227 )
   } ),

   // Fill for all Panels
-  panelFillProperty: new ProfileColorProperty( 'panelFill', {
+  panelFillProperty: new ProfileColorProperty( fourierMakingWaves, 'panelFill', {
     default: Color.grayColor( 245 )
   } ),

   // Stroke for all Panels
-  panelStrokeProperty: new ProfileColorProperty( 'panelStroke', {
+  panelStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'panelStroke', {
     default: Color.grayColor( 160 )
   } ),

   // Stroke for horizontal separators in Panels
-  separatorStrokeProperty: new ProfileColorProperty( 'separatorStroke', {
+  separatorStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'separatorStroke', {
     default: Color.grayColor( 200 )
   } ),

   // Grid line stroke for all charts except the Amplitude chart in the 'Discrete' and 'Wave Game' screens
-  chartGridLinesStrokeProperty: new ProfileColorProperty( 'chartGridLinesStroke', {
+  chartGridLinesStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'chartGridLinesStroke', {
     default: Color.grayColor( 200 )
   } ),

   // Stroke for all x and y axes
-  axisStrokeProperty: new ProfileColorProperty( 'axisStroke', {
+  axisStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'axisStroke', {
     default: Color.grayColor( 170 )
   } ),

   // Stroke for the sum plot in the Discrete and Wave Packet screens
-  sumPlotStrokeProperty: new ProfileColorProperty( 'sumStroke', {
+  sumPlotStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'sumStroke', {
     default: 'black'
   } ),

   // Stroke used to plot answer to a challenge in Sum chart of the Wave Game screen.
   // If you're thinking of changing this to something other than pink, note that the UI says "Match the pink waveform..."
-  answerSumPlotStrokeProperty: new ProfileColorProperty( 'answerSumPlotStroke', {
+  answerSumPlotStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'answerSumPlotStroke', {
     default: new Color( 255, 0, 255 )
   } ),

   // Stoke used to plot the user's guess to a challenge in the Sum chart of the Wave Game screen.
-  guessSumPlotStrokeProperty: new ProfileColorProperty( 'guessSumPlotStroke', {
+  guessSumPlotStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'guessSumPlotStroke', {
     default: 'black'
   } ),

   // Stroke used to plot the Sum for infinite harmonics in the Discrete screen
-  infiniteHarmonicsStrokeProperty: new ProfileColorProperty( 'infiniteHarmonicsStroke', {
+  infiniteHarmonicsStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'infiniteHarmonicsStroke', {
     default: Color.grayColor( 189 )
   } ),

   // Fill for the level-selection buttons AND the scoreboard in the Wave Game screen
-  levelSelectionButtonFillProperty: new ProfileColorProperty( 'levelSelectionButtonFill', {
+  levelSelectionButtonFillProperty: new ProfileColorProperty( fourierMakingWaves, 'levelSelectionButtonFill', {
     default: new Color( 255, 214, 228 )
   } ),

   // Fill for the width indicators in the Wave Packet screen
-  widthIndicatorsFillProperty: new ProfileColorProperty( 'widthIndicatorsColor', {
+  widthIndicatorsFillProperty: new ProfileColorProperty( fourierMakingWaves, 'widthIndicatorsColor', {
     default: 'red'
   } ),

   // Stroke for the Continuous Waveform in the Wave Packet screen
-  continuousWaveformStrokeProperty: new ProfileColorProperty( 'continuousWaveformStroke', {
+  continuousWaveformStrokeProperty: new ProfileColorProperty( fourierMakingWaves, 'continuousWaveformStroke', {
     default: Color.grayColor( 189 )
   } )
 };
@@ -103,7 +103,7 @@
   new Color( 255, 105, 180 )
 ];
 FMWColors.HARMONIC_COLOR_PROPERTIES = _.map( HARMONIC_COLORS,
-  ( color, index ) => new ProfileColorProperty( `harmonic${index + 1}Color`, {
+  ( color, index ) => new ProfileColorProperty( fourierMakingWaves, `harmonic${index + 1}Color`, {
     default: HARMONIC_COLORS[ index ]
   } ) );

Here's how Color Editor looks for Fourier:

From 8/5/21 dev meeting:
We decided to move this to a sub team discussion with @samreid, @pixelzoom, and @zepumph.

I'll apply the changes above and update other sim occurrences.  We will keep the duplication for now, and not worry about tandems/etc.

I added the Namespace parameter to ProfileColorProperty and marked ProfileColorProperty.name as private to the file.  @pixelzoom would you like to review?

I reviewed changes to ProfileColorProperty.js, how it looks in FMWColors.js, and took Color Editor for a test drive.  Looks nice! Closing.


Performance implications if next is not called in the middleware?

In the middleware function, to move on to the succeeding  middleware function, we need to invoke the next  function. As we all know, if we  omit the call the next() function, the request will be hanging. In these scenarios, is there are any performance implications due to this? If yes, then what are those issues? What might be the issues if we do not explicitly call next function and requests are left hanging?
Thank you.

The only issue I'm aware of would be hitting the max fd limit on linux based oses. Really just hitting som kind of limit to maximum number of open tcp connections on your server.
AFAIK whatever the issue is wouldn't be specific to Express, but rather a question for Node.js HTTP server (or whatever server you are using if not that).

yeah rather than specific to expressjs, its a general query. since i am using express to build my application and  there is not any information on the express documentation what happens if the requests are left hanging, i had posted on this.
so the only issue might be related to the tcp connections.
Thank you very much for the information


[Bug?]: Solid Start breaks compatibility with some Vite plugins (appending noscript to body)

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Vite plugins that append <noscript> tag to body prevent Solid Start applications from ever starting.
Expected behavior 🤔
Vite plugins that append <script> and <noscript> tags to <body> should work.
Steps to reproduce 🕹
Steps:

Start a Solid Start project.
Add vite-plugin-radar library to the project.

// app.config.ts

import { defineConfig } from '@solidjs/start/config'
import { VitePluginRadar } from 'vite-plugin-radar'

export default defineConfig({
  vite: {
    plugins: [
      VitePluginRadar({
      enableDev: true,
      gtm: [
        {
          id: 'GTM-AAAAAA',
        },
      ],
    }),
    ]
  }
});

Start the application.
Minimal reproduction repo: https://codesandbox.io/p/github/IgorSzymanski/solid-start-plugin-issue/main?import=true

Context 🔦
Trying to add Vite plugins that append noscript tags to body fails with error:
TypeError: assetMap[tag] is not a function
    at Module.renderAsset (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/renderAsset.jsx:34:23)
    at eval (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/StartServer.jsx:67:153)
    at Array.map (<anonymous>)
    at get assets [as assets] (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/StartServer.jsx:67:120)
    at get children [as children] (/project/solid-start-plugin-issue/src/entry-server.tsx:19:88)
    at NoHydration (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/web/dist/server.js:569:16)
    at Module.createComponent (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:357:10)
    at document (/project/solid-start-plugin-issue/src/entry-server.tsx:17:127)
    at Module.createComponent (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:357:10)
    at get children [as children] (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/StartServer.jsx:65:40)
    at eval (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/shared/ErrorBoundary.jsx:41:60)
    at Module.catchError (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:152:12)
    at TopErrorBoundary (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/shared/ErrorBoundary.jsx:41:37)
    at Module.createComponent (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:357:10)
    at get children [as children] (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/StartServer.jsx:63:46)
    at NoHydration (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/web/dist/server.js:569:16)
    at Module.createComponent (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:353:15)
    at StartServer (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/StartServer.jsx:61:32)
    at Module.createComponent (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:353:15)
    at eval (/project/solid-start-plugin-issue/src/entry-server.tsx:16:96)
    at eval (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/handler.js:78:18)
    at file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/web/dist/server.js:289:34
    at createRoot (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/dist/server.js:58:14)
    at Module.renderToStream (file:///project/solid-start-plugin-issue/node_modules/.pnpm/solid-js@1.8.17/node_modules/solid-js/web/dist/server.js:287:14)
    at eval (/project/solid-start-plugin-issue/node_modules/.pnpm/@solidjs+start@1.0.1_solid-js@1.8.17_vinxi@0.3.11_vite@5.3.1/node_modules/@solidjs/start/dist/server/handler.js:76:46)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async _callHandler (file:///project/solid-start-plugin-issue/node_modules/.pnpm/h3@1.11.1/node_modules/h3/dist/index.mjs:1821:16)
    at async _callHandler (file:///project/solid-start-plugin-issue/node_modules/.pnpm/h3@1.11.1/node_modules/h3/dist/index.mjs:1821:16)
    at async file:///project/solid-start-plugin-issue/node_modules/.pnpm/h3@1.11.1/node_modules/h3/dist/index.mjs:1962:19
    at async Object.callAsync (file:///project/solid-start-plugin-issue/node_modules/.pnpm/unctx@2.3.1/node_modules/unctx/dist/index.mjs:72:16)
    at async Server.toNodeHandle (file:///project/solid-start-plugin-issue/node_modules/.pnpm/h3@1.11.1/node_modules/h3/dist/index.mjs:2249:7)

The error is caused when a plugin returns a <noscript> tag in the transformIndexHtml() function, because the assetMap object does not have the noscript key defined.
interface HtmlTagDescriptor {
    tag: string;
    attrs?: Record<string, string | boolean | undefined>;
    children?: string | HtmlTagDescriptor[];
    /**
     * default: 'head-prepend'
     */
    injectTo?: 'head' | 'body' | 'head-prepend' | 'body-prepend';
}

Example:
{
      tag: "noscript",
      injectTo: "body-prepend",
      children: `<iframe src="${property.nsBase}?id=${property.id}${environmentAttachment}" height="0" width="0" style="display:none;visibility:hidden"></iframe>`
    }

On top of that, Solid Start doesn't respect the injectTo parameter and injects every tag into the header tag.
Your environment 🌎
No response

Yeah.. I can add noscript to the asset list but I admit I don't know what downstream consequences that might have. Mostly that depending where it ends up it might try to client render it. Honestly I didn't know these were being fed through Solid's rendering and not just applied to the output HTML. But I guess it makes sense given that we generate this template each run at runtime. Which maybe explains why injectTo doesn't work, because if we just end up with a list of assets we gave the developer the ability to place them in the JSX and use that placement to insert them. It is interesting choice, maybe @nksaraf knows more about that.


New version: GR v0.65.1

Registering package: GR
Repository: https://github.com/jheinen/GR.jl
Created by: @jheinen
Version: v0.65.1
Commit: a51ceb695492423d32056d028d9e8e09788bf8fa
Reviewed by: @jheinen
Reference: https://github.com/jheinen/GR.jl/commit/a51ceb695492423d32056d028d9e8e09788bf8fa#commitcomment-78046328
Description: Plotting for Julia based on GR, a framework for visualisation applications

There was a BinaryBuilder problem with release 0.65.0, so I had to tag a new version (0.65.1).
Please merge manually.


Related to - No ability to load dataset from a non pickled files - noMnist

Hi Sayna,
I am able now to load the data and transform into numpy array ,
however the torch.dataset is returning 0 on first task Dataset  1 (Mydataset-0-[0, 1])
Training set size:      0  images of 244x244
Validation set size:    0  images of 244x244
Test set size:          0  images of 244x244
task classes [[0, 12], [1, 12]]
Traceback (most recent call last):
File "main.py", line 19, in
tstart=time.time()
File "main.py", line 172, in main
acc, bwt = run(args, n)
File "main.py", line 116, in run
appr.train(t,dataset[t])
File "/media/Adversarial-Continual-Learning/src/acl.py", line 124, in train
train_res=self.eval_(dataset['train'], task_id)
File "/media/Adversarial-Continual-Learning/src/acl.py", line 345, in eval_
res['loss_t'], res['acc_t']=loss_t.item() / (batch + 1), 100 * correct_t / num
AttributeError: 'int' object has no attribute 'item'

valid_loader = torch.utils.data.DataLoader(valid_split, batch_size=int(self.batch_size * self.pc_valid),
shuffle=False,
num_workers=self.num_workers, pin_memory=self.pin_memory,
drop_last=True)
        test_loader = torch.utils.data.DataLoader(self.test_set[task_id], batch_size=self.batch_size,
                                                  num_workers=self.num_workers,
                                                  pin_memory=self.pin_memory, drop_last=True,shuffle=False)

        print("task_ids", self.task_ids)
        print(len(train_loader.dataset))
        self.dataloaders[task_id]['train'] = train_loader
        self.dataloaders[task_id]['valid'] = valid_loader
        self.dataloaders[task_id]['test'] = test_loader
        self.dataloaders[task_id]['name'] = 'Mydataset-{}-{}'.format(task_id, self.task_ids[task_id])

        print("Training set size:      {}  images of {}x{}".format(len(train_loader.dataset), self.inputsize[1], self.inputsize[1]))
        print("Validation set size:    {}  images of {}x{}".format(len(valid_loader.dataset), self.inputsize[1], self.inputsize[1]))
        print("Test set size:          {}  images of {}x{}".format(len(test_loader.dataset), self.inputsize[1], self.inputsize[1]))
        print("train_loader before returning dataloaders", train_loader)
        return self.dataloaders

1- I put Shuffle for falset and Drop last to true can i do that ? or both should be True or both Flase?
2- I am pretty sure its not returning any dataloaders which might be creating the error above

Now i am able to pass the tensors and the labels to the dataloader:
Training set size:      45  images of 224x224
Validation set size:    7  images of 224x224
Test set size:          52  images of 224x224
I will update the number of samples and batches (play with the hyperparamerts later on not an issue), my main concern is this error
src/acl.py", line 206, in train_epoch
y=target.to(device=self.device, dtype=torch.long)

AttributeError: 'tuple' object has no attribute 'to'

I tracked the error, target is not getting the numeric index of the mapped labels thats why this error occuring:
def getitem(self, index):
img, target, tt, td = self.data[index], self.targets[index], self.tt[index], self.td[index]
    img = Image.fromarray(img).convert('RGB')
    img = self.transform(img)
    print("targets[index]", self.targets[index])
    return img, target, tt, td

Output:
targets[index] Cat

I tracked the error, target is not getting the numeric index of the mapped labels thats why this error occuring:
def getitem(self, index):
img, target, tt, td = self.data[index], self.targets[index], self.tt[index], self.td[index]
    img = Image.fromarray(img).convert('RGB')
    img = self.transform(img)
    print("targets[index]", self.targets[index])
    return img, target, tt, td

Output:
targets[index] Cat

I am able now to get the data and load the labels as expected: however I am facing two errors:
1-
RuntimeError: size mismatch, m1: [8 x 46208], m2: [1152 x 128] at /pytorch/aten/src/TH/generic/THTensorMath.cpp:41
app.train(t,dataset[t])
I am using the acl alexnet
I added the below code under the the second maxpool solved the above error but also lead to another issue:
h = self.maxpool(self.drop1(self.relu(self.conv2(h))))
added
   h = h.view(x_s.size(0), -1

2-
RuntimeError: Expected 4-dimensional input for 4-dimensional weight [256, 128, 2, 2], but got 2-dimensional input of size [8, 184832] instead

I am able now to get the data and load the labels as expected: however I am facing two errors:
1-
RuntimeError: size mismatch, m1: [8 x 46208], m2: [1152 x 128] at /pytorch/aten/src/TH/generic/THTensorMath.cpp:41
app.train(t,dataset[t])
I am using the acl alexnet
I added the below code under the the second maxpool solved the above error but also lead to another issue:
h = self.maxpool(self.drop1(self.relu(self.conv2(h))))
added
   h = h.view(x_s.size(0), -1

2-
RuntimeError: Expected 4-dimensional input for 4-dimensional weight [256, 128, 2, 2], but got 2-dimensional input of size [8, 184832] instead

Hi Sayna,
in get_item() I am able to send my data and labels into the tensor,
targets[index] 8
tensor([[[-1.3987, -1.3987, -2.1179,  ...,  0.8961, -1.3815,  0.0741],
[ 1.3070,  0.6392,  0.4679,  ..., -0.3541, -0.7308, -0.0629],
[-0.6452, -0.6281,  0.9474,  ...,  0.1939,  0.6392, -1.2103],
...,
[-1.3302, -2.1179, -0.3883,  ..., -2.1179, -0.5253, -2.1179],
[-1.3302, -2.1179, -0.3883,  ..., -2.1179, -0.6452, -2.1179],
[-1.3302, -2.1179, -0.3883,  ..., -2.1179, -1.3130, -2.1179]],
    [[-0.1450, -1.5280, -1.9132,  ..., -0.2675,  0.7479,  0.2577],
     [ 0.5903,  0.8004, -0.9503,  ..., -0.0224, -0.3025, -1.2304],
     [ 0.8880,  1.0105, -1.2129,  ..., -0.6352,  1.1155, -0.9153],
     ...,
     [-2.0357,  0.0651, -2.0357,  ..., -0.4776, -2.0357, -0.4426],
     [-2.0357,  0.0651, -2.0357,  ..., -0.8627, -2.0357, -0.5476],
     [-2.0357,  0.0651, -2.0357,  ..., -1.2479, -2.0357, -1.0728]],

    [[-0.6367,  0.0779, -1.4384,  ...,  0.2696, -0.6541, -1.5081],
     [-0.7587,  1.2631, -0.1835,  ...,  0.1302,  0.3393, -1.3513],
     [ 1.2108,  1.0539, -0.7936,  ..., -1.1073,  1.5594, -0.3055],
     ...,
     [-0.0441, -1.8044, -1.8044,  ..., -1.8044, -0.6193, -1.8044],
     [-0.0441, -1.8044, -1.8044,  ..., -1.8044, -0.7238, -1.8044],
     [-0.0441, -1.8044, -1.8044,  ..., -1.8044, -1.1944, -1.8044]]])

however still getting this error,
RuntimeError: Expected 4-dimensional input for 4-dimensional weight [256, 128, 2, 2], but got 2-dimensional input of size [8, 184832] instead
My image size is 224*224 and the channel is 3 , i am using acl-alexnet should I do some adjustment to alexnet ?

Hi Sayna,
in get_item() I am able to send my data and labels into the tensor,
targets[index] 8
tensor([[[-1.3987, -1.3987, -2.1179,  ...,  0.8961, -1.3815,  0.0741],
[ 1.3070,  0.6392,  0.4679,  ..., -0.3541, -0.7308, -0.0629],
[-0.6452, -0.6281,  0.9474,  ...,  0.1939,  0.6392, -1.2103],
...,
[-1.3302, -2.1179, -0.3883,  ..., -2.1179, -0.5253, -2.1179],
[-1.3302, -2.1179, -0.3883,  ..., -2.1179, -0.6452, -2.1179],
[-1.3302, -2.1179, -0.3883,  ..., -2.1179, -1.3130, -2.1179]],
    [[-0.1450, -1.5280, -1.9132,  ..., -0.2675,  0.7479,  0.2577],
     [ 0.5903,  0.8004, -0.9503,  ..., -0.0224, -0.3025, -1.2304],
     [ 0.8880,  1.0105, -1.2129,  ..., -0.6352,  1.1155, -0.9153],
     ...,
     [-2.0357,  0.0651, -2.0357,  ..., -0.4776, -2.0357, -0.4426],
     [-2.0357,  0.0651, -2.0357,  ..., -0.8627, -2.0357, -0.5476],
     [-2.0357,  0.0651, -2.0357,  ..., -1.2479, -2.0357, -1.0728]],

    [[-0.6367,  0.0779, -1.4384,  ...,  0.2696, -0.6541, -1.5081],
     [-0.7587,  1.2631, -0.1835,  ...,  0.1302,  0.3393, -1.3513],
     [ 1.2108,  1.0539, -0.7936,  ..., -1.1073,  1.5594, -0.3055],
     ...,
     [-0.0441, -1.8044, -1.8044,  ..., -1.8044, -0.6193, -1.8044],
     [-0.0441, -1.8044, -1.8044,  ..., -1.8044, -0.7238, -1.8044],
     [-0.0441, -1.8044, -1.8044,  ..., -1.8044, -1.1944, -1.8044]]])

however still getting this error,
RuntimeError: Expected 4-dimensional input for 4-dimensional weight [256, 128, 2, 2], but got 2-dimensional input of size [8, 184832] instead
My image size is 224*224 and the channel is 3 , i am using acl-alexnet should I do some adjustment to alexnet ?


using RJDBC in R fails because of unimplemented ResultSet class in org.neo4j.jdbc

I am trying to connect to Neo4j from R (I am aware of RNeo4j library though)
I get the following exception:
Method setFetchSize in class org.neo4j.jdbc.ResultSet is not yet implemented.
I manage to get a result object in  but I cannot iterate through it.
My connection string is the following: jdbc:neo4j:bolt://localhost?noSsl,debug=true,flatten=[-1,100,1000])

Hi @slavakx, we're working on the issue. Method setFetchSize is indeed not yet implemented and we need to decide how to implement it.
In the meantime Please pay attention to the flatten param: you should provide a value. That list was just meant to give an example of possible values. Please have a look at this: https://github.com/neo4j-contrib/neo4j-jdbc#flattening
Connection URL could be something like this:
jdbc:neo4j:bolt://localhost?noSsl,debug=true,flatten=100

Hi @slavakx, could you please retry with this snapshot version? https://github.com/neo4j-contrib/neo4j-jdbc/releases/download/3.0.1-SNAPSHOT/neo4j-jdbc-driver-3.0.1-SNAPSHOT.jar
I just added a basic implementation for the missing method.
Let me know if it solves the issue.

Hi @inserpio
The snapshot works fine!
Just out of curiosity - how was it working in the 3rd party tool like SQL Workbench/J with the unimplemented ResultSet ?
Best

Cool! I'm closing this issue then..
We currently haven't implemented the entire JDBC interface mainly for two reasons:

we rather wanted to fail than causing unexpected behaviour (cit. @jexp)
we favoured to go live with a minimal marketable set of features

As soon as we understand that some methods are required by some tools we start implementing it.
Thanks for helping us.


Backport some of s3 repository tests.

Summary of the changes / Why this improves CrateDB
Backport of some tests for s3 blob store, blob store container, and repository.
We have only tests for the repository client settings, it would be nice to have some
additional test before cleaning up some obsolete code in s3 repository impl.
Checklist

[ ] User relevant changes are recorded in CHANGES.txt
[ ] Touched code is covered by tests
[ ] Documentation has been updated if necessary
[ ] CLA is signed
[ ] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

retest this please


Rename @EnableModule to @EnableBinding

Once this is applied, https://github.com/spring-cloud/spring-cloud-stream-modules/pull/30 must be applied as well.

At this context does it make sense to rename the ModuleChannels annotation to BindingChannels?

Possibly. Why not just @Binding or @Bindings though?

+1 for @Bindings

if that same annotation would eventually apply to other bindable components (e.g. Observable), then +1 for @Bindings

I think it should ... @Bindings is better than @ModuleChannels anyway.

rebased, squashed and merged as https://github.com/spring-cloud/spring-cloud-stream/commit/86e457fac41061e75e876779b97e7380c7e5bd88


Shields????

when I try to use a shield the animation is broken and bugged. Fix. This. Mod.

I second this comment, the shield does not work.


src/nix/manual.nix: Nix expression to build the manual

Add a Nix expression to build the Snabb manual.
You can run it like this:
nix-build src/nix/manual.nix

and it will build the manual in ./result.
The main differences compared with simply writing make book are:

Nix installs all of the build dependencies (pandoc, latex, ditaa, fonts, etc).
Automatically publishes the manual when built via the Hydra CI (example).

Depends on #830 to actually build successfully.
cc @domenkozar could you ack whether this looks like a reasonable starting point for in-tree nix expressions?

One nitpick. I'd also rather place the expression into src/doc/default, then it can be just invoked in that directory with nix-build.

I will merge this as soon as @domenkozar acks this.
By the way, I have a nix expression for SnabbBot lying around, should I PR that as well?

@domenkozar thanks for feedback, incorporated with latest commits.

By the way, I have a nix expression for SnabbBot lying around, should I PR that as well?

@eugeneia Yes!
I think we need a subsystem maintainer for reviewing and merging nix expressions. @domenkozar are you up for that? There is a hot-off-the-press description of the process for becoming a subsystem maintainer in #835 so you could also test that and give feedback :).

@lukego sure! I'd give #835 a go.

I did the patchShebangs wrong the first time. See 6a2d652 for the fix.
Generally I have a slightly tricky hacking situation with many documentation-related topic branches that are somewhat interdependent and hard to test in isolation. I am integrating them on pdf-manual and plan to send that upstream during this release cycle. So note to upstream maintainers: if there are some bugs in my latest documentation-related scripts then it is not the end of the world for those to slip upstream because we can fix/integrate them properly on next.
The main reason I am opening separate PRs is to get feedback and understand how easy/hard it will be to upstream these changes when they are all ready. I am also happy to use pdf-manual as the upstream branch for these changes provided that @eugeneia and others are happy with the general direction of these changes and will accept them upstream when ready.

Done: https://github.com/SnabbCo/snabbswitch/pull/836

@lukego What's the status of this PR and its associated changes now?

This can be closed as it's included in https://github.com/snabbco/snabb/pull/876


Resolves #228 - Custom Swagger API Reader support

Hi, the build is failing for some reason on openJDK with VM exception. Cannot reproduce on my local machine with the same JDK. Oracle JDK 6/7 is OK. I don't see any breaking changes apart from just instantiating another custom class and passing it over to Swagger
Thanks!

Tried to build my fork with Travis. Same pushed commit was also applied to this pull request.
Passes in my fork repo that is a copy of master + 2 changelists on top of that:
https://travis-ci.org/IgorGursky/swagger-maven-plugin/builds/97171914
Thanks!

Seems to be a global Travis issue:
https://github.com/travis-ci/travis-ci/issues/5227


[Issue]: vram_usage returned by rsmi_compute_process_info_get is 0

Problem Description
Hi! It looks like the vram_usage returned by rsmi_compute_process_info_get is always 0. Snippet to reproduce:
import pyrsmi as R
R.smi_initialize()
from ctypes import *
num_procs = c_uint32()
ret = R.rocm_lib.rsmi_compute_process_info_get(None, byref(num_procs))
buff_sz = num_procs.value + 10
proc_info = (R.rsmi_process_info_t * buff_sz)()
ret2 = R.rocm_lib.rsmi_compute_process_info_get(byref(proc_info), byref(num_procs))
print([(proc_info[i].vram_usage, proc_info[i].process_id, proc_info[i].pasid, proc_info[i].sdma_usage, proc_info[i].cu_occupancy) for i in range(num_procs.value)] if R.rsmi_ret_ok(ret2) else [])

Querying the VRAM of the processes one by one seems to work tho:
 num_procs = c_uint32()
ret = R.rocm_lib.rsmi_compute_process_info_get(None, byref(num_procs))
if R.rsmi_ret_ok(ret):
    buff_sz = num_procs.value + 10
    proc_info = (R.rsmi_process_info_t * buff_sz)()
    ret = R.rocm_lib.rsmi_compute_process_info_get(byref(proc_info), byref(num_procs))
    proc_info_list = (
        [proc_info[i] for i in range(num_procs.value)]
        if R.rsmi_ret_ok(ret)
        else []
    )
    result_proc_info_list = []
    # query VRAM usage explicitly, as rsmi_compute_process_info_get
    # doesn't actually return VRAM usage
    for proc_info in proc_info_list:
        vram_query_proc_info = R.rsmi_process_info_t()
        ret = R.rocm_lib.rsmi_compute_process_info_by_pid_get(
            int(proc_info.process_id), byref(vram_query_proc_info)
        )
        if R.rsmi_ret_ok(ret):
            proc_info.vram_usage = vram_query_proc_info.vram_usage
            result_proc_info_list.append(proc_info)
    return result_proc_info_list
return []

Note that I am running this inside a Docker container on aac.amd.
The driver info is:
======================= ROCm System Management Interface =======================
========================= Version of System Component ==========================
Driver version: 6.2.4

Operating System
Ubuntu 20.04.6 LTS (Focal Fossa)
CPU
AMD EPYC 7643 48-Core Processor
GPU
AMD Instinct MI250X
ROCm Version
ROCm 6.0.0
ROCm Component
No response
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
\ROCk module is loaded
HSA System Attributes
Runtime Version:         1.1
System Timestamp Freq.:  1000.000000MHz
Sig. Max Wait Duration:<PHONE_NUMBER>3709551615 (0xFFFFFFFFFFFFFFFF) (timestamp count)
Machine Model:           LARGE
System Endianness:       LITTLE
==========
HSA Agents

Agent 1

Name:                    AMD EPYC 7643 48-Core Processor
Uuid:                    CPU-XX
Marketing Name:          AMD EPYC 7643 48-Core Processor
Vendor Name:             CPU
Feature:                 None specified
Profile:                 FULL_PROFILE
Float Round Mode:        NEAR
Max Queue Number:        0(0x0)
Queue Min Size:          0(0x0)
Queue Max Size:          0(0x0)
Queue Type:              MULTI
Node:                    0
Device Type:             CPU
Cache Info:
L1:                      32768(0x8000) KB
Chip ID:                 0(0x0)
ASIC Revision:           0(0x0)
Cacheline Size:          64(0x40)
Max Clock Freq. (MHz):   2300
BDFID:                   0
Internal Node ID:        0
Compute Unit:            48
SIMDs per CU:            0
Shader Engines:          0
Shader Arrs. per Eng.:   0
WatchPts on Addr. Ranges:1
Features:                None
Pool Info:
Pool 1
Segment:                 GLOBAL; FLAGS: FINE GRAINED
Size:<PHONE_NUMBER>(0x3e3f942c) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       TRUE
Pool 2
Segment:                 GLOBAL; FLAGS: KERNARG, FINE GRAINED
Size:<PHONE_NUMBER>(0x3e3f942c) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       TRUE
Pool 3
Segment:                 GLOBAL; FLAGS: COARSE GRAINED
Size:<PHONE_NUMBER>(0x3e3f942c) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       TRUE
ISA Info:

Agent 2

Name:                    AMD EPYC 7643 48-Core Processor
Uuid:                    CPU-XX
Marketing Name:          AMD EPYC 7643 48-Core Processor
Vendor Name:             CPU
Feature:                 None specified
Profile:                 FULL_PROFILE
Float Round Mode:        NEAR
Max Queue Number:        0(0x0)
Queue Min Size:          0(0x0)
Queue Max Size:          0(0x0)
Queue Type:              MULTI
Node:                    1
Device Type:             CPU
Cache Info:
L1:                      32768(0x8000) KB
Chip ID:                 0(0x0)
ASIC Revision:           0(0x0)
Cacheline Size:          64(0x40)
Max Clock Freq. (MHz):   2300
BDFID:                   0
Internal Node ID:        1
Compute Unit:            48
SIMDs per CU:            0
Shader Engines:          0
Shader Arrs. per Eng.:   0
WatchPts on Addr. Ranges:1
Features:                None
Pool Info:
Pool 1
Segment:                 GLOBAL; FLAGS: FINE GRAINED
Size:<PHONE_NUMBER>(0x3eff1d20) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       TRUE
Pool 2
Segment:                 GLOBAL; FLAGS: KERNARG, FINE GRAINED
Size:<PHONE_NUMBER>(0x3eff1d20) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       TRUE
Pool 3
Segment:                 GLOBAL; FLAGS: COARSE GRAINED
Size:<PHONE_NUMBER>(0x3eff1d20) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       TRUE
ISA Info:

Agent 3

Name:                    gfx90a
Uuid:                    GPU-1f9de0957d137942
Marketing Name:          AMD Instinct MI250X/MI250
Vendor Name:             AMD
Feature:                 KERNEL_DISPATCH
Profile:                 BASE_PROFILE
Float Round Mode:        NEAR
Max Queue Number:        128(0x80)
Queue Min Size:          64(0x40)
Queue Max Size:          131072(0x20000)
Queue Type:              MULTI
Node:                    2
Device Type:             GPU
Cache Info:
L1:                      16(0x10) KB
L2:                      8192(0x2000) KB
Chip ID:                 29708(0x740c)
ASIC Revision:           1(0x1)
Cacheline Size:          64(0x40)
Max Clock Freq. (MHz):   1700
BDFID:                   10496
Internal Node ID:        2
Compute Unit:            104
SIMDs per CU:            4
Shader Engines:          8
Shader Arrs. per Eng.:   1
WatchPts on Addr. Ranges:4
Features:                KERNEL_DISPATCH
Fast F16 Operation:      TRUE
Wavefront Size:          64(0x40)
Workgroup Max Size:      1024(0x400)
Workgroup Max Size per Dimension:
x                        1024(0x400)
y                        1024(0x400)
z                        1024(0x400)
Max Waves Per CU:        32(0x20)
Max Work-item Per CU:    2048(0x800)
Grid Max Size:<PHONE_NUMBER>(0xffffffff)
Grid Max Size per Dimension:
x<PHONE_NUMBER>(0xffffffff)
y<PHONE_NUMBER>(0xffffffff)
z<PHONE_NUMBER>(0xffffffff)
Max fbarriers/Workgrp:   32
Pool Info:
Pool 1
Segment:                 GLOBAL; FLAGS: COARSE GRAINED
Size:                    67092480(0x3ffc000) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       FALSE
Pool 2
Segment:                 GLOBAL; FLAGS: FINE GRAINED
Size:                    67092480(0x3ffc000) KB
Allocatable:             TRUE
Alloc Granule:           4KB
Alloc Alignment:         4KB
Accessible by all:       FALSE
Pool 3
Segment:                 GROUP
Size:                    64(0x40) KB
Allocatable:             FALSE
Alloc Granule:           0KB
Alloc Alignment:         0KB
Accessible by all:       FALSE
ISA Info:
ISA 1
Name:                    amdgcn-amd-amdhsa--gfx90a:sramecc+:xnack-
Machine Models:          HSA_MACHINE_MODEL_LARGE
Profiles:                HSA_PROFILE_BASE
Default Rounding Mode:   NEAR
Default Rounding Mode:   NEAR
Fast f16:                TRUE
Workgroup Max Size:      1024(0x400)
Workgroup Max Size per Dimension:
x                        1024(0x400)
y                        1024(0x400)
z                        1024(0x400)
Grid Max Size:<PHONE_NUMBER>(0xffffffff)
Grid Max Size per Dimension:
x<PHONE_NUMBER>(0xffffffff)
y<PHONE_NUMBER>(0xffffffff)
z<PHONE_NUMBER>(0xffffffff)
FBarrier Max Size:       32
*** Done ***
Additional Information
No response

@eugen-ajechiloae-clearml Apologies for the lack of response. Can you please check if your issue still exists with the latest ROCm 6.2? If not, please close the ticket. Thanks!

Hi @ppanchad-amd ! It looks like the issue still exists

@eugen-ajechiloae-clearml Internal ticket is created to fix this issue. Thanks!

After speaking with the internal team, rsmi_compute_process_info_get() is intended to only retrieve process id and pasid as a first step before calling rsmi_compute_process_info_by_pid_get() for the full information, just as you have done in the working code. We're working on a documentation update that will make this clear. Thanks for bringing this to our attention!

Documentation has been updated to reflect this at https://rocm.docs.amd.com/projects/rocm_smi_lib/en/latest/doxygen/html/group__SysInfo.html. Thanks again for pointing this out!


ios input stack on disable/enable input

Version

Phaser Version: 3.55.2
Operating system: iOS

Description
Pointer is always down if input was disabled (and then enabled) while pointer is down.
Example Test Code
https://codepen.io/ddanushkin/pen/bGWxyVz

Test it using the latest beta 4 build<EMAIL_ADDRESS>

Test it using the latest 3.60.0 beta 4 build<EMAIL_ADDRESS>
Same, iOS 14.3, iPhone 6s
https://codepen.io/d-kozlov/pen/MWEqRON

This is such an edge case that I'm happy to leave it working like this. Toggling a boolean like that isn't going to reset the entire input system. As of 3.60 you can now call the new method InputPlugin#resetPointers which you can use to reset all the Points in a Scene. So invoke this method if you want to do this enable/disable toggle.


Context menu tree does not show all options in v2.3.13 Mac

Attaching ref images below -
On 2.3.12 -

On 2.3.13 -

Basically, I can open preview window with 'option + G' combo, but not via the context menu
System - M1 MacBook Air (2020)
OS - Mac OS Monterey 12.1
VSCode - v1.62.3

Hi.  Some of these options were intentionally moved in 2.3.13.  The right-click on the title bar is really for options that apply to the entire file, such as export to GLB and validating the whole file.  As a result, these few remaining options now work on all the open glTF files across the set of open tabs, not just the active tab.
The options that apply to a particular spot in the text, such as the Data URI converters, are now on the context menu for the body of the file instead of the title.  "Preview" had to move there too, as it only works for the currently active file, not all open tabs.
Several options became available in the file explorer tree.  Things like importing from GLB files are in that context menu now, and they only reveal themselves if you right-click the appropriate file type.  These options no longer need that file to be loaded into any editor in order to work correctly.
As always, you can manually run any command from the command bar.  This is F1 on the PC, but I don't know what it is on Mac, possibly the same key.  Type gltf into that command bar and it should present the full list of commands.


Use supplied tree

Per the Ember CLI docs I should be able to reference bower_components from my import files, like so:

@import "bower_components/foundation/scss/normalize.scss";

The current version of the compass add on does not support this, because the vendor tree is not being passed to the compiler class.
This change adds support for referencing the bower_components tree by passing the source tree to the compiler, and providing the importPath option to compass to allow imports to references files in the vendor trees.

This change now also addresses issue #35 to use app.scss as input.

Thanks, I will review and merge asap.

@christophercurrie This project currently supports either .scss or .sass entry-points.  Your branch only supports .scss.  Can it support both?  I believe it should support both for maximum flexibility.

I imagine it can; should just be a matter of creating a new tree to examine the input tree and configure the compiler accordingly. I'll try and get the PR updated ASAP.

Is this ever going to be merged?

As @rmorey-ap noted, it has a deficiency of not supporting .sass entry point. I'm not in a position to fix this PR any time soon, so it'd be great if someone else could.

@christophercurrie No worries, I forked from your fork and modified it to suit my needs. Thanks!

We do not want to recompile on every file change(js, hbs and other file changes) that's why supplied tree is not passed to compass compiler. If any additional directory should be watched it should be supplied with the importPath option. README includes examples on how to do that. This will be available in 0.1.0 which I will be releasing shortly.
Another way to compile with vendor files is to use the relative path:
@import "../../bower_components/foundation/scss/normalize.scss";


error when installing shadcn

hi
anyone knows whats the error reason when I try to install shadcn using npx shadcn-ui@latest init or npx shadcn-ui init
this error:
PS D:\projects\lawyer-appointment> npx shadcn-ui init
Need to install the following packages:
shadcn-ui
Ok to proceed? (y) y
node:fs:581
return binding.open(
^
Error: package.json: ENOENT: no such file or directory, open 'D:\projects\lawyer-appointment\package.json'
at Object.openSync (node:fs:581:18)
at Object.readFileSync (node:fs:457:35)
at Object.readFileSync (C:\Users\hp\AppData\Local\npm-cache_npx\74755fd285ad77f7\node_modules\jsonfile\index.js:50:22)
at Ae (file:///C:/Users/hp/AppData/Local/npm-cache/_npx/74755fd285ad77f7/node_modules/shadcn-ui/dist/index.js:245:4075)
at zt (file:///C:/Users/hp/AppData/Local/npm-cache/_npx/74755fd285ad77f7/node_modules/shadcn-ui/dist/index.js:245:4206)
at file:///C:/Users/hp/AppData/Local/npm-cache/_npx/74755fd285ad77f7/node_modules/shadcn-ui/dist/index.js:245:4433
at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)
at async loadESM (node:internal/process/esm_loader:34:7)
at async handleMainPromise (node:internal/modules/run_main:113:12) {
errno: -4058,
code: 'ENOENT',
syscall: 'open',
path: 'D:\projects\lawyer-appointment\package.json'
}
Node.js v20.10.0

can you share the code of your package.json file?

Hi, the same issue just happened to me. Here is the package.json code:
{
  "name": "test-site",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "react": "^18",
    "react-dom": "^18",
    "next": "14.0.4"
  },
  "devDependencies": {
    "typescript": "^5",
    "@types/node": "^20",
    "@types/react": "^18",
    "@types/react-dom": "^18",
    "autoprefixer": "^10.0.1",
    "postcss": "^8",
    "tailwindcss": "^3.3.0",
    "eslint": "^8",
    "eslint-config-next": "14.0.4"
  }
}

Hey there! It seems like you're encountering an issue while trying to install shadcn-ui. The error indicates that it's unable to find the 'package.json' file in your 'D:\projects\lawyer-appointment' directory.
To resolve this:

Ensure you are running the command in the root directory of your project.
Confirm that a 'package.json' file exists in the specified directory.

If the issue persists, you might want to:

Double-check the correctness of your project structure.
Run the command in a newly created directory with a 'package.json'.

Share more details if the problem persists.

Check this one.
https://stackoverflow.com/questions/51819180/i-keep-getting-errno-4058-from-npm

I think You are in the wrong directory. you are not in the same directory where the node module or package.json is installed

can you share the code of your package.json file?

{
"name": "lawyer",
"version": "0.1.0",
"private": true,
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint"
},
"dependencies": {
"next": "13.5.6",
"react": "^18",
"react-dom": "^18"
},
"devDependencies": {
"@types/node": "^20",
"@types/react": "^18",
"@types/react-dom": "^18",
"autoprefixer": "^10",
"postcss": "^8",
"tailwindcss": "^3",
"typescript": "^5"
},
"description": "This is a Next.js project bootstrapped with create-next-app.",
"main": "next.config.js",
"keywords": [],
"author": "",
"license": "ISC"
}

now i got this error

your png file is not uploaded please reupload

did you try. rm -rf node_modules package-lock.json && npm i && npx shadcn-ui@latest init

try changing directory from the parent directory to child directory. (cd nameofyourprojectyoucreated)

I am getting the same error for new Remix project. I cleared cache (C:/Users/usernameAppData/Local/npm-cache/_npx).
I get this error on Node 20.
Steps to reproduce:
1- npx create-remix@latest my-app
2- npx shadcn-ui@latest init

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

None of these solved my problem. I had to run npm install -g pnpm in order for @latest (and without @latest) to work. It seems the scripts now require you to have pnpm installed if using npx (I haven't tested any others).

i keep having the same problem. ive followed in guided steps provided by chat gpt, claude, etc. that still not fixing the problem. what going on?

@MrEshunOfficial have you tried what I suggested?

None of these solved my problem. I had to run npm install -g pnpm in order for @latest (and without @latest) to work. It seems the scripts now require you to have pnpm installed if using npx (I haven't tested any others).

It totally worked for me! Thanks

This is what mine is showing
node:internal/modules/esm/resolve:214
const resolvedOption = FSLegacyMainResolve(packageJsonUrlString, packageConfig.main, baseStringified);
^
Error: Cannot find package 'C:\Users\HP\AppData\Local\npm-cache_npx\d66c5096c7023bfb\node_modules\wcwidth\package.json' imported from C:\Users\HP\AppData\Local\npm-cache_npx\d66c5096c7023bfb\node_modules\ora\index.js
at legacyMainResolve (node:internal/modules/esm/resolve:214:26)
at packageResolve (node:internal/modules/esm/resolve:832:14)
at moduleResolve (node:internal/modules/esm/resolve:918:18)
at defaultResolve (node:internal/modules/esm/resolve:1148:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:390:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:359:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:234:38)
at ModuleWrap. (node:internal/modules/esm/module_job:87:39)
at link (node:internal/modules/esm/module_job:86:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
Node.js v21.7.1

This is what mine is showing
node:internal/modules/esm/resolve:214
const resolvedOption = FSLegacyMainResolve(packageJsonUrlString, packageConfig.main, baseStringified);
^
Error: Cannot find package 'C:\Users\HP\AppData\Local\npm-cache_npx\d66c5096c7023bfb\node_modules\wcwidth\package.json' imported from C:\Users\HP\AppData\Local\npm-cache_npx\d66c5096c7023bfb\node_modules\ora\index.js
at legacyMainResolve (node:internal/modules/esm/resolve:214:26)
at packageResolve (node:internal/modules/esm/resolve:832:14)
at moduleResolve (node:internal/modules/esm/resolve:918:18)
at defaultResolve (node:internal/modules/esm/resolve:1148:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:390:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:359:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:234:38)
at ModuleWrap. (node:internal/modules/esm/module_job:87:39)
at link (node:internal/modules/esm/module_job:86:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
Node.js v21.7.1

I am getting similar error when trying to install ShadCN component from cli...I have tried deleting npm cache, even reinstalling node, but the error is persistent.
@shadcn can you reopen this issue

@Ronit-gurjar let's open a new thread since we have a new cli. thank you.

my pro

I am attempting to do it this way, but no luck.
How exactly did you enter the code?
Thanks!

got this error when i am trying to use select component with the typescript ? i dont know how to resolve this issue

got this error when i am trying to use select component with the typescript ? i dont know how to resolve this issue

Try this command in terminal:
npm install @radix-ui/react-select
Or go to ShadCN select docs and install manually

The same error occurred in my computer 😞, can you please solve the problem @shadcn.

@yooosef3 bro, how did you solve the issue, can you please explain it to me?

@shadcn can you solve this?

Already installed it but still  Not working , still showing me that issue

npx shadcn@latest init
'shadcn' is not recognized as an internal or external command,
operable program or batch file.


Add some examples of crate usage

Hi, thanks a ton for this project! I'm relatively new to Rust and found integrating starlark-rust into a program a bit intimidating. Would you be open to adding some examples to the documentation? They could go in the README.md, an examples directory, or the rustdoc comments themselves. I ended up reading code in the starlark-repl directory to get familiar with how to use it, but it's a bit more complicated to parse than I had hoped. The specific information I was hoping to see was how codemap and starlark::stdlib::global_environment were meant to be used with eval, and how to use a Value returned from eval.
I made some sample code for myself, but it might be a bit too long for the README.md (it's also not directly compilable being outside a function, but I think that would make it even longer):
extern crate codemap;
extern crate codemap_diagnostic;
extern crate starlark;

use std::sync::{Arc, Mutex};

use codemap_diagnostic::{ColorConfig, Emitter};
use starlark::eval::simple::eval;
use starlark::stdlib::global_environment;

let starlark_input = "str([2 * x for x in range(5)])";

let global_env = global_environment();
global_env.freeze();
let mut env = global_env.child("shell_loop");
let map = Arc::new(Mutex::new(codemap::CodeMap::new()));

let res = match eval(&map, "string input", &starlark_input, true, &mut env) {
    Err(diag) => {
        let cloned_map = Arc::clone(&map);
        let unlocked_map = cloned_map.lock().unwrap();
        Emitter::stderr(ColorConfig::Always, Some(&unlocked_map)).emit(&[diag]);
        panic!("Error interpreting code '{}'", starlark_input);
    },
    Ok(res) => match res.get_type() {
        "string" => res.to_str(),
        _ => panic!(
            "Error interpreting code '{}': result must be string! (was {})",
            starlark_input,
            res.get_type()
        )
    }
};

I've signed the CLA so feel free to use or modify it if it seems useful. Thanks again, and looking forward to hearing your response!

Hi that looks like a good example to me. Would you mind sending a PR to add this either in a rustdoc somewhere or directly in an starlark-examples crate in this repository? (I don't think I can take code from someone even who has sign the CLA, because it would remove trace of authorship).

Awesome, thanks!


feat: support geo-restricted ios app

Support geo-restricted iOS app, issue #12

@balbertho Thank you for your contribution! Good work!


Updated venv activation cmd in README

Updated the code block to activate the virtual environment in the Setup portion of the README file. The current version points to the bin folder as opposed to the Scripts folder which causes an error when trying to execute.

Hi there - what error are you seeing?  Following the commands in the README I'm seeing successful environment creation and installation of dependencies.  I'm using Python 3.10.7 on MacOS Ventura:
tmp $ git clone https://github.com/redislabs-training/ru202.git
fatal: destination path 'ru202' already exists and is not an empty directory.
tmp $ rm -rf ru202
tmp $ git clone https://github.com/redislabs-training/ru202.git
Cloning into 'ru202'...
remote: Enumerating objects: 516, done.
remote: Counting objects: 100% (346/346), done.
remote: Compressing objects: 100% (243/243), done.
remote: Total 516 (delta 145), reused 284 (delta 100), pack-reused 170
Receiving objects: 100% (516/516), 967.54 KiB | 5.09 MiB/s, done.
Resolving deltas: 100% (221/221), done.
tmp $ cd ru202
ru202 $ python3 -m venv env
ru202 $ . env/bin/activate
(env) ru202 $ pip install -r requirements.txt
Collecting Faker==4.1.1
  Using cached Faker-4.1.1-py3-none-any.whl (1.0 MB)
Collecting redis==3.5
  Using cached redis-3.5.0-py2.py3-none-any.whl (71 kB)
Collecting text-unidecode==1.3
  Using cached text_unidecode-1.3-py2.py3-none-any.whl (78 kB)
Collecting python-dateutil>=2.4
  Using cached python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
Collecting six>=1.5
  Using cached six-1.16.0-py2.py3-none-any.whl (11 kB)
Installing collected packages: text-unidecode, six, redis, python-dateutil, Faker
Successfully installed Faker-4.1.1 python-dateutil-2.8.2 redis-3.5.0 six-1.16.0 text-unidecode-1.3

[notice] A new release of pip available: 22.2.2 -> 23.0.1
[notice] To update, run: pip install --upgrade pip
(env) ru202 $ python --version
Python 3.10.7

(I think you might be on Windows and that the Scripts folder is Windows specific?)


Mint a DOI for this Cookbook

It would be great to mint a DOI for this cookbook and credit all the contributors here - let's start by gathering ORCID IDs!!

I think this was done at the 2023 cook-off... Any closing this because the DOI exists: https://zenodo.org/doi/10.5281/zenodo.8075854


Add WAPE metric

Proposal

Add function wape into etna/metrics/functional_metrics.py, see wape
Add class WAPE into etna/metrics/metrics.py
Add tests like for other metrics

Discussed in https://github.com/tinkoff-ai/etna/discussions/1063

Originally posted by prokofyev January  9, 2023
Hello, dear developers!
I am interested why don't you have WAPE metric built-in in your ETNA library? I believe it would be highly popular and used.
Many thanks!

hello, i'm want do it on weekend)

@looopka Hi! Sounds great, feel free to ask any questions)
May you also assign yourself to this issue pls

I can't assign this issue to myself :(.
last time, iKintosh signed up for me.
if it's not difficult for you, fix it for me and https://github.com/tinkoff-ai/etna/issues/846


ingest: change all ingesters to use ProcessContext() instead of Process()

What are the steps to reproduce this issue?

Ingest and get into a very bad state -- disk full + cache full
Try to exit

What happens?
If you aren't using ProcessContext(), we can't gracefully shutdown.

this is as good as its going to get, if we are waiting to push something to disk and kernel says no, or blocks, there is no good way to get out.


Dart type checking for Map key

This issue was originally filed by<EMAIL_ADDRESS>
It appears that the type checker does not check that a strongly typed Map's key is correct. Take for example:
void main()
{
    Map<String, dynamic> m = { 2 : 200.0, 'x' : 8.0 };
    print( "m: $m");
}
When type checking is on, the compiler should fail and report that the first key, 2, is not of type String.
It appears that try.dartlang.org reports this as an error, but it does not report the following as an error:
void main()
{
    Map<String, dynamic> m = new Map();
    m[2] = 4;
}
versions:
Dart Editor version 0.8.10_r30107 (STABLE)
Dart SDK version <IP_ADDRESS>_r30107

Is it normal that this code compiles successfully (no warnings/errors):
class A {}

void main() {
  final map = <String, A>{};

  if (map[A()] == null) {
    print("1");
  }
  if (map[1] == null) {
    print("2");
  }
}

I would expect to get compiler error for invalid map key type used.

The type of the key on operator [] is Object (see https://api.dart.dev/stable/2.8.4/dart-core/Map/operator_get.html ), so all values are allowed.
Note that for mutating methods, like operator []=, the key type is K so you would get an error on map[A()] = A().

Thanks for the clarification. Maybe there are some historical reasons or some use case I don't notice right now for that it was not defined as
V operator [](K key);

which would make more sense in my opinion. I feel it is confusing that if I have explicitly defined the key be of type K, then I can still use any type.

This is a classic dilemma. Using V operator [](K key) would catch more cases, like the one above, but would also flag benign cases like
class A {}
class B extends A {}
class C extends A {}
class D implements B, C {}

main() {
  Map<C, String> map = {};
  D d = new D();
  map[d] = 'foo';
  B b = d;
  String value = map[b]; // An error would be emitted since `B` is not assignable to `C` even though a `D` is a `B`.
}


Corrected map combinator example

The map combinator example performs eta-expansion on the timesTwo method (unnecessarily, Scala does it automatically in this case), however the description above says that it's partial evaluation. Maybe it'd be better to remove the part about partial evaluation and just pass timesTwo without doing the eta-expansion? Alternatively  "partially evaluated function" could be replaced with "eta-expanded method", but maybe that would make it look too complicated.

Thanks! :+1:


Sometimes, new pages are generated but they still contain the old content

I can't really pinpoint how this work, but in some ocassions, new pages are generated, but they contain the old content. This might be when a single page in language is changed, but I haven't really been able to pin it down to anything.

After some testing I have discovered that the problem is Pod::To::Cached. It does not return the updated version of the pod. You can check this with the following code:
(modify the subtitle of docs/Type/Documentable.pod6)
use lib 'lib';
use Documentable::CLI;
use Pod::To::Cached;
use Documentable::Utils::IO;

my $cache-dir = cache-path("docs");

my $pod-cache = Pod::To::Cached.new(
    source      => "docs",
    :verbose,
    path        => $cache-dir
);

$pod-cache.update-cache;

my $pod = $pod-cache.pod("type/documentable");

# the subtitle of the pod
say $pod[0].contents[1].contents[0].contents.first

Can you please raise the issue there?
El dom., 9 feb. 2020 a las 21:14, Antonio<EMAIL_ADDRESS>escribió:

After some testing I have discovered that the problem is Pod::To::Cached.
It does not return the updated version of the pod. You can check this with
the following code:
(modify the subtitle of docs/Type/Documentable.pod6)
use lib 'lib';use Documentable::CLI;use Pod::To::Cached;use Documentable::Utils::IO;
my $cache-dir = cache-path("docs");
my $pod-cache = Pod::To::Cached.new(
source      => "docs",
:verbose,
path        => $cache-dir
);
$pod-cache.update-cache;
my $pod = $pod-cache.pod("type/documentable");
the subtitle of the pod say $pod[0].contents[1].contents[0].contents.first
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Raku/Documentable/issues/73?email_source=notifications&email_token=AAAAD5A5UU2UHL7A5SEGZKDRCBP35A5CNFSM4KI3GQJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELGWZJI#issuecomment-583888037,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAD5C3CMZQIX22EVUFF3TRCBP35ANCNFSM4KI3GQJQ
.

--
JJ

Great job!


YAML block scalars are supported in clang-tidy, but don't work in coc-clangd

As of D30567 it is possible to use block scalars in .clang-tidy. While manual invocation of clang-tidy behaves correctly, for some reason coc-clangd (or clangd in general) misbehaves. Below is the repro.
coc-settings.json:
{
    "clangd.compilationDatabasePath": "build",
    "clangd.arguments": ["--log=verbose"]
}

.clang-tidy:
---
Checks: >
    *,
    -modernize-use-trailing-return-type
...

CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
set(CMAKE_EXPORT_COMPILE_COMMANDS 1)
project(test-clangd)
add_executable(main main.cc)

main.cc:
int main() {}

When clang-tidy is used manually, there are no reports (expected):
❯ cmake -S . -B build
❯ cmake --build build
❯ clang-tidy -p build main.cc

When clang-tidy is used via coc-clangd in the editor, diagnostic is emitted (not expected):

Environment:
vim version: NVIM v0.4.4
node version: v14.12.0
coc.nvim version: 0.0.79-f176d09dc9
coc.nvim directory: /home/ave/.config/nvim/plugged/coc.nvim
term: xterm-kitty
platform: linux

Log:
I[21:12:54.247] clangd version 10.0.1
I[21:12:54.247] PID: 240382
I[21:12:54.247] Working directory: /home/ave/Documents/my/coc-clangd-repro
I[21:12:54.247] argv[0]: /usr/bin/clangd
I[21:12:54.247] argv[1]: --log=verbose
I[21:12:54.247] Starting LSP over stdin/stdout
V[21:12:54.247] <<< {"id":0,"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"textDocument":{"codeAction":{"codeActionLiteralSupport":{"codeActionKind":{"valueSet":["","quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}},"dynamicRegistration":true,"isPreferredSupport":true},"codeLens":{"dynamicRegistration":true},"colorProvider":{"dynamicRegistration":true},"completion":{"completionItem":{"commitCharactersSupport":true,"deprecatedSupport":true,"documentationFormat":["markdown","plaintext"],"preselectSupport":true,"snippetSupport":true},"completionItemKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]},"contextSupport":true,"dynamicRegistration":true,"editsNearCursor":true},"declaration":{"dynamicRegistration":true},"definition":{"dynamicRegistration":true},"documentHighlight":{"dynamicRegistration":true},"documentLink":{"dynamicRegistration":true,"tooltipSupport":true},"documentSymbol":{"dynamicRegistration":true,"hierarchicalDocumentSymbolSupport":true,"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]},"tagSupport":{"valueSet":[1]}},"foldingRange":{"dynamicRegistration":true,"lineFoldingOnly":true,"rangeLimit":5000},"formatting":{"dynamicRegistration":true},"hover":{"contentFormat":["markdown","plaintext"],"dynamicRegistration":true},"implementation":{"dynamicRegistration":true},"onTypeFormatting":{"dynamicRegistration":true},"publishDiagnostics":{"relatedInformation":true,"tagSupport":{"valueSet":[1,2]},"versionSupport":false},"rangeFormatting":{"dynamicRegistration":true},"references":{"dynamicRegistration":true},"rename":{"dynamicRegistration":true,"prepareSupport":true},"selectionRange":{"dynamicRegistration":true},"signatureHelp":{"dynamicRegistration":true,"signatureInformation":{"documentationFormat":["markdown","plaintext"],"parameterInformation":{"labelOffsetSupport":true}}},"synchronization":{"didSave":true,"dynamicRegistration":true,"willSave":true,"willSaveWaitUntil":true},"typeDefinition":{"dynamicRegistration":true}},"window":{"workDoneProgress":true},"workspace":{"applyEdit":true,"configuration":true,"didChangeConfiguration":{"dynamicRegistration":true},"didChangeWatchedFiles":{"dynamicRegistration":true},"executeCommand":{"dynamicRegistration":true},"symbol":{"dynamicRegistration":true,"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]},"tagSupport":{"valueSet":[1]}},"workspaceEdit":{"documentChanges":true,"failureHandling":"textOnlyTransactional","resourceOperations":["create","rename","delete"]},"workspaceFolders":true}},"clientInfo":{"name":"coc.nvim","version":"0.0.79"},"initializationOptions":{"clangdFileStatus":true,"compilationDatabasePath":"build","fallbackFlags":[]},"processId":240368,"rootPath":"/home/ave/Documents/my/coc-clangd-repro","rootUri":"file:///home/ave/Documents/my/coc-clangd-repro","trace":"off","workspaceFolders":[{"name":"coc-clangd-repro","uri":"file:///home/ave/Documents/my/coc-clangd-repro"}]}}

I[21:12:54.247] <-- initialize(0)
I[21:12:54.247] --> reply:initialize(0) 0 ms
V[21:12:54.247] >>> {"id":0,"jsonrpc":"2.0","result":{"capabilities":{"codeActionProvider":{"codeActionKinds":["quickfix","refactor","info"]},"completionProvider":{"resolveProvider":false,"triggerCharacters":[".",">",":"]},"declarationProvider":true,"definitionProvider":true,"documentFormattingProvider":true,"documentHighlightProvider":true,"documentLinkProvider":{"resolveProvider":false},"documentOnTypeFormattingProvider":{"firstTriggerCharacter":"\n","moreTriggerCharacter":[]},"documentRangeFormattingProvider":true,"documentSymbolProvider":true,"executeCommandProvider":{"commands":["clangd.applyFix","clangd.applyTweak"]},"hoverProvider":true,"referencesProvider":true,"renameProvider":{"prepareProvider":true},"selectionRangeProvider":true,"signatureHelpProvider":{"triggerCharacters":["(",","]},"textDocumentSync":2,"typeHierarchyProvider":true,"workspaceSymbolProvider":true}}}

V[21:12:54.249] <<< {"jsonrpc":"2.0","method":"initialized","params":{}}

I[21:12:54.249] <-- initialized
I[21:12:54.249] unhandled notification initialized
V[21:12:54.250] <<< {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"int main() {}\n","uri":"file:///home/ave/Documents/my/coc-clangd-repro/main.cc","version":1}}}

I[21:12:54.250] <-- textDocument/didOpen
I[21:12:54.250] Enqueueing 1 commands for indexing
I[21:12:54.250] --> textDocument/clangd.fileStatus
V[21:12:54.250] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"parsing includes","uri":"file:///home/ave/Documents/my/coc-clangd-repro/main.cc"}}

I[21:12:54.250] Updating file /home/ave/Documents/my/coc-clangd-repro/main.cc with command
[/home/ave/Documents/my/coc-clangd-repro/build]
/usr/bin/c++ --driver-mode=g++ -o CMakeFiles/main.dir/main.cc.o -c /home/ave/Documents/my/coc-clangd-repro/main.cc -fsyntax-only -resource-dir=/usr/lib/clang/10.0.1
V[21:12:54.250] BackgroundIndex: building version 1 after loading index from disk
V[21:12:54.250] BackgroundIndex: serving version 1 (10300 bytes)
V[21:12:54.251] Driver produced command: cc1 -cc1 -triple x86_64-pc-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -discard-value-names -main-file-name main.cc -mrelocation-model pic -pic-level 2 -pic-is-pie -mthread-model posix -mframe-pointer=all -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir /usr/lib/clang/10.0.1 -internal-isystem /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0 -internal-isystem /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu -internal-isystem /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/clang/10.0.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/ave/Documents/my/coc-clangd-repro/build -ferror-limit 19 -fmessage-length 0 -stack-protector 2 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -faddrsig -x c++ /home/ave/Documents/my/coc-clangd-repro/main.cc
V[21:12:54.251] Building first preamble for /home/ave/Documents/my/coc-clangd-repro/main.cc
V[21:12:54.257] index AST for /home/ave/Documents/my/coc-clangd-repro/main.cc (main=false):
  symbol slab: 0 symbols, 128 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 0 relations, 24 bytes
V[21:12:54.257] Built preamble of size 202844 for file /home/ave/Documents/my/coc-clangd-repro/main.cc
V[21:12:54.261] index AST for /home/ave/Documents/my/coc-clangd-repro/main.cc (main=true):
  symbol slab: 1 symbols, 4456 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 0 relations, 24 bytes
I[21:12:54.261] --> textDocument/publishDiagnostics
V[21:12:54.261] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"code":"modernize-use-trailing-return-type","message":"Use a trailing return type for this function (fix available)","range":{"end":{"character":8,"line":0},"start":{"character":4,"line":0}},"relatedInformation":[],"severity":2,"source":"clang-tidy"}],"uri":"file:///home/ave/Documents/my/coc-clangd-repro/main.cc"}}

I[21:12:54.261] --> textDocument/clangd.fileStatus
V[21:12:54.261] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///home/ave/Documents/my/coc-clangd-repro/main.cc"}}

Interesting, I got clangd and clang-tidy to dump the effective options used for processing main.cc
This was the diff
➜ diff clangd.log clang-tidy.log
2c2
< Checks:          "*,\n-modernize-use-trailing-return-type\n,-llvm-header-guard,-bugprone-use-after-move"
---
> Checks:          "clang-diagnostic-*,clang-analyzer-*,*,\n-modernize-use-trailing-return-type\n"

The only thing that appears to be cause for this discrepancy is that the use-trailing-return-type flag is at the end of the list. However a more pressing issue is that block scalars aren't supported in either, the > mark should not emit new lines unless there are 2 following each other.

It's clangd's issue, coc-clangd just displays what clangd returns.