Reorganization

Here is the "complete" log of the changes I think I made.  Sorry for the extend of this pull request.  I had to go a bit deeper than I hoped to get rid of that dead layer.  Unfortunately, with a multi month refactor like this, I tend to fix stuff I run into just because I won't be able to track of the whole list of TODOs.  But after one false start I managed to land it with a working test bench once more.  Now lets see what breaks on other architectures.
Ignoring the comments and the extra project files it should actually be a much smaller code base.
Module _jpype changes:

Moved python module objects to namespace PyJP so that they are consistent with a python module namespace.  Renamed module classes presented to  _jpype extension to PyJP* to match the internal classes.  Though not exactly a standard convention, the types were internal anyway and having the names match the C structure makes it more clear what resource is being  accessed.  It also eliminates the confusion between jpype and _jpype resources.
Removed all usage of Capsule from the extension module. This was bridging between python versions and had to be replicated on old platforms.  As the capsules were functioning as crippled objects, they could not have methods of their own.  Thus functionality that properly belonged to a specific class would get pushed to the base class.  This affected former capsules of JPObject, JPProxy, and JPArray.  These are now formal classes in the module as PyJPValue, PyJPProxy, and PyJPArray.
Moved the initialization of each class to the __init__ function.  Thus rather than creating the resource at the top level _jpype module (such as  _jpype.findClass('cls')), the resource is created by allocating a new  object (such as _jpype.PyJPClass('cls')).
The presentation of JPArrayClass has been merged as a generic JPClass.   The only requirement for creation of an array instance is that the supplied  PyJPClass satisfy isArray().
Removed direct dependencies that objects holding resource be exactly the type in jpype module.  This reduces the restrictions in the underlying  python layer and allows for multiple classes such as JavaArray, JWrapper, and JavaClass to all be recognized as holding resources.  This simplifies some paths in the jpype module where we needed to simply access a single method during bootstrapping and we were forced to construct complete classes necessitating the order of resource loading.
Remove JPObject concept and replaced it with JPValue.  JPValue holds the type of the object and a jvalue union.  Both JavaClass and JWrapper now point to these classes as __javavalue__.  Anything with a  __javavalue__ with type _jpype.PyJPValue is now recognized as being a  java object.
Changed the recognization of a JavaClass to any object holding __javaclass__ with type _jpype.PyJPClass.  This allows array classes, object classes, and wrappers classes to be used together.
Added hooks to direct convert PyJPClass to a PyJPValue with a type of java.lang.class and an object to the class. This replaces the need for calling forName to get to the existing class.
Changed PyJPField and PyJPMethod to descriptors so that we do not need to mess with  __getattribute__ and __setattr__ in many places.
Eliminated the unnecessary class bound method.

C++ Reorg:

Reorganized the type tree in the C++ layer to better match the Java  structures.
Flattened out the redundant layers so that JPType is now JPClass corresponding to an instance of a jclass.
JPClass is not the base class.  Arrays are now objects and have  base classes and methods.
Split JPClass into a separate type for each specialized object class for boxed, java.lang.Object, and java.lang.Class which all required specialized conversion rules.
Boxed, string, base java.lang.Object and base java.lang.Class are now specialized with their required conversion rules.

Path reduction:

Removed HostRef and all of its usage.  It was a halfway memory management method.  To be passed around it was being held as a dynamically allocated pointer type with no static presence for cleanup.  This defeats the point of having a smart point wrapper if the smart pointer is being used as a pointer itself.  Thus it was only as safe as the user applied conventions rather than safe by design.
Replaced all the HostRef methods and JPy* Python object wrappers with a new smart pointer concept (namespace JPPy).  This removes the redundant host and JPy* wrapper layers.
Removed multiple optimization paths such as bypassing between jchar and unicode if the size matched.  These paths were for speed reasons, but they could only be tested on particular machines.  Thus it was difficult to tell if something was broken.  It is better to have one tested code path that is slight slower, then a faster path that is busted.
Removed dead class JPCharString.
(bug) Replaced all string handling with conversion through UTF8.  Java and python use different UTF8 encodings and thus those paths that were trying to short cut directly through from one system to another were badly flawed. By forcing a conversion to and from each time a java string or python string are passed eliminates conversion problems.  This should resolve user issues having to do with truncating extended unicode characters.
Combined all code paths in canConvertToJava and convertToJava to use the JPValue
Combined code paths from check and get for JPValue, JPClass and JPProxy get patterns when fetching from python.  Almost always we want to use the object immediately and just check if we can.
Removed the entirely redundant Primitive type setRange and getRange. That code was entirely dead because it could not be reached. Renamed the direct methods as they now have the same function.
Removed JPTypeName.  This concept will be phased out to support lambdas. TypeManager now used getCanonicalName(). Transferred responsibility for conversion to native names to python module  interface.
Introduced named classes for all specialized instances of classes to be held in TypeManager namespace. Thus converted most of the "is this type" to  comparison of JPClass* pointers in place of string level comparisons.
Removed near duplicate methods.  JProxy was requesting slightly altered copies of many conversions to support its usage.  These operations could be supported by just splitting to two existing methods.  Thus we could eliminate a lot of stray methods that served this specialized purpose.
JPArray is now a method holder rather than the primary object like JPBoundMethod.  All array objects in python now hold both a __javaarray__ and a __javavalue__.  This eliminates need for special paths for  arrays.
_getClassFor is now overloaded to work with array classes.  Thus asking for a JClass('[java.lang.Object;') will now correctly  return a JavaArrayClass.
Constructing a string now shortcuts to avoid methodoverload on new instance if given a Python string.
Reworked the GIL handling.  The previous model was doing all the release locks on the JPJni calls automatically for almost all jni transactions. This would be fine, except that many utility functions were using those same calls regardless of whether is was a good time to release the lock.  This ultra fine grain locking was effectively allowing any call to JPJni methods to become a break point, including those calls in critical sections such as ensureTypeCache and TypeManager::findClass.  Any time it loaded a class or looked up a name it could be interrupted and thus end up in a corrupt state. Thus I moved all of the GIL calls to those places where we call user code on the type returns and the object constructors.  Thus cuts the number of GIL  transactions greatly and eliminates the need to deal with trampling global  resources.  The refactor exposed this a bit more because the removal of TypeName meant that we did a lot more transactions to get the class name. But that does not mean the flaw was not there before.  If our tests cases had been any more aggressive about creating class instances during execution it would have overrun the TypeManager table and all would have failed.
Removed the previous default option to automatically convert java.lang.String to either a python string or a unicode when returning from java.  This does mean some string operations now require calling the  java string method rather than the python one.  Having strings not convert  but rather remain on the jvm until needed cuts the conversion costs when  working with java heavy code.  I added a caching mech so that if we need to  convert the string multiple times, we don't pay additional over the previous option.
A special toString method was added to PyJPValue to convert java strings to python strings. This can convert java string resources to  python ones on request.

Proxy changes:

Proxy as implemented previously held only a pointer to the proxy object  and from this proxy object it lookup up the callable using either a  dictionary or an instance.  The majority of the resources were held  by the jpype.Proxy.   This was replaced with a more general function in which the PyJPProxy proxy holds two resources.  One is an object instance and the other is a lookup function that turns the name to a function definition. This supports the same use cases but eliminates the need for finding resources by convention.  There is no need for the proxy in Python to have any specific layout other than holding a PyJPProxy as __javaproxy__.  Thus allowing alternive structures  such as Proxy by inheritance to work.
Memory handling was changes slightly as a result so that the reference queue is now responsible for cleaning up the proxy.  Proxy handle instances are generated whenever the proxy is passed to java.  Thus we form no counting loops as the proxy has no reference to the handles and the handles hold a reference to the proxy.

Exception changes:

Changed all exception paths to use JPypeException exclusively.  The prior system did way to much in the Exception constructors and would themselves crash if anything unusual happened making changing of the system nearly prohibitive to debug.  Everything bubbles down to toJava and toPython where we perform all the logging and pass the exception off.  This also centralizes all the handling to one place.
This pulls all the logic from JPProxy so that we can now reuse that  when returning to any java jni native implemented function.
Same thing for Python, but that was already centralized on rethrow.
Reworked exception macros to include more info and introduced JPStackInfo. It may be possible to connect all the stack info into the Python traceback  (via a proxy class) to present a more unified error reporting.  But this work is currently incomplete without a python layer support class.
Integrated JPStackInfo into tracer to give more complete logs when debugging.

Code quality:

