feat: introduce monorepo with filters package included

Changes Added.

Turborepo Added.
Converted the generator repo to app,  inside the turborepo.
Added the required scripts of the turborepo to the root package.json file.

Related issue(s)
Resolves https://github.com/asyncapi/generator/issues/1044

@asyncapi/bounty_team

Some stuff needs update because of docs related links and automation:
* doc hooks.md need update of links pointing to GH that would break, change them to relative link from website, which will be `/docs/tools/generator/api`

* workflow update-docs-in-website needs an update of link that now point to `/generator/docs/`, and probably should point to `/generator/apps/generator/docs/`

in first point you mean https://github.com/asyncapi/generator/blob/master/docs/api.md to https://github.com/asyncapi/generator/blob/master/apps/generator/docs/api.md

@AyushNautiyalDeveloper no, it just should be /docs/tools/generator/api as I wrote, a relative link, asyncapi.com relative - add it to asyncapi.com and you will see what I mean -> https://www.asyncapi.com/docs/tools/generator/api
links in docs do not have to work in github in markdown, they need to work in website, where people read them

@derberg

updated all the links.
The Integration tests are working now.
The npm ci is working fine.

@derberg

We need gitignore in the apps/generator for the  test file that we dont want to be pushed. also adding those commands in root gitignore will not be applicable to all the apps. And also having multiple gitignore files for the turborepo is common pattern
updated the readmd file to correct place. Also I guess the readmd file for the generator should move to generator itself. so that we can add general
Added the required files to root.

Also i found that the test are not running properly with the current version. the issue is still not fixed
finding ways to run the tests.correctly.

@ayushnau how is it going, do you need anything?

This pr is moved to https://github.com/asyncapi/generator/pull/1213

/unbounty


%~dp0 instead %cd%

Beter to use %~dp0 - disk+path of script instead %cd% - current location (like pwd:UNIX )
because of c:\server\www>c:\server\start-wpn-xm.bat not working.
Option: Please short up script names to start, stop, restart or wwwstart, wwwstop, etc - its more easy to type in console (whatever name of your product in every header of bat file).

Good catch! I will change it.

[ ] switch from %cd% to %~dp0
[ ] shorten batch filenames


redundant FormsModule imports removed

Coverage remained the same at 94.528% when pulling 4982bc518cdaaafaa42efd0f8df2a5bdc1db80eb on development into 64862d79bed57cc336666985a08866cb89568011 on master.


[Minor][DOC]:fix comments typo and grammar issue in Flight.proto

When reading the Flight.proto comments, I found some typos and grammar issue. This PR is simple fix to the comments.

The failure message seems irrelevant.

Retest please


Updated Dockerfile to the latest versions of delta-spark [v2.3.0] and deltalake [v0.8.1]

Also the base container has been changed to official OSS Apache Spark v3.3.2 image.
Pandas version has been updated to the latest compatible version supporting Delta Spark v2.3.0.
Updated README as well to reflect these changes.
Tested all the steps end to end and also ran lint to fix any formatting issues.
Also fixes #44

thanks @P7h - will review shortly!

@P7h could you please review the branch conflicts and resolve them first?

BTW, I did a quick test of the instructions, Python, Rust, and ROAPI and it works great.

@P7h could you please review the branch conflicts and resolve them first?

Resolved the conflicts. And also tested the dockerfile and ran through all the steps in the README - all fine.


iDeprecationWarning if volto 17 last version run with nvm use 20.17.0

nvm use 20.17.0 got Warning:
🎭 Volto started at <IP_ADDRESS>:3000 🚀
(node:3245) [DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated
(Use `node --trace-deprecation ...` to show where the warning was created)

nvm use 20.16.0 is ok.
OS: Ubuntu 24.04

What does node --trace-deprecation ... show?


PrePassRenderer fails to rebuild

The PrePassRendererSceneComponent.rebuild method is implemented like this:
/**
 * Rebuilds the elements related to this component in case of
 * context lost for instance.
 */
public rebuild(): void {
    // Release textures first
    this.scene.disablePrePassRenderer();

    // Re-enable
    this.scene.enablePrePassRenderer();
}

However, on this PG: https://playground.babylonjs.com/#PIZ1GK#172
if you try to execute scene.disablePrePassRenderer(); this.scene.enablePrePassRenderer(); in the console, the SSR does not work anymore.

@CraigFeldspar any update?

@deltakosh as seen offline with @Popov72, nothing bad yet, but impacts WebGPU. Will check what's wrong as soon as I'm done with #10109

prepass works well, but SSR doesn't seem to get any valid texture output, probably it is still feeding on the disposed ones. I'm looking a bit deeper to see if it is a problem we should take care of inside the prepass, or on the postprocess level.

got it, SSR stores prePassRenderer as a variable on its creation, meaning it doesn't update when we rebuild the prepass renderer, I'll open a PR


JQuery Dependancy - NPM issues

Hey,
I would like to be able to require('slick-carousel') without also needing to require('jquery'). I do not want to require jquery, it would be much more sensible for me to use a cdn of jquery as most browsers will then already have it cached.
(function(factory) {
'use strict';
if (typeof define === 'function' && define.amd) {
define(['jquery'], factory);
} else if (typeof exports !== 'undefined') {
module.exports = factory(require('jquery'));
} else {
factory(jQuery);
}
}
is I believe what is causing the issue, there are a lot of suggestions online suggesting you go in and change the npm code to make it work, but that defeats the point of using npm so I do not want to have to do that. If you could find a way to resolve this it would be great! Thanks :).

+1

+1

+1

Makes sense to me!

+1

Its the right way to "require" jquery if a module system like CommonJS is available. When using a module system you want to avoid global modules.
If you are using CommonJS (which brings this require() thing), you are also using a bundler like browserify or wepack to make your code browser compatible. And this is where you have to inject your jQuery form the CDN. In Webpack this is done via a external definition with browserify you can use browserify-shim.
Hope this helps.

Spent a bit of time diggin into this; this UMD pattern for jQuery (discussed here) seems like it might be as universal as it gets, but I'd definitely want to test with a few different build scenarios.
// Uses CommonJS, AMD or browser globals to create a jQuery plugin.

(function (factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD. Register as an anonymous module.
        define(['jquery'], factory);
    } else if (typeof module === 'object' && module.exports) {
        // Node/CommonJS
        module.exports = function( root, jQuery ) {
            if ( jQuery === undefined ) {
                // require('jQuery') returns a factory that requires window to
                // build a jQuery instance, we normalize how we use modules
                // that require this pattern but the window provided is a noop
                // if it's defined (how jquery works)
                if ( typeof window !== 'undefined' ) {
                    jQuery = require('jquery');
                }
                else {
                    jQuery = require('jquery')(root);
                }
            }
            factory(jQuery);
            return jQuery;
        };
    } else {
        // Browser globals
        factory(jQuery);
    }
}(function ($) {
    $.fn.jqueryPlugin = function () { return true; };
}));

@micha149 touched on this a bit, but I wanted to reiterate: With regard to Webpack specifically, there's a workaround for the current implementation (1.6.0) using the import loader[https://webpack.github.io/docs/shimming-modules.html#broken-amd].
Getting a fork going for testing would be the next step, if anyone has the bandwidth.

+1

@ethanclevenger91 ,
Just found a solution. Though, I use browserify api through gulp, but it may help you.
I was using wordpress. Hence, I was kind of forced to use the wordpress core's jQuery, available in window object. Using CDN jquery should be the same.
It was generating slick() not defined error, when I tried to use slick() plugin from npm. Adding browserify-shim didn't help much.
I did some digging and found out that require('jquery') was not consistent always.
In my theme javascript file, it was calling the wordpress core's jquery.
But, in slick jquery plugin it was calling the latest jquery from node modules.
Finally, I was able to solve it. So, sharing the package.json and gulpfile configuration.
package.json:
"browserify": {
    "transform": [
      "browserify-shim"
    ]
  },
  "browserify-shim": {
    "jquery": "global:jQuery"
  },

gulpfile.babel.js:
browserify({entries: 'main.js', extensions: ['js'], debug: true})
    .transform(babelify.configure({
      presets: ["es2015"]
    }))
    .transform('browserify-shim', {global: true})

Doing transform 'browserify-shim' was crucial part, I was missing earlier. Without it browserify-shim was not consistent.

Same for me. I had 2 versions of jQuery, one global and one in as a node module. I wanted to use only the global one and remove the module dependancy. Solved it with webpack externals
externals: {     jquery: 'window.jQuery' }

@maxime-aknin Thank you for that, just had that issue, and your solution worked perfectly!


Update storage to 1.3.1.

Did this to update the google-resumable-media dependency to allow for empty files.
See #3685

https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/2754
https://github.com/GoogleCloudPlatform/google-cloud-python/releases/tag/storage-1.3.1


[Bug report] requestPermissionExtend() is always denied if only the READ_MEDIA_IMAGES permission is used, and the READ_MEDIA_VIDEO permission is missing in the manifest.

Version
3.1.1
Platforms
Android
Device Model
Samsung A71
flutter info
[✓] Flutter (Channel stable, 3.22.1, on macOS 14.5 23F79 darwin-arm64, locale en-VN)
    • Flutter version 3.22.1 on channel stable at /Volumes/Private-Data/Working/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision a14f74ff3a (3 weeks ago), 2024-05-22 11:08:21 -0500
    • Engine revision 55eae6864b
    • Dart version 3.4.1
    • DevTools version 2.34.3

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/thanglq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/thanglq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15F31d
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] VS Code (version 1.89.1)
    • VS Code at /Users/thanglq/Desktop/Visual Studio Code.app/Contents
    • Flutter extension can be installed from:
      🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (4 available)
    • SM A715F (mobile)               • R58NC2ZKY9T           • android-arm64  • Android 13 (API 33)
    • macOS (desktop)                 • macos                 • darwin-arm64   • macOS 14.5 23F79 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad • darwin         • macOS 14.5 23F79 darwin-arm64
    • Chrome (web)                    • chrome                • web-javascript • Google Chrome 125.0.6422.142
    ! Error: Browsing on the local area network for iPad của Anhthu. Ensure the device is unlocked and attached with a cable or associated with the same local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)

[✓] Network resources
    • All expected network resources are available.

• No issues found!

How to reproduce?
My app works only with images, so I just required the READ_MEDIA_IMAGES permission in the manifest. When I called the requestPermissionExtend method, it was always denied. Therefore, I had to add the READ_MEDIA_VIDEO permission in the manifest. However, my app does not actually need this permission because it is not working with videos
Logs
No response
Example code (optional)
No response
Contact
No response

Did you set a proper RequestType?

Hi @AlexV525. Thank you for pointing that out. I added the RequestType, and it's working now

