Nvidia H100 - Fine tune Dolly Failure - "Loss" and "learning rate" are start at 0 and remain 0 continually

I have successfully trained the model on my fine-tune data set on an A6000 GPU. However, I tried an H100 and I am getting weird results:
Command: deepspeed --num_gpus=1 --module training.trainer --deepspeed config/a100_config.json --local-output-dir testOutputDir --per-device-train-batch-size 2 --input-model databricks/dolly-v2-3b --logging-steps 10 --save-steps 200 --save-total-limit 20 --eval-steps 50 --warmup-steps 50 --test-size 10 --lr 5e-6 --epochs 2 --training-dataset data/testData.json --bf16 true
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 0.24}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 0.49}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 0.73}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 0.98}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 1.22}
{'eval_loss': 9.275385111957112e-39, 'eval_runtime': 1.5501, 'eval_samples_per_second': 6.451, 'eval_steps_per_second': 1.29, 'epoch': 1.22}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 1.46}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 1.71}
tried to get lr value before scheduler/optimizer started stepping, returning lr=0
{'loss': 0.0, 'learning_rate': 0, 'epoch': 1.95}
{'train_runtime': 135.9952, 'train_samples_per_second': 1.206, 'train_steps_per_second': 0.603, 'train_loss': 0.0, 'epoch': 2.0}```

As I mentioned, the training works great on A6000 ( using the V100 config ).

Weird, never seen that one. Did you modify the code or config at all?


Issue with case-sensitive database names and API's

C:\Users\sorin.pop>curl -H<EMAIL_ADDRESS>cloud-db.liferay.int/api/databases/mysql-57/kadas2
{"success":false,"error":["ERR_DATABASE_NO_RESULT"]}
C:\Users\sorin.pop>curl -H<EMAIL_ADDRESS>cloud-db.liferay.int/api/databases/mysql-57/KADAS2
{"success":false,"error":["ERR_ACCESS_DENIED"]}

The same API call returns  different results for lower and upper case database name. (this confuses somewhat LiferayUP, that's how we noticed this)
Suppose we call the API above with "kadas2" (lower case): it tells us that such a database doesn't exist.  But that fails with:
response:{"success":false,"error":["ERR_DATABASE_CREATE_FAILED","sending json message failed: got non-200 response '500' and message: {"status":305,"message":"creating database \"kadas2\" failed: database 'kadas2' already exists"}"]}

My expectation from LiferayUP point-of-view would be that also for the first API call I get ERR_ACCESS_DENIED. Well, in any case, I should not get ERR_DATABASE_NO_RESULT, because then I wrongly assume that this db doesn't exist, while it actually exists. (and the create API fails, for that reason)

I've been thinking about this, and you're right in that it should work consistently, which it does not do at the moment.
I think the obvious route is to make CloudDB case insensitive (lowercase everything) and inform everyone about this.
We wouldn't be losing anything with mysql-mariadb databases, as they are already case insensitive... but Oracle is going to be a problem, with maybe postgres also being affected - not sure.
If I only update the API part, it won't resolve the issue you're facing as I'd need to update the database as well.. Which I could do at next startup, but that would break the oracle portal-exts for sure. What do you think, how could we best handle this?

For the moment, I don't have any idea. I'm even a little bit confused in regard to this issue.

Migrated to the new location


Adopt quick pick item guidance in Remote Repositories

We now have team wide quick pick item guidance https://github.com/microsoft/vscode/issues/158895
We should adopt this guidance in Remote Repositories' pickers.
Originally reported by @jrieken

be on vscode.dev
pick a branch form the status bar picker
picker has a title and that's something we usually don't do, e.g desktop/file doesn't

is there anything extra I need in order to get the new version of vscode.dev? Currently, it seems my quick picker still has a title

Are you using insiders.vscode.dev or vscode.dev?

hm I was actually on github.dev- I should be using insider.vscode.dev?

Yes, please use insiders.vscode.dev as that ships both latest VS Code Insiders and latest RemoteHub. github.dev only ships stable RemoteHub regardless of VS Code quality, so should not be used for VS Code verification


Support casks in readall

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

[ ] Have you successfully run brew tests with your changes locally?

@MikeMcQuaid this should allow syntax checks for casks in CI

@MikeMcQuaid CI says no

@SMillerDev brew man wants run

I don't think the failure has anything to do with my code?

Cannot tap homebrew/cask: invalid syntax in tap!

That's definitely related, I'm afraid.

I can't reproduce this locally.

@SMillerDev on Linux? That's where it's failing. It seems unsurprising that reading taps would fail there 😄

grabs more coffee
I guess I need to return casks as successful on Linux then?

I can't manage to figure this out, closing.

@SMillerDev I'll get this finished off for you.

🥳


Extend ReadCubit to Add Support For First/Second Order Pyramid and Wedge Elements and Mixed Meshes

Brief

Added support for Pyramid5, Pyramid14 element types.
Added support for Wedge6, Wedge18 element types.
Tidied code by adding CubitElement class to store required information about block elements.
General rewrite of code to remove previous assumptions (for instance, Pyramids and Wedges have multiple face types).
Added a simple NetCDFReader class to wrap-around NetCDF API calls and handle any errors.
Added unit tests for Exodus/Genesis files (Tet4, Tet10, Hex8, Hex27, Pyramid5, Wedge6, Wedge18).
Added unit tests for first- and second-order mixed meshes.
Extended code to add support for mixed meshes (Exodus files allow a different element type to be specified for each block). This was originally intended to be a separate PR but the changes were relatively minor and some issues were encountered with side id mappings which have now been rectified by merging-in the commits from that PR.

Testing

The node IDs for each element have been compared with those from Apollo using identical test meshes.
The node IDs on each face have been compared.
The boundary nodes have also been compared.

Notes

While Pyramid14 can be read-in, it currently cannot be handled by the H1 FEC (see pyramid-dev branch which addresses this).

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#4178
@EdwardPalmer99
@tzanio
@mlstowell + @bslazarov
3/14/24
⌛due 3/28/24
⌛due 4/4/24

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

@EdwardPalmer99, can you please resolve conflicts?
@bslazarov and @mlstowell, can you please review?

@EdwardPalmer99, thanks for adding this. The code all looks good to me. Unfortunately, I'm having trouble running the unit tests for some reason. Everything builds fine and I see the new object file being linked into the unit_tests executable. However, the new test and tag names (as reported by ./unit_tests --list-tests and ./unit_tests --list-tags) do not seem to be available so I cannot verify that the new tests are being run.
I'm sure this is due to some small issue. I've checked a variety of possibilities but I haven't found the cause yet. I did recently upgrade my OS so it's possible this is a local issue. Can someone confirm that ./unit_tests "[ExodusII]", for example, produces the expected number of successful tests?

I'm sure this is due to some small issue. I've checked a variety of possibilities but I haven't found the cause yet. I did recently upgrade my OS so it's possible this is a local issue. Can someone confirm that ./unit_tests "[ExodusII]", for example, produces the expected number of successful tests?

I do not see "[ExodusII]" is the list of unit tests - otherwise I am compiling without any problems.

Hi @mlstowell and @bslazarov. The actual mesh files are stored in the mfem data repository since they are also required for the ExodusII writer. Try:
./unit_tests "[ExodusII]" --data=

Hi @EdwardPalmer99, Are these files included in the PR? I do not see any exodus files in the data directory.

@bslazarov You'll find them in the mfem/data repository in the exodusii directory.
Please see: mfem/data#7. These tests will be skipped if the directory is not present.

Merged in next for testing...


date picker mode

Hello, is it possible to put MMM DD YYYY from modal picker?

Hi! As far as I know, it's not possible. The picker is native, so it will use the OS-level date format.

@mmazzarolo Thank you)


[BSO] Add Lil'Creator to pet mystery boxes

🚀 Feature Proposal
What title said. Not seen anything about it being added, could be wrong

Fixed in next update.


Static class functions can be erroneously removed in ADVANCED mode

In a simple example with ADVANCED optimizations enabled
class Foo {
  static print() {
    console.log('f');
  }
  constructor() {
    this.constructor.print();
  }
}

let x = new Foo();

The call to the print function remains, but the implementation is missing.
new function() {
  this.constructor.print();
};

Live Example

What happens is this.

the ES6 class is transpiled into an ES5 class, so we end up withfunction Foo() {
 this.constructor.print();
}
Foo.print = function() { console.log('f'); }
var x = new Foo();

Then CollapseProperties does it's thing to rename Foo.print to Foo$print, but it doesn't realize that this.constructor.print is the same object and fails to update that.
Finally Foo$print appears to be unused, so it gets removed.

As a workaround, you can use the @nocollapse annotation to prevent collapsing the print function.
class Foo {
  /** @nocollapse */
  static print() {
    console.log('f');
  }
  constructor() {
    this.constructor.print();
  }
}

let x = new Foo();

I believe the situation may be a bit worse when the static method is on a super class. @azakus That's why #2286 exists.

This seems to happen anytime the static method is not called directly from the class.
Example:
class Foo {
   static foo() {
     console.log('foo');
   }
}

function callStaticMethod(Foo) {
  Foo.foo();
}

callStaticMethod(Foo);

(function(){}).a();

The problem doesn't occur when the language_out is ECMASCRIPT_2015 +
$ java -jar compiler.jar --js example.js -O ADVANCED --language_out ECMASCRIPT_2015

'use strict';class a{static a(){console.log("foo")}}(function(b){b.a()})(a);

I'm running into this issue as well, from a slightly different angle. Demo link.
Input:
class Foo {
  static method() {
    return true;
  }
}

const Bar = {
  Foo: Foo
}

console.log(Bar.Foo.method());

Output:
console.log(function(){}.method());

Created Google internal issue http://b/143308051


TitanIndexRepair Issue: Casting and Failure detection

I'm running into an issue with re-indexing on Titan 0.5.4. I have a property key on edges, for which I'd like to create a composite index. However, TitanIndexRepairMapper throws this exception when it appears to be nearing completion:
java.lang.Exception: java.io.IOException: com.thinkaurelius.titan.graphdb.types.vertices.PropertyKeyVertex cannot be cast to com.thinkaurelius.titan.hadoop.FaunusPropertyKey
at org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:403)
Caused by: java.io.IOException: com.thinkaurelius.titan.graphdb.types.vertices.PropertyKeyVertex cannot be cast to com.thinkaurelius.titan.hadoop.FaunusPropertyKey
at com.thinkaurelius.titan.hadoop.TitanIndexRepairMapper.map(TitanIndexRepairMapper.java:242)
at com.thinkaurelius.titan.hadoop.TitanIndexRepairMapper.map(TitanIndexRepairMapper.java:72)
at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:145)
at org.apache.hadoop.mapreduce.lib.chain.Chain.runMapper(Chain.java:389)
at org.apache.hadoop.mapreduce.lib.chain.ChainMapper.run(ChainMapper.java:149)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:763)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:339)
at org.apache.hadoop.mapred.LocalJobRunner$Job$MapTaskRunnable.run(LocalJobRunner.java:235)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassCastException: com.thinkaurelius.titan.graphdb.types.vertices.PropertyKeyVertex cannot be cast to com.thinkaurelius.titan.hadoop.FaunusPropertyKey
at com.thinkaurelius.titan.hadoop.FaunusElement.getProperty(FaunusElement.java:321)
at com.thinkaurelius.titan.graphdb.database.IndexSerializer.indexMatch(IndexSerializer.java:390)
at com.thinkaurelius.titan.graphdb.database.IndexSerializer.reindexElement(IndexSerializer.java:376)
at com.thinkaurelius.titan.hadoop.TitanIndexRepairMapper.map(TitanIndexRepairMapper.java:219)
... 12 more
I've attached a text file with a little more context around that stacktrace and to show the MapReduce job summary.
And here is a quick probe of the index in question:
rexster[groovy]> idx = mgmt.getGraphIndex('edge_type_composite')
==>com.thinkaurelius.titan.graphdb.database.management.TitanGraphIndexWrapper@6ea7748e
rexster[groovy]> idx.isCompositeIndex()
==>true
rexster[groovy]> idx.getIndexedElement()
==>interface com.thinkaurelius.titan.core.TitanEdge
rexster[groovy]> idx.getFieldKeys().collect{it.getClass()}
==>class com.thinkaurelius.titan.graphdb.types.vertices.PropertyKeyVertex
rexster[groovy]> idx.getFieldKeys().collect{it.getDataType()}
==>class java.lang.String
rexster[groovy]> idx.getFieldKeys().collect{it.getCardinality()}
==>SINGLE
If I change the index definition to be Mixed, the re-index process completes okay. I've also been able to do similar Composite re-indexing on Vertex.class in the past.
On a related note, the call to TitanIndexRepair.cassandraRepair() does not result in any exception being thrown to the client when I see the failure above, so the client code tries to continue on with the process of enabling the supposedly repaired index, which (obviously) isn't a functional index at this point. Is there any built-in way to determine that the index repair failed?

I changed the milestone from Titan1.0 to Titan0.5.5 because the code at the center of the stacktrace has been completely rewritten.  The ClassCastException throw site and assigned type no longer exist in titan09/1.0: FaunusPropertyKey and FaunusElement are both long gone.
For "part b" of this issue: reindex jobs run through titan09's TitanManagement.updateIndex should git fulgora and return a future; these futures could and probably should complete exceptionally.  Jobs run through MapReduce/TitanIndexRepair don't have an equivalent mechanism in either titan05 or titan09.


contributing guide

Thank you for this amazing tool!
It would help myself and other contributors if there was a github recognized contribute document as well as issue templates to separate bug fixes from features.

Thanks for stopping by @brandonmcclure and your other PR (that I'll review shortly).
I don't necessarily want to be over-prescriptive about contributing templates -- I feel like the split between bug fixes and features is somewhat easy to parse. If there's an easy template we can copy thats gentle then I'll all for that -- but otherwise I wouldn't want to turn anyone away since they feel like they have to follow some paperwork.
We get some REALLY early beginners on this project so I think erring on the side of caution is helpful

That makes a lot of sense. I agree it is best to keep it simple in order to keep the barrier to entry low. I think the information that is in the readme is good, and I created a branch/pr #1001 moving that info into it's own doc. I think this keeps the spirit of the project, while creating the file that github expects/will direct contributors towards.
I don't really have a good issue template to share. I personally like the consistency that issue templates give me. Without some guidelines I can have problems articulating the actual issue, and that can lead me to avoid contributing/speaking up about the issue because i over analyze what I am typing out, and spend more time on that, than writing code :-)

Commented on #1001, and took a stab at a simple template in:
https://github.com/pcottle/learnGitBranching/blob/main/CONTRIBUTING.md
feel free to edit that with any additional info! I think keeping the build information in the readme (before you submit a PR) is helpful


README variable error

Hi,
Just in the README.md file, you say the env variable is "BACKGROUND" but it's currently "BACKGROUND_IMAGE" as in template
Thank you for your image :)

Thanks! I just updated the README.


CWA shows 1.0.0-rc.7 as currently used CCL version

This is an informational issue
See title. I guess you intended to show 1.0.0, see https://github.com/corona-warn-app/cwa-app-ccl/releases/tag/v1.0.0.

@Ein-Tim thanks for raising this. Technically, v1.0.0 and v1.0.0-rc.7 contain exactly the same code. The RC build is currently live on production due to the initial go-live of the feature and some internal beta testing prior to that. We shouldn't see this again in the future.

Okay, as this is just a minor issue and I expect a fix soon, I'm already closing this issue now.

@mlenkeit CWA still shows the RC in the version. Is this your intention?

@Ein-Tim
Are you referring to the version display in the released version of the app?
In Android, three-dot symbol > App Information

@MikeMcC399
Yes, I do.

@mlenkeit CWA still shows the RC in the version. Is this your intention?

@Ein-Tim yes, it should disappear latest with CWA 2.19.

CCL Version is now 1.1.0 even if CWA Android 2.18.1 is still installed. I know this issue is closed, but it really is resolved now.


Adds travis jobs on ppc64le

This PR adds power support on travis.

This is part of the Ubuntu distribution for ppc64le. This helps us simplify testing later when distributions are re-building and re-releasing,For more info tag @gerrith3.

Please review this merge.

I don't see how we need this for this particular project. It's architecture-independent.

Can you elaborate?


Remove unnecessary first br/block on functions with more complex control flow

As the title says, methods with jumps and branching add a block that acts like the entry block, we should just use the entry block.

The entry block acts as an argument filter, since dataflow only adds block arguments for data that is used, but functions can have parameters that are not (especially since we currently ignore functions like drop, and could well ignore several more in the future). Additionally it avoids any potential issues with mlir's restrictions on jumping to entry blocks


Normalmap fix

The materialx specification defines the scale attribute of the normalmap to be either a float or a vector2 but the vector2 variant was missing from the implementation. This PR adds it.

Thanks for putting this change together, @mnikelsky!
To address the errors in unit testing, I believe we just need a single usage of this node in our test suite, so that it will be run through shader generation and validation.
Here's one example where you could potentially update the normalmap node to use your new signature:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/1d67704c0b1989ede00932f3da1b3754fc0fe5d5/resources/Materials/TestSuite/pbrlib/surfaceshader/normalmapped_surfaceshader.mtlx#L15

Added a material example to the normalmapped_surfaceshader.mtlx


Update README.md

GoldenGate
GoldenGate is an Android annotation processor for generating type safe javascript bindings (Bridges). The library is very similar in usage to something like retrofit in that only an interface has to be declared and annotated (though retrofit does not do any compile time code generating). This annotated interface is at compile time used to generate an type safe wrapper around a webview for interfacing with the javascript.
Installation
Replace version x.x.x with the latest version under releases log
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
    }
}

apply plugin: 'com.neenbedankt.android-apt'

dependencies {
    apt 'com.flipboard.goldengate:compiler:x.x.x'
    compile 'com.flipboard.goldengate:api:x.x.x'
}

Usage
Before starting you will need to configure how object should be serialized to json. By default GoldenGate will use gson but does not package this dependency in case you would like to use something else. If you want to use gson add it as a dependency to your build.gradle.
dependencies {
    compile 'com.google.code.gson:gson:x.x.x'
}

If you would like to use some other library like jackson or maybe a custom json implementation you can register a JsonSerializer with JavascriptBridge.
JavaScriptBridge.setJsonSerializer(new JsonSerializer(){
    @Override
    <T> String toJson(T stuff) {
        // do stuff
    }

    @Override
    <T> T fromJson(String json, Class<T> type) {
        // do stuff
    }
});

Start by creating an interface and annotate it with @Bridge and also add a method which you want to call in javascript.
@Bridge
interface MyJavascript {
	void alert(String message);
}

This will automatically generate a class called MyJavascriptBridge which is the implementation which wraps a webview and implements the interface we just defined. Now we have a compile time checked type safe way of opening a javascript alert.
Webview webview = ...;
MyJavascript bridge = new MyJavascriptBridge(webview);
bridge.alert("Hi there!");

The above example is just a fire and forget example. We often want to get some result back. For this we have Callback<T>, because javascript runs asynchronously we can't just return this value and must therefor use a callback. The callback argument must allways be the argument specified last in the method decleration. Here is an example of using Callback<T>.
@Bridge
interface MyJavascript {
	void calculateSomeValue(Callback<Integer> value);
}

Webview webview = ...;
MyJavascript bridge = new MyJavascriptBridge(webview);
bridge.calculateSomeValue(new Callback<Integer>() {
	@Override
	void onResult(Integer result) {
		// do something with result
	}
});

That's it for simple usage! There are two other annotations for customized usage, @Method and @Property. @Method can be used to override the name of the method on the javascript side of the bridge (The java name of the method is automatically chosen if this annotation is not supplied).
@Bridge
interface MyJavascript {
	@Method("console.Log")
	void alert(String message);
}

The @Property annotation should be used for when setting or getting a property on the javascript side of things. In this case the method may only have one parameter (either a callback for result or a value which should be set). Just like with the @Method delaration a custom name can be chosen for the property. The default name for properties however is the name of the parameter to the method.
@Bridge
interface MyJavascript {
	@Property("window.innerHeight")
	void getWindowHeight(Callback<Integer> height);
}

And lastly if things aren't working as expected there is a @Debug annotation that can be added to your @Bridge annotated interface which will cause the javascript being executed to be logged to the console beforehand.
@Debug
@Bridge
interface MyJavascript {
	void alert(String message);
}

Proguard
If you use Proguard, you'll want to make sure you add the following to your config
# GoldenGate
-keep class * extends com.flipboard.goldengate.JavaScriptBridge { *; }
-keepattributes JavascriptInterface
-keepclassmembers class ** {
    @android.webkit.JavascriptInterface public *;
}

Contributing
We welcome pull requests for bug fixes, new features, and improvements to GoldenGate. Contributors to the main GoldenGate repository must accept Flipboard's Apache-style Individual Contributor License Agreement (CLA) before any changes can be merged.

duplicate, already merged


Remove obsolete prefixed event names

This PR removes obsolete transitionend prefixed events as discussed at https://github.com/framework7io/Framework7/issues/1288 and at https://github.com/framework7io/Framework7/pull/1849

Merged, thanks!


Zeppelin integration

Description
This PR add Zeppelin module to Crossdata and is added too, to module dist, that place the library into /opt/sds/crossdata/lib/zeppelin to be used when the client wants.

Coverage decreased (-0.03%) to 35.797% when pulling 7605e2a305a8ad55f6451334d186a95f8546e101 on jjlopezm:ZeppelinIntegration into f6f4c0dc09b930240c47f0bb687ab5d9349bebbf on Stratio:master.

Coverage remained the same at 35.829% when pulling 3dfec6b925a20b77b19ee09a7a0a541104fa331f on jjlopezm:ZeppelinIntegration into f6f4c0dc09b930240c47f0bb687ab5d9349bebbf on Stratio:master.

Coverage remained the same at 35.829% when pulling 80678b9dd8c77d0be831ace883994b5d6e9bb1e7 on jjlopezm:ZeppelinIntegration into f6f4c0dc09b930240c47f0bb687ab5d9349bebbf on Stratio:master.

Coverage remained the same at 35.829% when pulling 8842f2c02fe6d37567ccbdb042ff8d1bfa04188d on jjlopezm:ZeppelinIntegration into f6f4c0dc09b930240c47f0bb687ab5d9349bebbf on Stratio:master.

Coverage remained the same at 35.829% when pulling 8842f2c02fe6d37567ccbdb042ff8d1bfa04188d on jjlopezm:ZeppelinIntegration into f6f4c0dc09b930240c47f0bb687ab5d9349bebbf on Stratio:master.

Changes Unknown when pulling 76b127da05d2addeadef19f76d1bd39e9eae1be7 on jjlopezm:ZeppelinIntegration into ** on Stratio:master**.

Changes Unknown when pulling 76b127da05d2addeadef19f76d1bd39e9eae1be7 on jjlopezm:ZeppelinIntegration into ** on Stratio:master**.

Changes Unknown when pulling d67c2d5fcdba664616137bbc2ff99fc2dea4a9ce on jjlopezm:ZeppelinIntegration into ** on Stratio:master**.

Coverage remained the same at 35.737% when pulling 6c3f85758f88edeed0c4714f13b30bf7a142a3be on jjlopezm:ZeppelinIntegration into 21fd91d39f959417f5fedba265b32ed4657b9540 on Stratio:master.


"select" callback during initialization fired before tab content is processed

Here is plunkr: http://plnkr.co/edit/9dRJRE2sbPdszg2HrKA0?p=preview
The issue is that selectTab(tab) method in controller is called before tab contents were processed by AngularJS. This causes inner directives to not behave properly since they listen to the event broadcast from that controller method.
It works for me if I wrap $broadcast with $timeout. Does not work with $evalAsync.
Is this known and expected behavior? Is there any other way to watch for tab selection from inside the tab contents?

Closing due to inactivity. Reopen if this is still an issue.


Fix build error

"ERROR in ./src/og/control/ShowFps.js Module not fou…nd: Error: Can't resolve '../utils/Shared.js'"

Thanks for a great project BTW!
I'm also looking to get UTF-8 characters working in the labels.

Thanks, Waldenn! Welcome!
Unfortunately chars atlas for is quite inconvenient, frankly speaking. It will be remade someday. This time you can try to add utf8 symbols(not many! sorry) right to the ./utils/FontAtlas.js to the tokens array. I'm not sure it will work, but it's easy to try.


No facts are shown

https://knooppuntnet.nl/nl/network-facts/2240269
On the left after facts it says 68, the old site also show these facts (mostly nodes where the integrityCheckFailed "expected_rwn_route_relations" failed) but the main screen says "Venlo
Facts
no facts"

@MaartenDeen thanks for reporting this problem.
Only route related facts were shown in the fact page. The code has been further completed to also include all other (network and node related) facts.


Matchers.booleanConstant(true) should not match Boolean.FALSE

Description of the problem / feature request:
booleanConstant(true) should not match both Boolean.TRUE and Boolean.FALSE.
Feature requests: what underlying problem are you trying to solve with this feature?
Matchers match code that they're build specifically not to match.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Writing tests.
What version of Error Prone are you using?
2.3.4
Have you found anything relevant by searching the web?
no

PR here: https://github.com/google/error-prone/pull/1455


Can you please offer secure httpS for your site/API?

Most modern browsers will now block mixed content, ie. content from http resource (your API) coming from a secure site.
I personally paid $8.40 with my domain registrar (INTERNET.BS) for setting up httpS but I read in several places the cost now is free through places like cloudfare.com
Let me know if you need it and I can share my log of the steps I went thru to set it up (it's fairly trivial).
I tried looking into automatic fixing/rewrites but it won't apply because at the end the resource (here an API) has to be able to load via https.  You can read about it here.
https://blog.cloudflare.com/fixing-the-mixed-content-problem-with-automatic-https-rewrites/

Thank you for you understanding and efforts.

Please offer https protcol for your api, my website refuse to connect because mixed content, and thank you.


Option to open files in tabs

Hi, the diff is unreadable, because I moved on_exit into a closure to pass a variable there. I also removed the path argument from joshunto() as it's just redefined later the function.

Thanks!

(fix to #7)


Http configurable logging

Change Description

Add configurable logging to http_plugin controlled by "http_plugin" log name.
A logging.json file will now need to be provided to get logging previously provided by default.
See example logging.json in ./programs/nodeos directory.

Consensus Changes

[ ] Consensus Changes

API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Documentation portraying expected nodeos output may need to be adapted to match the new less verbose output.  Either that or the documentation should describe adding a logging.json with debug settings.


The 'navigation' object hasn't been initialized yet. This might happen if you don't have a navigator mounted, or if the navigator hasn't finished mounting. See https://reactnavigation.org/docs/navigating-without-navigation-prop#handling-initialization for more details.

Hi,
I get this error whenever I start the android simulator, and it pops up again when I try to use solito router to push a route. It works perfectly on web tho.
This is my NavigationContainer:
`import { NavigationContainer } from '@react-navigation/native'
import * as Linking from 'expo-linking'
import { useMemo } from 'react'
export function NavigationProvider({
children,
}: {
children: React.ReactNode
}) {
return (
<NavigationContainer
linking={useMemo(
() => ({
prefixes: [Linking.createURL('/')],
config: {
initialRouteName: 'app',
screens: {
app: 'app',
login: 'login',
signup: 'signup',
},
},
}),
[]
)}
>
{children}

)
}
`
My provider:
`import { Dripsy, paperTheme } from './dripsy'
import { NavigationProvider } from './navigation'
import { FirebaseContextProvider } from 'app/contexts/use-firebase'
import { FirebaseAuthContextProvider } from 'app/contexts/use-firebase-auth-context'
import { Provider as PaperProvider } from 'react-native-paper'
import React from 'react'
export function Provider({ children }: { children: React.ReactNode }) {
return (

{children}

)
}
`

Unfortunately this example is too hard to parse. Also, your provider is empty, so that must be why it's broken. I need a better reproduction to help here, so I'm going to close for now.
Have you referenced the starter monorepo?


"GitHub Pull Requests and Issues" plugin causing a large number of requests to github enterprise installation

Extension version: v0.58.1
VSCode Version: Version: 1.75.1 (Universal) Commit: 441438abd1ac652551dbe4d408dfcec8a
OS: macOS 12.6 (21G115)

Steps to Reproduce:

Open VS code with extension installed
Open the "github" sidebar
Check internal graph of requests to github enteprise server
Note increase of ~4k requests per minute to server

For the time being I've just disabled the plugin. If there's a way to enable some debug logging that might say more about the plugin activity please let me know.

I can see from the request logs that these are graphql calls. They started around the time I updated to 0.58.1 and disabling the plugin stops the request flood.

Here's a parsed sample from the github enterprise server logs
app=github
env=production
enterprise=true
auth_fingerprint=<redact>
limited_limit=90000
limited_ttl=60
limited=api/time-based
current_user=Mat-Schaffer
controller="Api::GraphQL"
path_info="/api/graphql"
query_string=nil
version=merge-info-preview
non_integer_id=nil
auth=oauth
oauth_access_id=59018
oauth_application_id=14
oauth_scopes="read:user,repo,user:email,workflow"
integration_id=nil
installation_id=nil
parent_installation_id=nil
user_programmatic_access_id=nil
x_real_ip=<redact>
x_forwarded_for=<redact>
route=/graphql
rate_limit=5000
rate_limit_remaining=5000
rate_limit_key=user-2175
rate_limit_used=0
rate_limit_reset=1676324529
rate_limit_family=graphql
graphql_global_id_type=legacy
now="2023-02-13T20:42:10+00:00"
request_id=ccf16617-0d5c-49b7-babb-6aaeb1681b86
datacenter=default
server_id=<redact>
remote_address=<redact>
request_method=post
request_host=<redact>
content_length=276
content_type="application/json;
charset=utf-8"
user_agent="node-fetch/1.0 (+https://github.com/bitinn/node-fetch)"
accept="*/*,application/vnd.github.merge-info-preview"
referer=
status=200
elapsed=0.147
url="https://<redact>/api/graphql"
worker_request_count=534721
request_category=api

Duplicate of https://github.com/microsoft/vscode-pull-request-github/issues/4507

@matschaffer-roblox would you be able to share extension output?

set the log level to "Debug"

command: Developer: Set Log level
choose "GitHub Pull Request"
then click the little "Set as default log level" button to the right of the work "Debug")

share the output from "GitHub Pull Request" next time you see the issue

That will contain some rate limit logging that should narrow down what's happening.

I don't appear to have a "GitHub Pull Request" option in my set log level items.

The info logs had a lot of activity though. Here's a redacted sample incase it's helpful. Knowing which output tab to select was helpful. If you have any ideas about how to be enable debug logging please let me know.
logs.txt.gz
Looks like maybe some sort of authentication tight retry loop going on.

Sorry about that @matschaffer-roblox, I gave the pre-release build log level instructions. For the stable build:

Set the setting "githubPullRequests.logLevel": "debug"
Reproduce the issue
Share the output from GitHub Pull Request

@matschaffer-roblox are you able to also share the logs from GitHub Authentication and GitHub Enterprise Authentication?

Please fix this bug. I have also faced this issue on my Enterprise account and I had to uninstall the extension.

@Vasugupta946 can you share logs? I will release a fix as soon as I have one, but I'm not able to reproduce the issue and must rely on logs.

Set the setting "githubPullRequests.logLevel": "debug"
Reproduce the issue
Share the output from GitHub Pull Request (if you don't want to share your repo name/url you will need to redact it from the logs).
Share the output from GitHub Authentication
Share the output from GitHub Enterprise Authentication

While there may be some bug specific to authentication, would its make sense for this extension to have its own client-side rate limit for all HTTP requests?  Even if a specific auth problem is addressed, companies might be hesitant to approve this extension's usage again if they think there is a future risk of request flooding.

@alexr00 yep, here are those logs - Archive.zip
I also tried v0.59.2023020215 and the behavior seems the same.
I noticed today that it's not all repos that trigger it, but one specific (unfortunately internal) repository. The repo in question is also fairly cross-team so like has many more contributors than the others I work on.

v0.56.0 doesn't exhibit the problem. Also the repo in question has ~160 open PRs and ~8k closed PRs.
Here's a redacted pull request log from v0.56.0 - github-pull-request-v0.56.0-debug.log.gz

@alexr00 yep, here are those logs - ....
I also tried v0.59.2023020215 and the behavior seems the same.
I noticed today that it's not all repos that trigger it, but one specific (unfortunately internal) repository. The repo in question is also fairly cross-team so like has many more contributors than the others I work on.

Thanks @matschaffer-roblox For the v0.59.2023020215, would it be possible for you to reproduce the issue and provide the  the Github Pull Request log, as this should display when the calls are being to github
Also while I understand it's a private repo that it happens on, would it be possible for you to answer if the private repo is hosted on Github Enterprise? If not, you can just just ignore the question ;-)
So far I believe all reported instances have occurred on Github Enterprise, so it would be good to know if it's the same for you
@alexr00 I spent some time over weekend playing around with a vanilla instance of Github Enterprise, and was unable to recreate the issue.
I tried most things I could think of (Introducing extremely harsh rate limits, randomly pulling the network connection to the server), but for the life of me I couldn't reproduce the issue on 0.58 or 0.59

@jpspringall yes, the repo is on the same github enterprise installation that's seeing elevated request load when I enable the plugin.
I tried running the plugin from main this morning and got these logs. I couldn't figure out how to launch the extension in debug mode but I could switch to debug logging partway through.
main-logs-info-debug-1.txt.gz

Incase it's useful I ran a git bisect as well which landed on 295206885d4c1bbcae82f71335da2d932fc0d2d7

@jpspringall yes, the repo is on the same github enterprise installation that's seeing elevated request load when I enable the plugin.
I tried running the plugin from main this morning and got these logs. I couldn't figure out how to launch the extension in debug mode but I could switch to debug logging partway through.
main-logs-info-debug-1.txt.gz

@matschaffer-roblox That's great thanks!
From a quick look at the logs, the problem appears to be 3 fold:

Continuously calling /users
Attempting to Authenticate when it could resolve the remote host (I presume you have to connect via VPN, and weren't initially connected)
Then getting stuck in loop trying Initializing GitHub authentication provider

Out of interest, I presume you were starting VS Code from cold, when getting the logs, i.e you were starting a new instance of VS Code, not using a long running instance

So good news, kinda:
I have managed to consistently recreate the issue by doing the following:

Open VS Code Insiders pointing at the vs-code-pull-request repo
rm -rf node_modules
Yarn and
Sign out of Github Enterprise from within this instance of VS Code, so when you start the debugger you aren't signed in
Run the debugger
Make sure that the debugging instance of VS Code Insiders starts in Github Enterprise folder, so you may have debug twice
Click on the Github Extension
Go through the sign in process
Watch thousands of requests being sent to Github Enterprise

Confirmed that the above works as expected on 0.56
As for the actual problem, still working on that:
I think we can rule out #4420, as that was my first go to, but that didn't appear to fix anything
As for the actual problem it seems to stem from the fact that the function:
doUpdateRepositories in the file: src\github\folderRepositoryManager.ts is being called repeatedly
Though I haven't worked out why yet
I know that I started to have the issue on January 25th while it was on pre release, so I will probably look into PRs around that time to see if I can spot anything.
Though that will be tomorrow's task, I'm done for now
Cheers
J

@jpspringall and @matschaffer-roblox thank you both for your continued investigation into this. I'm going through the additional logs and trying to come up with a root cause now.

So I may not have not waited until tomorrow.
The Problem PR is #4427, beyond that not done any investigation.
If I had to guess, I suspect it's this: https://github.com/microsoft/vscode-pull-request-github/pull/4427/files#diff-b0f6b0e92ac9fb7c8d22583477dc01f57b0f31d4f545489ea966548b6e1321b9
Will pick this up tomorrow

Got a repro thanks to the logs providing a clue.

Run on a machine (or otherwise simulate) git initialization being slow

git initialization is done by the built in git extension and this extension relies on it for all git operations

Have a PR from main/default branch to another branch

The bug has a few parts:

Here, we do something that will trigger auth when repos update:
https://github.com/microsoft/vscode-pull-request-github/blob/77ca4453f544687360ab4c5a5df5d76d9d307a5c/src/issues/stateManager.ts#L103-L104
Here, we do something that will trigger update repos when we get an auth token:
https://github.com/microsoft/vscode-pull-request-github/blob/77ca4453f544687360ab4c5a5df5d76d9d307a5c/src/github/folderRepositoryManager.ts#L172-L173
This triggers an endless loop, but only when git is initialized slowly.
https://github.com/microsoft/vscode-pull-request-github/pull/4427/files#diff-b0f6b0e92ac9fb7c8d22583477dc01f57b0f31d4f545489ea966548b6e1321b9 did indeed cause the loop to happen.

I should have a fix today.

I've just released 0.58.2 (and a new pre-release version), which has a change that I'm fairly confident fixes the issue. If you could try it out and let me know if you still see the problem that would be very helpful!
Thank you for all the investigation effort!

Hope this version is stable and not going to bring down GHES

@ghecadmin I'm am fairly confident of the fix, but, given that I was only able to simulate one of the contributing factors to the bug, we won't know for sure until one of the folks who was experiencing the issue can reply here and let us know.

I updated to 0.58.2 about 15 minutes ago. The logs are a lot cleaner and I'm not seeing the GHE spikes I was before. Reloading the window a few times seems to have caused about GraphQL 400 requests from me in the server logs. This is 10x lower than before so I'd say you fixed it.
I'll keep an eye on the logs as I work today just incase and ping if I see trouble.
Nice work finding the repo @jpspringall and nice work finding the fix @alexr00 - thanks so much!

Is it possible to get a more general fix for this problem?  Back in August (which predates #4427) we saw thousands of requests to other endpoints, in that case it was .... pulls/{number}/requested_reviewers.

I'll be adding guards against this with https://github.com/microsoft/vscode-pull-request-github/issues/4546.


Docs (README) should warn customers about the implications of requiring the all-in-one google-cloud module

See https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2102 for corresponding NodeJS issue.
Per @lukesneeringer: "You should definitely open up an issue on Ruby; aggressive require resolution is standard practice in Sinatra and other places, and use of the meta-package should be discouraged there."

Does Ruby have this problem? We limit what code is loaded until the calls are actually made, so requiring "google/cloud" does not load every gem fully into memory.

Here is where google-cloud-bigquery lazily executes the require. Other service support is similar.

Sounds good. You clearly actively covered this base already.

@bjwatson Can we close this issue?

Yep, thanks!

For the sake of history, here is the memory pressure that the google-cloud libraries add. We have tried really hard to make it so only the services that are used are loaded.
First creating a global gcloud object and loading a service from it:
# create a baseline of memory usage
baseline = Object.new #-> 43.7 MB

# load the Google Cloud library, create global object
require "google/cloud" #-> 44.3 MB
gcloud = Google::Cloud.new #-> 44.3 MB

# create BigQuery object (and load the library) from global object
bigquery = gcloud.bigquery #-> 64.9 MB

# explicitly load the BigQuery library
require "google/cloud/bigquery" #-> 64.9 MB
# create another BigQuery library using library initializer
bigquery2 = Google::Cloud::Bigquery.new #-> 65.7 MB

Second, load google/cloud, but don't create a global object:
# create a baseline of memory usage
baseline = Object.new #-> 43.7 MB

# load the Google Cloud library
require "google/cloud" #-> 44.3 MB

# explicitly load the BigQuery library
require "google/cloud/bigquery" #-> 64.0 MB
# create BigQuery library using library initializer
bigquery = Google::Cloud::Bigquery.new #-> 65.2 MB

# create global object
gcloud = Google::Cloud.new #-> 65.2 MB
# create another BigQuery object from global object
bigquery2 = gcloud.bigquery #-> 65.2 MB

Third, load and create a service object, then load google/cloud:
# create a baseline of memory usage
baseline = Object.new #-> 43.7 MB

# explicitly load the BigQuery library
require "google/cloud/bigquery" #-> 63.6 MB
# create BigQuery library using library initializer
bigquery = Google::Cloud::Bigquery.new #-> 64.3 MB

# load the Google Cloud library
require "google/cloud" #-> 64.3 MB
# create global object
gcloud = Google::Cloud.new #-> 64.3 MB
# create another BigQuery object from global object
bigquery2 = gcloud.bigquery #-> 65.4 MB

As you can see, requiring google/cloud adds very little memory overhead.

Most ruby applications use a Gemfile to declare their dependencies, and some applications like Sinatra and Rails may choose to pre-load libraries. We have thought through this and believe we properly control how much is loaded into memory in these circumstances. For instance, given this Gemfile:
gem "google-cloud"

And creating a ruby process with bundle exec, the following memory is used:
# create a baseline of memory usage
baseline = Object.new #-> 54.8 MB

# call require which will load all gems in the Gemfile
Bundler.require #-> 55.2 MB

# explicitly load the BigQuery library
require "google/cloud/bigquery" #-> 69.6 MB
# create BigQuery library using library initializer
bigquery = Google::Cloud::Bigquery.new #-> 70.6 MB

If the Gemfile is changes to include the umbrella gem as well as the service gem used:
gem "google-cloud"
gem "google-cloud-bigquery"

Then the memory usage is similar:
# create a baseline of memory usage
baseline = Object.new #-> 54.8 MB

# call require which will load all gems in the Gemfile
Bundler.require #-> 55.2 MB

# explicitly load the BigQuery library
require "google/cloud/bigquery" #-> 69.6 MB
# create BigQuery library using library initializer
bigquery = Google::Cloud::Bigquery.new #-> 70.6 MB

Finally, here is the memory usage for loading all services into memory:
# create a baseline of memory usage
baseline = Object.new #-> 43.7 MB

# explicitly loading all google-cloud gems
require "google/cloud/bigquery"
require "google/cloud/datastore"
require "google/cloud/dns"
require "google/cloud/error_reporting/middleware"
require "google/cloud/language"
require "google/cloud/logging"
require "google/cloud/monitoring"
require "google/cloud/pubsub"
require "google/cloud/resource_manager"
require "google/cloud/speech"
require "google/cloud/storage"
require "google/cloud/trace"
require "google/cloud/translate"
require "google/cloud/vision" #-> 95.4 MB

Creating object instances for each service will use additional memory.

Great! Thanks for the metrics @blowmage, and thanks to both of you for all the effort to keep the metapackage lean (i.e. only loading what's needed).


feat(): Changed trf models to lg's parser architecture

Changed both trf models to lg model parser architecture

Thanks!


Setup Instructions: Audit and Report Components: Step 6

Setup instructions for Audit and Report Components: Step 6: INSTALL THE FLOWS should perhaps include clarification on modifying the following Flow

Admin | Find and disable flows that leverage certain connectors

in that, to exclude Admin flows from this, what is the dynamic content to be added to the exception condition step "Disable app if it uses highlighted connectors" ;

['creator']?['objectid'] is not equal to ….  blank

Assume correct entry would be the UPN of the admin flow owner, and assuming this is the same as the environment variable then dynamic content

variables('adminMail')

can be used?
Clarity would be useful :)

We have now clarified in the documentation that this Flow requires setup before running it.


Crash Report: Argument rangeInElement (39,316) endOffset must not exceed descriptor text range (618, 680) length (62).

Description
opened clion
Stacktrace
Please paste the full stacktrace from the IDEA error popup

Thanks for reporting! This issue has already been reported in #493 and has been solved in commit a4caa3cf552a4c36472dd610eaf15fc98df53859. A new release which includes the fix will be available soon.

Fixed in commit a4caa3c and will be included in release b0.6.1 in the near future.


Class attribute's type not detected properly when class is decorated

Describe the bug
It seems pytkdocs has trouble detecting a class attribute's type when the class is decorated.
To Reproduce
See an example here: https://github.com/copier-org/copier/pull/203#discussion_r459869048. The description is correctly parsed from the docstring, but the type is not used.
Expected behavior
The type (cli.Flag in the example) should appear in the Attributes table.
Screenshots
If you are using pytkdocs through mkdocstrings and if relevant, please attach a screenshot.

System (please complete the following information):

pytkdocs version 0.6.0
Python version: 3.6
OS: Linux

I don't think it's relevant anymore as Copier has migrated to the new handler and Griffe.


feat(NODE-2014)!: return the result of provided callback in withTransaction and withSession

Description
Updates withTransaction and withSession helpers to return the return value of the user provided callback.
What is changing?

session.withTransaction() now properly returns the return value of the callback.
client.withSession() updates its signature to return Promise<any> instead of Promise<void and returns the return value of the provided callback.
Updates migration guide.

Is there new documentation needed for these changes?
None
What is the motivation for this change?
NODE-2014

Double check the following

[x] Ran npm run check:lint script
[x] Self-review completed using the steps outlined here
[x] PR title follows the correct format: type(NODE-xxxx)[!]: description

Example: feat(NODE-1234)!: rewriting everything in coffeescript

[x] Changes are covered by tests
[ ] New TODOs have a related JIRA ticket

From slack: We're moving this effort down the road to the next major to get ahead of documentation updates that we would want to have ready before committing to this change.


MacOS installation through Conda

I try to install the crocoddyl through Conda.
It comes with issues as shown in this log.
crocoddyl_log.txt

Hi @ddliu365 This looks like a problem in your conda installation, and not crocoddyl.

I confirmed, croco is working well with conda install on macs.
The problem is on your side.

is there any specific version of Conda I should use?
I am using this python 3.8 anaconda
Anaconda3-2020.11-MacOSX-x86_64

I also installed pinocchio which works well.

@jcarpent @proyan
Thanks for your quick response.
I will check my side.

Should work with all versions. People from conda are doing an excellent job at this level.
We are not the best persons to answer your local computer problems.


Remove relaymq dependency and RelayMQDriver and its config

This is the change to remove RelayMQ driver and dependency from Maestro.

I have not done system testing with this change yet. I'm starting on that now, but the code review can start now.

@SenRamakri - as far as I can tell checktime.go should be fine. Been a while since I wrote that code. Let's check to make sure its working to integration cloud.

@edhemphill @cmonr - I have tested these changes and confirmed that gateway is successfully connecting and registering with the pelion cloud(os2). I think we can merge the changes now.


[Analytics] Manage context via version-bridge

Hey, I just made a Pull Request!
Closes #7436
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

@iamEAP changeset plz. :)

Even if it's only modifying an unreleased API?

Yeah fine to skip changeset

Ah ok - yeah, just realised that this was only merged recently.


Fix/admin back docker envar

Description
Make the back-admin image without env variable
Linked Issues
#466
Changes
What does it change ?
Is is a breaking change ?
Is is a new feature ?
Is is a patch, fix, hotfix ?
Screenshots
Put screenshots (if any)
Tests
How has it been tested ?

[X] Manually
[ ] Automated tests
[ ] QA
[ ] Other

Additional information
Precise any other information

eb459aedab226f507f25f3a191c40f3ff4ffb951f126a53fd881c966dfc003a5


Inconsistent background colour on the Survey app

The ODK-X Survey mobile app has a consistent white background colour across all screens.
Observation:
While reviewing the application, I noticed some screens had a different background colour with a poor contrast on the text and buttons.

Again, add some more context and description so future contributors can understand.

Hello @maprehensive and #teelda can i work on this issue if it is still relavent as a outreachy applicant .  if yes please assign it to me

please assign this to me, i will like to work on this


Refactor out to library and create CLI that reads in a modification

Depends on #6

When this is done I will need to refactor out the Autofac dependencies and make the concrete classes public.
Probably not a bad idea to go ahead and provide a facade as well.


append command

Hello,
I tried to execute a APPE command using the raw method.
But I have the error that the raw.appe command is not a function.
Is this command available ?

It will be in the next version, thanks.


[SPARK-38752][SQL][TESTS] Test the error class: UNSUPPORTED_DATATYPE

What changes were proposed in this pull request?
I add a test case for the error class UNSUPPORTED_DATATYPE in the QueryExecutionErrorsSuite.
Why are the changes needed?
To improve test coverage, and record expected error messages in tests.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
build/sbt "test:testOnly *QueryExecutionErrorsSuite"

+1, LGTM. Merging to master.
Thank you, @lvshaokang.

Can one of the admins verify this patch?


Error in minimax algorithm

Currently, the minmax algorithm only sets the value of the new disc via
position.board[row, col] = Board.BLACK
This does not flip any discs and causes the final evaluation to be flawed.
Suggest to create a copy of the board and call board.set_discs()  instead

Greetings Zhe!
I'm really grateful for you stepping forward to pay your attention to the project. Means a lot :)
For the issue,
Firstly I realised I was a dumbster for not noticing this fact,
Secondly, I have created a new branch for fixing the same issue
I'd appreciate you checking the updated code for minimax.py
I believe this code snippet should work to fix the problem (added this at two places in the minimax function, and once in the find_best_move function.
position_deepcopy = deepcopy(position) # create a deep copy of the board position
position_deepcopy.board[row, col] = Board.WHITE
position_deepcopy.set_discs(row, col, Board.WHITE)

currentEval = minimax(position, 5, float('-inf'), float('inf'), True)

Let me know how does this seem like..
Thanks!!

Greetings Zhe,
Thanks for letting me know about that!
My eyes just didn't catch that line of code ;p
Fixed it with the latest commit 👍
I shall mark this issue as closed as I merge the minimax-error-fix branch to main.
Thanks again!


Feature: reconnect when shutting down / starting again rosbridge

[x] I am at the right place and my issue is directly related to ROS#. General technical questions I would post e.g. at ROS Answers or Stack Overflow. For library-specific questions I would look for help in the corresponding library forums.
[x] I have thoroughly read the Contributing Guideline and writing this issue is the right thing to do in my case.

I have a feature request!
First of all, thanks to the ros-sharp team for producing such an amazing work :+1: .
I'm currently exploring the pros / cons to port an existing Unity project to ROS#, and one thing I couldn't get to work is reconnect to the bridge when it has been closed on ROS side (shutting down the project while Unity is still running, and run it again).
Is there any plan for this feature ? Or is it supposed to work already ( I'm running ROS + Unity on Ubuntu) ?
If not, I would gladly try to contribute if someone can give me some hints on where to start.

Hi @PymZoR
all you have to do is adjust RosConnector to your needs.
RosConnector is currently implemented in a very simple and generic way: Start when Unity calls Start().
RosConnector does not try to reconnect when the Connection to the ROS system is lost.
I agree that a "Do Reconnect" option in the RosConnector is helpful. We are currently not working on this feature. Please let me know if you find a simple and clean solution.


Row nested inside collapsed row, misalignment

So I see theres a note in the 6.1.2 changelog "Fix misaligned gutters when nesting a row inside of a collapsed row", which is odd since I now see exactly that issue after upgrading.
Here's a screen of how an example appears since 6.1.2, with some notations roughly marking the grid structure:

And here's what the same thing looked like in 6.1.0

The inner set of rows previously had some negative margins that aligned them with the outer row, which is no longer present.

Could you post a code sample with just the grid syntax used?

Sure thing, heres the grid structure with the contents removed.  First using 6.1.0:

And using 6.1.2:

Assuming the change is indeed a fix to some otherwise erroneous behaviour, are there any suggestions on how to keep column elements aligned, regardless of the number of nested rows? Otherwise, it seems to me, as you nest deeper and deeper, the left and right paddings build up and the rows get narrower as the depth increases.
Thanks

Looks like a specificity problem. .small-collapse .row trumps .row .row.
We could add !important to the margins of .row .row. Except yuck!
But if we change this…
.row .row {
    margin-left: -.9375rem;
    margin-right: -.9375rem;
}

to this…
.row .columns .row, .row.columns .row {
    margin-left: -.9375rem;
    margin-right: -.9375rem;
}

it's fixed.

This is one of the reasons for the new XY-Grid in 6.4. A PR for this will be merged, and we'll close this here since XY Grid resolves these specificity issues.


docs: [vision-os-sample-app][6/n] Common Views

This is a PR in a series of PRs to build sample app that runs Identify and Track in VisionPro
The app is built to be an interactive walk through guidance for developers who are integrating Customer.io Swift SDK in their VisioPro apps.
For more context:

See the project one pager
See Linear Issue

This PR adds punch of generic SwiftUI view

CommonLayoutView this view will be used to wrap all content and handle bunch of the navigation logic. Including displaying the Logo, the TutroialsMenuView, and error messages

LineView custom view for flexible divider

FloatingTitleTextView custom text field to ensure the field placeholder becomes labels when the field is filled.

Open VisionOs.xcproject

Hit CMD+R to run the project and make sure you have VisionOS simulator installed and selected

Stack:

#628
#627
#626
#625
#624
#623
#622 ⬅
#621
#620
#619
#618

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.


Reference documentation for each Panel

I think we should look to establish a reference section (see diataxis.fr) in the docs at https://jupyterhub-grafana.readthedocs.io/, where we describe each panel in each dashboard.
I think we should focus on letting the reference describe individual panels, like how diataxis.fr suggests a reference guide is written:

The only purpose of a reference guide is to describe, as succinctly as possible, and in an orderly way. Whereas the content of tutorials and how-to guides are led by needs of the user, reference material is led by the product it describes.

Why start with reference docs?
I propose we improve the docs of grafana-dashboards by starting at the reference docs, I've found it to be a good starting point in order to build more advanced docs that connects pieces as that is then offloaded from needin to do reference like descriptions.

How much overlap is there between the reference doc for a panel, and the description attribute of the panel? Can they be treated as the same?

Very good point, I've not thought this through that much but I was thinking that maybe it could make sense to link to the rendered docs from the description that presents itself. If this is a good idea or not depends on things like what format we are constrained to in the description and if its suitable to rendered in the sphinx-docs as well etc.

As part of https://github.com/jupyterhub/grafana-dashboards/pull/90 I've tried to also add more detailed references in the description, and it would be lovely in the long term to autogenerate reference docs from that.

After the following PRs, I hope it'll be easier for folk to add to and improve the documentation for this project :)

#96
#97


Manually created assembly looses it's factory reference

Hello!

I prefer to create assemblies manually because using layered architecture and need to create new assembly for each user layer. It's not possible to use automatic assemblies generation because I have to inject some user specific information into the assembly.
Everything works fine until the end of the method.
After that any attempt to instantiate new object causes "method not found" crash.
I did some research and found that manually activated assemblies become instances of TyphoonAssemblyAccessor and later loosing reference to fabric property. This property resets to nil because declared as weak. It makes the assembly unusable anywhere outside the method scope where is was created because it immediately looses it's fabric.
I've figured out that the only way to keep this reference alive is to patch the sources (make it strong) or to make the assembly default.
This definitely is something that I do not want to do.
Please help.
PS: Please do not suggest to switch to Swift or use plist assemblies creation.

Can you provide your usage code?

``

@interface AppAssembly : TyphoonAssembly

(AppAssembly *) create {
AppAssembly *assembly = [[AppAssembly new] activated];
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
[assembly inject:[userDefaults rac_channelTerminalForKey:@"currentUserId"] withSelector:@selector(currentUserIdDefault)];
return assembly;
}

For test purposes I've put [AppAssembly create] into viewDidLoad and inside this method everything works fine. But In the other method (button press callback) I can see reference to AppAssembly since it's retained, but fabric and assembly properties are nil.
I'm using current version on Typhoon installed using Pods.

When I checking assemblies created in PocketForecast sample app, I see that it has TyphoonBlockComponentFactory instance class.
Mine's are TyphoonAssemblyAccessor.
I'm really confused...

Hi, @AlexeyPoldeo ! I think that the problem is in the way you are trying to use Typhoon.

I prefer to create assemblies manually because using layered architecture and need to create new assembly for each user layer.
When you create multiple assemblies manually (by calling [[AppAssembly new] activated] each time), you don't share dependency graph between them. It means, that if you have a singleton object in AppAssembly, this instance won't be accessible in your second assembly.

It's not possible to use automatic assemblies generation because I have to inject some user specific information into the assembly.
Well, this is possible but this approach doesn't belong to best practices. Consider assemblies as simple factories without any internal state. They are just proxies to access an underlying pool of created dependencies.

With all my respect, but I see too many limitations in comparison to Dagger 2.
It's possible to name it as features, but they are not...
Senior developers, who are smart enough to learn how to use Typhoon, do not need to put configuration to plist file to simplify their work. They want to get some tool to manage complicated object graphs and layer fabrics.

@AlexeyPoldeo If you want to create assemblies manually this is no problem, however the way you tried is not the correct way for Typhoon. What you need to do is:

Create an assembly, such as your top-level layer. Let's say it needs a collaborating assembly, network components.

##Example
@interface UIAssembly : TyphoonAssembly

// Typhoon will automatically proxy the two collaborating assemblies
// (NetworkComponents and TyphoonAssembly<PersistenceComponents>) here.
@property(nonatomic, strong, readonly) NetworkComponents* networkComponents;

// Collaborating assemblies can be backed by a protocol. We declare
// type using TyphoonAssembly<FactoryProtocol> syntax to tell Typhoon
// that this is a collaborating assembly. In the app's own classes no further
// coupling to Typhoon is necessary, and we may declare a property as type
// id<FactoryProtocol>, avoiding your classes from being aware of Typhoon.
@property(nonatomic, strong, readonly) TyphoonAssembly<PersistenceComponents> persistenceComponents;

// Local components that require components from collaborating assemblies ...
- (RootViewController *)rootViewController;

- (SignUpViewController *)signUpViewController;

- (StoreViewController *)storeViewController;
@end

We declare a property of type NetworkComponents, like this: @property(nonatomic, strong, readonly) NetworkComponents* networkComponents;
And then to activate you just call:
UIAssembly *uiAssembly = [[UIAssembly new] activate];

Typhoon will automatically wire in the NetworkComponents assembly. If you wish to override this with a sub-class or anything else that fulfills the contract you can use:
UIAssembly *uiAssembly = [[UIAssembly new]
    activateWithCollaboratingAssemblies:@[
        [TestNetworkComponents new],
        [PersistenceComponents new]];

Typhoon for Objective-C is nothing like Dagger 2. The way that it works is:

Non-activated assemblies contain recipes for building components. These can be modularized and reference each other.
Typhoon gathers the recipes into a single factory that uses these to emit built components.

This is a very Objective-C-esque approach, which at the time Typhoon was written is what people were after.
More info on assembly modularization is available here: https://github.com/appsquickly/Typhoon/wiki/Modularizing-Assemblies
Typhoon for Swift is somewhat more like Dagger in that it uses compile-time rather than runtime processing.
Thank you for trying Typhoon and let me know if you need further assistance setting up.

Thank you for details, Jasper, but I didn't got what I did wrong...
I've created assembly and it's fabric died after finishing the enclosing method.
Example:
@property (nonatomic) TestAssemply *assembly;

(void) method1 {
self.assembly = [[TestAssembly new] activate];
/* It's OK! */
}

(void) method2 {
self.assembly - unusable because start responding "unknown selector" to any object creation request.
}

It it bug or it's by design?

Can you send me a sample project? Sounds like a bug or user error of some sort. Likely the latter. You code above looks fine - sample project will help me understand better.

@jasperblues @alexgarbarev  I'm attaching a simple project where I believe this issue is replicated.
It contains a test that asserts if the assembly injected by property is the same as the assembly passed to the initializer. (using the former works as expected)
BugFactory.zip
Thanks in advance.


DSM 7.1.1 (DS1813+) and Docker v24.0.6

It had been a while since I messed around with an update so decided to give it a shot.
Docker v24.0.6 refused to start, tried v23.0.6 instead.  That at least started but wasn't able to access any containers which used the default bridge network.  Tried various ip routes but none of them helped.  My macvlan still worked though, so just ended up switching all containers over to that.
Just wondering if anyone else has tried updating to v23 or v24 and whether similar issues were seen :)

Switched to Docker v26 here, no issues.

Client:
 Version:    26.1.1
 Context:    default
 Debug Mode: false

Server:
 Containers: 17
  Running: 16
  Paused: 0
  Stopped: 1
 Images: 17
 Server Version: 26.1.1
 Storage Driver: btrfs
  Btrfs:
 Logging Driver: local
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 926c9586fe4a6236699318391cd44976a98e31f1
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  apparmor
 Kernel Version: 4.4.302+
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 15.48GiB
 Docker Root Dir: /volume1/@docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false
 Product License: Community Engine


Added missing self.client references. Fixes #7.

References to self.get_all were failing because they needed to be to self.client.get_all.
This caused errors when using, for instance get_item_children.
This pull request solves that issue (reported as #7).

Looks great, thanks for your contribution


Added feature "Rock Paper Scissors

Added Rock paper scissor
Added in main home page
fixed issue #243

mention the issue no

already mention

Can u plse check and merge

?

there is a conflict resolve it


UI issue fixed for small tablets

UI issue fixed for small tablets.

Handling the font issue separately.


Added note about class from guzzle.client.*

Q
A

Bug fix?
[no]

New feature?
[no]

BC breaks?
[no]

Deprecations?
[no]

Tests pass?
[no]

License
MIT

Great! Thanks for your contribution!


Toggle handleSelect is triggered upon rendering

I noticed that the handleSelect in the Toggle component is triggered when the component is rendered. I've got the following Toggle inside a ReactModal and as soon as the modal is opened the handleSelect triggers, causing unwanted API requests. I'm not completely sure if I'm making a mistake somewhere so I'm wondering if more people have noticed this behaviour.
<Toggle defaultValue={"2"} color="emerald" handleSelect={(value) => postMood(value)}>
                    <ToggleItem value={"1"} text="Great"/>
                    <ToggleItem value={"2"} text="Okay"/>
                    <ToggleItem value={"3"} text="Bad"/>
</Toggle>

Hi @StefBrands, do you mind sharing the complete code snippet? The bug may be rooted in the postMood() handler.

Of course:
async function postMood(mood) {         console.log(mood)         more api stuff here         }
Logging as soon as it enters postMood() shows output when the modal gets opened.

hm yeah you're right, that shouldn't be the case. Will try to fix this as soon as possible. Thanks for pointing it out!

hey @StefBrands, the issue should be fixed with the new release v1.0.12.

hey @StefBrands, the issue should be fixed with the new release v1.0.12.

Working great now @mitrotasios! Great job, super fast

thanks for using our library and being so involved :)


Slower than encoding/json at all levels of GOMAXPROCS (8 cores, i7 macbook pro 16gb ram)

All, my results of running benchmarks against ffjson and encoding/json show that ffjson does not meet the claims of being 2-3x faster than encoding/json; and, in-fact, is much slower.
Should the documentation be revised, or did I do something 'wrong'?

type Message struct {
	Message string `json:"message"`
}

func Encode(item interface{}, out io.Writer) {
	// Encode
	buf, err := ffjson.Marshal(&item)
	if err != nil {
		log.Fatalf("Error: %+v\n", err)
	}

	// Write the buffer
	_, _ = out.Write(buf)

	// We are now no longer need the buffer so we pool it.
	ffjson.Pool(buf)
}

func encoderFunction(b *testing.B) {
	for i := 0; i < b.N; i++ {
		w := httptest.NewRecorder()
		_ = json.NewEncoder(w).Encode(&Message{helloWorldString})
	}
}

func ffencoderFunction(b *testing.B) {
	for i := 0; i < b.N; i++ {
		w := httptest.NewRecorder()
		Encode(&Message{helloWorldString}, w)
	}
}

func marshalFunction(b *testing.B) {
	for i := 0; i < b.N; i++ {
		w := httptest.NewRecorder()
		a, _ := json.Marshal(&Message{helloWorldString})
		w.Write(a)
	}
}

func ffmarshalFunction(b *testing.B) {
	for i := 0; i < b.N; i++ {
		w := httptest.NewRecorder()
		a, _ := ffjson.Marshal(&Message{helloWorldString})
		w.Write(a)
	}
}

func main() {

    // numProcs := runtime.NumCPU()
    numProcs := 1
    runtime.GOMAXPROCS(numProcs)
    log.Println("GOMAXPROCS: ", numProcs)

	ffmf := testing.Benchmark(ffmarshalFunction)
	ffef := testing.Benchmark(ffencoderFunction)
	mf := testing.Benchmark(marshalFunction)
	ef := testing.Benchmark(encoderFunction)

	log.Println("encoding/json Marshal Function: ", mf)
	log.Println("encoding/json Encoder Function: ", ef)

	log.Println("ffjson Marshal Function: ", ffmf)
	log.Println("ffjson Encoder Function: ", ffef)
}

main_ffjson.go:
// DO NOT EDIT!
// Code generated by ffjson <https://github.com/pquerna/ffjson>
// source: ./main.go
// DO NOT EDIT!

package main

import (
	"bytes"
	"fmt"
	fflib "github.com/pquerna/ffjson/fflib/v1"
)

func (mj *Message) MarshalJSON() ([]byte, error) {
	var buf fflib.Buffer
	err := mj.MarshalJSONBuf(&buf)
	if err != nil {
		return nil, err
	}
	return buf.Bytes(), nil
}
func (mj *Message) MarshalJSONBuf(buf fflib.EncodingBuffer) error {
	var err error
	var obj []byte
	_ = obj
	_ = err
	buf.WriteString(`{"message":`)
	fflib.WriteJsonString(buf, string(mj.Message))
	buf.WriteByte('}')
	return nil
}

const (
	ffj_t_Messagebase = iota
	ffj_t_Messageno_such_key

	ffj_t_Message_Message
)

var ffj_key_Message_Message = []byte("message")

func (uj *Message) UnmarshalJSON(input []byte) error {
	fs := fflib.NewFFLexer(input)
	return uj.UnmarshalJSONFFLexer(fs, fflib.FFParse_map_start)
}

func (uj *Message) UnmarshalJSONFFLexer(fs *fflib.FFLexer, state fflib.FFParseState) error {
	var err error = nil
	currentKey := ffj_t_Messagebase
	_ = currentKey
	tok := fflib.FFTok_init
	wantedTok := fflib.FFTok_init

mainparse:
	for {
		tok = fs.Scan()
		//	println(fmt.Sprintf("debug: tok: %v  state: %v", tok, state))
		if tok == fflib.FFTok_error {
			goto tokerror
		}

		switch state {

		case fflib.FFParse_map_start:
			if tok != fflib.FFTok_left_bracket {
				wantedTok = fflib.FFTok_left_bracket
				goto wrongtokenerror
			}
			state = fflib.FFParse_want_key
			continue

		case fflib.FFParse_after_value:
			if tok == fflib.FFTok_comma {
				state = fflib.FFParse_want_key
			} else if tok == fflib.FFTok_right_bracket {
				goto done
			} else {
				wantedTok = fflib.FFTok_comma
				goto wrongtokenerror
			}

		case fflib.FFParse_want_key:
			// json {} ended. goto exit. woo.
			if tok == fflib.FFTok_right_bracket {
				goto done
			}
			if tok != fflib.FFTok_string {
				wantedTok = fflib.FFTok_string
				goto wrongtokenerror
			}

			kn := fs.Output.Bytes()
			if len(kn) <= 0 {
				// "" case. hrm.
				currentKey = ffj_t_Messageno_such_key
				state = fflib.FFParse_want_colon
				goto mainparse
			} else {
				switch kn[0] {

				case 'm':

					if bytes.Equal(ffj_key_Message_Message, kn) {
						currentKey = ffj_t_Message_Message
						state = fflib.FFParse_want_colon
						goto mainparse
					}

				}

				if fflib.EqualFoldRight(ffj_key_Message_Message, kn) {
					currentKey = ffj_t_Message_Message
					state = fflib.FFParse_want_colon
					goto mainparse
				}

				currentKey = ffj_t_Messageno_such_key
				state = fflib.FFParse_want_colon
				goto mainparse
			}

		case fflib.FFParse_want_colon:
			if tok != fflib.FFTok_colon {
				wantedTok = fflib.FFTok_colon
				goto wrongtokenerror
			}
			state = fflib.FFParse_want_value
			continue
		case fflib.FFParse_want_value:

			if tok == fflib.FFTok_left_brace || tok == fflib.FFTok_left_bracket || tok == fflib.FFTok_integer || tok == fflib.FFTok_double || tok == fflib.FFTok_string || tok == fflib.FFTok_bool || tok == fflib.FFTok_null {
				switch currentKey {

				case ffj_t_Message_Message:
					goto handle_Message

				case ffj_t_Messageno_such_key:
					err = fs.SkipField(tok)
					if err != nil {
						return fs.WrapErr(err)
					}
					state = fflib.FFParse_after_value
					goto mainparse
				}
			} else {
				goto wantedvalue
			}
		}
	}

handle_Message:

	/* handler: uj.Message type=string kind=string */

	{

		{
			if tok != fflib.FFTok_string && tok != fflib.FFTok_null {
				return fs.WrapErr(fmt.Errorf("cannot unmarshal %s into Go value for string", tok))
			}
		}

		if tok == fflib.FFTok_null {

		} else {

			uj.Message = string(fs.Output.String())

		}
	}

	state = fflib.FFParse_after_value
	goto mainparse

wantedvalue:
	return fs.WrapErr(fmt.Errorf("wanted value token, but got token: %v", tok))
wrongtokenerror:
	return fs.WrapErr(fmt.Errorf("ffjson: wanted token: %v, but got token: %v output=%s", wantedTok, tok, fs.Output.String()))
tokerror:
	if fs.BigError != nil {
		return fs.WrapErr(fs.BigError)
	}
	err = fs.Error.ToError()
	if err != nil {
		return fs.WrapErr(err)
	}
	panic("ffjson-generated: unreachable, please report bug.")
done:
	return nil
}

"much slower" is rather an overstatement.  First of all use real-world data, a single string isn't going to tell you much.
Also, I don't think the ffjson code is actually included in your build. The ffjson must be generated before you build your executable.
I revised the encoder a bit: https://gist.github.com/klauspost/0aacfc0cbb9eee99b9db

Don't use ffjson generated types for testing encoding/json.
Reduce allocations, so it doesn't give noise to the benchmark
Use the encoder function
Check errors
Use the "Fast" functions. Performance will be the same, but you will get an error if ffjson isn't generated.

With that, I get this on my machine:
encoding/json Marshal Function:   1000000             2687 ns/op
ffjson Marshal Function:   1000000            1937 ns/op

encoding/json Encoder Function:   1000000             2031 ns/op
ffjson Encoder Function:    500000            2531 ns/op

The ffjson code was generated before the build, of course. Good catch on the usage of the ffjson methods in the encoding/json benchmarks, though!
I didn't test the ffjson Encoder, but rather the README Encode func, but it seems that the Encoder func you used closed the performance gap from ~50% slower to ~25% slower.
MarshalFast seems like the way to go, as it's around 38% faster on your machine.
Ffjson is a really interesting and fun project; however, the claims are "2-3x" faster, which are false. Additionally, the tuned encoder methods are still 25% slower.
Thoughts on either addressing the performance or documentation?

The performance numbers are inline for 'real world' structures, eg goser:
https://github.com/pquerna/ffjson/blob/master/tests/goser/ff/goser.go
and go.stripe:
https://github.com/pquerna/ffjson/blob/master/tests/go.stripe/ff/customer.go
I'm happy to add more structures -- ideally ones used in real world projects -- to the test suite to keep up to date benchmarks.

Ah yep, I'd just amended the comment above; I'll play around with those this evening. Maybe that should be mentioned in the docs, though.
Right now, the README mentions that we should ffjson all the things and shows an example which is similar to mine.

The ffjson code was generated before the build, of course,

Then something else is wrong, because using your code yields:
encoding/json Marshal Function:    200000         5000 ns/op
ffjson Marshal Function:   1000000        2312 ns/op

encoding/json Encoder Function:    300000         4635 ns/op
ffjson Encoder Function:    500000        2593 ns/op

But that would be dishonest, since it disfavours encoding/json (therefore the XMessage struct).

MarshalFast seems like the way to go, as it's around 38% faster than the encoding/json Marshal on your machine.

As I wrote, and as written in the docs, MarshalFast is the same speed as Marshal, it only checks if the struct can be unmarshalled fast and then calls Unmarshal.

Right now, the README mentions that we should ffjson all the things and shows an example which is similar to mine.

No. You encode a string in a struct. The example encodes a struct in a struct.

Don't know what to tell you about the code and the results disparity; I ran my bench a couple times today and got very similar results.

For what it's worth, here's what I get running @klauspost's version with current master:
2015/05/31 18:12:08 GOMAXPROCS:  1
encoding/json Marshal Function:   1000000	      1994 ns/op
ffjson Marshal Function:   1000000	      1630 ns/op

encoding/json Encoder Function:   1000000	      1876 ns/op
ffjson Encoder Function:    500000	      2198 ns/op

I agree though that the unqualified claims of 2-3x speed up are a bit misleading.

oldie% ./tests
2015/09/08 14:19:49 GOMAXPROCS:  1
2015/09/08 14:19:56 encoding/json Marshal Function:   1000000         1477 ns/op
2015/09/08 14:19:56 encoding/json Encoder Function:   1000000         1452 ns/op
2015/09/08 14:19:56 ffjson Marshal Function:   2000000         714 ns/op
2015/09/08 14:19:56 ffjson Encoder Function:   1000000        1634 ns/op
oldie [./tests] INS| ~/tmp/tests
oldie%

There is a bug in the Encode function, you pass a *interface{} to ffjson.Marshal which probably triggers a fallback to a standard json.Marshal. This is why the Encoder results are so slow.
You could easily see it if you used ffjson.FastMarshal instead of ffjson.Marshal.
Anyway, the fixed Encode functions looks as follows:
func Encode(item interface{}, out io.Writer) {
    // Encode
    buf, err := ffjson.Marshal(item) // <--- passing the interface as is
    if err != nil {
        log.Fatalf("Error: %+v\n", err)
    }

    // Write the buffer
    _, _ = out.Write(buf)

    // We are now no longer need the buffer so we pool it.
    ffjson.Pool(buf)
}

And the results I get are:
$ go run main.go
2016/02/02 09:47:04 GOMAXPROCS:  1
2016/02/02 09:47:11 encoding/json Marshal Function:   1000000	      1459 ns/op
2016/02/02 09:47:11 encoding/json Encoder Function:   1000000	      1453 ns/op
2016/02/02 09:47:11 ffjson Marshal Function:   2000000	       714 ns/op
2016/02/02 09:47:11 ffjson Encoder Function:   2000000	       662 ns/op

Excellent digging @korya

@korya  Damn, nice find!

I'm also observing better performance on newer versions of Go (tested on go1.6.2 darwin/amd64):
This is a simple testing (1 million times) loop result:
Interface:	  1000000	      1237 ns/op
Struct:        2000000	       930 ns/op

This is with 1.6 built-in encoding/json:
Interface:	  1000000	      1193 ns/op
Struct:        2000000	       899 ns/op

Maybe this is something that happened over time from many tweaks Google themselves have done to the JSON-decoder? The differences aren't dramatic, but if the 2-3x claim was true 2 years ago I can imagine that maybe back then it was valid, but over time Go's core code has caught up.


istiod helm chart is missing a configuration for topologySpreadConstraints

Describe the feature request
The helm chart for istiod does not allow configuring topologySpreadConstraints for the istiod pods.  Installing a high availability control plane is easier when spreading istiod instances across nodes and zones.
I suggest copying the way this is done for the gateways in that helm chart.
Describe alternatives you've considered
N/A
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[x] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

https://istio.io/latest/docs/setup/additional-setup/customize-installation-helm/

fixed in https://github.com/istio/istio/pull/45175


Running on Apple Silicon M1

Bug Description
Using the recommended command line input to start an image
docker run -d -p 8080:80 -p 8021:21 -p 8022:22 -v $HOME/q2galaxy_data/:/export/ quay.io/qiime2/q2galaxy
results in a warning
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
furthermore it seems to prevent exposure of port 8080 on the localhost.
Steps to reproduce the behavior

Follow the docker steps in the README for Docker setup up to the last terminal command.
While running macOS on a M1 chip go to terminal.
Run docker run -d -p 8080:80 -p 8021:21 -p 8022:22 -v $HOME/q2galaxy_data/:/export/ quay.io/qiime2/q2galaxy
See error WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Expected behavior
I expected the docker image to be created successfully.
Computation Environment

OS: [macOS Sonoma 14.1.1]
QIIME 2 Release [2024.2.1]

Fix

Run this command to start the container instead (added --platform linux/amd64)
docker run --platform linux/amd64 -d -p 8080:80 -p 8021:21 -p 8022:22 -v $HOME/q2galaxy_data/:/export/ quay.io/qiime2/q2galaxy

References

Where I found the fix

Thanks @nikothomas! I've updated the readme with your suggestion: https://github.com/qiime2/q2galaxy/commit/c837f392bb4ec27cea21f49c53afe5dd8f207826


Bug: HeadingNode isn't automatically registered by RichText

When you include the markdown plugin, its unable to create a heading node because it isnt registered. It seems like this should happen automatically, but it doesn't:

The docs are really bad, the error says to register custom nodes but no doc page explains this. Figured it out looking through the playground source code.
Lexical version: 0.3.2
Steps To Reproduce

Add rich text + markdown plugin
Type ## Test into the editor and you will see the error message

Link to code example:
Broken Code sandbox: https://codesandbox.io/s/lexical-plain-text-example-forked-ssqvu8
Fixed code sandbox: https://codesandbox.io/s/lexical-plain-text-example-forked-g4z24m
The fix is adding:
  nodes: [HeadingNode]

But this isn't described in the docs, and I would expect HeadingNode to be auto registered by Rich Text?

The HeadingNode is a custom node though, it's just one provided for you via a package. A custom node is a node that isn't exported from the core Lexical package.

Could I add documentation to explain that if you want to use the rich text or markdown plugins you need to register its custom nodes?
Just seems so weird to have a markdown plugin where it throws errors when you include it. Is there any way to auto register?

There is no way to auto register. You need to be specific, especially as in the future we're likely to open up ways to provide a way to over-ride the default nodes (like HeadingNode) with custom versions for specific use-cases.

Could I add documentation to explain that if you want to use the rich text or markdown plugins you need to register its custom nodes?

Please do, that would be awesome :)


update submodule console

Signed-off-by: bin liu<EMAIL_ADDRESS>
Description

Related Issue

Motivation and Context

Screenshots (if appropriate)
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.

Codecov Report

Merging #1908 (11560cf) into main (9cb65d7) will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1908      +/-   ##
==========================================
+ Coverage   43.09%   43.14%   +0.05%
==========================================
  Files         132      132
  Lines       16979    16979
==========================================
+ Hits         7317     7326       +9
+ Misses       9107     9099       -8
+ Partials      555      554       -1

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
43.14% <ø> (+0.05%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/daemon/peer/peertask_conductor.go
57.64% <0.00%> (+0.64%)
:arrow_up:


Remove 'Hawkular' from local-dmr resource-type-sets.

This set is to read the hawkular wildfly agent (subsystem).
Since we are using javaagent, its not needed here.

What about the EAP6 feature pack? See https://github.com/hawkular/hawkular-agent/blob/master/eap6-support/hawkular-javaagent-wildfly-feature-pack-eap6/src/main/resources/featurepack/content/standalone/configuration/hawkular-javaagent-config.yaml#L1252

Totally forgot EAP6 feature pack existed :+1:

Updated, thanks


Nonce issue

Hi,
I am seeing the same issue for the past 2/3 days now:
Transaction gas price is too low. There is another transaction with same nonce in the queue. Try increasing the gas price or incrementing the nonce.
I tried to change the gas price to 200k so it wont be that.  Tried many times over the past 48 hours to send different transactions.
Seems like a nonce issue.  I think there is a stuck transaction which is messing up the nonce sequence on my wallet.
Please can you look at this,  also sent an email to support.
Thanks

Closing this for inactivity.


Making GET_ACCOUNTS permission optional

The statement below (inside AssemblyInfo.cs) is not needed for devices higher 4.0.3
[assembly: UsesPermission(Name = "android.permission.GET_ACCOUNTS")]
Maybe making it optional by device version is the best option?
Since it is a pretty "eyebrow raising" permission, might make users worry about their private data.

+1


Can't create a public Marketplace [dep on N Badges]

User Impacted
0xBf17bE25a18c2F45fe4A8702b92B8dBd77872561
Discord ID (including number)
elisemarika#8643
Workflow Impacted
Analyze
Feature Impacted
Create Marketplace
Issue description
Who has permission to launch challenges?

this section only allows me to select Delegates only
this section should also include a dropdown option for Anyone which allows anyone to launch challenges and the Badger Contract Address and Badger Token ID inputs aren't needed for this selection

Blocking
yes it is
Relevant log output
No response

Ed: the more elegant workaround is a toggle to say "public" which does that behind the scenes
Mason: Effort for a toggle is 20 minutes, very very low effort I just was under the impression everything was Badge gated
Ed: can build that UI real quick

@masonchain curious if that toggle support is ready for app team?

The whitepaper did not have plans for a public toggle, as there are better solutions, and it adds additional bloat to the cost of every user. Instead, the recommendation and plan were just a marketplace with a zero balance / not-configured badge setup.
The balance required just needs to be set to zero and then it's public.

As a temporary workaround, the upcoming v1.6.0 of the Labor Markets primitive can have a LaborMarket created with the delegate badge set to the zero address. Token ID does not matter, but when this badge is set to the zero address, anyone can create a request on the marketplace.
  delegateBadge: LaborMarketConfigurationInterface.BadgePair({
      token: address(0),
      tokenId: DELEGATE_TOKEN_ID
  }),

Status report: In the process of finalizing NBadge a contract update was required for Badger.
In preparation for the audit, a final feature-add is taking place for Badger, and then N-Badge will be ready to support. All code for N-Badge has been completed and finalized (as a model), and only resolving dependency issues remain.

closing as duplicate to #362


fix: controller function and added new api end point

added new controller
fixed prev api response

Check that i.phone is necessary or not in officials .go file if not we can remove it

i.phone wont work so i fixed it


Can we save the current worksheet as a vector graph?

Describe the feature
This control is awesome, and it perfectly implements most of my functions. However, when I try to save the current worksheet as a vector map, I don't know what to do. Is there any way to save the current sheet as a vector map or a bmp image?
Thank you!
Which edition of ReoGrid is targeted

Windows Form

I found that I can save the current visible view as an image through the DrawToBitmap implementation, but what I want is to save the specified cell area as an image, and if it exceeds the current page (with scroll bars), it can also be saved. (A long screenshot)

I don't think the feature could be implemented, there is many elements to be considered such as outline, freeze, etc..