Applied a source formatter in netbeans.  It is not perfect as it tends to  add some extra spaces, but it does make faster work of the refactor.  Custom spacing rules were applied to netbeans to try to minimize the total changes in the source.
Improved error handling where possible.
Rework JPTracer so that reporting from places that do not have a formal frame or could not properly throw (such as destructors) and still appear in the trace log.  All TRACE macros were moved to JP_ so that were less likely to hit conflicts.  Removed guards that complete disabled Tracer from compiling when TRACE was not enabled so that unconditional logging for serious failure such as suppressed exceptions in destructors can report.
Defensively added TRACE statements whenever entering the module for a nontrivial action so that errors could be located more quickly.
Removed MTRACE layer as Java local frame handles all cleaning tasks for that now.

Renamed functions to best match the documented corresponding function in	the language it was taken from.  Thus making it easier to find the needed documentation.  (Ie  JPyString::isString() becomes JPPyString::check() if the corresponding language concept is PyString_Check()).  This does mean that naming is mixed for the Java/Python layers but it is better to be able to get the documentation than be a naming idealist.
Used javadoc comments on header of base clases.  These strings are picked up by netbeans for document critical usage.
Moved method implementations and destructors out of headers except in  the case of a truly trivial accessor.  This has a small performance loss because of removal of inline option.  This reduces the number of redundant implementation copies at link time and ensures the virtual destructor is fixed in a specific object.  We can push those back to the  header if there is a compelling need.

Documentation changes:

Documentation of major class methods have been added as well as marker whereever the underlying assumptions are not reasonably transparent.
Action items for further work have been marked as FIXME for now.

Module jpype changes:
Because these do affect the end user, we have marked them as enhance, change, remove, bug fix, or internal.
General:

(enhance) Static methods and fields are now accessible from an object instance.  Appropriate exceptions are issued if attempting to operate on a static member without an object instance.
(enhance) __all__ added to all modules so that we have a well defined export rather that leaking symbols everywhere. Eliminated stray imports in the jpype namespace.
(enhance) Add @deprecated to _core and marked all functions that are no longer used appropriately.  Use -Wd to see deprecated function warnings.
(enhance) Exposed JavaInterface, JavaObject, JavaClass so that they can be used in issubclass and isinstance statement.  JavaClass.__new__ method was pushed to factory to make it safe for external use.
(enhance) mro for Java Classes removes JavaInterface so that issubclass(cls, JavaInterface) is only true if the class not derived from JavaObject.
(enhance) All classes derived from java.lang.Throwable are now usable as thrown exceptions.  No requirement to access special inner classes with exception types.  Exceptions can be raised directly from within a python context to be passed to java when in proxy.  Throwables now  use a standard customizer to set their base class to the python Exception tree. Deprecated JException
(enhance) args is a property of java.lang.Throwable containing the  message and the cause if specified.
(enhance) JChar array now converts to a string and compares with string properly.  Conversion uses range so that it does not try to convert character by character.
(remove) JByte array is not a string type.  It is not a string in java and should not be treated as a string without explicit conversion. Conversion path was horribly inefficient converting each byte as a python object.  Test marked as skip.
(change) Array conversion errors produce TypeError rather than  RunTimeError.
(enhance) JArray now supports using raw python types as the specifier for array types.  It will convert to the most appropraite type or return an  error.
(remove) property conversion customizer is deactivated by default.  This one proved very problematic.  It overrided certain customizers, hid intentionally exposed fields, bloated the dictionary tables, and interferred with the unwrapping of exception types.  We can try to make it an optional system with import jpype.properties or some such but it will still have all those problems.  Best to kill this misfeature now.
(enhance) JArray classes now have class_.  We can access the component type.  This makes them more consistent with JClass.  (required for testing)
(enhance) Use of constructor call pattern eliminated the need for use of a separate factory and type.  Thus we are back to the original design in  which we only need to expose a small number of "types".  This was applied to  JArray, JClass, JException, and JObject.  Use of isinstance() and issubclass now supported. The only challenge was keeping box types working.
(remove) Functions that return a string now return a java.lang.String rather than converting to Python.  Thus when chaining elements together in java will get the full benefit matching types.  The previous auto convert has been removed.
(enhance) java.lang.String now has much more complete set of python  operations.  String conversions are now cached, so the penalty of  converting is kept to a minimum.
Tried to be more consistent about returning errors that are valid in python.

Too many or two few arguments to a function will throw a TypeError
Value conversion out of range will throw OverFlowError
Value conversions that are the right type but invalid value will
give ValueError (char from string too long)
Type conversions that cannot be completed should give TypeError.
Errors setting attributes should give AttributeError such as trying to set a final field or trying to get an instance field from a static object.
Arrays access should produce IndexError on bad range.
(it would be nice if these also mapped to java errors and the corresponding errors in java were derived from the python error so that we can properly look for ArrayIndexOutOfBoundsException (derived from IndexException).  But  that is too heavy to attempt now.)

Wrappers:

(internal) Rewrote the JWrapper module from scratch to reflect the use of JPValue.  Renamed _jwrapper to _jtypes.  The concept of wrappers has now been lost internally.  All objects and primitives are just values.
(enhance) Created import module containing all of the symbols needed for creating types in jpype so that we can support a limited import statement from jpype.types import *
(enhance) JString contructor now returns a java.lang.String object.  Removed JStringWrapper as java.lang.String serves its purpose.
(enhance) JObject now returns an object with the java type as a functional object rather than a dead end wrapper.  This does allow some redundant  things such as converting a python class wrapper into a class  JObject(java.lang.String) == java.lang.String.class_ but otherwise seems good.
(enhance) 'JObject' and 'JString' accept 0 arguments to generate a generic object and empty string.
(enhance) JArray, JException and JObject report as JavaClass when  using issubclass.

Internal:

(internal) Changes corresponding to the __init__ rework to match revised PyJP* classes.
(internal) Changes corresponding to the capsule removal.
(internal) Remove SPECIAL_CONSTRUCTOR_KEY as everything that uses it can recognize a PyJPValue as indicating they are receiving an existing java resource as input.  All special handling required to construct objects from within C++ layer were thus eliminated.
(internal) Removed almost all required resources from python needing to be register in _jpype with the exception of getClassMethod.
(internal) Java class customizers did not need to be deferred until after the JVM is initialized.  Pushing them into the dictionary immediately fixes issues in which a customizer was not applied to classes during early bootstrapping.  This eliminates a large number of the need for calling initialize on each jpype module in _core.
(internal) JArrayClass and JClass are the same for purposes of  Customizers and class tree.
(internal) Customizer code and dictionary moved to _jcustomizer so that it can be shared between Object and Array classes.
(internal) Converted JavaClass to more python like "try first, eat an exception if it fails" philosophy to increase robustness to failure.  This eliminates the problems when a new base class is introduced with a  customizer without setting up a meta class.
(internal/enhance) Broke connections between boxed types and wrappers.  User supplied wrappers can implements specified "Value" method. Wrapper types now have similar methods to boxed types with appropriate range checks.
(internal) All $Static meta classes have been eliminated.  There is now only one tree of classes.  A single meta class JClass serves as the type for all classes.
(intenal) Short cut for just adding a base class as a customizer.

Bugs:

(bug fix) Fixed bug in jpype.imports in which it would not install its  hooks if loaded afer the jvm was started.
(bug fix) Fixed bug in JBoxed type wrappers in python which would lead
java.lang.Double and java.lang.Float to have an integer value when boxed was corrected.
(bug fix) Fixed bug in JObject that was preventing classes from being  wrapped as objects.  Verified a number of test cases in the test suite.
(bug fix) Reenabled the throw from java test during proxy.  The issue was  that jpype was releasing resources before it could transfer control  a PyErr_Clear removed the reference and thus our throwable was invalid.  It was dastardly to find, but the fix was moving a statement one line up.

TODO:

[ ] Finish specialization of JPArray classes for byte[] and char[]
[ ] Read the user manual and revise accordingly.
[ ] Deal with fast array conversions misuse of types. int[]<=>float[]
[ ] Direct bridge methods for char[] are currently bypassing the unicode
translation layer.  It is unclear what Java does with extended unicode
when dealing with char[].
[ ] Add a system to register a translation customizer so that we do not need to
modify C++ code to add new simple translations like python date to java
Instant.  These would be installed into the PyJPClass during class
wrapper customization. We will need to make sure each class has a Python
type wrapper cached in ensureTypeCache so we are guaranteed to find
the conversion.
[ ] Use translation customizer to merge numpy basic data types into
primitive conversions.
[ ] Revise proxy to use implements.  (Assuming someone ever responds to the
issue posting.)
[ ] Add tests for Exception.args
[x] Reenable lost "synchronized" command