Hi. @AlexV525

Did you set a proper RequestType?

Does not work for api less than 29.
The "READ_MEDIA_IMAGES" permission is not enough. It is necessary to add
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28"/>

I don't quite understand why it's necessary to request write permissions if you only need to read.
https://github.com/fluttercandies/flutter_photo_manager/blob/d61bda8a7546b6bbd24896f14da3e2b43a3be2e9/android/src/main/kotlin/com/fluttercandies/photo_manager/permission/impl/PermissionDelegate23.kt#L26

@srnden which means you didn't even look at the README.

@AlexV525, I'm sorry, but I didn't see in the README why WRITE_EXTERNAL_STORAGE is required for Android 9.
https://github.com/fluttercandies/flutter_photo_manager/blob/b3f27d3ba3093c6852d3d7e4b01392b7c6ce09d7/android/src/main/kotlin/com/fluttercandies/photo_manager/core/PhotoManagerPlugin.kt#L154C9-L160C14
In version flutter_photo_manager 2.7.2, WRITE_EXTERNAL_STORAGE was optional, as far as I can see. Everything worked fine for me without specifying this permission. Maybe I don't understand something. If you have the time and desire, please explain.

If you're using an outdated version please upgrade since we've fixed related things starting from v3.1.0.

Hello, @AlexV525
https://youtu.be/cSFHyBvedUU
in video:
emu api 28.
part 1 - pm3.2.0 with WRITE_EXTERNAL_STORAGE, result - authorized (flutter 3.22.2);
part 2 - pm3.2.0 without WRITE_EXTERNAL_STORAGE, result - denied (flutter 3.22.2);
part 2 - pm2.7.2 without WRITE_EXTERNAL_STORAGE, result - authorized (flutter 3.13.9).

Hello, @AlexV525 https://youtu.be/cSFHyBvedUU
in video: emu api 28. part 1 - pm3.2.0 with WRITE_EXTERNAL_STORAGE, result - authorized (flutter 3.22.2); part 2 - pm3.2.0 without WRITE_EXTERNAL_STORAGE, result - denied (flutter 3.22.2); part 3 - pm2.7.2 without WRITE_EXTERNAL_STORAGE, result - authorized (flutter 3.13.9).

Fixed in v3.2.2.


New package: vivainio.RoughGrep

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[x] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree

This implements issue #182569

[!TIP]
Modify your very first comment of this pull request as follows, can help linking this pull request to the related issue. When this pull request is successfully merged, the linked issue can also be closed as completed. ❤
  Checklist for Pull Requests

  - [x] Have you signed the [Contributor License Agreement](https://cla.opensource.microsoft.com/microsoft/winget-pkgs)?
- - [x] Is there a linked Issue?
+ - [x] Resolve #182569

[!TIP]

Your package is published via GitHub Releases.
GitHub Actions is enabled for your source repository.

Are you willing to maintain your package with WinGet Releaser v2? This can simplify your "manifest submission" process and speed up request reviewing and approval.

This application runs, but not from the symlink. Verify while here:

[!NOTE]
Although adding BurntSushi.ripgrep.MSVC as a Dependencies > PackageDependencies, RoughGrep still unable to launch via symbolic link.

diff --git a/manifests/v/vivainio/RoughGrep/3.14.3/vivainio.RoughGrep.installer.yaml b/manifests/v/vivainio/RoughGrep/3.14.3/vivainio.RoughGrep.installer.yaml
index c3df286b0a1..70110e1605d 100644
--- a/manifests/v/vivainio/RoughGrep/3.14.3/vivainio.RoughGrep.installer.yaml
+++ b/manifests/v/vivainio/RoughGrep/3.14.3/vivainio.RoughGrep.installer.yaml
@@ -8,6 +8,9 @@ NestedInstallerType: portable
 NestedInstallerFiles:
 - RelativeFilePath: RoughGrep\rgg.exe
   PortableCommandAlias: rgg
+Dependencies:
+  PackageDependencies:
+  - PackageIdentifier: BurntSushi.ripgrep.MSVC
 Installers:
 - Architecture: x64
   InstallerUrl: https://github.com/vivainio/RoughGrep/releases/download/v3.14.3/RoughGrep-3.14.3.zip

@vivainio - Support for zipped binaries has now been added and is available in the pipelines. This will require you to update your submission to ManifestVersion: 1.9.0 and set ArchiveBinariesDependOnPath: true in the installer node. To keep things clean, this PR is being closed. Please submit a new PR for the latest version of this package. Thank you for your contributions!


Order Parts for Dark Power from Ti

Here is the link to the power module:
http://www.ti.com/product/PTN78020W/samplebuy

I'd recommend consolidating the parts we want to get sampled from TI under 1 issue for ease of ordering by our members

This part is no longer available for free sampling, this issue will remain closed unless that changes


Update installation.md

Hey @securingsincity! Thanks for the PR.
I actually was looking at this the other day and am thinking it will be a good idea to add the documentation.

Note: As shown above, com.google.android.geo.API_KEY is the recommended metadata name for the API key. A key with this name can be used to authenticate to multiple Google Maps-based APIs on the Android platform, including the Google Maps Android API. For backwards compatibility, the API also supports the name com.google.android.maps.v2.API_KEY. This legacy name allows authentication to the Android Maps API v2 only. An application can specify only one of the API key metadata names. If both are specified, the API throws an exception.
Source: https://developers.google.com/maps/documentation/android-api/signup

Is there a chance you can update this PR to take the note above into account?
There are a few other notes we could add about setting up restricted usage where the apps package name and SHA-1 signing-certificate fingerprint need to be added to the list.
I can update the docs with this info after we get this merged in.

Thanks!


Support Latest compileSdk 34 on Isar Flutter Libs

Steps to Reproduce
Please describe exactly how to reproduce the problem you are running into.
While Build the flutter apk.
###Error:

What went wrong:
Execution failed for task ':isar_flutter_libs:verifyReleaseResources'.

A failure occurred while executing com.android.build.gradle.tasks.VerifyLibraryResourcesTask$Action
Android resource linking failed
ERROR:D:\aurvon\aurvon\build\isar_flutter_libs\intermediates\merged_res\release\values\values.xml:194: AAPT: error: resource android:attr/lStar not found.

Details

Platform: iPhone 13 Pro, Galaxy S7, x86 Android Emulator on Windows etc.
Flutter version: [3.24.0]
Isar version:  hive: ^4.0.0-dev.2
isar_flutter_libs: ^4.0.0-dev.14
path_provider: ^2.1.4

[ ] I searched for similar issues already
[ ] I filled the details section with the exact device model and version
[ ] I am able to provide a reproducible example

what solved this for me, adding some scripts to the subprojects section in android/build.gradle:
allprojects {
  repositories {
    google()
    mavenCentral()
  }
}

rootProject.buildDir = "../build"
subprojects {
  //  fix for verifyReleaseResources
  // ============
  afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
      project.plugins.hasPlugin("com.android.library")) {
      project.android {
        compileSdkVersion 34
        buildToolsVersion "34.0.0"
      }
    }
    if (project.hasProperty("android")) {
      project.android {
        if (namespace == null) {
          namespace project.group
        }
      }
    }
  }
  // ============
  project.buildDir = "${rootProject.buildDir}/${project.name}"
  project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
  delete rootProject.buildDir
}

what solved this for me, adding some scripts to the subprojects section in android/build.gradle:
allprojects {
  repositories {
    google()
    mavenCentral()
  }
}

rootProject.buildDir = "../build"
subprojects {
  //  fix for verifyReleaseResources
  // ============
  afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
      project.plugins.hasPlugin("com.android.library")) {
      project.android {
        compileSdkVersion 34
        buildToolsVersion "34.0.0"
      }
    }
    if (project.hasProperty("android")) {
      project.android {
        if (namespace == null) {
          namespace project.group
        }
      }
    }
  }
  // ============
  project.buildDir = "${rootProject.buildDir}/${project.name}"
  project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
  delete rootProject.buildDir
}

it worked! thanks

@f4bio after failing so many git hub actions your solution finally worked for me

Worked thanks a ton

@f4bio worked for me, thanks

worked for me a lot of thanks

it worked! thanks!!!

A problem occurred evaluating root project 'android'.

Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

I also get this..
A problem occurred evaluating root project 'android'.
Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.
any tips on how to fix?

I also get this..
A problem occurred evaluating root project 'android'.
Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.
any tips on how to fix?

Here's the correct order:
`rootProject.buildDir = '../build'
subprojects {
afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
            project.plugins.hasPlugin("com.android.library")) {
        project.android {
            compileSdkVersion 34
            buildToolsVersion "34.0.0"
        }
    }

    if (project.hasProperty('android')) {
        project.android {
            if (namespace == null) {
                namespace project.group
            }
        }
    }
}

project.buildDir = "${rootProject.buildDir}/${project.name}"
project.evaluationDependsOn(':app')

}
tasks.register("clean", Delete) {
delete rootProject.buildDir
}`
project.evaluationDependsOn(':app') should be called as last line.

I also get this..
A problem occurred evaluating root project 'android'.
Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.
any tips on how to fix?

Here's the correct order:
`rootProject.buildDir = '../build'
subprojects { afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
            project.plugins.hasPlugin("com.android.library")) {
        project.android {
            compileSdkVersion 34
            buildToolsVersion "34.0.0"
        }
    }

    if (project.hasProperty('android')) {
        project.android {
            if (namespace == null) {
                namespace project.group
            }
        }
    }
}

project.buildDir = "${rootProject.buildDir}/${project.name}"
project.evaluationDependsOn(':app')

}
tasks.register("clean", Delete) { delete rootProject.buildDir }`
project.evaluationDependsOn(':app') should be called as last line.

I did this but also got the error
* What went wrong:
A problem occurred evaluating root project 'android'.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

I thank you with all my sincierity!

thank you, it works for me , as flutter3.24.1 with isar3.10+1

it's worked fine

I'm still having this error. I did follow the given solution but didn't work.

* Where:
Build file '<PATH>/android/build.gradle' line: 25

