Enforcing uniqueness of project and task names under projects

My actions before raising this issue

[X] Read/searched the docs
[X] Searched past issues

Using the cvat sdk it is currently impossible to find the right project if you don't have the ID. This means that if someone by accident creates two projects with the same name, you have no way of getting the right project id from the project name.
The same issue exists with tasks in projects.
Steps to Reproduce (for bugs)
Duplicate project names

Create a project in the projects tab
Create another project with the same name in the projects tab
The only way to differentiate the projects is project ID, which is not easily memorized for users

Duplicate task names

Create a task in the tasks tab
Create another task in the tasks tab with the same name
The only way to differentiate the tasks is the task ID which is not easily memorized for users

Expected Behaviour
Similar to how Organization names are expected to be unique, project names within organizations (also within personal space) should enforce the same uniqueness of name as organizations does. The same goes for task names in projects.
Current Behaviour
See previous sections
Possible Solution
The simplest fix is to add uniqueness requirements in the django db models.
Context
I am trying to make the annotation experience as seamless as possible for a large number of different types of users, and these problems currently mean that I need to make some assumptions that might not be true in the future.
Your Environment
Not relevant

Hi @rogvidarge
I do not think we are going to implement it. There are a lot of potential difficulties and really do not see reasons to do it.
If on your instance you need unique names, keep them unique.

The simplest fix is to add uniqueness requirements in the django db models.

This will not work. A lot of dublicates in existing data.

I do understand that this is a breaking change, but the solution should work. Keeping names unique, requires a whole other level of management, that I don't want to get into.
Is there a reason for no uniqueness restriction of project names, and task names in projects, when there is uniqueness in organization slurs?

I do not think this change is demanded. Actually for several years you are the first one who interested it.

I understand and respect the decision, and have already worked around it in our setup. But I am still curious as to why the data models of the projects and tasks don't have unique slugs like organizations do.

I believe because "Organization" is something what keeps the idea of mapping somehow with instances in the real world. Whether it is a real organization (like Intel, AMD, NVidia), or internal departments that are also usually have unique naming. All they are regular use-cases in our practice.
In contrast with projects, where can be multiple: "Test" or "RoadTraffic", even for the same user.


check is folder or directory exists before prompt a message

Codecov Report
Base: 61.57% // Head: 61.63% // Increases project coverage by +0.05% :tada:

Coverage data is based on head (18a67b7) compared to base (2463453).
Patch coverage: 78.57% of modified lines in pull request are covered.

:exclamation: Current head 18a67b7 differs from pull request most recent head 7071a87. Consider uploading reports for the commit 7071a87 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #109      +/-   ##
==========================================
+ Coverage   61.57%   61.63%   +0.05%
==========================================
  Files          11       11
  Lines         799      808       +9
==========================================
+ Hits          492      498       +6
- Misses        307      310       +3

Impacted Files
Coverage Δ