wow, very impressive! I'm kind of underwater right now, so the review of this will take some time - sorry.

Not to worry.  I still have to get it working on the CI.  Oddly none of the 4 that I test on are displaying that segfault.  It seems like it is a shutdown bug so I will start there.  Once I get done with that I will start on phase 2 of the refactor which is gutting the JNI, moving to a class loader, etc.

Progress thus far. Finished Linux build, 2.7 linus, cygwin 3.6, and both flavors of windows compiler issues.   I still have to finish the unicode to string method for 2.7 (there was no test case for this), fix the int length issue, and investigate pypy issues.
After this I will go fix numpy issues.

I made some progress on PyPy.  It is much closer to working than previous.  All problems with crashing due to mishandling of tuples were fixed with the refactor. Unfortunately, it is failing checks regarding memory leaks.  I am not sure if this is a problem with the test code or with our functionality on PyPy.   It is not a high priority to track down for me as I do not use PyPy, but perhaps it is close enough for someone who is interested to run to ground.

@marscher This massive patch is complete.
There are still a half dozen test cases that I need to add and work through before it is ready to use in a production sense.  Most of the issues have to do with untested code on unicode conversion of jchar types.  I didn't have much to work with other than the python docs and I may have messed up a pattern.  It is not so much that I am sure that it is wrong, but simply that I less confident than with the rest of the code.
I did manage to keep Python 2.6 working in this patch, but it is getting a bit burdensome.  Our test cases for the memory view stuff is pretty thin.  I suspect that some stuff may not be quite right on raw io buffers.  But that code was just as suspect before as it is now.  The jpype_memoryview stuff was actually disabled in master due to a header issue and my refactor reactivated some of that.  Given that 2.6 docs are getting scarce I am not sure how much longer we can support it.
I know that you are currently occupied, but I do plan to make further progress in the meantime.   Rather than piling those other changes into this massive pull request I am going to split out those clean up activities into separate branches off of my devel head.  Thus I won't be able to submit them until this current pull is reviewed.  Most of them are single issue pulls such as getting synchronized working, improving proxy, auto generation of proxy for functors, more test cases,  revising customizers, etc.  But once those are complete I will be cutting into the jni transactions at the back end.   With this reorg that should be much less disruptive but will still generate another very large pull request.

Synchronized branch now has a working test case for synchronized using pyjp_monitor.

Lambdas branch now has working test case for returning an anonymous class or lambda.

I am working on the next patch for duck typing of primitives that will allow numpy types to get converted.  It is a pain because it is hard to determine if something is actually an int type or a float type given they all have both __int__ and __float__.  I have settled on checking for __and__ as the tie breaker.  Does this seem reasonable?

Nevermind.  I found the call I needed for the duck typing.
https://www.python.org/dev/peps/pep-0357/

primitive_duck branch now has support for duck typing of primitives to support numpy types.

customizer branch has mostly complete rework of class customizers.  Using @JImplementationFor we can declare any class to hold the methods for the finished JClass instance.  This simplified adding new customizers.  The revised customizers are applied with O(1) so there is not performance cost.  By setting a __jclass_init__ method in customizer class, it can apply customizations to all derived classes.
It fails with a segfault in one test.  So I need to run it to ground before it is ready.

devel_utf8 branch has a working test case for UTF8 with surrogate codes for Python3.  I will need to test Python2 before it is complete.  The patch is a bit of a mess as  it pulled the devel branch in twice.  I will get it cleaned up when the devel is branch up to date.

devel_utf8 branch now has full support for utf translation for python 2 and python 3 thanks to test cases provided by rene-bakker-it.
@marscher I have about two to three more tasks that I can complete before maintaining separate branches for each modification will start to become difficult due to conflicts on the C++ backend.
I think I can complete the customizer rework debugging, fix numpy array encoding, and improve proxies with decorators.  After that I will start needing code from the multiple branches together so that I can proceed to add the automatic type conversion (hits all classes in C++ derived from jp_class) and the class loader code (hits all C++ code using jp_jniutil and typemanager) .  Pulling char[] and byte[] from jp_arrayclass is currently on hold as it will conflict with utf-8 encoding changes.  Auto proxy on functional interface is contingent on type conversion code.  Enhanced tracing may be possible without conflicts, but as the only person likely to benefit from integrating java, c++ and python stacktraces is me I am leaving that as a low priority.  Automatic docstring will depend on me being about to override the slot designation to produce a dynamic string, so that will just depend on how lucky I get with cpython fallback paths on slot lookup.   And all it can do is state the method signatures unless I find a portable way to fetch javadoc from a class file.
I could start pushing this other branches into the devel, as the massive patch is already a reviewing nightmare I don't think that is a good route.  Thus I am going to run out the list of independent tasks, update the project plan, then go on break until you have time to catch up.

customizer branch contains a completed rework of class customizers.  Customizers now simply require using a decorator on an ordinary class to define new methods.  Late customizers (post class construction) are possible.  One issue resulting in a segfault was identified and verified to be an issue in master.  The branch is ready for a pull request once devel is reviewed.

@marscher any hope of starting this review?  My lead employee just quit and I am going to be snowed under for the next few months while I try to find a replacement.  I should still be able to get the branched copied merge in once the main review is complete, but otherwise I will have to put the rest on hold until the situation is corrected.