* What went wrong:
A problem occurred evaluating root project 'android'.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.```

This is my `android\build.gradle`

```buildscript {
    ext.kotlin_version = '2.0.20'
    repositories {
        google()
        jcenter()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:4.1.3'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = "../build"

subprojects {
    //  fix for verifyReleaseResources
    afterEvaluate { project ->
        if (project.plugins.hasPlugin("com.android.application") ||
        project.plugins.hasPlugin("com.android.library")) {
        project.android {
            compileSdkVersion 34
            buildToolsVersion "34.0.0"
        }
        }
        if (project.hasProperty("android")) {
            project.android {
                if (namespace == null) {
                    namespace project.group
                }
            }
        }
    }
    // ===============================

    project.buildDir = "${rootProject.buildDir}/${project.name}"
    project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
    delete rootProject.buildDir
}

I also get this..
A problem occurred evaluating root project 'android'.
Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.
any tips on how to fix?

Here's the correct order:
`rootProject.buildDir = '../build'
subprojects { afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
            project.plugins.hasPlugin("com.android.library")) {
        project.android {
            compileSdkVersion 34
            buildToolsVersion "34.0.0"
        }
    }

    if (project.hasProperty('android')) {
        project.android {
            if (namespace == null) {
                namespace project.group
            }
        }
    }
}

project.buildDir = "${rootProject.buildDir}/${project.name}"
project.evaluationDependsOn(':app')

}
tasks.register("clean", Delete) { delete rootProject.buildDir }`
project.evaluationDependsOn(':app') should be called as last line.

I did this but also got the error
* What went wrong:
A problem occurred evaluating root project 'android'.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

@Tr736 here's a fix for this error

Thanks a lot man, It works for me when Implementing SendBird SDK

works thanks

what solved this for me, adding some scripts to the subprojects section in android/build.gradle:
allprojects {
  repositories {
    google()
    mavenCentral()
  }
}

rootProject.buildDir = "../build"
subprojects {
  //  fix for verifyReleaseResources
  // ============
  afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
      project.plugins.hasPlugin("com.android.library")) {
      project.android {
        compileSdkVersion 34
        buildToolsVersion "34.0.0"
      }
    }
    if (project.hasProperty("android")) {
      project.android {
        if (namespace == null) {
          namespace project.group
        }
      }
    }
  }
  // ============
  project.buildDir = "${rootProject.buildDir}/${project.name}"
  project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
  delete rootProject.buildDir
}

It works, thanks a lot! But why does it work? What does it actually do? I know the minimum of the minimum of Gradle.

A problem occurred evaluating root project 'android'.

Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

Me too.

A problem occurred evaluating root project 'android'.

Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

Me too.

@ITApexGroup
have you tried this solution: https://github.com/isar/isar/issues/1654#issuecomment-2370930364

what solved this for me, adding some scripts to the subprojects section in android/build.gradle:
allprojects {
  repositories {
    google()
    mavenCentral()
  }
}

rootProject.buildDir = "../build"
subprojects {
  //  fix for verifyReleaseResources
  // ============
  afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
      project.plugins.hasPlugin("com.android.library")) {
      project.android {
        compileSdkVersion 34
        buildToolsVersion "34.0.0"
      }
    }
    if (project.hasProperty("android")) {
      project.android {
        if (namespace == null) {
          namespace project.group
        }
      }
    }
  }
  // ============
  project.buildDir = "${rootProject.buildDir}/${project.name}"
  project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
  delete rootProject.buildDir
}

worked like a charm in one go😍🔥🔥

what solved this for me, adding some scripts to the subprojects section in android/build.gradle:
allprojects {
  repositories {
    google()
    mavenCentral()
  }
}

rootProject.buildDir = "../build"
subprojects {
  //  fix for verifyReleaseResources
  // ============
  afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
      project.plugins.hasPlugin("com.android.library")) {
      project.android {
        compileSdkVersion 34
        buildToolsVersion "34.0.0"
      }
    }
    if (project.hasProperty("android")) {
      project.android {
        if (namespace == null) {
          namespace project.group
        }
      }
    }
  }
  // ============
  project.buildDir = "${rootProject.buildDir}/${project.name}"
  project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
  delete rootProject.buildDir
}

it worked! thanks

It works, thanks a lot! thanks from my soul

it works,  thanks a lot guyes

Thank You so much, It is worked! 100%

worked for me.    great  solution

I also get this..
A problem occurred evaluating root project 'android'.
Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.
any tips on how to fix?

Here's the correct order:
`rootProject.buildDir = '../build'
subprojects { afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
            project.plugins.hasPlugin("com.android.library")) {
        project.android {
            compileSdkVersion 34
            buildToolsVersion "34.0.0"
        }
    }

    if (project.hasProperty('android')) {
        project.android {
            if (namespace == null) {
                namespace project.group
            }
        }
    }
}

project.buildDir = "${rootProject.buildDir}/${project.name}"
project.evaluationDependsOn(':app')

}
tasks.register("clean", Delete) { delete rootProject.buildDir }`
project.evaluationDependsOn(':app') should be called as last line.

thank you buddy its working


WebPack: Relative modules were not found

This Issue is about (delete as applicable)

A problem with my own code

It looks like WebPack cannot find the following files (which exist):
* ../shaders/TextureTint.frag in ./node_modules/phaser/src/renderer/webgl/pipelines/TextureTintPipeline.js
* ../shaders/ForwardDiffuse.frag in ./node_modules/phaser/src/renderer/webgl/pipelines/ForwardDiffuseLightPipeline.js
* ../shaders/FlatTint.frag in ./node_modules/phaser/src/renderer/webgl/pipelines/FlatTintPipeline.js
* ../shaders/BitmapMask.frag in ./node_modules/phaser/src/renderer/webgl/pipelines/BitmapMaskPipeline.js

To try it out yourself check my repo: Kong
The following file contains the pahser code: src/pages/index.vue

Hi. I've tried your project here. I'm not familiar with all the details of Quasar framework but I think these hints will take you in the right direction.
There are a few changes you'll need to perform to make your project work.
First, replace that phaser-glsl-loader with raw-loader. It is the recommended one for use with the included Phaser shaders at the moment. You'll need to update your Quasar configuration like below (don't forget to require('webpack') at the top of that file).
extendWebpack (cfg) {
  cfg.module.rules.push({
    enforce: 'pre',
    test: /\.(js|vue)$/,
    loader: 'eslint-loader',
    exclude: /(node_modules|quasar)/
  })

  cfg.module.rules.push({
    test: /\.(frag|vert)$/,
    loader: 'raw-loader'
  })

  cfg.plugins.push(new webpack.DefinePlugin({
    // Required by Phaser: enable WebGL and Canvas renderers.
    WEBGL_RENDERER: true,
    CANVAS_RENDERER: true
  }))
}

Edit you index.vue to move the preload and create methods inside the scene object. The script will look like this.
import Phaser from 'phaser'

export default {
  data () {
    return {
      config: {
        type: Phaser.AUTO,
        width: 800,
        height: 600,
        physics: {
          default: 'arcade',
          arcade: {
            gravity: { y: 200 }
          }
        },
        scene: {
          preload () {
          },

          create () {
            //  Set this scene background color, so we know it's working.
            this.cameras.main.setBackgroundColor('#336699')
          }
        }
      },

      game: null
    }
  },

  methods: {
  },

  created () {
    this.game = new Phaser.Game(this.config)
  }
}

One thing I couldn't figure out is why a new game instance is added to the page every time you edit the index.vue component, though. I guess HMR is not working properly.

Thank you merry much that relly helped me! :)


refactor(info): increase default log level in development mode

This also shows all request logs, not sure, if that is something that we actually want?
Maybe we need another, lower level, such as silly ;)
Or we could implement hint with a log level of info, so that they will always be visible.

I think these hints provide benefits - why else would we add them?
If we don't want to introduce a new loglevel, I would propose that the doctor checks whether warnings were generated and if so, it should print another line, saying:
This command produced $n warnings. Execute the command again with "-v" to see additional hints on how to resolve those..

Of course the hints are somewhat useful - I am just opposed to printing them by default: one will need to see the warnings themselves every time they are triggered, but the hints only really provide benefits the first time they are generated. After having gotten a hint once, a user will already know what to do about a given type of warning.
Besides that, I would personally prefer improving our docs as opposed to adding a meta-hint such as the one you are proposing. Anyway, feel free to open another PR to deal with this the way you see fit!


Question: can one study Hubbard models with this

I apologize for the naive question, but can this package support Hubbard Hamiltonians or not?  Thanks.

There is currently no native support for fermionic models. One could map the fermionic Hamiltonian to a spin-1/2 one, but all information about symmetries would (likely) be lost. First, this is quite tedious work and as such not very user-friendly. Secondly, loosing information about symmetries would greatly reduce the size of systems which can be tackled.
So I'd say that right now there is no support for Hubbard models, but I have some ideas about potential implementation of fermionic bases, so this feature might be added in the future.

Thanks for the info.  I am really rusty on this topic.  I looked at Hubbard a lot many years ago and saw t-J, etc. in the literature but apparently forgot the higher order bit of which ones were fermionic versus bosonic.


refactor: migrate 'integrations_processor' to python-gitlab library

In this change, home grown APIs related to configuring project integrations have been removed. The integration config processor has been updated to use python-gitlab library.
closes #623

@amimas - lgtm, needs rebase


Fix module name

The example does not work otherwise.

It works. I have renamed the module to rockstar from Rockstar. PEP8 says to have lower case, which I forgot first time. Now I fixed them.


Merge main into dev

Preview is available here:http://soroban-docs-pr263.previews.kube001.services.stellar-ops.com/


Simple Mobile Tools Music Player not getting picked up.

Tracks played via the Simple Mobile Tools Music Player are not appearing in the SLS notification nor in the scrobble cache.
As far as I know, SLS has all the settings (battery, permissions, etc).
Pixel 2 xl with everything updated, including OS.

Hello @astronouth7303
Some apps do not engage with Android's Libraries for music metadata exchange so we cannot pick them up unfortunately.
Your app may fall under this category at this time.


Adding instructions on error reporting.

Added detailed instructions on how to report an issue.
Change-Id: I152bbfffd31e1e10b6830b5662dce730a2c190c6

Looking over that top level readme, it is in desperate need or re-organization, and an update.
This looks pretty good, thanks for tackling this.
But for this particular section you are missing specification for the binary. Did the user compile it themselves? Or download and install it from some place? Also, we could include a little encouragement for the community to participate in the bug reporting process.

Addressed all of the comments in the updated pull request.


Migrate old flags to new system scope for old worlds

Migrate all old flags to new system scope "starwarsffg" for items, actors

Nice 👍


Refactor dynamic validator

https://github.com/Azure/ARO-RP/pull/1595 needs to be merged first.
Adds a simplified constructor for dynamic validator used in the ARO operator.

/azp run e2e

PR accidentaly got merged too early. I'm addressing feedback in https://github.com/Azure/ARO-RP/pull/1619


Emoji as an alternative to images?