shellfirm/src/checks.rs
73.27% <78.57%> (-0.56%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


SIGSEGV when running mpi_ping

When running htf with eztrace  on a ping pong program, recording events with htf make the program crash.
Step to reproduce:
wget https://gitlab.com/eztrace/eztrace/-/blob/master/test/mpi/mpi_ping.c
mpicc -o mpi_ping.c -o mpi_ping
mpirun -np 2 eztrace -t mpi  ./mpi_ping

When changing the number of warmup loop to 0, the recording of events works fine. The problem may be due to a sequence appearing in several different loops.

Corrected in 50e2dd7cc79acbc96e8583a3f0155b7c5b1c2d84


type is incompatible with some incompatible instantiation

Following code does not type check:
/* @flow */

type F = <a> (input:a) => a
const double:F = x => x * 2

It errors as follows:
src/flowing.js:4
  4: const double:F = x => x * 2
                           ^ a. This type is incompatible with
  4: const double:F = x => x * 2
                           ^^^^^ number

src/flowing.js:4
  4: const double:F = x => x * 2
                           ^^^^^ number. This type is incompatible with
  4: const double:F = x => x * 2
                      ^^^^^^^^^^ some incompatible instantiation of a

Found 2 errors

I would expect flow to infer implementation of double and refine it's type to be a bound version of claimed F or more specifically it to be <a:number> (x:a) => a rather than error as it does now.
I can also get behind the idea that flow should not bind polymorphic types by inferring double since author claimed it's type to be F. Although in that case user should be allowed to annotate double with a bound version of F.
/* @flow */

type F = <a> (input:a) => a
const double:F<number> = x => x * 2

But flow does not allow that either instead it fails with following errors:
src/flowing.js:4
  4: const double:F<number> = x => x * 2
                  ^^^^^^^^^ type application of identifier `F`. Expected polymorphic type instead of
  4: const double:F<number> = x => x * 2
                  ^^^^^^^^^ type `F`

src/flowing.js:4
  4: const double:F<number> = x => x * 2
                              ^^^^^^^^^^ arrow function. Expected polymorphic type instead of
  4: const double:F<number> = x => x * 2
                  ^^^^^^^^^ type `F`

Found 2 errors

P.S.: This example is convoluted but that's so that it can be short & simple.

I think this is the same as #856. At least, my explanation for why this is a non-issue is the same.

Also, if you actually want to parameterize the type of F, you can, you just need to move the parameterization back into the type alias. type F<T> = (x: T) => T, then double: F<number> = x => x*2 should type check.

I think I answered this completely.

Is there a workaround that doesn't involve declaring a separate type for every function?
I encountered this problem while writing this function:

async function resolveIgnoreErrors<T>(promise: Promise<T>): ?T {
  try {
    return await promise;
  } catch (e) {
    // probably not worth cluttering logs. These must be orgs outside of EATS (U4B etc)
    return null;
  }
}

I was pretty surprised to see an error, and despite reading your comments on this and #856, I don't understand why it's happening, nor why the workaround helps.
 13:     return await promise;
         ^^^^^^^^^^^^^^^^^^^^^ Promise. This type is incompatible with the expected return type of
     v---------------------------------------------------------------
 11: async function resolveIgnoreErrors<T>(promise: Promise<T>): ?T {
 12:   try {
 13:     return await promise;
...:
 18: }
     ^ some incompatible instantiation of `T`

Seconded. @samwgoldman, It would be really helpful if you could go into a little bit more detail about your description of why this is valid error? I re-read your paragraph in the other issue about 20 times, and I still can't make sense of it. Or, is there maybe another resource I can seek out for some more context?

@keithkml async functions are returning Promise objects, so the signature should be resolveIgnoreErrors<T>(p: Promise<T>): Promise<?T>.
if you leave the return type as ?T, then returning null is actually Promise<null>, which might be not compatible with T (eg. when T is number, you can only return ?number, and Promise<null> is definitely not number).
The error message, in this case, is cryptic, flow should report that async functions must return promises.


Use Xcode for Travis CI builds on macOS

Switched from "Unix Makefiles" to "Xcode" for Travis CI builds on macOS.
This allows us to catch issues with the generated Xcode projects, which macOS users are more likely to use when debugging / building.

Codecov Report

Merging #456 into development will decrease coverage by 3.12%.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           development    #456      +/-   ##
==============================================
- Coverage        86.63%   83.5%   -3.13%
==============================================
  Files              316     292      -24
  Lines            15503   12217    -3286
==============================================
- Hits             13431   10202    -3229
+ Misses            2072    2015      -57

Impacted Files
Coverage Δ

framework/test/driver/BundlePropsInterface.h
0% <0%> (-100%)
:arrow_down:

...mework/include/cppmicroservices/ShrinkableVector.h
0% <0%> (-100%)
:arrow_down:

framework/test/bundles/libS/TestBundleSService0.h
0% <0%> (-100%)
:arrow_down:

framework/src/service/ServiceListeners.h
0% <0%> (-100%)
:arrow_down:

...ramework/include/cppmicroservices/ServiceFactory.h
0% <0%> (-100%)
:arrow_down:

framework/test/bundles/libSL1/FooService.h
0% <0%> (-100%)
:arrow_down:

framework/test/bundles/libS/TestBundleSService2.h
0% <0%> (-100%)
:arrow_down:

framework/test/bundles/libLQ/TestBundleLQService.h
0% <0%> (-100%)
:arrow_down:

framework/test/driver/ServiceControlInterface.h
0% <0%> (-100%)
:arrow_down:

...amework/include/cppmicroservices/BundleActivator.h
0% <0%> (-100%)
:arrow_down:

... and 177 more


fix_31_validate_ops

Assuming that validation means the serviceDescripor associated with
the grpc server has the method in methoddesc array.
2.Expose the serviceInfo in Grafeas and set after it is registered.
Function that takes a method name for servicename and checks if it exists in the serviceInfo map
Invoke the function wherever reqd.
Q. Should this validation be optional ? Via startup config ?
Q. the var methodName may also be not reqd as the string can be directly passed, but is there
so can later on use reflection to derive operation name from the calling function. Is the calling
function in api always likely to match operation name  and is reflect call performant ?
Tested by running client-go samples test and not getting any "not found" errors.

Thanks for any feedback and clarifications and will follow up with suggested changes.

tests in v1alpha1/impl_test.go do not yet have  the ServiceInfo initialized, so will update PR with the changes ....

Hey @shrajfr12 thanks for your PR.
I think you misunderstood the issue, we don't need to check if the API method is implemented. What the issue was about is to check if an occurrence or note was created with an operation, we want to call GetOperation() to validate the operation object exists in the database.
An operation can be used to track a group of notes or occurrences created for a common reason. For example, all the occurrences created during some scan of a number of resources (like Docker images) might be assigned the same operation.
Hope that clarifies things, feel free to adjust your PR accordingly. Thanks.

Thanks @vtsao for the clarification.  Much appreciated. Might have more  follow up questions later as  I revise the PR.

Hi @vtsao , Currently operation is not tied to Note or Occurrence so to make the validation,  Note and Occurrence needs to be first enhanced with an extra field with the operation name. So during an operation if a note needs to be created, this field will be set. which can then be used for validation.   Is this  assumption ok ?

Ah yes you're right we have to add an operation_name field on the Occurrence and Note message. Please feel free to add that. Thanks!

Thanks for this!


cannot focus space due to an error with the scripting-addition

macOS version 11.1
csrutil status  output  is  System Integrity Protection status: disabled
already tried reinstall scripting-addition sudo yabai --uninstall-sa && sudo yabai --install-sa

yabai-v3.3.6

yabai-v3.3.6

After sudo yabai --install-sa, did you run sudo yabai --load-sa manually? If not, try to run it.

After sudo yabai --install-sa, did you run sudo yabai --load-sa manually? If not, try to run it.

thanks ! it works ! 👍

thanks ! it works ! 👍

@koekeishiya Will you consider to mention this (manually run sudu yabai --load-sa) in the wiki? I saw many users have such a concern.  In the first installation, sometimes sudo yabai --install-sa won't load sa automatically.
Thanks.

@koekeishiya Will you consider to mention this (manually run sudu yabai --load-sa) in the wiki? I saw many users have such a concern.  In the first installation, sometimes sudo yabai --install-sa won't load sa automatically.
Thanks.

This is actually mentioned in the wiki already: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#macos-big-sur---automatically-load-scripting-addition-on-startup

This is actually mentioned in the wiki already: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#macos-big-sur---automatically-load-scripting-addition-on-startup

Yeah, it just mentions that scripting-addtion is not loaded automatically on startup. What I mean is that it is not loaded on the first installation either. So after installation of yabai, we should first run sudo yabai --load-sa to load sa. Then the second thing is add it at the top of yabairc to make it being loaded on each startup.

Yeah, it just mentions that scripting-addtion is not loaded automatically on startup. What I mean is that it is not loaded on the first installation either. So after installation of yabai, we should first run sudo yabai --load-sa to load sa. Then the second thing is add it at the top of yabairc to make it being loaded on each startup.

Updated wiki.

Updated wiki.

Happened on MacOS BigSur 11.6. Already tried
sudo yabai --uninstall-sa && sudo yabai --install-sa && sudu yabai --load-sa

scripting-addition failed to inject
$ yabai -m space --focus next
cannot focus space due to an error with the scripting-addition.
$ sudo yabai --load-sa
Password:
yabai: scripting-addition failed to inject payload into Dock.app!

yabai-v4.0.0
macOS 12.01
M1 apple silicon
SIP is disabled

same problem ^ but on Monterey 12.2

same problem ^ but on Monterey 12.2

same here D: wish i could downgrade. did it work for u on 12.1? amethyst also broken on 12.2

opened a new issue #1158 on this problem

I'm getting "cannot focus space due to an error with the scripting-addition" on Ventura.

I'm getting "cannot focus space due to an error with the scripting-addition" on Ventura.

Same with me on Ventura.

I'm getting "cannot focus space due to an error with the scripting-addition" on Ventura.

Same with me on Ventura.

It's fixed in the development version. https://github.com/koekeishiya/yabai/commit/206c0d6968210f48363f206526760e5750810a61 with https://github.com/koekeishiya/yabai/issues/1297 as context.
You can install the development version by following the wiki. https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD). You'll be asked by homebrew to unlink the previous yabai, but after that and following the instructions on the wiki it works like a charm again. Don't forget to update the sha256 for the new binary.

Still seeing this issue on Ventura 13.2.1: yabai-v5.0.2 & SIP disabled (only need the ability to focus spaces that are created manually).

Created yabai-cert as per instructions in the wiki
Used brew to install from HEAD
Could NOT find yabai installed in /usr/local/bin as per the wiki instructions. Codesigned yabai here instead:

> codesign -fs 'yabai-cert' /opt/homebrew/bin/yabai
> codesign -fs 'yabai-cert' /opt/brew/Cellar/yabai/HEAD-147b356/bin/yabai

Provided accessibility permission to the executables at /opt/brew/bin/yabai/ and /opt/brew/Cellar/yabai/HEAD-147b356/bin/yabai since there was nothing in the local bin.

Issue:
> yabai -m space --focus next
cannot focus space due to an error with the scripting-addition.

Is there anything wrong here, or something else that I can try? Please let me know.

Problem prevails for me as well. Using latest yabai from homebrew on Ventura 13.2.1 (22D68):
% yabai --version
yabai-v5.0.2
% yabai -m space --focus next
yabai --cannot focus space due to an error with the scripting-addition.

I am facing the same issue:
yabai -m space --focus next                                08:48:42
cannot focus space due to an error with the scripting-addition.

Apple Silicon
Ventura 13.5
yabai-v5.0.6 (installed from brew)
SIP status:
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled
	Boot-arg Restrictions: disabled
	Kernel Integrity Protections: enabled
	Authenticated Root Requirement: enabled

I am facing the same issue:我面临着同样的问题：
yabai -m space --focus next                                08:48:42
cannot focus space due to an error with the scripting-addition.

Apple Silicon 苹果硅 Ventura 13.5  文图拉13.5 yabai-v5.0.6 (installed from brew) yabai-v5.0.6（从brew安装） SIP status:  SIP 状态：
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled
	Boot-arg Restrictions: disabled
	Kernel Integrity Protections: enabled
	Authenticated Root Requirement: enabled

may be you should use
yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa" sudo yabai --load-sa
in https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#configure-scripting-addition says

Don't forget to update the sha256 for the new binary.

This solved it for me: updating the sha256 hash in the sudoers file for yabai to match the latest installed binary.
https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#configure-scripting-addition

I am facing the same issue:我面临着同样的问题：
yabai -m space --focus next                                08:48:42
cannot focus space due to an error with the scripting-addition.

Apple Silicon 苹果硅 Ventura 13.5  文图拉13.5 yabai-v5.0.6 (installed from brew) yabai-v5.0.6（从brew安装） SIP status:  SIP 状态：
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled
	Boot-arg Restrictions: disabled
	Kernel Integrity Protections: enabled
	Authenticated Root Requirement: enabled

may be you should use yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa" sudo yabai --load-sa
in https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#configure-scripting-addition says

you were right, I missed that section. Thank you!

Anyone else getting: sudo yabai --install-sa ?

Anyone else getting:
$ sudo yabai --install-sa
yabai: '--install-sa' is not a valid option!

For anyone who comes along, try running sudo yabai --load-sa. For later versions of macOS this should work.

I encountered this error after running a brew upgrade. Re-checking the output of shasum -a 256 $(which yabai) showed that a new sha256 hash had been generated. Updating /private/etc/sudoers.d/yabai to replace the old sha256 with it fixed this.

I encountered this error after running a brew upgrade. Re-checking the output of shasum -a 256 $(which yabai) showed that a new sha256 hash had been generated. Updating /private/etc/sudoers.d/yabai to replace the old sha256 with it fixed this.

Should this case be also listed in the wiki?

I encountered this error after running a brew upgrade. Re-checking the output of shasum -a 256 $(which yabai) showed that a new sha256 hash had been generated. Updating /private/etc/sudoers.d/yabai to replace the old sha256 with it fixed this.

Please add this in wiki, took me hours to find this...

its mentioned in the shell comments of https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#configure-scripting-addition
#   this hash must be updated manually after upgrading yabai.


[traceable tensor subclasses] Add proxy and transform for a callable with subclasses

What does this PR do?

New Proxy for traceable tensor subclasses
Initial support of traceable tensor subclasses, tested with a simple subclass
Tensor factory is not supported

Very exciting! Would you also link a (draft?) design doc?


[WIP] Improve Code Quality

Remove platform specific logic that is no longer necessary on .NET core
Add implicit casting to CborByteString and CborTextString to their respective types (byte[] and string)
Use optimized OperatingSystem classes for platform specific logic
Minor test cleanup
Improve AndroidKey error messages
Improve CredentialPublicKey test coverage

Codecov Report

Merging #422 (4be6b6e) into master (86b6c6d) will increase coverage by 0.40%.
The diff coverage is 67.85%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master     #422      +/-   ##
==========================================
+ Coverage   75.13%   75.54%   +0.40%
==========================================
  Files         100      100
  Lines        2783     2776       -7
  Branches      460      456       -4
==========================================
+ Hits         2091     2097       +6
+ Misses        576      560      -16
- Partials      116      119       +3

Files Changed
Coverage Δ

Src/Fido2.Models/COSETypes.cs
66.66% <ø> (ø)

Src/Fido2/AttestationFormat/AndroidKey.cs
94.04% <0.00%> (-1.20%)
:arrow_down:

Src/Fido2/AttestationFormat/Apple.cs
90.32% <0.00%> (-3.23%)
:arrow_down:

Src/Fido2/AttestationFormat/AppleAppAttest.cs
68.75% <0.00%> (-2.09%)
:arrow_down:

Src/Fido2/AttestationFormat/Tpm.cs
93.54% <0.00%> (-0.72%)
:arrow_down:

Src/Fido2/Objects/CredentialPublicKey.cs
81.81% <33.33%> (+13.13%)
:arrow_up:

Src/Fido2/Extensions/CryptoUtils.cs
87.09% <50.00%> (-1.08%)
:arrow_down:

Src/Fido2/Extensions/EcCurveExtensions.cs
77.77% <85.71%> (+34.02%)
:arrow_up:

Src/Fido2/AttestationFormat/FidoU2f.cs
100.00% <100.00%> (+8.57%)
:arrow_up:

Src/Fido2/AuthenticatorAttestationResponse.cs
79.43% <100.00%> (ø)

... and 2 more

... and 2 files with indirect coverage changes

@abergs Ready for review

@iamcarbon I understood your making some small changes? I'm OK either way.

@abergs All set. I know these small changes can get tedious to review -- and I appreciate you for for taking the time and for the feedback.
The 4.0 release is shaping up nicely!

@iamcarbon Your contributions are highly valued!

@iamcarbon Your contributions are highly valued!

^ Extremely!


Ng-repeat, Internet explorer 11 (windows 10) and output in style attribute

I want to report the bug with ng-repeat and output in style attribute of repeated element. This bug only occurs in Internet explorer 11 (and probably other versions as well), it does not occur on edge, firefox and chrome, windows phone explorer, etc.... I am not sure if problem occurs in ie on other versions of windows os.
I have created minimal example which shows what bug is:
http://plnkr.co/edit/teo6MQ2hxeLtCjCOcVZz
On internet explorer 11, left and top in style of a div will not be updated to correct values. In all other browsers "labels" will have their correct positions. It seams that in expression

{{label.x}} and {{label.y}} are not parsed (and executed) for problematic browser
I have updated to the latest version of angularjs 1 branch and problem still occurs

This is a documented known issue for IEs (and there are straightforward workarounds available).


Update how-to-inference-server-http.md

See pypy:

@shohei1029
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


[PDI-17736] Job Runs Locally but not on a Carte server

When we execute on a Carte Server, there´s no filename, since we load data from a block of xml and not from a file. Even more if we are not in a repository context, we also don't have the repository directory info. So the job was not running remotely because the internal variable directory logic didn't take this case in consideration. This logic was added.

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/main/java/org/pentaho/di/job/JobMeta.java
  engine/src/main/java/org/pentaho/di/trans/Trans.java
  engine/src/main/java/org/pentaho/di/trans/TransMeta.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change: -0.4% :small_red_triangle_down:
Complexity Change: -0.5% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -1.7% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Method Change: -1% :small_red_triangle_down:

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -1.1% :small_red_triangle_down:
Complexity Change: -1.3% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:
Line Change: -0.4% :small_red_triangle_down:

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Branch Change: -2.6% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.symmetriccrypto.symmetriccryptotrans.SymmetricCryptoTransMeta

Branch Change: -3.3% :small_red_triangle_down:
Complexity Change: -1.8% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.TransMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UISecurityRole

Branch Change: -1.8% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.5% :small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceinsert.SalesforceInsertMeta

Instruction Change: -0.1% :small_red_triangle_down:

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/main/java/org/pentaho/di/job/JobMeta.java
  engine/src/main/java/org/pentaho/di/trans/Trans.java
  engine/src/main/java/org/pentaho/di/trans/TransMeta.java

Newly Broken Tests:
org.pentaho.di.trans.step.mqtt.MQTTStreamSourceTest.testMqttStreamSingleTopic:
:red_circle: junit.framework.AssertionFailedError
junit.framework.AssertionFailedError
	at org.pentaho.di.trans.step.mqtt.MQTTStreamSourceTest.getQuickly(MQTTStreamSourceTest.java:253)
	at org.pentaho.di.trans.step.mqtt.MQTTStreamSourceTest.testMqttStreamSingleTopic(MQTTStreamSourceTest.java:122)

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change: -7.2% :small_red_triangle_down:
Complexity Change: -7.7% :small_red_triangle_down:

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.4% :small_red_triangle_down:
Line Change: -3.8% :small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Branch Change: -0.6% :small_red_triangle_down:
Complexity Change: -0.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -1.7% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -1.8% :small_red_triangle_down:
Complexity Change: -1.1% :small_red_triangle_down:
Instruction Change: -0.4% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:

org.pentaho.di.trans.TransMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceinsert.SalesforceInsertMeta

Instruction Change: -0.1% :small_red_triangle_down:

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/main/java/org/pentaho/di/job/JobMeta.java
  engine/src/main/java/org/pentaho/di/trans/Trans.java
  engine/src/main/java/org/pentaho/di/trans/TransMeta.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change: -0.8% :small_red_triangle_down:
Complexity Change: -1% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Branch Change: -0.6% :small_red_triangle_down:
Complexity Change: -0.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -2.1% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:
Line Change: -0.7% :small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -2.2% :small_red_triangle_down:
Complexity Change: -2.6% :small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Branch Change: -2.6% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -0.5% :small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.TransMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.www.TransformationMap

Branch Change: -1.1% :small_red_triangle_down:
Complexity Change: -1.6% :small_red_triangle_down:

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/main/java/org/pentaho/di/job/JobMeta.java
  engine/src/main/java/org/pentaho/di/trans/Trans.java
  engine/src/main/java/org/pentaho/di/trans/TransMeta.java
  engine/src/test/java/org/pentaho/di/job/JobMetaTest.java
  engine/src/test/java/org/pentaho/di/job/JobTest.java
  engine/src/test/java/org/pentaho/di/trans/TransMetaTest.java
  engine/src/test/java/org/pentaho/di/trans/TransTest.java

Newly Broken Tests:
org.pentaho.di.job.JobTest.testSetInternalEntryCurrentDirectoryWithoutFilenameOrRepository:
:red_circle: org.junit.ComparisonFailure
org.junit.ComparisonFailure: expected:<...ginal value defined [in] run execution> but was:<...ginal value defined [at] run execution>
	at org.pentaho.di.job.JobTest.testSetInternalEntryCurrentDirectoryWithoutFilenameOrRepository(JobTest.java:197)

org.pentaho.di.trans.step.mqtt.MQTTStreamSourceTest.testMqttStreamSingleTopic:
:red_circle: junit.framework.AssertionFailedError
junit.framework.AssertionFailedError
	at org.pentaho.di.trans.step.mqtt.MQTTStreamSourceTest.getQuickly(MQTTStreamSourceTest.java:253)
	at org.pentaho.di.trans.step.mqtt.MQTTStreamSourceTest.testMqttStreamSingleTopic(MQTTStreamSourceTest.java:122)

org.pentaho.di.trans.TransMetaTest.testSetInternalEntryCurrentDirectoryWithoutFilenameOrRepository:
:red_circle: org.junit.ComparisonFailure
org.junit.ComparisonFailure: expected:<...ginal value defined [in] run execution> but was:<...ginal value defined [at] run execution>
	at org.pentaho.di.trans.TransMetaTest.testSetInternalEntryCurrentDirectoryWithoutFilenameOrRepository(TransMetaTest.java:866)

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -2.1% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:
Line Change: -0.7% :small_red_triangle_down:

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -1.1% :small_red_triangle_down:
Complexity Change: -1.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Branch Change: -2.6% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.TransMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceinsert.SalesforceInsertMeta

Instruction Change: -0.1% :small_red_triangle_down:

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/main/java/org/pentaho/di/job/JobMeta.java
  engine/src/main/java/org/pentaho/di/trans/Trans.java
  engine/src/main/java/org/pentaho/di/trans/TransMeta.java
  engine/src/test/java/org/pentaho/di/job/JobMetaTest.java
  engine/src/test/java/org/pentaho/di/job/JobTest.java
  engine/src/test/java/org/pentaho/di/trans/TransMetaTest.java
  engine/src/test/java/org/pentaho/di/trans/TransTest.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.4% :small_red_triangle_down:
Line Change: -3.8% :small_red_triangle_down:

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change: -0.8% :small_red_triangle_down:
Complexity Change: -1% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -1.7% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -1.8% :small_red_triangle_down:
Complexity Change: -1.1% :small_red_triangle_down:
Instruction Change: -0.4% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Branch Change: -2.6% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -0.5% :small_red_triangle_down:

org.pentaho.di.trans.TransMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryUser

Branch Change: -8.3% :small_red_triangle_down:
Complexity Change: -6.7% :small_red_triangle_down:
Instruction Change: -0.9% :small_red_triangle_down:
Line Change: -3.1% :small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UISecurityRole

Branch Change: -1.8% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.5% :small_red_triangle_down:

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/main/java/org/pentaho/di/job/JobMeta.java
  engine/src/main/java/org/pentaho/di/trans/Trans.java
  engine/src/main/java/org/pentaho/di/trans/TransMeta.java
  engine/src/test/java/org/pentaho/di/job/JobMetaTest.java
  engine/src/test/java/org/pentaho/di/job/JobTest.java
  engine/src/test/java/org/pentaho/di/trans/TransMetaTest.java
  engine/src/test/java/org/pentaho/di/trans/TransTest.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.4% :small_red_triangle_down:
Line Change: -3.8% :small_red_triangle_down:

org.pentaho.di.trans.step.BaseStep

Branch Change: -0.5% :small_red_triangle_down:
Complexity Change: -0.5% :small_red_triangle_down:
Instruction Change: -0.7% :small_red_triangle_down:
Line Change: -0.9% :small_red_triangle_down:
Method Change: -0.9% :small_red_triangle_down:

org.pentaho.di.trans.step.StepStatus

Branch Change: -3.3% :small_red_triangle_down:
Complexity Change: -1.6% :small_red_triangle_down:
Instruction Change: -1.5% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Method Change: -1% :small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -3% :small_red_triangle_down:
Complexity Change: -3.2% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:
Line Change: -0.7% :small_red_triangle_down:

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Branch Change: -1.3% :small_red_triangle_down:
Complexity Change: -0.9% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.TransMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryUser

Branch Change: -8.3% :small_red_triangle_down:
Complexity Change: -6.7% :small_red_triangle_down:
Instruction Change: -0.9% :small_red_triangle_down:
Line Change: -3.1% :small_red_triangle_down:

PR Updated. Thanks.


DLRS trigger errors while Contacts are merged

Hi.  We were notified by some end users of the following error when they were attempting to merge Contact records (in our Higher Education environment, the Contact record is or main personal record for our constituents).
Apex trigger dlrs_ContactTrigger caused an unexpected exception, contact your administrator: dlrs_ContactTrigger: execution of AfterDelete caused by: System.NullPointerException: Attempt to de-reference a null object: (dlrs)
So, it appears to be coming from one of the DLRS triggers.  I never remember this issue coming up before.
Is there any way to work around this? It looks like it is referring to a contact that was deleted because of the merge.
If it helps I will ask internally how the merges are taking place (delivered functionality, DemandTools, etc.).
Thanks,
Jim Williams
Berkeley College

Hi.  I just upgraded DLRS from version 2.4.1 to version 2.5 and this seems to have solved the issue, based on feedback from our end users.   So I am closing the incident.  If this comes up again I will let you know.
Thanks,
Jim Williams
Berkeley College


IDEA: add in info message (instead of error) when < Python 3 is used

As described here: https://twitter.com/robfig/status/1484987839804751875?s=21

can I pick this issue?

cc: @StefanBogdan ⬆


[Snyk] Upgrade @types/node from 8.10.66 to 17.0.38

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @types/node from 8.10.66 to 17.0.38.

:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

Warning: This is a major version upgrade, and may be a breaking change.

The recommended version is 934 versions ahead of your current version.
The recommended version was released 22 days ago, on 2022-05-31.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Won't upgrade because I want to keep the types from Node 17, just so we don't accidentally use stuff from Node 18 even though Node-Red uses Node 8.


Make Project and Logger available to workers in Worker API

This is a feature request to make the Gradle Project and Logger objects available to worker threads in the Worker API. The current restriction that all worker parameters be serializable makes it impossible to pass the project or logger to a worker thread. At best this leads to clumsy code that has to effectively remove Gradle constructs before calling a worker (e.g. converting a ZipTree to a Set, switching from project.copy to a less capable mechanism, etc). At worst, the inability to access the project or logger is a blocker for adopting the Worker API.

The Project will not be available, as that would defeat the parallel safety of the worker API.
Services like the logger and file operations on the other hand make perfect sense and should be made available through service injection.

Thanks @oehme for the quick reply. I understand that exposing the Project would be problematic. One aspect of the Project that would be useful to expose besides file operations would be the ability to call ant tasks (e.g. I have a use case calling ant.get).

Yes, a stateless service that allows you to call Ant makes sense as well.

Any ETA on this feature?

Ping

No ETA I can commit to, we'll update this issue as soon as we have a milestone for it.

If nobody on the team has bandwidth to do something like this, it seems like something worth a community contribution (I would be happy to sign up to do it).  Main thing would be for someone on the team to define the requirements and maybe a few hints about where to do work.

I'd like to have it as well. I need to redirect worker's stdout to logger.info calls.

I'd find something similar to project.exec and project.javaexec useful.

A thought I had about this... what about a read-only ProjectView, which just lets you read specific things, like path, logger, objects, providers, etc. that you might want to pass around without specifically pulling all of them out into (worst case) 10+ argument method calls?
This way, you can pass around "project-scoped bag of utilities", without actually passing around the mutable whole-world Project.  I'd be happy to do something of the sort if helpwanted .

I suppose just such a thing could be created in a plugin or set of tools, which is what I'll do if it's not desirable to have in gradle itself.  It would be slightly easier if Project implements ProjectView, though likely better to do with an immutable class that has a constructor(Project p).

@big-guy it looks like this is on the queue for 5.5 RC1 - which parts from this ticket are planned to be included? Is there any way I can help with this?

In https://github.com/vanniktech/gradle-code-quality-tools-plugin/pull/191 I've wanted to leverage the Worker API. Currently, I'm using project.javaexec to run a java binary. Unfortunately, I have to maintain several incompatible versions of the dependency that I want to execute. Hence using the classpath approach of the worker API does not really work well and the string reflection approach suits my needs better since depending on the version I can pass different arguments as well as different main classes. (Detekt integration is slightly easier than ktlint where I have the problem with different main classes)

this will be in 6.0

Can you reference some kind of documentation / sample?

@vanniktech https://github.com/gradle/gradle/blob/master/subprojects/workers/src/integTest/groovy/org/gradle/workers/internal/WorkerExecutorServicesIntegrationTest.groovy
@big-guy from a quick look at the PR for this (if it is the only one),
is it correct, that you can neither access the AntBuilder, nor the Logger?
Both were mentioned here as being quite necessary and sensible.

I am trying to migrate this plugin to Gradle 6.0: https://github.com/tschulte/gradle-jnlp-plugin . Unfortunately, this plugin is incompatible with Gradle 6.0.
The plugin uses Ant to sign the jar files. As far as I know, there is no way to sign jar files by using Gradle without calling Ant.
I just found out that there is no way to call Ant from within a worker thread, so I am stuck now. We still need to deploy our application using Webstart, so this plugin is vital for us. Because of this, we are now stuck with Gradle 5.6, because the plugin doesn't work with Gradle 6.0 (this is excusable) and there is no way to make it work with Gradle 6.0 because of missing APIs.

@ChristianCiach the Gradle AntBuilder is a wrapper around the Groovy AntBuilder, well actually a sub-class. Just use the Groovy AntBuilder directly, that works fine for the most part. Alternatively you could call the JarSigner in-process directly, but as it has no stable public API, it could break.
I used to use the JarSigner classes directly, as it was the only way to have parallel processing that does not kill the machine running the build, as the Ant task basically is just a wrapper around the standalone jarsigner tool. The API once actually broke for me between too Java versions.
Another alternative is, to do as the Ant task does and simply call the standalone tool use javaexec.
And finally you could try to use no isolation and have some static reference to the Gradle AntBuilder that you use in the workers, but I don't think that is a good idea.

@Vampire Thank you for your suggestions!
I already got it to work by using ExecOperations.exec(..) to call the jarsigner executable directly, but your suggestions seem to be more elegant.
I didn't know that there are classes inside the JDK to do the jar signing. I will check them out.
Using the AntBuilder is probably the easiest way to make the JNLP-plugin compatible while retaining all of its features. I will try that!

All has its pros and cons.
The standalone tools are mostly just thin starters that invoke the respective classes via JNI, be it java, javac or jarsigner. The classes are the one that used to be in tools.jar in the JDK, but missing in the JRE. Now they are simply classes in modules that are not on the module path by default.
Using the Groovy AntBuilder can also have its own problems. I used it to call a 3rd party task and always created a new instance. That made me run out of meta space add too often the classes were loaded. But using one static was also no solution, because the task is not thread safe and also static might be conflicting easily with daemon usage and so on.
I ended up having a custom registry with semaphores. If a worker needs the builder, it checks the existing semaphores, whether one builder is free and if not, creates a new one. This way I had as many builders as workers, but not more, even if new worker threads were made. Basically a custom AntBuilder pool.
But with a thread safe task, or a standard task that does not need to load additional classes and so on, it might again be completely different.


keybind on "Mod4-" does not always work

It seems you have to press several times to get one successful trigger.
I suspect somehow the very first one is always eaten by X window system menu.

I use Mod4-<key> bindings created by this library every day and they work as intended, with no additional keypresses required.

Does your X window start menu pop up when you press Mod4 (aka. super / win)?
Mine does.
So in key combinations like Mod4-z, the Mod4 is eaten by start menu.
However, if you press and release Mod4 to trigger the start menu popup first, then pressing Mod4-z works.

There is no X window start menu. You clearly have other applications
competing for the same key bindings, so this isn't a problem with xgbutil.
On Mon, Aug 20, 2018, 23:47 ayuanx<EMAIL_ADDRESS>wrote:

Does your X window start menu pop up when you press Mod4 (aka. super /
win)?
Mine does.
So in key combinations like Mod4-z, the Mod4 is eaten by start menu.
However, if you press and release Mod4 to trigger the start menu popup
first, then pressing Mod4-z works.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/BurntSushi/xgbutil/issues/42#issuecomment-414540735,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb34mWwALVr0_01w-cplGT-R2J9HZaiks5uS4LEgaJpZM4WDS1e
.


Stop video

how stop video when change view?

+1 what is the best way to unmount the Video component?

+1

@vvavepacket super late answer, but you could just conditionally render it
{ isVideoPlaying && <Video source={{ uri: 'somewhere.com/video.mp4' }} ... /> }

I would also be very happy to know how to implement a stop video functionality. Setting controls makes gives us
 and

but is there no "X" button?

Why is pause even a prop? If it is being internally controlled by controls, shouldn't the this.player ref provide a method for (un)pausing video?

how stop video when change view?

You can add a listener for navigation blur/focus to stop start video playback, here is an example using hooks:
`  useEffect(() => {
const stopVideo = props.navigation.addListener('blur', () => {
setStop(true);
});
return stopVideo;

}, [props.navigation]);`
// Video props
<Video
...
paused={stop}
/>


Fix openid settings jquery selectors

At some point Orchard settings changed and now when properties are rendered through asp-for adds a prefix "ISite_", That broke OpenIdSettings view.
This PR fixes it.

What is wrong is that you should not guess the ids, you should generate them. Use @Html.IdFor(m => m.Foo) in the javascript. Or if it's a js file then generate a div tag with an known id and data attributes that contain the ids. Then from the javascript you load these values.

Done


New App: Tilt Hydrometer

This pull request is to add a new Tidbyt app, tilthydrometer. The Tilt Hydrometer logs and tracks data throughout fermentation via Bluetooth. Log data is published to a Google Sheet generated by Tilt and shared with a user-specified Google account. This app retrieves the following data from the Sheet and displays it on the Tidbyt:

I have read the CLA Document and I hereby sign the CLA

@matslina Thanks for taking a look! The Tilts are pretty cool, I just started using one and thought it'd be great to tie into my Tidbyt. Two solutions come to mind for showing the app without the configuration; do you have any preference between the two or other ideas?

Copy a Tilt spreadsheet to a hosted location outside of Google that does not require the API key.
Embed sample JSON data in the app to populate the necessary display values if no API/Sheet link are provided.

I think sample data might be easiest! No need to worry about the spreadsheet disappearing later on that way.
Btw, might be good to add a bit more info to the app description about how to get the key for the sheet as well. Just to make things smoother for users.

Sounds great! I've added sample data to the app, which will now work without user configuration. I also updated the manifest file to include a link to Google's instructions on creating an API key. Let me know if you would like to see any other changes.


Feat/srgb_to_xyz

Lymui
Totoro is going to review your PR

What does this PR accomplish

[x] Add a new feature supporting a new color type
[x] Add a new binding supporting for a type color
[x] Provide a fix to the current project
[x] Add new test

We will check that

[x] Make sure to have unit test
[x] Make sure that any test is passing
[x] Make sure to respect that when converting a type T to return a type T Rgb

🐷 Thanks for contributing ! 🐷

Pull Request Test Coverage Report for Build 433

58 of 59 (98.31%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 96.217%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lymui/srgb.c
21
22
95.45%

Totals

Change from base Build 429:
0.05%

Covered Lines:
1984

Relevant Lines:
2062

💛  - Coveralls


V8 compile scripts if reused?

Not sure if this is a JSPool thing or a React.net thing but been reading about compiled scripts. From my understanding these are the parsed version of a script, that parsing takes time so by caching the resultant "byte code" and passing that into the ClearScript engine you can save on that parsing time. As the user scripts are re-used over and over it might be worth looking into saving these down as compiled scripts and then using them when initialising the engines?
Again might be more performances savings here due to them being re-used over and over.
Side note, this a great code base, real easy to poke around and the fact we are raising this minor tuning tweaks is only a good thing. Great work @Daniel15

At the moment, I think it would have to be added to JavaScriptEngineSwitcher first, as that's the abstraction layer I'm using for JavaScript engines. Perhaps I should switch to using V8 directly rather than JavaScriptEngineSwitcher? I'm using two different V8 integration libraries (ClearScript on Windows and a fork of VroomJs on Linux and Mac OS) so I'd still need an abstraction layer of some sort.

Side note, this a great code base, real easy to poke around and the fact we are raising this minor tuning tweaks is only a good thing. Great work @Daniel15

Thanks! :D

I think the pooling provided by JSPool should be sufficient for now. If we wanted to implement better V8 compilation then either that should be added to JavaScriptEngineSwitcher or we should switch to using ClearScript (for Windows) + VroomJs (for Mac OS and Linux) directly. I like the abstraction layer JavaScriptEngineSwitcher provides, but it makes it more difficult to do anything engine-specific.

I found the additional repo for JavascriptEngineSwitcher needed to do our debugging and optimising a bit of a chore plus the chances of getting PR accepted get stretched as our stuff is pretty specific to V8. As the code is only parsed once then left in the pool the gains of compiling would be minimal I suppose.


[OpenAI-Assistant] Added support for 2024-07-01

close: https://github.com/Azure/azure-sdk-for-java/issues/41195

Fixed the breaking change and re-recorded the tests with 2024-07-01 service API version
Added 2024-07-01-preview support for Assistants.

API change check
APIView has identified API level changes in this PR and created following API reviews.
com.azure:azure-ai-openai-assistants


'startindex' option not working

I'm trying to make the first thumbnail active by default. I have this code:
fotorama.setOptions({
  startindex: 0
});
fotorama.load(aData);

However, the fotorama is still initiated with the 6th thumbnail (last) as active. The only way for me to set the first thumbnail active is with this code:
fotorama.load(aData);
fotorama.show(0);

However, this is not ideal because when the page first loads, I can see it showing the 6th thumbnail first, then quickly slide back to the first thumbnail.

UPDATE: My current workaround is the code below, but it would still be better if setOptions( startindex:0 ) works as expected.
fotorama.load(aFotoramaImages);
fotorama.show({
  index: 0,
  time: 0
});


Error: Transport endpoint is not connected

Hi, I'm using pylibmc for my project which involves a lot of parallel processes each writing some data to the memcache, when I reduce the number of processes things work fine but when I increase the number of processes, I keep getting similar errors like the following:
  File "parallel.py", line 523, in <module>
    update_features()
  File "parallel.py", line 323, in update_features
    features = extract_from_mc(features, mc, "edge", "features_edge", 1, len(keypoints)+1)
  File "parallel.py", line 432, in extract_from_mc
    var[str1 + str(index)] = mc.get(str2 + str(index))
pylibmc.Error: error 26 from memcached_get(features_edge1): Transport endpoint is not connected

Please let me know if I need to provide extra details. Thanks.

This string does not occur in the libmemcached source code. Are you using SASL? Which version of libmemcached? Binary protocol? Etc.

On 13 May 2019, at 11:51, Rishabh Agrahari<EMAIL_ADDRESS>wrote:
Transport endpoint is not connected

Hi @lericson thanks for your quick response. I'm pretty new to all these. I installed memcached version 1.5.6 by apt-get, installed pylibmc with pip. I'm following the default configuration of mc client as mentioned in the docs as pylibmc.Client(["<IP_ADDRESS>"], binary=True, behaviors={"tcp_nodelay": True,  "ketama": True})
I need to check for SASL as I don't really know what that is. I'll get back to you soon.

I don't thing I'm using SASL. I've started memcached demon using the following command: memcached -u memcached -d -m 1024 -I 128m -l <IP_ADDRESS> -p 1111

I'm indeed using binary protocol.
Every once in a while, I also get error about bad data chunk, here's a traceback.
Traceback (most recent call last):
  File "/home/ags/miniconda3/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/home/ags/miniconda3/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "multi-processing.py", line 297, in get_features
    mc.set("features_edge%s" % str(edge_index), edgewise_keypoint_features)
pylibmc.ClientError: error 9 from memcached_set: (0x561ecf2c8c40) bad data chunk,  host: <IP_ADDRESS>:1111
Traceback (most recent call last):
  File "multi-processing.py", line 523, in <module>
    update_features()
  File "multi-processing.py", line 323, in update_features
    features = extract_from_mc(features, mc, "edge", "features_edge", 1, len(keypoints)+1)
  File "multi-processing.py", line 432, in extract_from_mc
    var[str1 + str(index)] = mc.get(str2 + str(index))
pylibmc.Error: error 26 from memcached_get(features_edge1): Transport endpoint is not connected

I used pymemcache and It worked. I had to handle covert numpy arrays to python lists though as they are not JSON serializable. Thanks @lericson for your help.


XR doesn't exist in bin

Installed using:
composer require --dev chevere/xr
(also tried without --dev)
it installs psr7 in main deps (which I don't really want)
but nothing in the bin:
ls vendor/bin

xr command not found

@rodber
Thanks for the update. So to be clear I need to install xr and xr server?
I don't understand why it's getting added as a composer main req. It can be / should be a package requirement. And at very least added to dev reqs only

XR is a server side debugger, it needs a server and a client. This is the client package, the one you add in your project.
XR server is a dev requirement in this package, I've no intention on making it a main requirement. For the server you can pick among a dependency server, a source server and a docker server, suit your needs.


Porting problems from RosettaCode

I cannot get bin/js2json_challenges.js running. Is gulp watch-dev working for you?
I get Syntax Error: Unterminated template. Looks like it's pointing to Element-wise operation challenge.

I use npm run watch-dev to start watch-dev and it does work.
I will check the Element-wise operation challenge.
Earlier it didn't show any errors on watch-dev or in the unit testing.

Earlier as in when I made the pull request for the challenge.

I ran watch-dev again. It shows no error. Can you remove the Element-wise operation challenge script and check if the error persists?


Fix FKFields not being converted from hex to binary when used as the PK.

1. Why is this change necessary?
When the primary key of an entity is a single FKField, using the constructor argument of Criteria won't work, because the hex representation of the ID is not converted to binary, causing the SQL query to find no results.
2. What does this change do, exactly?
It converts hex to binary for FKFields when previously this would only happen with IDFields.
3. Describe each step to reproduce the issue or behaviour.
Try searchIds on the 'theme_sales_channel' entity.
$criteria = new Criteria([Defaults::SALES_CHANNEL]); $themeSalesChannelRepository->searchIds($criteria, $context);
4. Please link to the relevant issues (if any).
5. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[ ] I have written or adjusted the documentation according to my changes
[X] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

Duplicate https://github.com/shopware/platform/pull/714

closed in favor of #714


feat: drop support for python 3.8

Description

Related issue: #1030

I did not touch the files, that pre-commit is complaining about. What is happening?

An observation: Is the lint step in ci still needed with pre-commit.ci enabled?

An observation: Is the lint step in ci still needed with pre-commit.ci enabled?

that pre-commit.ci is currently only still in the dependency-updates enabled (https://github.com/rdmorganiser/rdmo/pull/1154)
Maybe this PR should be branched off  and merged into dependency-updates?
those linting errors actually make sense, since those typing errors only apply from 3.9 on,
(https://docs.astral.sh/ruff/rules/non-pep585-annotation/, https://peps.python.org/pep-0585/ )
However, I think that I should fix those typing linting errors since I started adding typing to my features..
Think it's better to make this PR target to dependency-updates and fix the linting errors there.

Interesting. I will switch the target branch then.

Done.


Is there a changelog anywhere?

Expected behavior
N/A
Actual behavior
N/A
Steps to reproduce
N/A
Really, I'd just like to know what changes in each version before upgrading to a potentially broken version.

You can check this https://github.com/Hacker0x01/react-datepicker/releases
(As for me it's broken now, don't upgrade yet)

For 2.1.0, there isn't any description, and the commit representing the change is just a version bump. 😭

I guess I forgot to add, but you can simply check out the commits done between 2.0 and 2.1.


Add model cache path option to Docker run instructions in readme

I haven’t thoroughly checked where the models are stored, but it seems the tiny and large Whisper models inside the container are located at:
/config/.cache/huggingface/hub/models--Systran--faster-whisper-tiny
/config/.cache/huggingface/hub/models--Systran--faster-whisper-large-v3

Meanwhile, the VAD files appear to be stored at:
/config/.cache/torch/hub/snakers4_silero-vad_master/src/silero_vad/data

Given this, I thought it would make sense to simply mount the entire .cache directory.


Create EGA DAC when REMS DAC is submitted

Proposed solution

Rems integration replaces the need to submit EGA DAC, but we could create the DAC EGA object automatically when a REMS DAC is created.
nb: Possibly, need to verify that this is really necessary.
DoD (Definition of Done)

EGA DAC object is created when a REMS DAC is submitted.
Testing

I think we need to get the first contact from a REMS workflows (name, email and organization), application link (REMS application link) and title of the Workflow as the DAC title in our submission


[PUI] Fix licensing dialog

This helps if the licensing for either platform is not available or empty; currently, the modal just crashes.
Discovered during #6987

Thanks @matmair


Multiple levels of owned entities cause incorrect state when doing bulk insert

Minimal reproduction is here:
https://github.com/armw1/BulkInsertBug
As you see in there repo bulk inserting Person_Bug causes FirstName and LastName to be null.

Only first level of Composition is supported.
You could try a workaround explained: https://github.com/borisdj/EFCore.BulkExtensions/issues/167#issuecomment-476737959 Dupe


Null behaviour of begin method

The begin method in the RepositoryConnection specifically states that it handles null as an isolation level, while the same method in the SailConnection does not say this.
If the begin method in the SailConnection should handle null it should be:

documented
tested

We should also consider making "getDefaultIsolationLevel" a required method in the Sail, since it would then be required to be able to support nulls.
We should also remove any unneeded null handling, like in the SchemaCachingRDFSInferencerConnection where we check if the isolation level is null, even though we could just pass null to super.begin.

My current take on this is that I agree it should be documented that it accepts null, and that if null is supplied, the Sail should fall back to its default isolation level. This would also be easy to write a simple test for (the SailIsolationLevelTest class would be a good spot for it I guess).
I'm not sure what you mean with making getDefaultIsolationLevel a required method - it's defined right in the Sail interface so it currently already is a required method.

I think it shouldn't take null.

I think it shouldn't take null.

Why is that?

Because we have two begin methods. One that takes an isolation level and one that doesn't. It makes a lot more sense to require an isolation level when there is a method specifically designed to handle the cases where you don't have an isolation level.

Furthermore, starting a transaction explicitly with null as the isolation level should be equivalent to specifying NONE, since null feels a lot more like NONE than it does "unknown" in Java (unlike SQL).

Alternatively we deprecate the begin() method (without any arguments) so that we in the future are left with only one begin method in the sail, but multiple in the repository api signaling that the repository api is for targeted at users while the sail api is targeted at implementers and is thus as concise as possible.
I actually prefer this approach to be honest.

Because we have two begin methods. One that takes an isolation level and one that doesn't. It makes a lot more sense to require an isolation level when there is a method specifically designed to handle the cases where you don't have an isolation level.

To be honest if we were designing this from scratch I would probably agree with you that a null-check is more elegant, but it's been implemented for quite a while now to accept null as an argument. My concern is mostly that changing the (admittedly implicit) expectation to one where null is not accepted as an argument can lead to errrors in third party code.
As an aside: the reason we have two begin methods is itself a backward compatibility issue: transaction isolation levels were introduced much later than the notion of transactions itself.
Anyway, at the end of the day I'm fine with either approach. We can go ahead and make non-null argument mandatory at the sail level, and if someone complains about their code suddenly breaking we can point out that they were relying on undocumented behavior (so we can argue that it's not a backward incompatible change). I don't know how likely it is that this will happen, just be prepared to not make friends if it does occur.
As for deprecating begin() in the SailConnection: I don't mind, and the 'minimal internal interface' argument makes sense. On the other hand it's properly documented what isolation level it uses, it's not really in our way and we can easily implement a default method in AbstractSailConnection that properly handles it, so sail implementors don't have to override. So while I'm fine with deprecating it and avoiding using it ourselves, I'm not in any rush to remove it in the next major.

I'm actually thinking we should both deprecate the empty begin method and at the same time remove support for null in the begin method with isolation level. At the same time we should also introduce a getDefaultIsolationLevel method to the SailConnection. That way there is no way for an implementer to start a transaction without specifying an isolation level.

I think that's what I suggested in the end as well. Except getDefaultisolationlevel already exists. At the sail level. And I don't see any benefit to moving it to the connection.


Change run-expression! to return nil if expression failed to run

condition-match checks the result of run-expression!
In case of expression failure, what was checked is the success of an sp/send!

Good catch, thanks!


Jenkins: Set a standard locale (LC_ALL/LANG)

2018-06-16 02:25:41.255 | [1.7.x] perl: warning: Falling back to the standard locale ("C").
2018-06-16 02:25:41.255 | [1.7.x] perl: warning: Setting locale failed.
2018-06-16 02:25:41.255 | [1.7.x] perl: warning: Please check that your locale settings:
2018-06-16 02:25:41.255 | [1.7.x] 	LC_ALL = (unset),
2018-06-16 02:25:41.255 | [1.7.x] 	LANG = "C.UTF-8"
2018-06-16 02:25:41.255 | [1.7.x]     are supported and installed on your system.

https://jenkins.znc.in/job/cron/job/crowdin/269/console

I've upgraded the FreeBSD image used. The warning disappeared.


Add ncmpcpp among tha available players

Hi @trizen, do you think it is possible to add ncmpcpp among the available players besides vlc and mpv?

Hi. I'm not familiar with ncmpcpp. Try to add it in the configuration file to see if it works. It must support playing of files by URL.


Add kunalsheth/units-of-measure

A type-safe dimensional analysis library for Kotlin.

Would you consider publishing the library to one of the following platforms?

Bintray
Jitpack
Maven central
Sonatype

The script that generates the content from the JSON files supports only these repositories ATM (we can update the script, but I wanted to ask you first).

I will publish on Maven Central once the library is more complete.
Thanks for looking into this.


Implicit conversion from json::string to std::string_view

Fix #538

Because this is an implicit conversion I'd like @pdimov or @glenfe to weigh in on whether there are situations where a cycle of conversions could cause compilation errors or unexpected results.

It's already present in standalone.

Looks good

We need a CHANGELOG.md entry

"json::string is convertible to string_view" would be my choice of commit message


Generated code is not valid from schemas w/ scalar array

Hi, given the following schema:
table List {
  people : [Person];
}

table Person {
  firstName : string;
  lastName : string;
  luckyNumbers : [int];
}

root_type List;

From that the generated Swift 3 code can't be compiled. It's because getVectorScalarElement method (which reads the int array) returns an optional but the caller method expects an unwrapped type. So unwrapping/nil cases are not handled.
In the Swift 2.3 branch it has worked well.
Could you recommend any solution? Thanks!

Hi Tamas,
thank you for reporting I will add such case to unit tests and solve the problem ASAP.
Meanwhile if it is urgent for you, you would have to fix the generated code manually.
I hope to provide the fix today.

Just pushed a version which improves the way Vectors are handled in FlatBuffersSwift.
The generated code has however slightly different API.

@mzaks thanks for the fast feedback. 👍
After pulling the updated generator the output contains two undeclared types (FlatBuffersDirectAccess, FlatBuffersTableVector) so still can't be compiled.
Am I doing something wrong? 🤔

Sorry forgot to update the FlatBuffersReader in the code generator. Should be fixed now.

Thanks for the help, really appreciate!


Offer creation and confirmation modal

Okay, since we are moving from sliding animation for better responsiveness, here is a modal for offers
Main

I will continuously update this file with other modals like transfer, change price, etc https://www.figma.com/file/JXNtryaNYhY0XJNArzvPQx/Handoff?type=design&node-id=1458%3A19091&mode=design&t=pLbuEFyq5yIOXpXF-1

Functionality

it pop-ups whenever you are connected, does not matter if you have funds or not
is then split into three flows

user filled out everything and is valid - make offer button active
the user does not have enough balance for the offer he filled out - disabled button with tooltip on hover
the user does not have any funds at all - button changes copy to: no "asset" on "network". The tip underneath is displayed.

Modal

shares lot of similarities with the confirm modal
top part is the same across all of them
then there is nft you are placing offer to - collection name, name, listed price
some additional data that should help you decide what is good offer amount, best offer on this specific nft and then collection floor

offer input

under is balance

the input behaves like this component, only change here is the placeholder text - its k-shade in case of light mode - used k-grey in the offer expiration date calculator

it would be nice to add the functionality for the balance so that if you click that, the input will be filled with the max balance

Offer expiry

by default, there would be 7 days
works like a dropdown selector

input has hover effect

note that there is also time when the offer expires - current time + offer length (in this case 14 days)

button in the dropdown has normal hover effects

Dark mode

added in figma

I can offer a smooth offer creation modal. 🤔

waiting for offer system on nft pallet

waiting for offer system on nft pallet

update: won't happen on assetHub, will be doable on parachain

Offers are ready on AH :P


Modify login bg image position about skinnable

Modify login background image position

Coverage increased (+0.1%) to 64.514% when pulling 3c4227765162be35d13b68627e5ac5b6b80e9a78 on pengpengshui:skinnable into 9a2b522a2f30ae811434e75c7141c08c3c55759d on vmware:master.


Fix: show all public ips on the farm

Description

pagination is no longer supported on this table #2713, but its logic was still  and I just removed it,

Changes
remove pagination logic and now all ips are listed
Related Issues

#2845

Documentation PR
For UI changes, Please provide the Documetation PR on info_grid
Checklist

[ ] Tests included
[x] Build pass
[ ] Documentation
[x] Code format and docstrings
[ ] Screenshots/Video attached (needed for UI changes)

https://github.com/threefoldtech/tfgrid-sdk-ts/issues/2886
https://github.com/threefoldtech/tfgrid-sdk-go/issues/1067
https://github.com/threefoldtech/tfgrid-sdk-ts/issues/2884
this pr is just fixing the listing issue, not supporting the pagination, the mentioned issues should handle that


Fix texture build error

Tizen not support  pixel buffer texture, add empty implementation to fix build error.

@xuelian-bai Done? We must at least resolve the header file naming conflict as I said before.

@xuelian-bai Done? We must at least resolve the header file naming conflict as I said before.

I have changed file name(shell/platform/tizen/public/flutter_texture_registrar.h -> shell/platform/tizen/public/flutter_tizen_texture_registrar.h).


[ bug Report ] Sophia-Leigh behaviour and issues

TombEngine version
v<IP_ADDRESS> (Latest Release)
Tomb Editor version
v1.7.2
Describe the bug
Sophia-Leigh is behaving odd and the setup for her isnt clear. #969
OCB Reference.
The comments in the code states:
Normal = 0,			 // Move, climb, attack, and chase player.
Tower = 1,			 // TR3 one, with climbing only.
TowerWithVolume = 2, // TR3 one, but uses volume to move instead of height check. Must increase/decrease creature->LocationAI to go up/down.

(https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L128)
General bugs
Can be blown apart by explosive weapons.
OCB 0 bugs

Will follow the path of AI_X1 if she can reach them then when she has reached the end: she will run around and do what she likes.

https://github.com/user-attachments/assets/347274d6-cd23-4f55-93a1-a611e1bc1b40

OCB 1 Bugs

Pathfinding is broken.

Same as above. If player is nowhere near the last AI_X1 that Sophia can reach on her path: she will just back to another portion of the path she can take.

Does not fire at player until the end of her path.

Does not height check to see if player is above or below her. No matter what: she will just continue on her path.

The code here does suggest that Sophia should check if player is above or below her and move accordingly but this does not happen
https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L290

If player is near: Sophia will attack but will not care if there is an obstacle and will continously fire at player.

OCB 2 Bugs:
The same bugs apply as OCB 1 but I also would like clarification on the intended setup that is meant to be used here. The brief detail is that Sophia's ascent is controlled via volumes in Tomb Editor. Which node exactly? There are none that seem applicable.
General comments
There are itemflags in the code but can the itemFlag for making Sophia fire where she is triggered be clarified (if it is not enabled?)
https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L701
Several instances of magic numbers used in the code:
https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L685C59-L685C61
https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L648
https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L649
https://github.com/MontyTRC89/TombEngine/blob/60f3c3d8c5bd1fe40337ff2c52be55b4bd905fab/TombEngine/Objects/TR3/Entity/SophiaLeigh.cpp#L473
Minimal reproduction project
Download here
Sophia has OCB 1.
If production files are needed then please comment and I will provide.

Exploding Sophia fixed by Lwmte : https://github.com/MontyTRC89/TombEngine/commit/87b9c3caacf188d21d2dbffd52c4afb4ab4db1ba

Updates:
Since it was identified there was a bug in the pathfinding: I have rested the above.
OCB 1
Distance / height check too small
Sophia will still follow her AI_X1 path, but when she reaches the end: she will start descending and the code for the height check is failing.
However: further testing is showing that Sophia is not finding Lara until she is closer to her:}
To test this: I have activated Sophia at different distances away from Lara.

6 Blocks away

Doesnt recognise Lara

5 blocks away

Doesnt recognise Lara

4 blocks away

Doesnt recognise Lara

3 blocks away

Doesnt recognise Lara

2 blocks away

Doesnt recognise Lara

AI Notes
What is happening is that Sophia is going to the end of her path , as dictated by the AI_X1 nullmeshes. Once she reaches the end : she will then find Lara. This is incorrect because she is supposed to find Lara and move to her level to attack her.
Comparison with TR3
Running the same exact setups in TR3 results in Sophia tracking where Lara is and if she is above Lara: she will aim and fire at her. This is shown here: https://cdn.discordapp.com/attachments/1072569001986773023/1309942886304845885/2024-11-23_18-02-58.mp4?ex=67436ae1&is=67421961&hm=0114d8f2cb83b22d81316459a44c53b0b95105837977f93b7d626e9e790fca26&


ENYO-5047: Add QA sample for ExpandableList with default selection

Issue Resolved / Feature Added
QA-sample add default selected ExpandableList
Links
ENYO-5047
Comments
Enact-DCO-1.0-Signed-off-by: Teck Liew<EMAIL_ADDRESS>

Added back the old sample that was replaced by the new one. Otherwise, LGTM!


Update integration tests to use new testing framework

Use cargo xtest and bootimage runner instead of the old bootimage test for testing. See https://os.phil-opp.com/testing/ for more information on the approach.

bors r+


Creating tutorial

closes #40

Might need to cookiecut API again so that the tutorial.rst shows up on the documentation

@cadenmyers13 I merged this but I expect you need to add the tutorial to the top level pages for it to appear in the left panel etc.  Cookicuttung won't do that. It just autobuilds the API docs from the docstring s


Improve the method to retrieve progenitor

https://github.com/z3z1ma/dbt-osmosis/pull/83 added progenitor information to meta, and I found that progenitor (and column description) is wrong in some cases.
A typical case is the following.
graph LR;
  A.myColumn --> B.my_column;
  B.my_column --> C.my_column;

From the above figure, the true progenitor of C.my_column(snake_case) is A.myColumn(camelCase). But current implementation does not care about this kind of column lineage, so it outputs B.my_column as the progenitor of C.my_column.
I have improved the method to get the progenitor.

@z3z1ma By the way, I would like to see a test of dbt-osmosis to make sure I am not unintentionally breaking existing behavior, as well as this improvement and the pull requests I recently sent. I use dbt-osmosis for BigQuery, and I'm always sending pull requests with a sense of dread to see if the behavior in Snowflake has gone awry 😅.
I know there are some functions that are hard to test, but I think staticmethod functions are relatively easy to write tests for and can be tested on GitHub actions. If you would like, I will send another pull requests in the future to add these types of tests, but I would like to hear your thoughts.

Yeah 100%
Its quite the hill to climb, the tool was originally composed in such a way that we wanted as little code as possible, it would perform its function and be feature complete until internal dbt-core changes eventually break it. It was tested functionally on many dbt projects including a huge internal one pretty much constantly -- which is what kept it stable with all my tinkering. Now my attention is split on some new data engineering efforts, so tests here would be a boon in order to move faster on interesting features. Its the only thing I think that plays with dbt internals and the Graph in this way. cc @syou6162

@z3z1ma OK, I'll add more tests after this pull request is merged!

@z3z1ma Thank you for your advices! I have corrected the points you pointed out.