Applied the autopep8.  It changed a lot of stuff and not necessarily in the places that I had been working.  Do you have specific settings that we should be applying or is the default settings fine?
I ran it as
python3 -m autopep8 --in-place jpype/*.py setup.py setupext/*.py test/jpypetest/*.py

I can't flatten this pull though because I have 7 branches hung off it right now.

Defaults should be fine! Thanks a lot for this massive change!

Okay I rebased customizer, primitive_duck and synchronized and applied  autopep8 to each of them.  Once you apply this pull request to devel I will submit those.  I can then move forward the utf8.
We won't quite be to a releasable once all the patches go in.  We should consider doing the following before we release 0.7.0:

[ ] go over the docs
[ ] merge the user relevant part of my change logs into the official change log.
[ ] fix the np.array bug
[ ] decide the severity of the base class method bug.  It is pretty nasty because it is a hard crash.  But it is on an undocumented function so I could go either way.

Hmm it appears that the appveyor check is not up yet.

@marscher  Do we want to merge this now or do we need to wait for an appveyor check?


Create array.xml

As you wanted ;)
We do not always translate the CC licenses in French, we sometimes prefer to keep the original English expression.

Ahh OK,, sorry. I didn't know that.
Anyway, I merged the pull request.
Thank you again :+1:  :)


Unit tests for ImportKeyValuePairRDD and ImportRDDOfElements should use standard temp directory

The unit tests ImportKeyValuePairRDDToAccumuloHandlerTest and ImportRDDOfElementsHandlerTest create temporary directories in the current directory - they should use CommonTestConstants.TMP_DIRECTORY as other unit tests do.
ImportRDDOfElementsHandlerTest should use ClassTagConstants.ELEMENT_CLASS_TAG rather than creating its own class tag (line 51). The same applies to ImportKeyValuePairRDDToAccumuloHandlerTest.

Merged into develop.


Fixed sqlx link under related projects

The sqlx link was directing users to Go's sqlx package instead of Rust's.

Whoops, I used to write Go so that must have been the first one in my search history.


[Request] Solid background addon icon

Transparent background addon icon is not looking good on kodi addon browser or on the widgets. Please consider to change 100% solid background.
Example:

Changing to static background will make it look good in one skin, and bad in others.
Anyway, I'm not a designer, feel free to make a change and make a PR for it.

All add-ons are solid(static) backgrounds on the official repo. It's their design rules I guess. https://kodi.wiki/view/Add-on_structure#icon.png
It's up to you to follow their rules. If you are OK with transparent background I am fine with It.


Stuck upgrade from 4.13. to 4.14

Hi.
Upgrade from 4.13.0-0.okd-2023-10-28-065448 to 4.14.0-0.okd-2023-11-12-042703 stucked. The issue is https://github.com/okd-project/okd/issues/1776. I did as described https://access.redhat.com/solutions/5099331 on all my master nodes which were in degreded status. After that all my master nodes are in Ready, SchedulingDisabled and I cant mark them as Schedulable because they automatically get back to SchedulingDisabled.

I removed drain annotation from nodes.


invalid transition out of a Parallel or Map container not caught by validator

Describe the bug
The Parallel and Map states do not allow states to link into or out from the state machine nested within a branch or iterator.
Here's the relevant part of the spec for Parallel:

A state in a Parallel State branch "States" field MUST NOT have a "Next" field that targets a field outside of that "States" field. A state MUST NOT have a "Next" field which matches a state name inside a Parallel State branch’s "States" field unless it is also inside the same "States" field.
Put another way, states in a branch’s "States" field can transition only to each other, and no state outside of that "States" field can transition into it.

To Reproduce
PR with test cases is inbound. Here's the parallel test:
{
  "Comment": "An example of the Amazon States Language using a parallel state to execute two branches at the same time.",
  "StartAt": "Parallel",
  "States": {
    "Parallel": {
      "Type": "Parallel",
      "Next": "Final State",
      "Branches": [
        {
          "StartAt": "Wait 20s",
          "States": {
            "Wait 20s": {
              "Type": "Wait",
              "Seconds": 20,
              "End": true
            }
          }
        },
        {
          "StartAt": "Pass",
          "States": {
            "Pass": {
              "Type": "Pass",
              "Next": "ChoiceState"
            },
            "ChoiceState": {
              "Type": "Choice",
              "Choices": [
                {
                  "Variable": "$.foo",
                  "NumericEquals": 1,
                  "Next": "Wait 10s"
                },
                {
                  "Variable": "$.foo",
                  "NumericEquals": 2,
                  "Next": "Final State" <---- this is an error
                }
              ],
              "Default": "Wait 10s"
            },
            "Wait 10s": {
              "Type": "Wait",
              "Seconds": 10,
              "End": true
            }
          }
        }
      ]
    },
    "Final State": {
      "Type": "Pass",
      "End": true
    }
  }
}

Expected behavior
Error is reported when a branch/iterator tries to link to a state outside of its container
Version:
2.0.0
Additional context
Add any other context about the problem here.

Thanks for the detailed report

Closing, fix got merged. Thanks.

Released in<EMAIL_ADDRESS>


Interpolator mask

Description
The interpolator currently does not use the mask variable so it returns interpolated values when it shouldn't. In the case of nearest neighbour time interpolation, this results in the model value from the last time point always being returned.
Issue(s) addressed
Resolves #95
Dependencies
None.
Impact
Only affects JOPA runs where the model background has multiple time steps. The configuration files have recently been updated to all use linear interpolation so there will be no effect from this change.
Checklist

[x] I have updated the unit tests to cover the change
[x] New functions are documented briefly via Doxygen comments in the code
[x] I have linted my code using cpplint
[x] I have run the unit tests
[ ] I have run mo-bundle to check integration with the rest of JEDI and run the unit tests under all environments: output can be seen at http://fcm1/cylc-review/taskjobs/hadgs/?suite=mo-bundle-orca_jedi_97.

I've tested the code on MetOp SST data using the sith suite and it appears to work. However, I'm not 100% confident I understand the way the mask variable is supposed to be used. @twsearle, please could you give an initial review and if you think it looks OK I will work on updating the unit test reference data.

This looks correct to me - its slightly different from how others implement it in that we ensure the default value is always the missing data indicator, however I still think this lines up with the behaviour of the generic atlas interpolator here:
https://github.com/JCSDA-internal/oops/blob/c531e3fde8a313349f7a27f3da00f8719858ad00/src/oops/generic/AtlasInterpolator.cc#L53

@odlomax Can you confirm this is the correct approach to implementing the oops interpolator "time mask" variable?

I think this is all good, and the reason the CI is failing is because the nearest-neighbour interpolation is used in our tests and is now giving a different result. I think this should be possible to fix by changing the dates on the various tests to match to the final state in the file. I will leave that to you to double check.

Interesting that you saw a CPP lint issue that wasnt picked up by the CI? maybe somehow when you ran cpplint it didn't pickup the configuration file? Regardless it all looks great to me! Do you want to take it out of draft, I will review and we can get it merged up?

Interesting that you saw a CPP lint issue that wasnt picked up by the CI? maybe somehow when you ran cpplint it didn't pickup the configuration file? Regardless it all looks great to me! Do you want to take it out of draft, I will review and we can get it merged up?

I ran cpplint on the command line without a config file on the files that I had changed. It gave some errors about not indenting in a namespace. Let me know if you prefer the previous version as I can easily reverse my change.

Interesting that you saw a CPP lint issue that wasnt picked up by the CI? maybe somehow when you ran cpplint it didn't pickup the configuration file? Regardless it all looks great to me! Do you want to take it out of draft, I will review and we can get it merged up?

I ran cpplint on the command line without a config file on the files that I had changed. It gave some errors about not indenting in a namespace. Let me know if you prefer the previous version as I can easily reverse my change.

if it passes the CI its fine by me. I think to use the configuration you need to run it starting from the root directory of the repo (the one containing CPPLINT.cfg). At least that is what the CI is doing, and it passed both before and after your change.

Interesting that you saw a CPP lint issue that wasnt picked up by the CI? maybe somehow when you ran cpplint it didn't pickup the configuration file? Regardless it all looks great to me! Do you want to take it out of draft, I will review and we can get it merged up?

I ran cpplint on the command line without a config file on the files that I had changed. It gave some errors about not indenting in a namespace. Let me know if you prefer the previous version as I can easily reverse my change.

if it passes the CI its fine by me. I think to use the configuration you need to run it starting from the root directory of the repo (the one containing CPPLINT.cfg). At least that is what the CI is doing, and it passed both before and after your change.

I investigated this and found that I was running a version of cpplint that is installed in one of the mobbs builds but the version that is run in the orca-jedi checks is in the orca-jedi repository and has the line that checks for incorrect indentation commented out: https://github.com/MetOffice/orca-jedi/blob/develop/tools/cpplint.py#L5963-L5964. If I uncomment this, there are 30 errors reported.

Interesting that you saw a CPP lint issue that wasnt picked up by the CI? maybe somehow when you ran cpplint it didn't pickup the configuration file? Regardless it all looks great to me! Do you want to take it out of draft, I will review and we can get it merged up?

I've now marked this as ready for review.


Update management-and-monitoring.md

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


Update Release Drafter docs

This updates the Release Drafter to be in sync with the latest Release Drafter readme

Thanks for the update @toolmantim!


Feature: cache key control

How about to add some function/module in nuxt config, to have ability control cache key and global version without rebuild app.
For examples:

Caching by user, cookie session key as additional cache key
Caching by app view settings stored in cookies (mobile/desktop, custom layouts, i18n etc)
Flush cache if some global data change time point from redis or etc, is grater than cache time

@gendalf done.


Migration from pages to app directory

What problem does this feature solve?
Hello.
Do you have a plan to migrate from the pages to the app next.js directory?
Can you please answer for both free and pro versions?
What does the proposed solution look like?
https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#migrating-from-pages-to-app

Hi @mrbodich,
Currently, we are working on the pro version, and the Next.js 13 is already provided in our pro version. However, the app directory has become stable from Next.js v13.4.0. So we have started working on it and you will get an update in the next major release of the pro version.
Our current focus is providing app directory in the pro version so once it's completed then we will start working on the free version. It might take atleast 3-4 months for the free version.
We appreciate your patience and understanding.

How much faster it will be done for the Pro version?

Hi @mrbodich.
We do not have an exact timeline but it may take atleast 2-3 months as it will require a complete re-write of the current code base to take advantage of new structure, features, and concepts.


C++: Stop emitting childof edges from anchors to their files. [phab:D1334]

Created by fromberger at 2017-02-13 22:58:16:

Update unit tests.
Update schema examples for C++.

zarko accepted this revision at 2017-02-13 23:24:41

fromberger closed via commit 42440dee60a6194290b1bdec1c9985332c793979 at 2017-02-13 23:29:47


Can't use DOM manipulation library not defined on window.

It would be convenient to be able to use Backbone with multiple versions of jQuery or other libraries that are used for DOM manipulation. Currently Backbone only supports libraries defined as window.{jQuery, Zepto, ember, $} at time that backbone.js is loaded, with no ability to explicitly override the library used at runtime.

Pull request #918 add this functionality.

To repeat myself, without a concrete use case, this is going to be a wontfix. The previous ticket allows you to set Backbone to use any object as a DOM library.
Switching out the dependency at runtime, in the middle of your app's lifecycle, will only break all of your views and routers, so I'm afraid I don't see the point.

For context, this is what you said in #551: "I want whichever pull request it ends up being to be driven by someone with a real project and a real library in mind -- otherwise we usually end up with an implementation that doesn't actually work."
I'm not sure how we got from there to the assumption that I don't have a real project in mind. For clarity, I have three real projects for which I currently have to maintain a modified version of backbone.js because of this issue and my pull request works for me.
Now, if you don't like the implementation because it will break your views and routers if done in the middle of the lifecycle, I can work on that - I am only using it right at the beginning of the lifecycle where is isn't a problem, but I can see that doing it in the middle would be problematic. But if you just don't have any interest in this behavior, that's fine too, but it does have a real use case.

Great, then I'd love to hear more about it. Which version of jQuery do you want to use that isn't the same as the value of jQuery ... and why can't you set it to jQuery before you load Backbone?

Excellent, apologies for not having been explicit enough earlier - the use case is this - two versions of jQuery on the same page, the one we want to use for Backbone is in window.jQuery_new, there is an older version of jQuery in window.$ and window.jQuery, with most of the code using $ without any scoping. If we set window.$ = window.jQuery_new before loading backbone.js, we need to be careful about setting it back before loading most of the rest of the code. It's easier to modify our vendored backbone.js version to just use root.jQuery_new rather than having to be so careful about load orders, but it would be easier to be able to set the library dynamically when application code begins to use Backbone, rather than at load time.

Hey, thanks for explaining the real-world use case -- that's almost always all I'm ever looking for. Your patch is merged, and will make it out with 0.9.1.

How about a real world case for AMD, will that convince ya? hehe. :-)

Ha ha -- that's actually exactly it. To quote the ever infallible wycats...

12:06 PM wycats: amd is a large, unnecessary dependency
12:06 PM wycats: you don't need asynchronous loading with that level of complexity ever
12:06 PM wycats: the AMD people admit this, and tell you to use a builder
12:06 PM wycats: I cut out the middleman and don't add complexity to my projects if I'm just going to use a builder
12:06 PM wycats: oh shit I think I probably just started something

It's a shame the two best MVC libraries take this stance. It makes a lot of assumptions about what the "level of complexity" their users applications are, as well has how their users would like to share code across projects etc, I know I'm beating a dead horse so I'll bow out, thank you for Backbone. Unlike Ember.js it is reasonably patchable for AMD, it seems I'll be using a patched version forever. ;-)

Thanks @jashkenas!


Nested 'import' with code splitting support

In my code for code-splitting, I'm getting:
index.js:156:9: Parsing error: 'import' and 'export' may only appear at the top level
However, according to the webpack2 guides and the proposed ES6 modules spec, import can in fact be nested.
https://webpack.js.org/guides/migrating/#code-splitting-with-es2015

It looks like import() is still in stage 3 of the standardization process. ESLint has a policy of only implementing features in their parser once they're in stage 4. You can try installing this babel plugin (https://babeljs.io/docs/plugins/syntax-dynamic-import/) and tell standard to use babel as it's parser. To do that:
npm install babel-eslint
standard --parser babel-eslint

Thanks for the speedy response!


Filter out only on web videos from downloads

JIRA: https://openedx.atlassian.net/browse/MA-1659

:+1:


Error on Machines page on Firefox browser

Hello,
I'm running the docker version: 0.3.3
I have an issue on Firefox browser which print me the following error:

React error url from the screenshot: https://react.dev/errors/418?args
Step to reproduce:

Connect to headplane on firefox browser
Go on Machines page (the initial page is ok)
Wait for few seconds to see the error

I don't have the issue on Chromium browsers

That actually isn't the full error, could you check for more errors in your console?


[#2479] Allow unique_id to take a list

resolves #2479
Description
This derives from pull request #4159.
Checklist

[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[x] I have updated the CHANGELOG.md and added information about my change

I'm not quite sure what the flow should be here. Should this PR be merged first and then the separate adapter changes be addressed?

@gshank I'm not opposed to doing those changes in a separate PR as long as this change doesn't break anything w/o those other changes. If we do a separate PR, can you please open a tracking issue so we don't lose track of doing the work?

@leah I think they would have to be separate PRs, because they're different repositories, right? You can't put changes from multiple repos into the same PR. I don't know if this change would break anything in the other repos, and I'm not sure how to test them against a dbt-core branch.

they're different repositories, right?

@gshank that is correct but I just didn't know if we needed to coordinate with the other repos. I don't want to merge this change if it causes the other repos to start failing tests and instead coordinate to merge all the PR's the same day if that makes sense.

I encounter an error when running an incremental bigquery model with multiple unique keys. The error I am getting is:
10:24:38  Database Error in model sample_model (models/ODL_derived/sample_model.sql) 10:24:38    Syntax error: Unexpected "[" at [546:33]. If this is a table identifier, escape the name with , e.g. table.name rather than [table.name].
10:24:38    compiled Code at target/run/sample_dwh/models/ODL_derived/sample_model.sql`
This is caused by the compiled code:
[...] ) as DBT_INTERNAL_SOURCE         on DBT_INTERNAL_SOURCE.['col1', 'col2', 'col3'] = DBT_INTERNAL_DEST.['col1', 'col2', 'col3']
Config used is:
     , name="sample_model"         , materialized = 'incremental'         , unique_key=['col1', 'col2', 'col3']
Am I doing something wrong or is this dbt code that fails with bigquery with tese settings?

Heya @HeddeCrisp ! It looks like you have the right syntax. Your error is familiar and strikes me as what used to happen before we merged this.
I did a little incremental model test with the following config:
{{
    config(
        materialized='incremental',
	unique_key=['id', 'first_name', 'last_name']
    )
}}

And my dbt version is:
Core:
  - installed: 1.4.5
  - latest:    1.4.5 - Up to date!

Plugins:
  - bigquery: 1.4.3 - Up to date!

So this to me implies there's not an error on our end with this feature but rather you might be using a dbt bigquery version that didn't have this feature active yet. What does dbt --version yield on your system?

Receiving an error when I pass a list
Parsing Error
at path ['unique_key']: ['usr_key', 'usr_mbr_key', 'prgm_key', 'prmsn_key', 'resp_key', 'mbr_cmpy_key', 'usr_prgm_prmsn_key'] is not valid under any of the given schemas
{% snapshot snap_mkp_usr_prgm_prmsn %}
{{
    config(
      target_schema='edl_workdb',
      strategy='timestamp',
      unique_key=['usr_key', 'usr_mbr_key', 'prgm_key', 'prmsn_key', 'resp_key', 'mbr_cmpy_key', 'usr_prgm_prmsn_key'],
      updated_at='upd_ts',
      invalidate_hard_deletes=True,
    )
}}

-- Filter out value analysis app as it's sunset and has duplicates
select * from {{ source('hzn_mkp', 'mkp_usr_prmsn_app_t') }} where app_key <> 5

{% endsnapshot %}


no volume regulation

First of all thanks for developing the bot!
But this really needs a way to safe volume on serverside.
Every new user gets blown away because the bot is on 100% clientside by default in discord :D

I think you can change the volume in Spotify?


Profiles registered by the user get checked and saved in the backend

Gets tested by "createUser_duplicateUsername_throwsException" in UserServiceIntegrationTest.java
Added within commit a3e381d


[scripts/welcome] add logo for Kali

I'm tempted to go with "no"

what about backtrack !!??!? 😡😡🤬🤬

I have to use a Kali VM for school (pain) and using the command line without dotfiles is absolutely unusable. /s?
What's your point in excluding Kali?

Relax, this was a joke. I will answer your questions though:

what about backtrack !!??!?

I don't understand what you mean.

I have to use a Kali VM for school (pain) and using the command line without dotfiles is absolutely unusable.

My condolences. I recommend ohmyzsh.

What's your point in excluding Kali?

I don't use it.
Anyway, @lexisother, I have added options to the welcome script for adding logo search directories, you may use it in your fork. Logos of distros I don't use is not something I want to keep here.
@thgeraads and @phorcys420, please see the README of this repository.
Also, @phorcys420, who are you? I know only who @thgeraads is. Have we met?

Thanks for the option!
(you haven't met Phorcys, they're a friend)

Relax, this was a joke. I will answer your questions though:
This was a joke too, dw.

Also, @phorcys420, who are you?
As lexi said, one of her friends (and that pfp isnt me just incase)


Examples and Jupyter notebooks: improvement and clean-up - [merged]

In GitLab by @cmastalli on Feb 12, 2019, 23:21
Merges jupyter-cleanup -> devel
In this PR, I continue with the task defined #83. I will listed here the general changes:

Renamed Jupyter notebooks with descriptive names, e.g. bipedal_walking_from_foot_traj.ipynb
Moved most of the examples out of notebooks folder.
Put all Jupyter notebooks inside notebooks folder.
Removed some duplicate files.
Simplified the introduction_to_crocoddyl.ipynb
Reviewed the text of most of notebooks.
Kept consistency between notebooks and examples.

Additionally I improved or added functionality to few examples:
1. Bipedal walking

Added a double support phase to the biped walking example.
Improved regularization for walking with double support phase.
Added documentation in the biped walking class.
Created the createStepModel function for easier understanding of the biped walking class.

2. Unicycle

Increased the arrow dimension for better visualization.
Added function to plot the unicycle motion.

3. Cartpole

Improved the animation by using a rectangle and adding time information.
Added solution for the Jupyter notebook.

In GitLab by @nmansard on Feb 13, 2019, 10:09
for an example, what about this solution?
from crocoddyl import *

In GitLab by @nmansard on Feb 13, 2019, 10:10
please comment the withGaussApprox option.
# We specify the withGaussApprox=True to have approximation of the hessian based on the jacobian of the cost residuals.

In GitLab by @nmansard on Feb 13, 2019, 10:11
I don't think you need that outside the jupyter. So don't put it here.

In GitLab by @nmansard on Feb 13, 2019, 10:12
why? this is pretending the notebook folder would be used as an external library. We should not have such a file here.

In GitLab by @nmansard on Feb 13, 2019, 10:14
you should propagate these nice display in the plotCartpole function (or better, use the plotCartpole function inside the animateCarpole function).

In GitLab by @nmansard on Feb 13, 2019, 10:18
here it is! I really don't like that.  Either you really want this functionality, then put the example in the notebook folder ; or you don't care so much, the display is only for the notebook, then you don't import from notebook.

In GitLab by @cmastalli on Feb 13, 2019, 10:58
added 50 commits
740caf13...1c0f8d68 - 21 commits from branch devel69acaaed - [examples] Double support phase and simplify talos example5b3ad572 - [example] Renamed functions to keep consistencyd127aeaa - [example] Added documentation to talos example949a85ba - [example] Changed the regularization in the switch phase for talosdad6c796 - [notebook] Consistent with talos.py, added questionsc31cb798 - [examples] Renamed loco3d to bipedal_walking174d3c7d - [loco3d] This is duplicate in bipedal_walking9d95e5f2 - [unicycle] This file is duplicate in examples/unicycle.py0965de4f - [notebooks] Moved the introduction_to_crocoddyl notebook to its folderefdf89b6 - [examples] Renamed to bipedal_walking_from_foot_trajdc62e3b0 - [notebook] Review introduction_to_crocoddyl notebookb72317b2 - [notebook] Review the unicyle notebookc7b2e25b - [notebook] Further improvement in the unicycle notebook54d13a45 - [unicycle] Increading the arrow head268dd490 - [unicycle] Added function for plotting the its motionb67b8e87 - [unicycle] Consistent example with notebook2df600a1 - [unicycle] Added __init__ file for using utilsf5e3382d - [unicycle] Renamed the files to make more clear its contain137b8e34 - [cartpole] Cleaned up the cartpole utilsf7a37d70 - [notebook] Reviewed and improved the cartpole notebookad86a3b0 - [cartpole] Improved animation -- added text and rectangle0161798e - [cartpole] This example is consistent with the notebook2371c473 - [cartpole] Renamed the files with a more descriptive name7e6a50b9 - [cleanup] Removed useless file7be52765 - [notebook] Added the solution of the cartpole notebook6467466a - [cartpole] Access to the cartpole utils5045a8cf - [bugfix] pinocchio.SE3.Zero doesn't exist29a7261a - [bugfix] Fixed propagate error after rebaseab2b9396 - [notebook] Put inline matplotlib for bipedal walking notebook
Compare with previous version

In GitLab by @cmastalli on Feb 13, 2019, 11:07
It's used for the example which are inside example, not notebook

In GitLab by @cmastalli on Feb 13, 2019, 11:08
Do you mean you want cartpole_swing_up.py inside notebooks folder? I put all Python examples inside example folder. If so I need to move all of them

In GitLab by @cmastalli on Feb 13, 2019, 11:09
changed this line in version 3 of the diff

In GitLab by @cmastalli on Feb 13, 2019, 11:09
added 1 commit
408aef8f - [doc] Added a comment about the withGaussApprox=True option
Compare with previous version

In GitLab by @cmastalli on Feb 13, 2019, 11:10
I included a comment inside the Python script but also inside the Jupyter notebook.

In GitLab by @cmastalli on Feb 13, 2019, 11:31
changed this line in version 4 of the diff

In GitLab by @cmastalli on Feb 13, 2019, 11:31
changed this line in version 4 of the diff

In GitLab by @cmastalli on Feb 13, 2019, 11:31
added 3 commits
dd85d8ee - [examples] Using from crocoddyl import *, it reduced many lines929aea3b - [notebook] Added %matplotlib inline to the intro notebook9180059e - [notebook] Cleaned up the output of intro notebook
Compare with previous version

In GitLab by @cmastalli on Feb 13, 2019, 11:32
I usef from crocoddyl import * in each example and notebook. This reduces the among of lines.

In GitLab by @cmastalli on Feb 13, 2019, 12:38
added 1 commit
7bf0bc66 - [cartpole] Removed legacy plotCartpole function
Compare with previous version

In GitLab by @cmastalli on Feb 13, 2019, 12:39
This function doesn't provide anything new. Indeed it's a legacy function. So I decided to remove it.

In GitLab by @cmastalli on Feb 13, 2019, 12:50
changed this line in version 6 of the diff

In GitLab by @cmastalli on Feb 13, 2019, 12:50
changed this line in version 6 of the diff

In GitLab by @cmastalli on Feb 13, 2019, 12:50
added 1 commit
763916b8 - [examples] Removed notebooks dependency
Compare with previous version

In GitLab by @cmastalli on Feb 13, 2019, 12:51
I removed the subfolder dependency and moved these files to notebooks folder.

In GitLab by @cmastalli on Feb 13, 2019, 12:52
I put this file inside notebook folder.

In GitLab by @cmastalli on Feb 13, 2019, 12:52
resolved all discussions

In GitLab by @cmastalli on Feb 13, 2019, 12:53
@nmansard I resolved all the discussions and rebase this branch. Please merge it as soon as possible. We need for tomorrow's class.

In GitLab by @nmansard on Feb 13, 2019, 15:42
closed

In GitLab by @nmansard on Feb 13, 2019, 15:42
reopened

In GitLab by @nmansard on Feb 13, 2019, 15:43
merged

In GitLab by @nmansard on Feb 13, 2019, 15:43
mentioned in commit 47b5db38b81103c7d9cba3959b886f8263b617a9


Class "Modules\Posts\Providers\PostsServiceProvider" not found | laravel 11

I just installed laravel 11 version with "jetstream"
after that I installed "laravel-modules" package.
after that, run this command for demo module from docs
php artisan module:make posts
and then run laravel command
php artisan serve

Got this provider error
 Error

  Class "Modules\Posts\Providers\PostsServiceProvider" not found

  at vendor\laravel\framework\src\Illuminate\Foundation\ProviderRepository.php:206
    202▕      * @return \Illuminate\Support\ServiceProvider
    203▕      */
    204▕     public function createProvider($provider)
    205▕     {
  ➜ 206▕         return new $provider($this->app);
    207▕     }
    208▕ }
    209▕

  1   vendor\laravel\framework\src\Illuminate\Foundation\ProviderRepository.php:142
      Illuminate\Foundation\ProviderRepository::createProvider("Modules\Posts\Providers\PostsServiceProvider")

  2   vendor\laravel\framework\src\Illuminate\Foundation\ProviderRepository.php:61
      Illuminate\Foundation\ProviderRepository::compileManifest()