Is there any interest from anyone else to be able to use emoji instead of images? E.g. instead of specifying an "imageName" in the design .json file, you'd specify something like:
"warning": {
	"backgroundImageName": "NotificationBackgroundWarning.png",
	"borderColor": "#A28918",
	"borderHeight": 1,
	"buttonBackgroundImageName": "NotificationButtonBackground.png",
	"buttonTitleTextColor": "#484638",
	"buttonTitleShadowColor": "#E5D87C",
	"buttonTitleShadowOffsetX": 0,
	"buttonTitleShadowOffsetY": 1,
	"contentFontSize": 12,
	"contentTextColor": "#484638",
	"emoji": "⛔",
	"emojiFontSize": 16,
	"shadowColor": "#E5D87C",
	"shadowOffsetX": 0,
	"shadowOffsetY": 1,
	"textColor": "#484638",
	"titleFontSize": 14,
	"backgroundColor": "#DAC43C"
}

Perhaps even a way to override the emoji used when actually creating the message?
TSMessage.showNotificationInViewController(self, title: "Thanks for the feedback!", subtitle: nil, type: .Success, emoji: "👍", emojiFontSize: 20)

I like the idea, but TSMessages is not in active development unfortunately. Also, the method headers are a big pain, as there are so many parameters already. This would all be awesome in Swift :+1:

OK, were you thinking of creating a successor to TSMessages yourself in Swift, or is there another library you recommend people move to for similar functionality?

Sorry, I wanted to do that, but never found the time to. I don't know about good alternatives out of the top of my head.


use kpt from main branch

Change it to install from main explicitly. Otherwise it still installs the pre-v1 kpt.

Change it to install from main explicitly. Otherwise it still installs the pre-v1 kpt.

This shouldn't be the case. Are you sure?

Change it to install from main explicitly. Otherwise it still installs the pre-v1 kpt.

This shouldn't be the case. Are you sure?

You're right. We should change this as these instructions are incorrect now:
https://kpt.dev/installation/?id=source

You're right. We should change this as these instructions are incorrect now:

I saw you have already updated it.
I guess if we rename next to master instead of main, it should work and we don't need to specify @main.


jshon: 20140712 -> 20170302

Motivation for this change
This fixes a somewhat critical (security?) bug.
We are trying to get it merged upstream but have had no response from
the ordinary maintainer in over a week.
(See https://github.com/keenerd/jshon/issues/53.)
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Hmm... any idea what causes that kind of error?

@dbrock are you referring to the travis error? It's unrelated, please ignore :)

Would it be sufficient to just apply the fix as a patch? I.e. something like the following
diff --git a/pkgs/development/tools/parsing/jshon/default.nix b/pkgs/development/tools/parsing/jshon/default.nix
index 4b35ba0cce..823aa499d4 100644
--- a/pkgs/development/tools/parsing/jshon/default.nix
+++ b/pkgs/development/tools/parsing/jshon/default.nix
@@ -1,7 +1,7 @@
-{ stdenv, lib, fetchFromGitHub, jansson }:
+{ stdenv, lib, fetchFromGitHub, fetchpatch, jansson }:

 stdenv.mkDerivation rec {
-  name = "jshon-20140712";
+  name = "jshon-20140712-nix1";

   rev = "a61d7f2f85f4627bc3facdf951746f0fd62334b7";
   sha256 = "b0365e58553b9613a5636545c5bfd4ad05ab5024f192e1cb1d1824bae4e1a380";
@@ -12,6 +12,14 @@ stdenv.mkDerivation rec {
     repo = "jshon";
   };

+  patches = [
+    # Fix null termination in read_stream.
+    (fetchpatch {
+      url = https://github.com/mbrock/jshon/commit/32288dd186573ceb58164f30be1782d4580466d8.patch;
+      sha256 = "04rss2nprl9nqblc7smq0477n54hm801xgnnmvyzni313i1n6vhl";
+    })
+  ];
+
   buildInputs = [ jansson ];

   patchPhase =

Thanks @rycee, that's better.
Fixed.

Back ported to 16.09 and 17.03 as well.

Nice, thanks guys!


完成翻译 /content/glossary.md #327

完成翻译 /content/glossary.md #327

@SimonLeeee I believe you meant to target this PR to the webpack-china fork.

@skipjack  Yes, you are right.  I am sorry about that  - - .


added amimations to logo-tiles on clicks

both the prettier script and the pre-commit hooks were failing so I had to commit this with --no-verify 🤠
Now when user clicks anywhere on the page the logo-tiles spin quick 1-by-1 alternating.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Rob-Rychs sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

The spinning wheel is a bit much in my opinion.

Thanks for your feedback @DoctaCloak !
I wanted to contribute somehow with js without adding any new elements and the ms-tiles seemed the logical thing to animate. I also liked how the activated tile reloads with the initial loading animation (that was an unintended side-effect). I think it's cool when some aspect of infinite interactivity are included in the design of splash-pages which is what inspired my PR.


Add an api to edit task; fix #384

Codecov Report

Merging #433 into master will increase coverage by 0.38%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             master    #433      +/-   ##
===========================================
+ Coverage     82.31%   82.7%   +0.38%
- Complexity      321     324       +3
===========================================
  Files           106     107       +1
  Lines          1018    1035      +17
===========================================
+ Hits            838     856      +18
+ Misses          180     179       -1

Impacted Files
Coverage Δ
Complexity Δ

app/Http/Requests/UpdateTaskRequest.php
100% <100%> (ø)
2 <2> (?)

app/Http/Controllers/TaskController.php
82.05% <100%> (+2.63%)
8 <1> (+1)
:arrow_up:

app/Policies/TaskPolicy.php
66.66% <100%> (+16.66%)
6 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 342f5c3...22996a8. Read the comment docs.

Resolves #384


File upload implementation instructions may be incorrect

I am following instructions to implement a file upload on here: https://docs.mendix.com/studio-how-to/pages-how-to-attach-files#2-prerequisites
In Paragraph "3 Creating a File Entity" the following is stated:
1. Open your domain model and open the Toolbox tab.
2. Select the File Entity and drag and drop it to your domain model.

I am using Studio Pro 9.8.2 and when I am in my Module's Domain Model I do not see any "File Entity" in the Toolbox, in fact there are only 2 items in the toolbox "Entity" and "Annotation". The "Prerequisites" also do not state that I ahve to install anything from the Marketplace. So either a prerequisite is left out or the 2 points above are incorrect. Not sure which one? For now I will try to create an entity and set its generalization to System.FileDocument.

Sorry I was on the Studio Guide


fix: track total delegated tokens changes when rewards or fees are collected

Indexer side of the totals should be already taken care of, as restaking for indexers is done through _sendRewards and if restaked, it triggers a StakeDeposited event which takes care of the network totals


Distance and Direction - Creating lines based on distance and bearing always creates a line longer then length parameter value

Widget
Distance and Direction
Version of widget
build 11 Jan 2017 09:51
Bug or Enhancement
When creating lines from distance and bearing the created line is always longer then what the user specified.
In the screenshot below, I set the length to 1000 km, but the labeled line states line is longer then 1000 km. Also tested all the other length units and behavior is the same for all units.

Another verification that the length is longer, is that I created a circle with 1000 km radius centered at 1,1 and the arrow head of the line extends past the circle

Repo Steps or Enhancement details

From line tool, select "Distance and Bearing"
Set Start Point to 1, 1 and hit return.
Set Length to 1000 kilometers.
Set Angle to 90 degrees and hit return.
The label on the created line is longer then 1000 kilometers. Also verified with the Measure widget.

@elinz @nfeuerstein @kgonzago
I have fixed the length issue, the logic in the way the line was being created was not robust enough. Essentially a geodesic circle was created with the radius being the required line length. A line was then created using the center point and the first point of the circle (due north). This line was then rotated using the angle value which is incorrect as a geodesic circle will not be exactly round.
I changed the logic to create a circle with the amount of points required (360 for degrees or 6400 for mils). I then create the line from the center point to the corresponding point in the circle for the angle required. No rotation needed and the point is in the correct geodetic location.
This highlighted another issue that the arrow endpoint on the line is essentially a triangle marker symbol rotated to the required angle for the line. This means the end of the line is actually the center of the triangle and not at its point. the arrow symbol is created using:
arrow1: "m0.5,50.5c0,0 99.5,-41 99.5,-41c0,0 0.5,81.5 0.5,81.5c0,0 -100,-40.5 -100,-40.5z",
I am not sure how you change this to butt join the line. For now i have changed the end symbol to a cross, is this acceptable?

@adgiles @nfeuerstein @kgonzago I'm okay with using the cross if everyone else is. I think it's better to change it from an arrow since the arrowhead was extending past the correct length. With the cross at least it meets with other graphics. For example, I drew a line and circle so they intersect and now the line doesn't extend past the edge of the circle...


docs: update cohere documentation

Description: Update of Cohere documentation (main provider page)
Issue: After addition of the Cohere partner package, the documentation was out of date
Dependencies: None

@ccurme i've taken in all your review comments


Widnows and Mac clients not working with v2ray method

Did anyone manage to use the v2ray method on windows or mac clients?
My server config is correct as it works on iOS and Android.
Also, other Shadowsocks configs which do not use the v2ray plugin, work fine for me.

I'm using the Windows client.
You should download the v2ray  plugin for windows, copy it to Shadowsocks folder and rename it to v2ray-plugin.exe.

Also, check this out. A V2Ray client for Windows, support Xray core and v2fly core. V2rayN.

I installed the shodowsocks on windows and copied the V2ray into the shadowsocks folder as mentioned here.
But it doesn't change my IP. (The IP is the same, before and after the VPN connection, and VPN doesn't work)
Did anyone have the same problem?

I installed the shodowsocks on windows and copied the V2ray into the shadowsocks folder as mentioned here. But it doesn't change my IP. (The IP is the same, before and after the VPN connection, and VPN doesn't work)
Did anyone have the same problem?

There are 2 files for windows, try with the other one:


Now for something different: increase performance with multi-threads/multi processing

Is your feature request related to a problem? Please describe.
Currently processing ~33000 pics of a Photos DB. The full Photos size is ~90000.

It takes about 1.7 hours to process --update phase

Processed: 33764 photos, exported: 0, updated: 0, skipped: 33699, updated EXIF data: 70, missing: 72, error: 0
Elapsed time: 6127.738 seconds

and about 3 hours to process the delete phase
for a total of ~5 hours

[notice] --- Start
Mon 10 Jan 2022 23:52:00 WET
(...)
[notice] --- End
Tue 11 Jan 2022 05:12:07 WET