I just want to try this package but first try failed.
Please confirm, this is about package error or I am doing setup in wrong way.

have you added/updated your composer.json file?
By default, the module classes are not loaded automatically. You can autoload your modules by adding merge-plugin to the extra section:
"extra": {
    "laravel": {
        "dont-discover": []
    },
    "merge-plugin": {
        "include": [
            "Modules/*/composer.json"
        ]
    }
},

don't forget to run composer dump-autoload afterwards.

Dear dcblogdev,
I followed your instructions and updated my composer.json file accordingly. Adding the merge-plugin to autoload the modules was precisely what I needed, and it resolved my issue flawlessly.
thank you so much for your prompt and effective help.
Warm regards,


pixel added

Checklist

[x] I ran npm test locally and it passed without errors.

[x] I only edited the _data/pixels.json file.

[x] I entered the username in the pixels.json that I'm also using to create this pull request.
[x] I acknowledge that all my contributions will be made under the project's license.

Hi @CopperBeardyTwitch, I moved your pixel a bit because they need to be integers :) thanks for contributing!


Use Disassembler in Script-Ware instead of Decompiler

SW's decompiler has been unavailable for a while now, so I'd suggest using it's Disassembler (use basic feature detection or getexecutorname and getexecutorname() === 'ScriptWare') instead of the currently still unavailable decompiler, once someone implements the text box.