So, if we extrapolate it could take up to 15 hours to process 90000 pics.
Describe the solution you'd like
Maybe launch in parallel multiple copy tasks? Add a flag for --multiprocessing <n>with the level of processes to launch.
To achieve this in other scenarios I've used with relative success the library multiprocessing on https://github.com/oPromessa/flickr-uploader/blob/master/lib/mprocessing.py
Of course the code must be ware of multiprocessing and use locks to access database and will be dependent of the performance of the underlying HW and LAN.
Describe alternatives you've considered
Hmmm. Launch multiple osxphotos at the same time each with it's own selection/filter process. Problem is that, if each one uses its own .osxphotos_db to avoid concurrency you'll end up deleting each other's pics.
Additional context
I'm copying over a 100Mbps lan (will upgrade to 1Gbps lan shortly) from an iMac (i7, 16GB, ssd) into a Synology DSM 918+.

I've considered this in the past but the additional complexity has kept me from looking more deeply into this.   osxphotos has been optimized for export to the local mac where you're likely to be I/O bound waiting on the disk.  It does use copy-on-write to speed up copying, etc.  I'm not familiar with Synology devices but assuming they cache writes so they can handle multiple simultaneous writes and your network is fast enough, the approach you propose might work.
The export code would need to be updated and this is no small feat (I'm currently in the middle a big refactoring of the export code that will make it easier to change).  Currently, the export code processes all actions serially photo by photo:

download the photo if missing
copy the photo
create sidecars if needed
update with exiftool if needed
process next photo

The cleanup phase happens at the end after all exports are done.

It takes about 1.7 hours to process --update phase

This is surprising given you only exported 70 updated photos.  Doing these 70 copies in parallel is unlikely to make much of a dent in the update time.  My guess is the slow part is checking the file stat of the 30000 images across the LAN & NAS. If this is the slow part, then throwing more processes at may not help much if the NAS can't keep up.
Before tackling a multithreading project I'd suggest doing some profiling to see where the slowdowns are actually occurring.
I'll take a look at your project to see what you did.

Do you space on your local disk to do an export or a partial export? It would be interesting to compare that to the same export on the NAS.

Sorry!!!! rookie mistake I believe the Mac went to sleep half way thru the process. I'll gather more stats with the caffeinate option and come back to you!

A few more thoughts:
The main obstacle to effective multiprocessing in the current design is that the target filename is not fully known until the actual export happens.  The CLI code renders the --directory and --filename templates to compute the intended target but then the export code needs to check to see if an edited version will be exported, will side cars be generated, and does the target already exist and if so, is it in the export database and does it match the source photo or is it a name collision.  With multiple processes exporting, you'd run the risk of name collisions.
If the code to determine name collisions, etc. happened before calling export, you could deterministically know the target file then you could spawn multiple export processes.  One downside with this approach is that you might have some "false" name collisions -- e.g. you thought there would be a name collision but one file was missing and didn't get exported so instead of getting IMG_1234.jpg and IMG_1234 (1).jpg, you got IMG_1234 (1).jpg as the first was missing and didn't get exported.   Some of this would be difficult to work around when using --download-missing but I think having some "false" collisions is better then real collisions.

One other thought -- the export database is implemented in sqlite which handles multiprocessing fine so that shouldn't be an impediment.

Sorry for the delay. Here's a test with 88 pics comparing local SSD vs NAS (100Mbps) vs NAS (1Gbps).Using --update option.

In a nutshell... go 1Gbps :smiley:
The 2nd run on NAS (100) was a tad faster than NAS (1G) possibly due to caching of the NAS Server. The NAS (1G) Server does not have caching. But is residual the difference.

Run
Pics
SSD
NAS (100)
NAS (1G)
Sec/Pic SSD
Sec/Pic NAS (100)
Sec/Pic NAS (1G)

1st
88
37.158
183.095
99.971
0.422
2.080
1.136

2nd run
88
17.630
19.160
19.797
0.200
0.218
0.224

--1st SSD
Processed: 88 photos, exported: 88, updated: 0, skipped: 0, updated EXIF data: 88, missing: 0, error: 0
Elapsed time: 37.158 seconds
--update SSD
Processed: 88 photos, exported: 0, updated: 0, skipped: 88, updated EXIF data: 0, missing: 0, error: 0
Elapsed time: 17.630 seconds

--1st NAS (100Mbps Network)
Processed: 88 photos, exported: 88, updated: 0, skipped: 0, updated EXIF data: 88, missing: 0, error: 0
Elapsed time: 183.095 seconds
--update NAS (100Mbps Network)
Processed: 88 photos, exported: 0, updated: 0, skipped: 88, updated EXIF data: 0, missing: 0, error: 0
Elapsed time: 19.160 seconds

--1st NAS (1Gbps Network)
Processed: 88 photos, exported: 88, updated: 0, skipped: 0, updated EXIF data: 88, missing: 0, error: 0
Elapsed time: 99.971 seconds
--update NAS (1Gbps Network)
Processed: 88 photos, exported: 0, updated: 0, skipped: 88, updated EXIF data: 0, missing: 0, error: 0
Elapsed time: 19.797 seconds

Thanks! This is useful.  I've done some profiling on the export code and found it takes a lot of it's time in the code that validates file names to avoid name collisions so that might be worth a look before tackling something like multithreading.  I can imagine that if going across a network all the remote file lookups would slow things down.  I was also surprised to see the export db is getting opened/closed with each photo.  I'd expected it to stay open so I need to take a look there.  Full profile results attached.
osxphotos export ~/Desktop/export --from-date 2021-01-01
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Exporting 3853 photos to /Users/rhet/Desktop/export...
  [####################################]  100%
Processed: 3853 photos, exported: 372, missing: 3504, error: 0
Elapsed time: 65.114 seconds
         17361339 function calls (16993129 primitive calls) in 83.575 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      4/1    0.000    0.000   83.799   83.799 {built-in method builtins.exec}
        1    0.000    0.000   83.798   83.798 <string>:1(<module>)
        1    0.148    0.148   83.798   83.798 cli.py:1305(_export)
     3853    0.289    0.000   64.202    0.017 cli.py:2634(export_photo)
     3866    0.192    0.000   47.759    0.012 cli.py:3043(export_photo_to_directory)
     3866    0.230    0.000   45.088    0.012 photoexporter.py:483(export2)
     3866    0.043    0.000   40.263    0.010 photoexporter.py:748(_validate_dest_path)
     3866    0.142    0.000   39.708    0.010 utils.py:384(increment_filename_with_count)
     3866    0.104    0.000   38.827    0.010 utils.py:291(findfiles)
   765118   19.986    0.000   32.955    0.000 utils.py:284(normalize_fs_path)
     3866    0.671    0.000   32.654    0.008 utils.py:302(<listcomp>)
        1    0.001    0.001   17.654   17.654 photosdb.py:92(__init__)
        1    8.426    8.426   17.635   17.635 photosdb.py:1618(_process_database5)
     7719    0.075    0.000   13.821    0.002 cli.py:3007(_render_suffix_template)
     3866    0.041    0.000   13.723    0.004 photoinfo.py:1413(render_template)
     3866    0.097    0.000    9.643    0.002 phototemplate.py:354(__init__)
     3866    0.034    0.000    9.438    0.002 export_db.py:763(__init__)
   765131    8.924    0.000    8.924    0.000 __init__.py:77(__enter__)
    79968    8.517    0.000    8.517    0.000 {method 'execute' of 'sqlite3.Cursor' objects}
     3866    0.075    0.000    8.321    0.002 export_db.py:773(_open_export_db)
     3867    0.168    0.000    7.549    0.002 export_db.py:639(_create_db_tables)

profile.txt

Interesting that for the export of 372 files, there were 765118 calls to normalize_fs_path!  Definitely need to take a look at what's going on there.

I've added a hidden --profile option to the export command that enables profiling.  It also has a hidden --profile-sort option to specify one or more sort keys for profiled stats output.  I'll include in the next release.
I made some changes to the filename normalization to minimize calls to normalize_fs_path (which can't be optimized further as it's really only a single line call to an objective-C function).  This has reduced the calls to normalize_fs_path for the test case above more than an order of magnitude from 765118 calls to 11610 calls!
The new --profile flag should make it much easier to start doing some optimization.
Profiling...
Exporting 3855 photos to /Users/rhet/Desktop/export...

Processed: 3855 photos, exported: 372, missing: 3506, error: 0
Elapsed time: 123.597 seconds
Profiling completed
         14850806 function calls (14482537 primitive calls) in 149.191 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    80008   25.722    0.000   25.722    0.000 {method 'execute' of 'sqlite3.Cursor' objects}
     3868   24.039    0.006   37.314    0.010 utils.py:306(list_directory)
        1    9.479    9.479   23.764   23.764 photosdb.py:1618(_process_database5)
   733207    8.455    0.000    9.180    0.000 _convenience.py:131(<lambda>)
        1    4.946    4.946    7.770    7.770 _photosdb_process_searchinfo.py:37(_process_searchinfo)
     3869    3.123    0.001    3.123    0.001 {built-in method posix.mkdir}
     3868    2.783    0.001   11.963    0.003 utils.py:314(<listcomp>)
     3879    2.328    0.001    2.328    0.001 {method 'close' of 'sqlite3.Connection' objects}
    11610    2.283    0.000    4.076    0.000 utils.py:284(normalize_fs_path)
    17255    2.193    0.000    2.351    0.000 {built-in method posix.stat}
     3881    2.065    0.001    2.065    0.001 {built-in method _sqlite3.connect}
     3869    1.944    0.001    1.944    0.001 {built-in method posix.rmdir}

profile_new.txt

I'll use it once available. I still have a few thousand pics to transfer so I'll have plenty of opportunity to test it.

@oPromessa  I've added the --profile to export in v0.44.11.  There are a number of hidden options and commands I use for debugging.  These can now be exposed by setting the environment variable OSXPHOTOS_SHOW_HIDDEN=1, for example, this can be done on command line as:
OSXPHOTOS_SHOW_HIDDEN=1 osxphotos help export to see hidden options for export
or
OSXPHOTOS_SHOW_HIDDEN=1 osxphotos help to see hidden commands

I found the cause of the thousands of unnecessary sqlite calls to the ExportDB code (see #603).  I'll work on that later this week which should cause a bit of a speed up as thousands of sqlite database instances won't need to be needlessly recreated.

@oPromessa I fixed the unneeded sqlite calls.  Try version v0.44.13 next time you export photos with the --profile flag.  On my quick testing, most of the time is spent in the list_directory function used to list files for avoiding name conflicts.  I can imagine that over a NAS this will be even slower. One possible fix would be to create a virtual filesystem cache (read the entire export directory once at startup) and compare names to the cache.  This would only work if no other process was writing to the export directory at the same time but might give a big speed boost.

I will run it later tonight with the main 65K photos library. But meanwhile did a test with 88 pics:
I ran a full initial export of about  with --profile and tottime for sorting.
I attach two files of two runs with the same config but:

from local SSD exporting to the local SSD: so_ssd.log
from local SSD exporting to theNAS Disk (100Mbps): so_nas.log

Edit: I'm overthinking this. In most cases osxphotos doesn't need to know what's in a directory, only whether a file exists so I think this can be sped up by just using is.path.exists()

I tried this and immediately realized why I implemented the collision code the way I originally did.  What osxphotos currently does is increment the filename if any file stem matches.  e.g. if the image being exported is named "IMG_1234.JPG" and there's already an "IMG_1234.PNG" in the destination folder, osxphotos will export the image as "IMG_1234 (1).JPG".  This is done to avoid collisions with side car files which in this case might both be named "IMG_1234.xml" for example.

Looking at your logs, the majority of the time is spend on {method 'readline' of '_io.BufferedReader' objects} which is called by the exiftool code as this is how osxphotos communicates with the exiftool subprocess via a pipe.  The NAS is 4X slower (not surprising).  One potential speedup is to delay copying the file to the NAS until after exiftool processes it but that makes the export code more complicated.
           ncalls  tottime  percall  cumtime  percall filename:lineno(function)
ssd:    43548   34.903    0.001   34.903    0.001 {method 'readline' of '_io.BufferedReader' objects}
nas:    43548  127.876    0.003  127.876    0.003 {method 'readline' of '_io.BufferedReader' objects}

I believe it confirms your comments. Attached is the
profile.69k.log  profile.log run of 69K pics with 1.8K exported pics.

Thanks for the profile data. I think I can cut this time (hopefully significantly) by processing the exiftool updates on the local machine then copying the file to the NAS.  I've just finished a series of refactoring that will allow me to insert this into the code fairly easily and have the basic design for this change done.
I've also done some thinking on a basic design for multiprocessing but will need to do some research and testing about sharing data between processes.  Currently, the entire Photos database gets processed and stored in a PhotosDB instance.  In its current design, this object is not compatible with pickle which means it can't be shared between processes. It's also a large object so not sure you'd want to pass it around between objects. But the export code all depends on access to PhotoInfo objects which in turn access the PhotoDB object.

I was wondering on this flow:

download the photo if missing

copy the photo

create sidecars if needed

update with exiftool if needed

process next photo

...if the exiftool processing could be done in-memory (of course it may be an issue for leve multi gigs videos -- but hey it would be up to the OS to do some swapping to disk itself) and immediately in Step 2.:

download the photo if missing

load the photo in-memory and update with exiftool if needed

write with exiftool to the destination file: aka copy the photo

create sidecars if needed

process next photo

Read a bit about exiftool programming options but I confess I'm no expert ;)

Does this make sense?
Does exiftool allow one to make this operation in one go: reading from a local file, making changes to metadata, and writing it into the destination file?

of course many of the protections and checks (like name duplicates) osxphotos does in the copy step may not be possible with an "exiftool copy process".

Your first flow is basically what happens today.
I'm almost done with a new flow that

stages a temporary copy of the photo (either from the local database or downloads from iCloud)
converts to jpeg if necessary
runs exiftool if necessary
copies the temporary file to the export location

This will avoid sending any file to the export location until it's "done" and avoid any unnecessary reads or writes from/to the export location.

if the exiftool processing could be done in-memory

It can't. The approach I implemented creates a temporary copy of the file, but assuming you're on APFS file system (Catalina+) and the Photos library is on the main disk (the most likely use case), then osxphotos takes advantage of APFS copy-on-write so the temporary file actually takes no time and the writing to disk doesn't actually happen until the conversion or exiftool update. I thought about using a RAM disk (old school style) but it's almost always better to let the OS manage memory and with APFS copy-on-write, it's just as fast.

Does exiftool allow one to make this operation in one go

It does and this would offer a bit of a speedup as the updates wouldn't have to be written to local disk then copied to the NAS but then it would be hard to do things like --retry or catch errors.  It would also mean that it some cases the file is copied by osxphotos and in others copied by exiftool which makes the code more complex.
Once I finish this next round of refactoring on the exiftool bits, I have an idea for parallel processing.  I think true multi-processing will be hard due to the complex nature of the data structures that need to be passed around the code to make that work.  However, I think that multiple copies of osxphotos could run in parallel, all using the same export database.  I've got an idea for an "export runner" mode that would collect UUIDs of all the photos that need to be exported then parse those up to multiple osxphotos export processes to manage and spawn those as separate processes.   Would be some memory overhead of reading in the database to multiple processes but you'd get speed up from running in parallel. Some complexities with --report, etc. but those are probably workable.

Initial results from new version 0.45.0.  This version doesn't copy the photo to destination until after exiftool (and jpeg conversion) is complete.  Following results are for exporting 100 photos to a network drive. With --exiftool the improvement is about 66% (exactly what would be expected from cutting out 2/3 of the transfer over the network).  With both --exiftool and --convert-to-jpeg, the speed up is about 50% (I'm sure one limiting factor is my old Macbook).
osxphotos version 0.44.13
exporting 100 photos with --exiftool

time osxphotos export /Volumes/rhet/Public/export --uuid-from-file ~/Dropbox/Code/osxphotos/not_missing_uuid.txt --exiftool --exportdb /private/tmp/osxphotos.db
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Warning: export database '/private/tmp/osxphotos.db' is in a different directory than export destination '/Volumes/rhet/Public/export'
Exporting 100 photos to /Volumes/rhet/Public/export...
  [####################################]  100%
Processed: 100 photos, exported: 115, missing: 0, error: 1
Elapsed time: 372.266 seconds

export 100 photos with --exiftool and --convert-to-jpeg
time osxphotos export /Volumes/rhet/Public/export --uuid-from-file ~/Dropbox/Code/osxphotos/not_missing_uuid.txt --exiftool --exportdb /private/tmp/osxphotos.db --convert-to-jpeg
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Warning: export database '/private/tmp/osxphotos.db' is in a different directory than export destination '/Volumes/rhet/Public/export'
Exporting 100 photos to /Volumes/rhet/Public/export...
  [####################################]  100%
Processed: 100 photos, exported: 115, missing: 0, error: 0
Elapsed time: 527.868 seconds

osxphotos version 0.45.0
export 100 photos with --exiftool

time python -m osxphotos export /Volumes/rhet/Public/export --uuid-from-file ~/Dropbox/Code/osxphotos/not_missing_uuid.txt --exiftool --exportdb /private/tmp/osxphotos.db
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Warning: export database '/private/tmp/osxphotos.db' is in a different directory than export destination '/Volumes/rhet/Public/export'
Exporting 100 photos to /Volumes/rhet/Public/export...
  [####################################]  100%
Processed: 100 photos, exported: 115, missing: 0, error: 1
Elapsed time: 137.268 seconds

export 100 photos with --exiftool and --convert-to-jpeg

time python -m osxphotos export /Volumes/rhet/Public/export --uuid-from-file ~/Dropbox/Code/osxphotos/not_missing_uuid.txt --exiftool --exportdb /private/tmp/osxphotos.db --convert-to-jpeg
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Warning: export database '/private/tmp/osxphotos.db' is in a different directory than export destination '/Volumes/rhet/Public/export'
Exporting 100 photos to /Volumes/rhet/Public/export...
  [####################################]  100%
Processed: 100 photos, exported: 115, missing: 0, error: 0
Elapsed time: 247.882 seconds

I tried running two osxphotos exports at the same time, splitting the UUIDs between them.  For the --exiftool scenario above, this reduced the run time from 137 seconds to 102 seconds so this may be a viable solution to get some improvement.  osxphotos could have a mode that opens a pipe to each process to monitor overall progress (and perhaps a special option for export that outputs progress in json format for easy consumption by the monitoring process).
Exporting 50 photos to /Volumes/rhet/Public/export...

Processed: 50 photos, exported: 57, missing: 0, error: 1
Elapsed time: 102.416 seconds

Exporting 50 photos to /Volumes/rhet/Public/export...

Processed: 50 photos, exported: 58, missing: 0, error: 0
Elapsed time: 101.908 seconds

Thiamin wonderful. Will try the new version and provide feedback.

Super results in my 88 pics testing.

Updated performance table:

osxphotos version
Run
Pics
SSD
NAS (100)
NAS (1G)
Sec/Pic SSD
Sec/Pic NAS (100)
Sec/Pic NAS (1G)

0.44.13
1st
88
37.158
183.095
99.971
0.422
2.080
1.136

0.44.13
2nd
88
17.630
19.160
19.797
0.200
0.218
0.224

0.45.0
1st
88
-
94.290
53.304
-
1.071
0.605

0.45.0
2nd
88
-
6.922
3.774
-
0.078
0.042

One thing though, I timed the execution with time and it does reference a different value from Elapsed. The first  is measuring the total time and the second is possibly measuring the export phase only.

$ time bash runit_nas.bash

real	0m42.515s
user	0m21.059s
sys	0m4.283s
(venv)
$  egrep "Processed|Elapsed" so.log
Processed: 88 photos, exported: 0, updated: 0, skipped: 88, updated EXIF data: 0, missing: 0, error: 0, touched date: 0
Elapsed time: 6.922 seconds

A. NAS (100) 1st run profile

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      179   45.571    0.255   45.584    0.255 fileutil.py:93(copy)
    43548   35.576    0.001   35.576    0.001 {method 'readline' of '_io.BufferedReader' objects}
        1   15.064   15.064   33.609   33.609 photosdb.py:1618(_process_database5)
        1    8.832    8.832   13.845   13.845 _photosdb_process_searchinfo.py:37(_process_searchinfo)

B. NAS (1G) 1st run profile

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    43548   35.254    0.001   35.254    0.001 {method 'readline' of '_io.BufferedReader' objects}
        1   14.393   14.393   32.979   32.979 photosdb.py:1618(_process_database5)
        1    8.863    8.863   13.914   13.914 _photosdb_process_searchinfo.py:37(_process_searchinfo)
      179    7.023    0.039    7.035    0.039 fileutil.py:93(copy)

5.Will run now the 80K file upload/update on to the NAS(100).

Great!

One thing though, I timed the execution of the 2nd run on NAS(100) with time and it does reference a different value from Elapsed.

Yes, the elapsed time only shows the time from when osxphotos begins exporting photos, not any of the setup time.  Perhaps I should change that to avoid confusion?

@all-contributors add @oPromessa for ideas, test

@allcontributors add @oPromessa for ideas, test

So after a lot of hacking, I think I have multiprocessing sort of working.  There were way too many things in the PhotosDB() object that couldn't be pickled (a requirement for multiprocessing) and I didn't want to refactor it completely so I made a compromise.  I settled for a two pass approach:

If in single process mode (normal), export photos as normal
If in multi-process mode, run the first part of the export code to collect all photos that need to be exported
Create a list of all UUIDs that need to be exported and break it into chunks based on desired processes
Spawn separate processes and give each a chunk of UUIDs to process
Each new export process has to reload the Photos database (the second pass) and recreate the PhotoInfo objects but then can export in parallel

On my 2013 MacBook Pro (2.4 GHz Dual-Core Intel Core i5), this does appear to provide a modest improvement in export speed:
Single Process
time python -m osxphotos export ~/Desktop/export --uuid-from-file uuid.txt --exiftool --convert-to-jpeg --report single_proc.csv
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Exporting 595 photos to /Users/rhet/Desktop/export...
  [####################################]  595/595
Processed: 595 photos, exported: 601, missing: 32, error: 0
Elapsed time: 0:03:12
python -m osxphotos export ~/Desktop/export --uuid-from-file uuid.txt      96.87s user 30.02s system 58% cpu 3:38.15 total

Two processes
time python -m osxphotos export ~/Desktop/export --uuid-from-file uuid.txt --exiftool --convert-to-jpeg --report multi_proc.csv --multiprocess 2
Using last opened Photos library: /Users/rhet/Pictures/Photos Library.photoslibrary
Exporting 595 photos to /Users/rhet/Desktop/export...
Starting process number #0
Starting process number #1
Process 0 is done
Process 1 is done
All processes finished
Processed: 595 photos, exported: 583, missing: 1, error: 0
Elapsed time: 0:02:28
python -m osxphotos export ~/Desktop/export --uuid-from-file uuid.txt      2  126.20s user 39.10s system 97% cpu 2:49.35 total

You'll notice the total exported is different between the two runs so I need to figure out the difference by examining the export reports but I think this I'm getting close to getting this working correctly.

Success!

Let me know how I can help in the testing of this.

I pushed the branch to Github: https://github.com/RhetTbull/osxphotos/tree/multiprocessing
Happy for any feedback or code contributions if you're feeling inclined.  It's a rough alpha at the moment--got it working but need to clean up the code quite a bit (most of the changes are in cli.py:
https://github.com/RhetTbull/osxphotos/blob/79dcfb38a8c067c63a36fd9462ba4b58c2385674/osxphotos/cli.py#L1966
The biggest issue I'm aware of at the moment is that there's a race condition for filename if multiple processes are trying to export a file with the same name to the same location at once.  I have a solution in mind but not yet implemented: "reserve" the file with an empty filename preceded by a ..   e.g. if file being exported is IMG_1234.jpg, export code would create an empty file named .IMG_1234.jpg to reserve the filename then remove it upon successful export.
Because each of the processes need to load the entire Photos database this is likely to only improve performance for exports where there are a large number of files.  It's likely that performance with --convert-to-jpeg and/or --exiftool may improve as these are CPU-bound and not I/O-bound.

Results with multiprocessing under rows "0.45.3 mp=x".

there is definitely an overhead of processing the database on each process. As you mentioned it's probably only worthwhile for large number of files being exported.
on the run with mp=8 it was rather strange as the progress bars for all processes were complete but it took quite sometime wrapping up to present All processes finished.

osxphotos version
Run
Pics
SSD
NAS (100)
NAS (1G)
Sec/Pic SSD
Sec/Pic NAS (100)
Sec/Pic NAS (1G)

0.44.13
1st
88
37.158
183.095
99.971
0.422
2.080
1.136

0.44.13
2nd
88
17.630
19.160
19.797
0.200
0.218
0.224

0.45.0
1st
88
-
94.290
53.304
-
1.071
0.605

0.45.0
2nd
88
0.576
6.922
3.774
0.006
0.078
0.042

0.45.3
1st
88
-
-
52
-
-
0.590

0.45.3 mp=2
1st
88
-
-
52
-
-
0.590

0.45.3 mp=4
1st
88
-
-
53
-
-
0.602

0.45.3 mp=8
1st
88
-
-
104
-
-
1.181

Thanks for the data. I'm not surprised that 0.45.x is faster as it's avoiding unnecessary round trips to the NAS so this is in family with what I'd expect.  The multiprocessing data is interesting as it indicates that either the overhead of loading the library is dominant or the export is I/O bound.  It's probably worth instrumenting the multiprocessing code such that it reports time metrics on how long it took to load the library and how long it spent in export.  Unless multiprocessing shows a huge improvement for a large export, I'm not sure it's worth spending too much time on the multiprocessing feature.

on the run with mp=8 it was rather strange as the progress bars for all processes were complete but it took quite sometime wrapping up to present All processes finished

Interesting -- I'll take a look and see if I can figure out what's going on. This is the very first python multiprocessing code I've written so quite possible I've done something wrong or inefficient.   The progress bar (uses rich.progress) should exit when all tasks have reported done or when no other processes are active (there are two nested loops):
https://github.com/RhetTbull/osxphotos/blob/79dcfb38a8c067c63a36fd9462ba4b58c2385674/osxphotos/cli.py#L2040-L2043

Ran a test with a larger set of pics: 1304 Multiprocessing now shows its potential.
But you were right that some conflict could exist on duplicate filenames.
This test dataset is also tricky as it is the one with multiple pics with the same filename on the same album.
Masked some names with  (...)
2: ('Writing metadata with exiftool for AAD019 (5).jpg',)
(...)
Error exporting photo (51E8424E-627C-49DD-ADA4-08FFAAC8DD82: AAD019.jpg) as AAD019.jpg: Error copying file /var/folders/28/x8vbdy4j4vn680b5pt33hs0w0000gn/T/osxphotos_photo_exporter_51E8424E-627C-49DD-ADA4-08FFAAC8DD82_2kcq2cxg/AAD019.jpg to /Volumes/photo/Test.Album/(...)/AAD019 (4).jpg: Error Domain=NSCocoaErrorDomain Code=516 "“AAD019.jpg” couldn’t be copied to “(...)” because an item with the same name already exists." UserInfo={NSSourceFilePathErrorKey=/var/folders/28/x8vbdy4j4vn680b5pt33hs0w0000gn/T/osxphotos_photo_exporter_51E8424E-627C-49DD-ADA4-08FFAAC8DD82_2kcq2cxg/AAD019.jpg, NSUserStringVariant=(
    Copy
), NSDestinationFilePath=/Volumes/photo/Test.Album/(...)/AAD019 (4).jpg, NSFilePath=/var/folders/28/x8vbdy4j4vn680b5pt33hs0w0000gn/T/osxphotos_photo_exporter_51E8424E-627C-49DD-ADA4-08FFAAC8DD82_2kcq2cxg/AAD019.jpg, NSUnderlyingError=0x600001e3c510 {Error Domain=NSPOSIXErrorDomain Code=17 "File exists"}} (photoexporter.py: 1127)
Retrying export for photo (51E8424E-627C-49DD-ADA4-08FFAAC8DD82: AAD019.jpg)

osxphotos version
Run
Pics
SSD
NAS (100)
NAS (1G)
Sec/Pic SSD
Sec/Pic NAS (100)
Sec/Pic NAS (1G)

0.45.3
1st
1304
-
-
672
-
-
0.515

0.45.3 mp=4
1st
1304
-
-
290
-
-
0.222

But you were right that some conflict could exist on duplicate filenames.

I've made some changes to the multiprocessing branch to use lock files to effectively "reserve" a filename which should minimize if not eliminate file name conflicts.  When you get a chance, I'd appreciate you re-running the larger export set to see if you still get name conflicts.

Some quick feedback:

No name collision! YAY!
a bit slower with the locking mechanism of course but still faster then single process.
Some WARNING messages on database locked.
Oddly enough process 1: took longer than others.

Was it handlilng larger files ? (must go through the logs to double check).
like, processes 0, 2 and 3 reached the total 326 (1034/4) while process 1 was  still at 78!

osxphotos version
Run
Pics
SSD
NAS (100)
NAS (1G)
Sec/Pic SSD
Sec/Pic NAS (100)
Sec/Pic NAS (1G)

0.45.3
1st
1304
-
-
672
-
-
0.515

0.45.3 mp=4
1st
1304
-
-
290
-
-
0.222

0.45.8 mp=4
1st
1304
-
-
413
-
-
0.316

Maybe you're more comfortable with a mini web server +API, but wouldn't a control process and then use Queues and locks from multiprocessing do the trick?

Maybe you're more comfortable with a mini web server +API, but wouldn't a control process and then use Queues and locks from multiprocessing do the trick?

Yes, I'm just not familiar with multiprocess programming and find a server/client easy to understand. I'll read some more about the multiprocessing package -- maybe a lock that could be acquired by the file naming method could work.
However, one consideration is I want to minimize the places in the code that have to be "aware" of multiprocessing to not further complicate the code.  Currently, only a couple of methods in cli.py need to deal with multiprocessing. The actual code that does the export (in PhotoExporter class) doesn't need to know whether or not it's running in a single process or several.  Adding things like locks or interprocess queues means I have to pass that state around and then python starts to get really whiny about which things can be pickled and which can't.
One possible solution is the dependency injection method I use for --dry-run.  The PhotoExporter class gets an instance of an ExportDB class which handles the export database and a FileUtil class which handles things like copy(), move(), unlink(), etc.  If in dry run mode, PhotoExporter gets no-op versions of those classes so all the export logic runs just as it would in the actual export but nothing actually gets exported.  I suppose the FileUtil class could be modified to add a FileUtilMultiProcess version which took care of the file renaming by acquiring a lock.  I'll have to think about this and read up on using locks.

Other than that yes, it would need a placeholder to reserve the filenames in memory

I think this would suffice if all file names were obtained through a common method that kept track of which names had been given out.  If this was done with a lock, it could be guaranteed that only a single instance of a name was ever handed out.

Re-ran some tests for NAS copy with version 0.47.1

with the .osxphotos_export.db on the remote NAS server: we know it's slow! A bit slower than 0.45.3
with the --ramdb option we have a whopping performance

osxphotos version
Run
Pics
SSD
NAS (100)
NAS (1G)
Sec/Pic SSD
Sec/Pic NAS (100)
Sec/Pic NAS (1G)

0.45.3
1st
1304
-
-
672
-
-
0.515

0.45.8 mp=4 (locking)
1st
1304
-
-
413
-
-
0.316

0.47.1
1st
1304
-
-
700
-
-
0.536

0.47.1 --ramdb
1st
1304
-
-
390
-
-
0.299

Will see if I can merge multiprocessing with 0.47.1 master branches to run some more tests!
0.47.1 profile results
Profiling completed
         89654371 function calls (78067164 primitive calls) in 771.205 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   227172  211.915    0.001  211.915    0.001 {method 'readline' of '_io.BufferedReader' objects}
     5219  195.555    0.037  195.555    0.037 {method 'commit' of 'sqlite3.Connection' objects}
    13504  123.162    0.009  123.162    0.009 {method 'execute' of 'sqlite3.Cursor' objects}
     2611  104.748    0.040  105.405    0.040 fileutil.py:93(copy)
     3147   35.444    0.011   35.444    0.011 {built-in method posix.listdir}
        1   14.478   14.478   31.781   31.781 photosdb.py:1576(_process_database5)
    22867   10.413    0.000   10.447    0.000 {built-in method posix.stat}
4614293/92738    8.221    0.000   26.330    0.000 __init__.py:234(parse)
        1    7.820    7.820   12.533   12.533 _photosdb_process_searchinfo.py:37(_process_searchinfo)
     2608    6.324    0.002    6.324    0.002 {built-in method posix.utime}
2674454/92738    3.647    0.000   25.533    0.000 __init__.py:353(_parse)
851611/92737    2.817    0.000    6.027    0.000 model.py:477(process_node)
     4348    2.662    0.001    2.662    0.001 {method 'fetchone' of 'sqlite3.Cursor' objects}
     3910    2.142    0.001  214.343    0.055 exiftool.py:305(run_commands)
  4386876    2.062    0.000    3.342    0.000 utils.py:418(normalize_unicode)
2440290/1500458    1.960    0.000    2.734    0.000 __init__.py:108(flatten)
1760147/1759614    1.771    0.000    8.185    0.000 __init__.py:759(parse)

0.47.1 --ramdb profile results
Profiling completed
         89609322 function calls (77959587 primitive calls) in 467.076 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   220397  251.014    0.001  251.014    0.001 {method 'readline' of '_io.BufferedReader' objects}
     2527   74.567    0.030   75.771    0.030 fileutil.py:93(copy)
     2781   25.982    0.009   25.982    0.009 {built-in method posix.listdir}
        1   14.858   14.858   32.100   32.100 photosdb.py:1576(_process_database5)
     1766   14.523    0.008   14.523    0.008 {built-in method posix.unlink}
    23482   10.171    0.000   10.204    0.000 {built-in method posix.stat}
4639493/93242    8.086    0.000   26.028    0.000 __init__.py:234(parse)
        1    7.781    7.781   12.435   12.435 _photosdb_process_searchinfo.py:37(_process_searchinfo)
     2524    4.165    0.002    4.165    0.002 {built-in method posix.utime}
        2    4.134    2.067    4.134    2.067 {method 'executescript' of 'sqlite3.Cursor' objects}
2689070/93242    3.563    0.000   25.232    0.000 __init__.py:353(_parse)
856147/93241    2.822    0.000    5.956    0.000 model.py:477(process_node)
     3742    2.097    0.001  253.388    0.068 exiftool.py:305(run_commands)
  4386876    2.068    0.000    3.332    0.000 utils.py:418(normalize_unicode)
2453394/1508522    1.938    0.000    2.684    0.000 __init__.py:108(flatten)
1769723/1769190    1.790    0.000    8.178    0.000 __init__.py:759(parse)

Great! The export code refactor in 0.46 requires more read/writes to the database so not surprised it's a bit slower but it will be much more robust.

Will see if I can merge multiprocessing with 0.47.1 master branches to run some more tests!

That may be difficult as I've refactored bug sections of the affected code. It might be easier to add the multiprocessor code back in manually.
It might be worth adding a checkpoint option that writes the export data base from RAM periodically.

By the way, I don't think --ramdb will be compatible with multiprocessing as each process would get a copy of the database.

Though  I have way too many projects at the moment, I had an idea last night and I think I have a new design that could resurrect multiprocessing without too much rework and without the cost of the previous design which had to re-read the database inside each process.
The primary limitation for multiprocessing at the moment is the fact that the PhotosDB and PhotoInfo objects can't be serialized and sent between processes.  It would be possible to create a new PhotoInfo subclass that instead of reading the database, reads a JSON serialization of a PhotoInfo object. The ability to export to JSON is already inbuilt in the PhotoInfo.json(), need to add the ability to instantiate a PhotoInfo object from the JSON then the JSON could be passed between processes (or just written to a temp SQLite database that all processes could read) and all the rest of the code would work as expected.


feat(modal): enhance modal component with multiple animation variants

Fixes #65
Add support for multiple animation variants in the Modal component.

Extend the modalVariants object in packages/ui/src/components/modal.tsx to include multiple animation options such as fade, zoom, scaleBounce, slideUp, slideDown, slideRight, slideLeft, flip, and rotate.
Allow dynamic selection of animation variants based on the animationVariant prop in the Modal component.
Update the documentation in apps/www/content/docs/components/modal.mdx to explain how to select and use the new animation variants.
Add test cases in apps/www/app/playground/page.tsx to cover all supported animation options for the Modal component.
Add a new file apps/www/components/preview/Modal/modalAnimation.tsx to demonstrate the use of different animation variants in the Modal component.
Update the version in packages/ui/package.json from 2.2.3 to 2.2.4.

For more details, open the Copilot Workspace session.

This pull request enhances the Modal component by introducing support for multiple animation variants and updating the documentation accordingly. The key changes include importing the modalVariants from the ruru-ui library, adding examples of different modal animations in the playground, and updating the documentation to reflect these new features.
Enhancements to Modal component:

apps/www/app/playground/page.tsx: Imported modalVariants and added examples of different modal animations in the playground. [1] [2]
apps/www/components/preview/Modal/modalAnimation.tsx: Created a new ModalAnimation component to demonstrate the different animation variants.

Documentation updates:

apps/www/content/docs/components/modal.mdx: Updated the documentation to include information about the new animation variants and added a preview of the ModalAnimation component. [1] [2] [3]


Adding a new tag(s) in product, with Markdown field, falls in a duplication of the existing first

General information about testbed
We are running Defect Dojo v. 2.6.2 ( release mode ) with MariaDB ver. 10.5
Bug description
The bug is almost "cosmetic" but can drive user to a bad behavior loosing time trying to correct input data.
When editing tags, after the insert of a new tag, the first (already) present tag is duplicating when hitting return.
By the way, submitting the update, tags are correctly updated with no duplication.
More critical is the usage of the comma separated tags in the markdown window.
When trying to add more than one tag (comma or semicolon separated) the markdown field get "confused".
It insert partial pieces of tag and blocks the field editing.
See last image (adding multitag)
Steps to reproduce

Go to Product
Click on 'Edit'
Scroll down to 'tags'
Write a new tag and hit return
Look at the updated list of tags on the top (first tag duplicated)
Hit 'Submit'
Product updated with the correct number of tags

Expected behavior
when adding new tags, after the return key pressure, no duplication of the tags should be present.
Deployment method (select with an X)

[ ] Docker Compose
[X] Kubernetes
[ ] GoDojo

Environment information

Linux defectdojom01 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux
Defect Dojo v. 2.6.2 ( release mode )
MariaDB ver. 10.5

Logs
N.A.
Sample scan files
N.A.
Screenshots
Initial product status

Current product tags are debug:00001 and debug:00002

Adding the new tag debug:00003

When hitting return the tags are updated with the new added tag debug:00003 but duplicating the first debug:00001.

By the way, after the submit button is clicked, the product is correctly updated with the 3 tags. The first tag (debug:00001) is not duplicated.

ADDING MULTITAG ERROR
In this example I would like to add two tags: debug:MULTI01 and debug:MULTI02.
When adding the ";" and starting to write the second tag (debug:MULTI02) the markdown splits the first char of the second tag and add it on the top (duplicated). No way to add the rest of the second tag.

When adding "submit" all the partial tags are added with the exclusion of the first (that is duplicated one).

Additional context (optional)
Add any other context about the problem here.

Something is completely wrong with the tag field on the edit product page. There should be no markdown edit box. Possibly related to the changes made in https://github.com/DefectDojo/django-DefectDojo/pull/5207 and related PRs.


AnimationPlayer: pasting animation resource causes Godot to crash

Operating system or device - Godot version:
Windows 7 64bit, Godot 2.1 beta
Issue description (what happened, and what was expected):
Pasting the animation resource to animation player causes Godot to crash.
Steps to reproduce:

Create a new animation resource.
Copy Resource (gear icon in inspector)
Paste Animation (gear icon in animation player)
Crash

More info please, I can't recreate

Ok. I'm using beta version from the website for Windows 64-bit. I didn't compile it from GitHub source. I would upload the test project but I can replicate it even in new empty one.

I know now, your scene is empty, basically you couldn't have any AnimationPlayer, you just opened the Anim editor by clicking on the "Animation" button on the bottom, right? You should change this issue to "Hide Animation editor plugin button if no node selected" to prevent from unintentional use, or something like that.

Yes, that's it. The Animation button is confusing. Will change the name of issue.

I think this was solved by 1247253


When ListView scrolling ,how can I close all the open(swiped) Items?

Is there a feature , make it click an swiped(open) list item to close it? Or when ListView scrolling ,how can I close all the open(swiped) Items?
It just like this:

Hi,
Is this feature included in the latest release.


Shift load from main thread to child thread for heavy computation (eg complex Sql queries)

The following line which appears in logs opened this issue:-
skipped 40 frames :- Looks like  main thread has Load

what modifications we can do the code to provide the jank

Use Future and Stream for async and await  operations to reduce stress on main thread

I have to asynchronous programming methods wherever needed, if you think some part of code still needs it feel free to comment

What i have observed is if we run our app for the 2nd time ,the jank is much more less than the 1st one.

after some more research i have found this in the flutter docs(https://docs.flutter.dev/perf/shader).  I think it is the problem of shader jank and after following the steps in above docs the app was running faster.


⚠ ClamAV has degraded performance

In 2919951, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 457 ms

Resolved: ClamAV performance has improved in 99304da.


Removed all direct references and definition of Colors.appActionButtonShadow.

After #6100
Colors.appActionButtonShadow
ButtonsBarViewModel

From main wallet screen, look at Buy Crypto Button.

Light
Dark After

Checked for changes


Refactor viewcontroller to use extension

Quick refactoring of some ViewController files to use extensions.
Fix #57

Leaving parentheses fixes in there – if SiwftLint doesn't fix them, will go through and manually fix them later.


Finalize DOI design

Finalize the DOI design, e.g. use a dedicated button to reserve and register a DOI? Will there be an interaction with Publish feature?
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Sprint: Seabright Sprint 10 Jet Ski
┆Issue Number: DOCK-727
┆Epic: Walt - Create DOIs

➤ Walt Shands commented:
Updated design doc is here: https://wiki.oicr.on.ca/x/O4jVBg ( https://wiki.oicr.on.ca/x/O4jVBg )

➤ Walt Shands commented:
Design doc updated with tickets generated from prototype demonstration