not planned for this iteration of hydroxide


[BUG] The argument "Tasks.Read.All" does not belong to the set "AgreementAcceptance.Read.All,Agr...

Affected Command:
Register-PnPAzureADApp -ApplicationName "testapp" -Tenant $TenantURL -Interactive -GraphApplicationPermissions Directory.Read.All,Group.ReadWrite.All,Sites.ReadWrite.All,User.ReadWrite.All,Tasks.Read.All -SharePointDelegatePermissions AllSites.FullControl -SharePointApplicationPermissions Sites.FullControl.All,User.ReadWrite.All

Is the issue related to the cmdlet itself, its parameters, the syntax, or do you suspect it is the code of the cmdlet that is causing the issue?
Yes, itseems like an issue with the validate set
i tried running Get-PnPPlannerTask and it only works if i manually add Tasks.Read.All permission manually to the azure app registration...

Reporting an Issue or Missing Feature
issue with command Register-PnPAzureADApp
Expected behavior
I would expect the command to create a new azure app registration and add the permission to the azure app registration like it does for other permissions, but the command fails, i have to remove this specific permission for the command to complete and then manually add permission Tasks.Read.All to achieve what i need
Actual behavior
The error below is thrown:
Register-PnPAzureADApp: Cannot validate argument on parameter 'GraphApplicationPermissions'. The argument "Tasks.Read.All" does not belong to the set "AgreementAcceptance.Read.All,Agreement.ReadWrite.All,Agreement.Read.All,ConsentRequest.ReadWrite.All,Policy.ReadWrite.ConsentRequest,ConsentRequest.Read.All,Sites.Selected,PrintSettings.Read.All,Chat.Create,ChatMember.ReadWrite.All,ChatMember.Read.All,DataLossPreventionPolicy.Evaluate,SensitivityLabel.Evaluate,SensitiveInfoType.Detect,SensitiveInfoType.Read.All,APIConnectors.ReadWrite.All,APIConnectors.Read.All,TeamsTab.ReadWriteForUser.All,TeamsTab.ReadWriteForTeam.All,TeamsTab.ReadWriteForChat.All,ChatMessage.Read.All,CallRecord-PstnCalls.Read.All,RoleManagement.Read.All,Policy.Read.ConditionalAccess,ShortNotes.ReadWrite.All,ShortNotes.Read.All,ServiceMessage.Read.All,ServiceHealth.Read.All,TermStore.ReadWrite.All,TermStore.Read.All,TeamMember.ReadWriteNonOwnerRole.All,Team.Create,TeamsAppInstallation.ReadWriteSelfForUser.All,TeamsAppInstallation.ReadWriteSelfForTeam.All,TeamsAppInstallation.ReadWriteSelfForChat.All,TeamsAppInstallation.ReadWriteForUser.All,TeamsAppInstallation.ReadWriteForTeam.All,TeamsAppInstallation.ReadWriteForChat.All,TeamsAppInstallation.ReadForUser.All,TeamsAppInstallation.ReadForTeam.All,TeamsAppInstallation.ReadForChat.All,Teamwork.Migrate.All,PrintTaskDefinition.ReadWrite.All,PrintJob.ReadWriteBasic.All,PrintJob.ReadWrite.All,PrintJob.ReadBasic.All,PrintJob.Read.All,PrintJob.Manage.All,Printer.ReadWrite.All,Printer.Read.All,Policy.ReadWrite.PermissionGrant,Policy.Read.PermissionGrant,Chat.ReadBasic.All,Policy.ReadWrite.Authorization,Policy.ReadWrite.AuthenticationMethod,Policy.ReadWrite.AuthenticationFlows,ChannelMember.ReadWrite.All,ChannelMember.Read.All,TeamMember.ReadWrite.All,TeamMember.Read.All,TeamSettings.Read.All,TeamSettings.ReadWrite.All,Channel.ReadBasic.All,Team.ReadBasic.All,ChannelSettings.ReadWrite.All,ChannelSettings.Read.All,Channel.Delete.All,Channel.Create,EntitlementManagement.ReadWrite.All,EntitlementManagement.Read.All,Sites.Manage.All,Sites.FullControl.All,Notes.ReadWrite.All,UserShiftPreferences.ReadWrite.All,UserShiftPreferences.Read.All,User.ManageIdentities.All,Device.Read.All,Policy.ReadWrite.ApplicationConfiguration,Domain.Read.All,TeamsTab.ReadWrite.All,TeamsTab.Read.All,TeamsTab.Create,UserAuthenticationMethod.Read.All,UserAuthenticationMethod.ReadWrite.All,Policy.ReadWrite.ConditionalAccess,CallRecords.Read.All,Schedule.ReadWrite.All,Schedule.Read.All,ThreatAssessment.Read.All,Group.Create,GroupMember.ReadWrite.All,GroupMember.Read.All,BitlockerKey.ReadBasic.All,BitlockerKey.Read.All,Application.Read.All,UserNotification.ReadWrite.CreatedByApp,TeamsApp.ReadWrite.All,TeamsApp.Read.All,ApprovalRequest.ReadWrite.CustomerLockbox,ApprovalRequest.ReadWrite.AdminConsentRequest,ApprovalRequest.ReadWrite.EntitlementManagement,ApprovalRequest.ReadWrite.PriviligedAccess,ApprovalRequest.Read.CustomerLockbox,ApprovalRequest.Read.AdminConsentRequest,ApprovalRequest.Read.EntitlementManagement,ApprovalRequest.Read.PriviligedAccess,ThreatIndicators.Read.All,PrivilegedAccess.ReadWrite.AzureResources,PrivilegedAccess.ReadWrite.AzureADGroup,PrivilegedAccess.ReadWrite.AzureAD,PrivilegedAccess.Read.AzureResources,PrivilegedAccess.Read.AzureADGroup,PrivilegedAccess.Read.AzureAD,TeamsActivity.Send,TeamsActivity.Read.All,DelegatedPermissionGrant.ReadWrite.All,AppRoleAssignment.ReadWrite.All,DeviceManagementServiceConfig.ReadWrite.All,DeviceManagementRBAC.ReadWrite.All,DeviceManagementManagedDevices.ReadWrite.All,DeviceManagementManagedDevices.PrivilegedOperations.All,DeviceManagementConfiguration.ReadWrite.All,DeviceManagementApps.ReadWrite.All,OrgContact.Read.All,Calls.Initiate.All,Calls.InitiateGroupCall.All,Calls.JoinGroupCall.All,Calls.JoinGroupCallAsGuest.All,Calls.AccessMedia.All,OnlineMeetings.Read.All,OnlineMeetings.ReadWrite.All,IdentityUserFlow.ReadWrite.All,IdentityUserFlow.Read.All,Calendars.ReadWrite,Calendars.Read,Device.ReadWrite.All,Directory.ReadWrite.All,Directory.Read.All,Group.ReadWrite.All,Group.Read.All,Contacts.ReadWrite,Contacts.Read,Mail.Send,Mail.ReadWrite,Mail.Read,MailboxSettings.Read,Domain.ReadWrite.All,MailboxSettings.ReadWrite,Application.ReadWrite.All,ChannelMessage.UpdatePolicyViolation.All,ChannelMessage.Read.All,Chat.Read.All,Chat.UpdatePolicyViolation.All,People.Read.All,Reports.Read.All,AccessReview.Read.All,AccessReview.ReadWrite.All,ProgramControl.Read.All,ProgramControl.ReadWrite.All,Application.ReadWrite.OwnedBy,AuditLog.Read.All,User.Read.All,User.ReadWrite.All,IdentityRiskyUser.Read.All,EduAdministration.ReadWrite.All,EduAdministration.Read.All,EduAssignments.ReadWrite.All,EduAssignments.Read.All,EduAssignments.ReadWriteBasic.All,EduAssignments.ReadBasic.All,EduRoster.ReadWrite.All,EduRoster.Read.All,EduRoster.ReadBasic.All,IdentityRiskEvent.Read.All,Files.Read.All,IdentityRiskyUser.ReadWrite.All,IdentityRiskEvent.ReadWrite.All,Chat.ReadWrite.All,SecurityEvents.Read.All,SecurityEvents.ReadWrite.All,Sites.Read.All,SecurityActions.Read.All,SecurityActions.ReadWrite.All,ThreatIndicators.ReadWrite.OwnedBy,Files.ReadWrite.All,User.Invite.All,Notes.Read.All,InformationProtectionPolicy.Read.All,AdministrativeUnit.Read.All,AdministrativeUnit.ReadWrite.All,IdentityProvider.Read.All,IdentityProvider.ReadWrite.All,Policy.Read.All,Policy.ReadWrite.TrustFramework,TrustFrameworkKeySet.Read.All,TrustFrameworkKeySet.ReadWrite.All,OnPremisesPublishingProfiles.ReadWrite.All,DeviceManagementServiceConfig.Read.All,DeviceManagementRBAC.Read.All,DeviceManagementManagedDevices.Read.All,DeviceManagementApps.Read.All,DeviceManagementConfiguration.Read.All,AccessReview.ReadWrite.Membership,ExternalItem.ReadWrite.All,Member.Read.Hidden,Place.Read.All,Organization.Read.All,Organization.ReadWrite.All,RoleManagement.Read.Directory,RoleManagement.ReadWrite.Directory,Sites.ReadWrite.All,Policy.ReadWrite.FeatureRollout,Mail.ReadBasic,Mail.ReadBasic.All" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.
Steps to reproduce behavior
Install the module
Run the command against the target tenant
What is the version of the Cmdlet module you are running?
Get-Module -Name "PnP.PowerShell" -ListAvailable
Directory: /home/darwin/.local/share/powershell/Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands

Manifest   2.4.0                 PnP.PowerShell                      Desk      {Add-PnPAdaptiveScopeProperty, Add-PnPEntraIDGroupMember, Add-PnPEntraIDGroupOwn…
Which operating system/environment are you running PnP PowerShell on?

[ ] Windows
[ x ] Linux
[ ] MacOS
[ ] Azure Cloud Shell
[ ] Azure Functions
[ ] Other : please specify

Fixed it, will be available in tomorrow's nightly builds.
We were missing the values in the validate set


[REQUEST] Support for more popular environmental sensors in firmware for CC2530 based Sonoff BASICZBR3?

@kirovilya  Any chance you be willing to add support for any more popular environmental sensors?
I guess that the most popular in demand in this specific case would be the sensors that ITead already sell for Sonoff TH10 / Sonoff TH16 so can buy them and Sonoff BASICZBR3 from same site.

https://www.itead.cc/sonoff-th.html

ITead sells these as Sonoff branded sensors:

Sonoff TH Sensor Si7021

https://sonoff.tech/product/accessories/si7021

Sonoff TH Sensor AM2301

https://sonoff.tech/product/accessories/AM2301

Sonoff Temp Sensor DS18B20

https://sonoff.tech/product/accessories/DS18B20

Other popular low-cost sensors that support both humidity + temperature are DHT11, DHT12 & DHT22

https://www.itead.cc/humidity-temperature-sensor-dht11.html

https://www.itead.cc/wiki/DHT11_Humidity_Temperature_Sensor_Brick

https://www.itead.cc/humidity-temperature-sensor-dht22.html

They also sell several different versions of DS18B20

https://www.itead.cc/waterproof-ds18b20-temperature-sensor.html
https://www.itead.cc/temperature-sensor-with-steel-head-and-plastic-connector.html
https://www.itead.cc/temperature-sensor-with-steel-head.html

@ptvoinfo Zigbee Configurable Firmware v2.3 for example now supports a lot of environmental sensors; DS18B20, BMP280, BME280, DHT11, DHT22, DHT12, AM2301, Sonoff SI7021, MHZ19, SenseAir S8 so not sure if he would be willing to share his code and input on it for CC2530?

https://ptvo.info/zigbee-switch-configurable-firmware-v2-210/

https://ptvo.info/zigbee-switch-configurable-firmware-router-199/

My article and this repository are just an example of firmware implementation. If you understand, you can make your firmware to use these sensors.
As you correctly noticed, the @ptvoinfo configurator can make firmware for this device and other sensor. You can build the firmware yourself by correctly specifying the pins on which the button, LED and sensors are located.

If I understand yours is for Z-Stack 3.0 right and @ptvoinfo configurator is for Z-Stack Home 1.2 or?
https://habr.com/ru/company/iobroker/blog/495926/
Sorry I don't read Russian so had to use Google Translate, regardless, this code is beyond my skills.

:) This is normal, I also use Google Translate.
Yes, my version of Zigbee is 3.0, and the configurator is at 1.2
But this does not affect the operation of the device. You can use both options in different networks.


Adding extra props to all mui components at once

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
Hello Team,
I trying to add extra custom props to all mui components at once using react and typescript but im unable to achieve. Im able to add custom props to components by extending the component individually.
Is there any way that i can add custom props to all mui components.
Examples 🌈

here render is custom prop that i want to add to all mui components
Motivation 🔦
No response
Order ID 💳 (optional)
67449

Thanks for providing the codesandbox example, the Button component comes under material-ui repo, I've transferred the issue there, someone will check it out soon.

You will likely need to do this per component basis, you will likely anyway need to handle that prop somehow. Otherwise, by default the prop would be propagated to the underlying DOM node which is probably not what you intend.


70B Quant Potential Issue

We have been trying to do a 2.55bpw on a model and am seeing something odd in the logs. A couple of us have tried across multiple devices and it appears it is choosing the 2.17bpw for most of the layers. I ran a separate at the 4.6bpw and that came out with no issues.
Don't understand all the details of this process so not sure if it is a user error or expected output. Included the first ten layers from a couple of the runs and then one of the measurement files. Have tried a few measurement files including wikitext with the same output.
quant log.txt
measurement.json

2.17bpw is the lowest setting for a layer, made of a mix of 5% 3-bit rows, 95% 2-bit rows at group size 32. With a 4-bit scale parameter per group and some overhead for the row permutation and such, it works out to 2.17. The next step up from that is 2.38, then 2.63.
The point of the measurement is to determine how sensitive each layer is to quantization errors so that the optimization step can create a plan for quantizing the whole model that minimizes the overall error. As it happens, later layers of the model typically need more bits, as do the MLP layers in general since they're higher effective rank than the attention projections.
So seeing a lot of 2.17bpw layers with a 2.55bpw target is normal and expected. It doesn't have a lot of extra bits over the minimum, so it's very selectively applying them where they're needed the most.

Thanks that is helpful.


LMS api documentation online unaccessible/outdated

the documentation on http://docs.myriadrf.org/LMS_API/.html
is currently unaccessible in most browsers due to hsts (forces https) and a following domain/certificate mismatch.
also it seems not to have been updated in a while (version shown is 18.06)

seems fixed now. https://docs.myriadrf.org/LMS_API/


Stochastic GCG for optimizing prompts on datasets

Let's generalize the easy_gcg code to optimize prompts on a dataset of (x, y) pairs, where each x is the question and y is the answer.
We want to solve u := argmax_u E [P(y | u + x)] where the expectation is taken over the dataset (x, y) ~ D.
We can start by simply aggregating gradients for the swaps in GCG over multiple elements of the batch (https://github.com/amanb2000/Magic_Words/blob/32840cd867c83fc131205e5ff639a109f4e4f78c/magic_words/easy_gcg.py#L178).
All that remains is to create an efficient batch_compute_score_dataset() function to compute the scores of each potential new prompt w.r.t. the dataset (https://github.com/amanb2000/Magic_Words/blob/32840cd867c83fc131205e5ff639a109f4e4f78c/magic_words/easy_gcg.py#L263)

Finished first version with https://github.com/amanb2000/Magic_Words/commit/2c3ee24277fa7b9ba711143c2e26e94751ceda3e
Todo

[ ] Adjustable eval_batch_size (how many training examples we use to compute the score of each alternative prompt)
[ ] Store + return prompts and losses over the course of optimization (per iteration)