read fails to stub, halts test runner

When I attempt to run a test with a stub, the test runner gets stuck without throwing an error. It must be exited with CTRL + C
$ find -type f | entr ./node_modules/bats/bin/bats -r ./helpers/tests
 ✓ a/b matcher to ensure the asserts are working
 ✓ createConfigFile
 ✓ toLowercase
   gatherConfigOptions                    4/4

I need to stub read to allow automated testing to work. But this code is causing the halt:
# tests.bats
load "batsMock/stub" # saved via git submodule into this folder

@test "gatherConfigOptions" {
   # setup
   stub read \
      "echo 'returnValue1'" \
      "echo 'returnValue2'"

   # test execution & assert
   local options=$(gatherConfigOptions)
   assert_equal $options "wrongValue"

   # teardown
   unstub read
}

Also tried

Commenting out the unstub statement. No effect

I suspect that read is running unstubbed and causing the infinite delay. I could be wrong though.
Anyone able to tell what the issue is and how to overcome it?
Here is the function I am attempting to stub the internals of:
# ./helpers/helpers.sh

function gatherConfigOptions {
   declare -A configData

   read -p "prompt text here" "configData[languageCode]"
   read -p "prompt text here" "configData[numberOfRepeats]"

   echo "${configData[*]}"
}

Disclaimer: I haven't looked into this deeply.
read is a shell builtin, so the builtin will always take priority over a disk command. Recall that bats-mock works by making an executable shim on disk, which is placed first in PATH, thereby "shadowing" other disk commands.
Because shell builtins take precedence over disk commands, the read builtin will never be shadowed by the bats-mock shims. However, the enable builtin allows you to disable shell builtins.

Disabling allows you to execute a disk command which has the same name as a shell builtin without using a full pathname.

See the enable man page with help enable. I can't vouch for whether it will work within a bats test, though, because the bats run command executes things in a subshell, IIRC. And I'm not certain if enable affects subshells or not. But it's worth a try, and I'd love to hear if it works for you (or not).

Just a note to say that I attempted this in my own tests and it didn't work. If someone else tries and figures out a way to make it work, please update here.


General Issue: STEP 3 - ADT/ADY derivation

Background Information
Creation of ADT and ADY variables.
Function used for the scope: derive_vars_dt and derive_var_dy.
To test the functions mentioned.
Definition of Done
Creation of ADT and ADY variables in line with Vaccines standards.

First version drafted. Please provide comments.
Function derive_vars_dt testet.


How can help and report labels be modified?

I want to add customized help files or report labels in OSCM. How can this be achieved? The "old way" is described in the Operator's Guide, Appendix E

Hi @gertipoppel.
Regarding customized help files, there is an open issue here: servicecatalog/oscm-dockerbuild/issues/65. Basically it will be possible to create archives containing the customized help files and mount them into the online help container, which will then provide/serve them.
As for custom report labels, I'll create an issue in servicecatalog/oscm-dockerbuild since it's an enhancement of the container functionality.

Issue regarding custom reports: servicecatalog/oscm-dockerbuild/issues/76
Closing as duplicate.


DebugConfigurationProvider only calls resolveDebugConfiguration

Issue Type: Bug
Occurs in Insiders, not release.
We are trying to convert our DebugConfigurationProvider to only use resolveDebugConfigurationWithSubstitutedVariables.
However, in the scenario with no launch.json, it calls provideDebugConfigurations, then after a user selects a configuration. It only seems to call resolveDebugConfiguration.
I think it should also be calling resolveDebugConfigurationWithSubstitutedVariables
Actual:

Then nothing.
Expected:

Bug Version:
VS Code version: Code - Insiders 1.51.0-insider (89c002ab02f87102d91efc83c191ef1174756c6a, 2020-10-15T23:17:08.035Z)
OS version: Windows_NT x64 10.0.19041
Working Release Version:
Version: 1.50.1 (user setup)
Commit: d2e414d9e4239a252d1ab117bd7067f125afd80a
Date: 2020-10-13T15:06:15.712Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19041

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (8 x 3000)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
63.85GB (45.49GB free)

Process Argv
--crash-reporter-id b203f981-bd1f-4c33-9e1e-fd8717861426

Screen Reader
no

VM
0%

Extensions (3)

Extension
Author (truncated)
Version

vscode-docker
ms-
1.6.0

csharp
ms-
1.23.3

cpptools
ms-
1.1.0-insiders2

I have just tried this with latest VS Code insiders and it works just fine for me.
Here are my steps:

Have a hello.js file. Do not have a launch.json
Press F5 -> notice how the resolveDebugConfigurationWithSubstitutedVariables gets called on provider side

Also the whole milestone I was on vacation, so it is very strange that this would work for stable and not for insiders.
@WardenGnaw is it possible that you somehow change mock debug so we can clone and be able to reproduce this issue on our side?

I just realized that this is my error. I forgot we rely on returning null instead of empty configuration {} to prompt the provider.
I hope you had a wonderful vacation!

Glad you found the issue.
Yeah vacation was great, thanks :)


Added BentleyHensel.com

Hoping to feed my personal blog to Kagi 🐶

From the readme

Do not submit your own website unless you submit 2 other sites that are not yours (and are not in list).

2 per guidelines


Disable to update application info via the web UI

What this PR does / why we need it:
In order to make the application config defined in Git a single source of truth, we need to make it impossible to update anything other than Piped and Cloud Provider from the web.

Which issue(s) this PR fixes:
Close https://github.com/pipe-cd/pipe/issues/2778
Does this PR introduce a user-facing change?:

Updating application information via the Web UI is no longer possible

Great! Finally, we can disable those operations.
/approve

web-test failed

@nghialv Let me comment out the failed test for now case as I couldn't figure out why it failed. I'm going to ask @khanhtc1202 then I would fix and revert it.

Sure.
/approve

What the yarn versions between local and CI are different confuses me always.

yarn run v1.19.1

I wonder why the version yarn on CI is v1.19.1 even though it's fixed by bazel: https://github.com/pipe-cd/pipe/blob/f927e576cb5fddd7fe99d9275c8837b7990939b2/WORKSPACE#L197

/approve


deno support?

Hi is there any interest in porting this project to deno? I dont know a ton about webassembly but I do believe it is portable as is to deno (https://deno.land/manual@v1.6.3/getting_started/webassembly). Plus having no npm dependencies makes this a prime candidate

Hey @andykais,
It seems interesting to do that. I'll try to port it probably within 1-2 weeks due to my current workload.
Cheers,
Ezzat

Hey @andykais,
It seems interesting to do that. I'll try to port it probably within 1-2 weeks due to my current workload.
Cheers,
Ezzat

awesome! Take your time of course. I took a stab at it yesterday and has some trouble. I opened an issue in the emscripten repo that you may find helpful https://github.com/emscripten-core/emscripten/issues/13190

awesome! Take your time of course. I took a stab at it yesterday and has some trouble. I opened an issue in the emscripten repo that you may find helpful https://github.com/emscripten-core/emscripten/issues/13190

Hey @andykais, deno support is ready!
Try this:
import { cv, cvTranslateError } from<EMAIL_ADDRESS>
console.log(Deno.version);
let mat = cv.matFromArray(2, 3, cv.CV_8UC1, [1, 2, 3, 4, 5, 6]);
console.log('cols =', mat.cols, '; rows =', mat.rows);
console.log(mat.data8S);

Expected output:
{ deno: "1.6.3", v8: "8.8.294", typescript: "4.1.3" }
cols = 3 ; rows = 2
Int8Array(6) [ 1, 2, 3, 4, 5, 6 ]

Please report if you find any bugs. :)

Hey @andykais, deno support is ready!
Try this:
import { cv, cvTranslateError } from<EMAIL_ADDRESS>
console.log(Deno.version);
let mat = cv.matFromArray(2, 3, cv.CV_8UC1, [1, 2, 3, 4, 5, 6]);
console.log('cols =', mat.cols, '; rows =', mat.rows);
console.log(mat.data8S);

Expected output:
{ deno: "1.6.3", v8: "8.8.294", typescript: "4.1.3" }
cols = 3 ; rows = 2
Int8Array(6) [ 1, 2, 3, 4, 5, 6 ]

Please report if you find any bugs. :)

it works! This is awesome! Im surprised that opencv-deno.js seems to work without any modifications to the emscripten output

it works! This is awesome! Im surprised that opencv-deno.js seems to work without any modifications to the emscripten output

Great! I'll close this issue. Feel free to open another one if you find any problem.
Cheers

Great! I'll close this issue. Feel free to open another one if you find any problem.
Cheers


resolve all quacc/prefect flow futures to data make prefect happy

Summary of Changes
Prefect3 now requires all jobs to be resolved before a flow exits. If you return a job that is still running, this causes warnings and problems.
Also, return futures/states is good in that you can avoid passing around data until it's needed, but annoying in that you may ended up with complex structures that have prefect futures embedded inside them.
This PR introduces a function resolve_futures_to_results modeled on the prefect function resolve_futures_to_states that will recursively crawl python collections and resolve any futures to their final results. This function is called on any results that are returned by a quacc flow so that they are properly resolved before the flow finishes.
Requirements

[x] My PR is focused on a single feature addition or bugfix.
[x] My PR has relevant, comprehensive unit tests.
[x] My PR is on a custom branch (i.e. is not named main).

Example code
import time

from quacc import flow, job

@job
def slow_math():
    # An independent piece of work that might take a while
    time.sleep(2)
    return 5

@flow()
def math_flow():
    return slow_math()

@flow()
def double_flow():
    a = math_flow()
    b = math_flow()
    return a + b

math_flow()
double_flow()

Before these patches, prefect would throw warnings about how tasks were not being resolved within flows. After, each flow finishes cleanly.

Can one of the admins verify this patch?

Note to self: We have to update the documentation (examples) to reflect this change in behavior.

Note to self: We have to update the documentation (examples) to reflect this change in behavior.

docs updated!

Thanks, @zulissimeta! I assume this doesn't break concurrency of things, so I'm happy to merge this. Overall, it seems much more intuitive for end users anyway.
Would be good to get something like this in Prefect so that upstream code changes don't break our utility function. But for now, let's not let perfect be the enemy of good enough.


[FEATURE REQUEST] Passthrough for visionOS 2

Current MRTK cannot render passthrough on the new visionOS XR plugin from Unity [https://discussions.unity.com/t/feature-highlights-for-polyspatial-2-0-pre-release/1488495]
Is there a workaround, or could you support this feature?
Thanks a lot

VissionOS support needs help from the community.  @hungngo04 Please provide as many details as possible and maybe someone with a visionOS rig can pick up the work.

These are the steps I did to get the passthrough in an visionOS app (Metal pipeline) in Unity

Install com.unity.xr.visionos 2.0.0-pre.9
Disable Rendergraph
Disable Quality → HDR in URP setting
Set App Mode to Metal
Set Metal Immersion Style to Mixed
Set camera's background color to (0,0,0,0)

So I guess the remaining work is just to set all the MRTK cameras' backgrounds?


Installer does not work on Ubuntu 14.04.3

Please let me know if I did something wrong.
phpunit --configuration phpunit.xml --filter 'StructuredDynamics\osf\tests\ws\crud\read\CrudReadTest::testLanguageEnglishSpecified'
A non-recoverable error happened. ...

drush make --prepare-install resources/osf-drupal/osf_drupal.make /usr/share/drupal
A non-recoverable error happened. ...

cd /usr/share/drupal
A non-recoverable error happened. ...

cd /usr/share/drupal/sites/all/libraries/
A non-recoverable error happened. ...

cd /usr/share/drupal
A non-recoverable error happened. ...

Hi @amalic,
I am not sure I am following what the A non-recoverable error happened. ... string is about. If this what is returned in the shell? Or is this a placeholder for a long error returned? Please clarify since I don't understand the current question.

Closing for now since I haven't heard anything more about this issue.


[HOW-TO] record in YUV420?

I've been working for a few days now with the mjpeg_server.py example, but I cannot, for the life of me, figure out how to convert the stream from yu444p to yu420.
I'm trying to decode the stream on my Nvidia GPU using mjpeg_cuvid, but it doesn't support yu444p.
I've tried doing something like picam2.create_video_configuration(main={"size": (1280, 720), "format": "YUV420"})
However, I get an error saying Buffer has wrong number of dimensions (expected 3, got 2)
Here is the reslult of running ffmpeg on the stream
Input #0, mpjpeg, from 'http://<IP_ADDRESS>:8000/stream.mjpg':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 1280x720 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn

I've also tried converting with open-cv, but I can't figure out how to convert the video, then stream it.
Anyone have any solutions?

Ah, hello again, I see that I've already answered your questions elsewhere. But I think the information here is a bit clearer, so let me try to give a better answer!
The first point is that Python libraries, so far as I have found, don't generally support YUV formats very well, but only RGB ones. This is why you get the error - basically you mustn't change the format to YUV420. Unfortunately the JPEG encoders will then spend time converting the RGB they are given to YUV, which they then encode. This all seems pretty sub-optimal, but that's how things seem to be.
Secondly, the choice of YUV444 is presumably being made by the JPEG encoder that does the conversion from RGB to YUV. In this case we're using the Python "simplejpeg" module. I notice it does have a parameter  that allows you to select the colour subsampling, and so I've created a PR which allows you to pass your choice to the JpegEncoder class. In fact, I've also made YUV420 the default.
The PR in question is here - would you be in a position to try it and see if it does what you want? In which case I'd then be happy to merge it. Thanks!

Ah, hello again, I see that I've already answered your questions elsewhere. But I think the information here is a bit clearer, so let me try to give a better answer!
The first point is that Python libraries, so far as I have found, don't generally support YUV formats very well, but only RGB ones. This is why you get the error - basically you mustn't change the format to YUV420. Unfortunately the JPEG encoders will then spend time converting the RGB they are given to YUV, which they then encode. This all seems pretty sub-optimal, but that's how things seem to be.
Secondly, the choice of YUV444 is presumably being made by the JPEG encoder that does the conversion from RGB to YUV. In this case we're using the Python "simplejpeg" module. I notice it does have a parameter that allows you to select the colour subsampling, and so I've created a PR which allows you to pass your choice to the JpegEncoder class. In fact, I've also made YUV420 the default.
The PR in question is here - would you be in a position to try it and see if it does what you want? In which case I'd then be happy to merge it. Thanks!

I left this comment on the PR request, but I'll leave it here for other people searching this.
This works perfectly! Thank you so much. I literally spent close to four days attempting to get this working. I ended up finally giving up, but you've just saved my server's CPU from so much unnecessary load.
Old output of ffprobe on the http stream:
Input #0, mpjpeg, from 'http://<IP_ADDRESS>:8000/stream.mjpg':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 1640x1232 [SAR 1:1 DAR 205:154], 25 tbr, 25 tbn

New output of ffprobe on the http stream:
Input #0, mpjpeg, from 'http://<IP_ADDRESS>:8000/stream.mjpg':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 1640x1232 [SAR 1:1 DAR 205:154], 25 tbr, 25 tbn


⚠ Jurnal has degraded performance

In a136b58, Jurnal (https://jurnal.unmer.ac.id) experienced degraded performance:

HTTP code: 200
Response time: 10890 ms

Resolved: Jurnal performance has improved in c160131.


layer.conf: set INITRAMFS_IMAGE for sa8155p machine

Set INITRAMFS_IMAGE as "initramfs-kerneltest-full-image"
for sa8155p machine .
Signed-off-by: Bhupesh Sharma<EMAIL_ADDRESS>

@bhupesh-sharma LGTM.

AS per @lumag , this should be in sa8155p-adp.conf instead. In fact , in its current form, it doesn't even set it correctly (since we have changed the override syntax in master, e.g. we should use : instead of _ now. But regardless, it should be in the machine conf.


Lombok APT Fail with Gradle v4.9

I started to get this the build error:

lombok.javac.apt.LombokProcessor could not be initialized. Lombok will not run during this compilation: java.lang.ClassCastException

... following an upgrade to Gradle v4.9.
I have this ERROR using Lombok with Gradle on Linux.  On the command line.  I rolled back my project to Monday (today being Friday).  Same resultafter reverting my project to Monday 's check-point.
I moved my Gradle version back to Gradle v4.8 using SDKMAN  and ran the same build command.

It works!!

Something between Gradle 4.8 and Gradle 4.9 is breaking a very straightforward Lombok build.
As the error trace reports issues stemming from the JavacAnnotationHandler ... I begin by reporting this here.  Apparently this has occurred before but people were looking at IDE plug-in problems, etc.  Running my builds on the command line eliminated 99% of that noise.
The conclusion is that there is a misalignment between gradle-apt-plugin v0.17 and gradle v4.9.

Gradle v4.8 works.

And that means it is possible that the Gradle v4.9 broke my build.

There is noting I could find in the Gradle v4.9 Release nodes covering known APT issues.

Even though it is Obviously a Gradle change causing this ERROR, the root cause appears to be a APT processing error/mismatch.  For instance, I had a day and a half of fun organising the publish functionality to work with the upgrade.
From my perspective, I feel it is quite important for the Gradle project to Inform plugin providers about these structural changes, BEFORE the release.  At least that way you can provide some kind of 'Warning' message.
2nd problem
This message is emitted as a "Warning".  This situation is a definite, certified ERROR,  None of my source code that used Lombok compiles.  It is a project Build / Run / Test show-stopper.  No compilation.  Not successful build.
To be fair, I thing Lombok is reporting a "Warning" ... imho, when an annotation processor reports that it: "Can Not process the code"; this is a (project build) Fatal Error.
configuration:
O/S name:       Linux
Gradle version: 4.9
Groovy version: 2.4.12
Java version:   1.8.0_172-b11 (vendor: Oracle Corporation)

Root project:   'root project 'foundation''
  JAVA_HOME   = '/usr/lib/java/jre/home'
  target...
    JRE_HOME  = '/usr/lib/java/jre/home'
    JDK_HOME  = '/usr/lib/java/jdk/home'

net.ltgt.apt = v0.17
Lombok       = v18.0

related:

#1046 -- ClassCastException: Cannot cast HandleFieldDefaults to JavacASTVisitor (IntelliJ)
#197 -- Cannot cast lombok.javac.handlers.HandleFieldDefaults to lombok.javac.JavacAnnotationHandler

stackdump (see attachment for details):
warning: lombok.javac.apt.LombokProcessor could not be initialized. Lombok will not run during this compilation: java.lang.ClassCastException: org.gradle.api.internal.tasks.compile.processing.IncrementalFiler cannot be cast to com.sun.tools.javac.processing.JavacFiler
public class Rpt
       ^
        at lombok.javac.apt.LombokProcessor.getJavacFiler(LombokProcessor.java:447)
        at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:90)
        at lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:112)
        at lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:165)
        at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:73)
        at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.init(DelegatingProcessor.java:57)
        at org.gradle.api.internal.tasks.compile.processing.IsolatingProcessor.init(IsolatingProcessor.java:44)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:500)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:597)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:690)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
        at com.sun.tools.javac.main.Main.compile(Main.java:523)
        at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
        at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
        at org.gradle.api.internal.tasks.compile.AnnotationProcessingCompileTask.call(AnnotationProcessingCompileTask.java:85)
        at org.gradle.api.internal.tasks.compile.ResourceCleaningCompilationTask.call(ResourceCleaningCompilationTask.java:53)
        at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:50)
        at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:36)
        at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.delegateAndHandleErrors(NormalizingJavaCompiler.java:100)
        at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:52)
        at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:38)
        at org.gradle.api.internal.tasks.compile.AnnotationProcessorDiscoveringCompiler.execute(AnnotationProcessorDiscoveringCompiler.java:49)
        at org.gradle.api.internal.tasks.compile.AnnotationProcessorDiscoveringCompiler.execute(AnnotationProcessorDiscoveringCompiler.java:35)
        at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:40)
        at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:27)
        at org.gradle.api.tasks.compile.JavaCompile.performCompilation(JavaCompile.java:156)
        at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:141)
        at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        :
     etc.

compileJava-FAILED.txt

This is completely unrelated to the net.ltgt.apt plugin: with Gradle 4.9 (and 4.8, back to 4.6), it basically only configures the options.annotationProcessorGeneratedSourcesDirectory of the JavaCompile tasks (it also adds the various DSLs, and the legacy apt configurations), as everything required (annotationProcessor configurations, etc.) is provided by Gradle proper. If you don't use the plugin's DSL, try removing the plugin and run your build again; the only difference would be that no generated source is written to disk.
That said, this exception points at Lombok code itself. Lombok is "hacking" into the compiler using internal and unsupported APIs, and assuming a certain runtime environment. Gradle itself changes that environment for its "incremental annotation processing" feature, but still following the API contracts for annotation processors. Lombok is not an annotation processor though, it just masquerades as one to hook into the mechanism as a way to "inject" itself into the compilation/compiler. So first make sure you're using the very last version of Lombok; I know they already had to make a change for Gradle "incremental annotation processing", and maybe another one was required for Gradle 4.9.
(as a side note, I'd recommend using the Gradle wrapper to "lock" a version of Gradle that's known to be "compatible" with your build rather than using external installations, through SDKMAN, distribution packages, or whatever)

Looks like https://github.com/rzwitserloot/lombok/issues/1782

Ay ya!
Side note advised.  For me builds shall-be: specific / reproducible / traceable.  Where I am.
Anyway personally speaking, imho ...

Every bug has a home and
Every bug has an owner.

The Lombok v18.0 is the latest build with Maven central.

also that Lombok version has been the same for over two months.

If the problem is elsewhere, say -- with Gradle v4.9(??) then we should identify that.

We just released lombok v1.18.2 which is the first release version with the fix from our end in it.

Thanks @rzwitserloot  ...
Same outcome, the class itself fails to compile.  There is a different issue.  The resulting message is more useful.
warning: Can't initialize javac processor due to (most likely) a class loader problem: java.lang.NoClassDefFoundError: com/sun/tools/javac/processing/JavacProcessingEnvironment
public abstract class LibraryTestContext        extends TmacsTestContext
                                     ^
        at lombok.javac.apt.LombokProcessor.getJavacProcessingEnvironment(LombokProcessor.java:413)
        at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:89)
        at lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:128)
        at lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:181)
        at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:73)
        at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.init(DelegatingProcessor.java:57)
        at org.gradle.api.internal.tasks.compile.processing.IsolatingProcessor.init(IsolatingProcessor.java:44)
   :
  etc.

Class loading problem --  sounds interesting ....  BUT !!!

I opened the Java class: public abstract class LibraryTestContext file.
It is plain old Java; No Groovy mentioned.
The build fails because

AND but ...

This class has NO Lombok processing
There seems to me to be a Gradle problem

It builds fine with Gradle 4.8.1.

Looks like gradle now invokes the annotation processors with its own
modular classloader system.
There's no coming back from that. If team gradle insists this is the best
way forward, henceforth gradle and lombok cannot be used together then. If
it truly is this, the fix from our side is technically perhaps impossible,
and even if it is possible, a huge project (we'd have to basically use
reflection for everything. We'd probably move forward by writing a tool
to reflect-ify an entire directory full of class files, and the performance
is just one of many big worries with that kind of drastic move).
Roel and I will try to make some time to look at this, reproduce, etc.
It'll be a little while I'm afraid.
--Reinier Zwitserloot
On Sat, 28 Jul 2018 at 14:45, will<EMAIL_ADDRESS>wrote:

Thanks @rzwitserloot https://github.com/rzwitserloot ...
Same outcome, the class itself fails to compile. There is a different
issue. The resulting message is more useful.
warning: Can't initialize javac processor due to (most likely) a class loader problem: java.lang.NoClassDefFoundError: com/sun/tools/javac/processing/JavacProcessingEnvironment
public abstract class LibraryTestContext        extends TmacsTestContext
^
at lombok.javac.apt.LombokProcessor.getJavacProcessingEnvironment(LombokProcessor.java:413)
at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:89)
at lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:128)
at lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:181)
at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:73)
at org.gradle.api.internal.tasks.compile.processing.DelegatingProcessor.init(DelegatingProcessor.java:57)
at org.gradle.api.internal.tasks.compile.processing.IsolatingProcessor.init(IsolatingProcessor.java:44)
:
etc.
Class loading problem -- sounds interesting .... BUT !!!

I opened the Java class: public abstract class LibraryTestContext
file.
It is plain old Java; No Groovy mentioned.
The build fails because

AND but ...

This class has NO Lombok processing
There seems to me to be a Gradle problem

It builds fine with Gradle 4.8.1.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tbroyer/gradle-apt-plugin/issues/87#issuecomment-408605729,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFsd1Tl5tGPTD4T9I1YhyZB2cfmRR8Eks5uLFzrgaJpZM4VYJui
.

Out of curiosity, could Lombok work as a javac plugin? (the kind loaded with an -Xplugin:Lombok)

@tbroyer yeah probably; looked at the API and you get basically the same classes as annotation processors get. Because of that I'm not entirely sure what the point of the plugin API is (not sure why it is needed given that annotation processors are a thing), but if you think this would solve some gradle issues that sounds like a good direction to go into for fixing things.

Because of that I'm not entirely sure what the point of the plugin API is (not sure why it is needed given that annotation processors are a thing)

@rzwitserloot I'd say that's basically the difference between abusing an unrelated API (annotation processors are supposed to generate new classes, not modifying the internal compiler state or whatever Lombok actually does) and relying on implementation assumptions (exactly what currently breaks Lombok in Gradle: they respect the interface contracts, but you're assuming you can actually cast the instance to a specific javac class) vs. using a supported API designed (AFAIK) specifically to support your use-case :man_shrugging:

The plugin API doesn't let you really do anything that an annotation processor can't already do: There's nothing in the interfaces returned there which lets you modify existing classes, either. Hence why I wonder what the point of this is.
Just like with the annotation processor API (Because it's mostly the same types!) you can presume certain implementations, cast to them (or reflect into them) and do things the interfaces won't let you do.

Oh 🤔 I stand corrected then (I never actually looked at the plugin API, hadn't noticed it's for analysis only), but I still think a plugin would be a better fit :man-shrugging:

Yeah, probably! At the time we wrote lombok it wasn't around, and at least up to java 8, annotation processors on the classpath are just.. run. No need for extra parameters. Trying to tell maven to inject an -X parameter in javac is not easy at all, and given that the APIs are virtually identical, even today I'd say lombok being an AP is the better general mode.
modules change things a bit. The build tools are catching up somewhat. I guess the day where lombok should prefer to be a plugin instead of an AP is coming closer, but it's not here quite yet.


ES IndexerBold - Fix behaviour of afterBulk

Hi @jnioche,
I was looking into https://github.com/DigitalPebble/storm-crawler/pull/989#discussion_r918581042 and reviewed the old code in order to make sure, that I get the wanted behaviour. (see https://github.com/FelixEngl/storm-crawler/blob/834347e53f79376d3a79f125a6203c91d062e04f/external/elasticsearch/src/main/java/com/digitalpebble/stormcrawler/elasticsearch/bolt/IndexerBolt.java)
Now I am wondering, shouldn't it be enough to only process the first encounter of a BulkResponseElement with a specific id and otherwise just print the required LOG-events and update the counters accordingly?
Because the old code worked like this (if I got that right):
:START afterBulk

:ITERATION 1
+ waitAck ---------------+
| "A" | [tuple1, tuple3] |
| "B" | [tuple2]         |
+------------------------+

+ bulk_response ---------------+
| 1. (id: "A", state: SUCCESS) |
| 2. (id: "B", state: SUCCESS) |
| 3. (id: "A", state: FAILURE) |
+------------------------------+

respone = bulk_respose.removeFirst() : (id: "A", state: SUCCESS)
tuples = waitAck.getIfPresent(response.id) : [tuple1, tuple3]
for(tuple in tuples){
    // process all tuples as state: SUCCESS
    ...
}
waitAck.invalidate(response.id) // Immediate removal
:ITERATION 1

:ITERATION 2
+ waitAck -------+
| "B" | [tuple2] |
+----------------+

+ bulk_response ---------------+
| 2. (id: "B", state: SUCCESS) |
| 3. (id: "A", state: FAILURE) |
+------------------------------+

respone = bulk_respose.removeFirst() : (id: "B", state: SUCCESS)
tuples = waitAck.getIfPresent(response.id) : [tuple2]
for(tuple in tuples){
    // process all tuples as state: SUCCESS
    ...
}
waitAck.invalidate(response.id) // Immediate removal
:ITERATION 2

:ITERATION 3
+ waitAck -------+
+----------------+

+ bulk_response ---------------+
| 3. (id: "A", state: FAILURE) |
+------------------------------+

respone = bulk_respose.removeFirst() : (id: "A", state: FAILURE)
tuples = waitAck.getIfPresent(response.id) : null
LOG.warn("could not find unacked tuple for A")
:ITERATION 3

:STOP afterBulk

Best Regards
Felix

Hi @FelixEngl
I have to admit that some of your recent changes have made the code slightly more complicated than it was. Are you trying to simplify the current code?

Hi @FelixEngl
I have to admit that some of your recent changes have made the code slightly more complicated than it was. Are you trying to simplify the current code?

Yes. To be honest right now i am not happy with the design i used in the ES part.
Its working fine, but looks too "wild" and may become problematic to support in the future.
So right now i am working on a redesign, but first i want to make sure, that I understood the ACK logic.

Its working fine, but looks too "wild" and may become problematic to support in the future.

That's also what I am worried about.

So right now i am working on a redesign, but first i want to make sure, that I understood the ACK logic.

Your step by step description above is correct although we just iterated on the bulk_response items without removing them.
BTW could you please add some comments to BulkItemResponseToFailedFlag so that readers can understand what it does?

Its working fine, but looks too "wild" and may become problematic to support in the future.

That's also what I am worried about.

Yes, that also came to me when I started to fix the bug. So I decided to da a "big rewrite" (Like Dylan Beattie described in his song "Big Rewrite": https://www.youtube.com/watch?v=xCGu5Z_vaps)

So right now i am working on a redesign, but first i want to make sure, that I understood the ACK logic.

Your step by step description above is correct although we just iterated on the bulk_response items without removing them.
BTW could you please add some comments to BulkItemResponseToFailedFlag so that readers can understand what it does?

Yes, I only added this step to emphasize the iteration. (A queue is easier to visualize than an iterator. 😄)
And I'll look into that, maybe we won't need that flag BulkItemResponseToFailedFlag anymore when I redesigne the code. (I hope to get rid of some of the confusing parts, remove or at leas streamline the streaming part.)

What about reverting to the previous version and simply add the lock logic?

What about reverting to the previous version and simply add the lock logic?

That wont do it, because the lock would span over too much logic. So I have to rewrite the whole thing anyway.

ES is gone.


Typo in README example

Took me a while to figure out why the example wasn't working for me...

ahhh - oops! Thanks for catching that :sparkles:


Acknowledgement of All Cadre PMIS Registration.

1. After click on the "Registration" button there should have a warning message like this:

2. Registration successful message should be like this

3. Registration confirmation email body should be like this:

by default<EMAIL_ADDRESS>

It's done


improve: table resize icon

What changes were proposed in this pull request
Issue Number: close #xxx

Brief change log

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

app page form add column drag and drop icon, limit jobName column width to minimum 100px

https://github.com/apache/incubator-streampark/assets/39726513/3bc5b4bc-55ea-43e1-84b1-f6e4bcf4ba0a

Does this pull request potentially affect one of the following parts

Dependencies (does it add or upgrade a dependency): (yes / no)

cc @wolfboys I have added drag and drop icons to the table columns in the app view interface.

@wangsizhu0504 Can you submit another PR to the dev branch, thank you

ok！ I will submit a new PR later


Various Toolchain and OS X Fixes

See commit messages for full details.
/cc @chef-cookbooks/engineering-services

:+1:

:+1:


clean up left over tokens and their admin policies from diagnostics

see #3332

@susanev the other bit was the one missing. thanks for creating this card. I do have the intention of picking up those pieces next, I just wanted to split something independently reviewable as quick as possible.


Modernization

The original project is great!
It relies on a lot of outdated dependencies, though. I've gone through the codebase and bumped dependencies, gotten rid of old code, and implemented a unified way to set the icons on the right bar and the bottom bar.
The key dependency react-notion-x is not altered here. I'm also working on that, but have hit some sort of a roadblock with some dependency.

Thanks @gauravmm for this! While we are waiting for @transitive-bullshit to decide how to continue with this starter I created my own fork with updated react-notion-x dependency.
See more here:
https://github.com/onnimonni/nextjs-notion-starter-kit/pull/2
You can see the forked react-notion-x here: https://github.com/onnimonni/react-notion-x/tree/publish-forked-versions
It works perfectly but few tests are still failing which are written with ts and try to import the internal packages eg `import "notion-utils"' are not working and fail with:
Uncaught exception in src/notion-api-universal.test.ts

  Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@onnimonni/notion-utils' imported from /Users/onnimonni/Projects/react-notion-x/packages/notion-client/src/notion-api.ts

I'm happy to add you as contributor to both of these forks if you want to help out 👍.

Fixed in https://github.com/transitive-bullshit/nextjs-notion-starter-kit/pull/641


refactor Clock::stream_slots to use IntervalStream

we can likely use something like this to simplify the clock internals:
https://docs.rs/tokio-stream/latest/tokio_stream/wrappers/struct.IntervalStream.html

fixing this one, github mev bot look away

I'm hitting a roadblock here because tokio::time::interval can only take in non-zero params
As mentioned here: panics
Here's my current Impl:
    pub fn stream_slots(&self) -> impl Stream<Item = Slot> + '_ {
        async_stream::stream! {
            let slot = self.current_slot().expect("after genesis");
            yield slot;
            let mut interval_tick = tokio::time::interval(self.duration_until_slot(slot + 1));
             interval_tick.tick().await;
        }
    }

My bad, I forgot to add the loop:
 pub fn stream_slots(&self) -> impl Stream<Item = Slot> + '_ {
        async_stream::stream! {
            let mut slot = self.current_slot().expect("after genesis");
            let mut interval_tick = tokio::time::interval(self.duration_until_slot(slot + 1));

            loop{
            yield slot;
            interval_tick.tick().await;
            slot = self.current_slot().expect("after genesis");
            }
        }
    }

but now when I run the test_slot_stream it just keeps on going indefinitely:
running 1 test
test clock::tests::test_slot_stream has been running for over 60 seconds

can you open a PR w/ the changes?

the idea behind this issue was to just use IntervalStream, so there is no longer any need to use async_stream::stream!
also, the interval will just be SECONDS_PER_SLOT
you can collect the first tick, yield the current slot, and then just await each tick

Just open a PR  w/ the changes
And I couldn't figure out a way to do this, :(

the idea behind this issue was to just use IntervalStream, so there is no longer any need to use async_stream::stream!
also, the interval will just be SECONDS_PER_SLOT
you can collect the first tick, yield the current slot, and then just await each tick


Fix "error when reading settings values from file system" logs in settings UI tests

Describe the bug
Errors/warnings in settings UI tests
Steps to reproduce
Steps to reproduce the behavior:

Run settings UI tests locally or check e.g. https://drone.owncloud.com/owncloud/ocis/5569/54/7
See Error while reading the settings values from file system...

Expected behavior
No error messages
Actual behavior
Lots of Error while reading the settings values from file system...  in the logs

there is code to restore the settings of the user after running the tests because deleting the user would not do that before, but looks like that is fixed now and is not required anymore


Continuous integration tracking with Travis

It would be neat to have the automated tests run on d3, and tracking over time of how they fare. Travis provides this for free, and I just went through the easy http://about.travis-ci.org/docs/user/getting-started/ guide to try setting it up for my d3 fork. My output from the two last test commits is here (and this view is also the main feature I personally seek):
http://travis-ci.org/#!/johan/d3/builds
…which also showed up like this in the Freenode IRC channel #d3-travis I noted for live notifications of the build bots:
09:09 travis-ci has joined<EMAIL_ADDRESS>09:09 travis-ci: [travis-ci] johan/d3#1 (master - 1db25aa : Johan Sundström): The build passed.
09:09 travis-ci: [travis-ci] Change view : https://github.com/johan/d3/compare/d86074b...1db25aa
09:09 travis-ci: [travis-ci] Build details : http://travis-ci.org/johan/d3/builds/675203
09:09 travis-ci has left ()
09:17 travis-ci has joined<EMAIL_ADDRESS>09:17 travis-ci: [travis-ci] johan/d3#2 (master - 3f5c60d : Johan Sundström): The build was broken.
09:17 travis-ci: [travis-ci] Change view : https://github.com/johan/d3/compare/1db25aa...3f5c60d
09:17 travis-ci: [travis-ci] Build details : http://travis-ci.org/johan/d3/builds/675220
09:17 travis-ci has left ()
...and like this, in the build hook emails I tested (all notification setup is in .travis.yml): http://mailinator.com/maildir.jsp?email=d3-travis
It might of course be worth turning off testing on node.js 0.7 (I tried it to see how it fared) and perhaps tweak other Travis config flags as per http://about.travis-ci.org/docs/user/build-configuration/ at your discretion. :-)

Hi @johan. Thanks for contributing. I don't see a strong need to have continuous integration tracking at the moment, since I'm currently the only person with permissions to push to master; maintaining this will only mean extra overhead for me in the short-term. But, I'll keep this in mind in the future!


Add more tests and logic check the skipped_stats function

The skipped_stats function (and the filters_to_sql / filter_to_sql queries it rely on) should be better tested.  There are probably corner cases / bugs in the function.
The function could also use a logic check from a pair of fresh eyes.

@MrPowers - hey! I would like to work on this.

Awesome, thanks @brayanjuls

@MrPowers  - working on this issue I just realized we can do the same in delta scala using DeltaLog..snapshot.filesWithStatsForScan, after finishing with this I will take a deeper look at it.


Adding pt-BR Localization

Added Locale files and proper settings to integrate Brazilian Portuguese into the Web Configurator

@Yanrs thanks for the commit! Would you mind merging in our latest main (simplified Chinese was added) to your PR to resolve the conflicts?
Thanks!

To add to @arntsonl's message, some more hardcoded strings were identified in #473 so this needs a quick fix :)


Streamline Sherlock Platform build by integrating plugin fetching from the build script

This change integrates the fetching of android repo (getPlugins.sh) directly into the build_sherlock_platform.sh script.

The getPlugins.sh script is now called before the build process, ensuring that the required Android plugin is available before compilation begins.

Additionally, the getPlugins.sh script has been updated to handle cases where the android directory already exists, preventing potential errors.

@emrekultursay PTAL


Allow explicit compose name, bypass compose validation

Description

Introduce a new bool configuration option tf_allow_explicit_compose_name / tf_explicit_compose / ... (default=False)
Bypass the compose validation and here for internal tf
set compose = compose if explicit name option set to True

Context:
With the effort to test conversion cloud images in convert2rhel, we have proceeded with making the mapping in Testing Farm configuration more generic (maps through regex).
This matches to an explicit official AMI name.
These images unfortunately won't land in any of the compose lists, so the effort to dispatch jobs through packit fails on the compose validation in the testing_farm helper.
The current workaround suggested by @lachmanfrantisek is overriding the compose in tf_extra_params.
This solution works, but would yield unsatisfactory results in the future, when we introduce support for conversions to RHEL 9.
We still need to set the distros to some known value to satisfy the compose validation against available_composes.
This would get confusing with target distro set to oraclelinux-8 (which would appear in the packig job check name) and overriding the compose value to the desired OL9.x
Benefit

Allow testing official cloud images
Upstream transparency in the cloud testing efforts (official image name to be seen in the packit job check instead of ambiguous alias)
Possibly get rid of some workarounds to satisfy the TF compose mapping

for convert2rhel that would be

elif compose == "Oracle-Linux-7":
    compose = "Oracle-Linux-7.9"
elif compose == "Oracle-Linux-8":
    compose = "Oracle-Linux-8.6"

Importance
medium
What is the impacted category (job)?
Testing Farm tests
Workaround

[X] There is an existing workaround that can be used until this feature is implemented.

Participation

[X] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

Hello!
Thanks for the issue! Since there is currently an easy workaround (actually, that's what tf_extra_params is for), we will not prioritise this but let us know once this starts to be an issue.

@thrix hello, are you ok with promoting this use-case (=using custom APIs)? Is this something you "support" or it just works?

Hi @lachmanfrantisek, we are slowly leaning towards supporting conversions to RHEL9.
That is when we hit the issue hard.
We need to bypass the compose validation somehow, which is currently done by "lying" to packit and pointing the distro key to some, that is known by Packit, e.g. oracle-linux-8, which translates to Oracle-Linux-8.6.
Then we overwrite the compose key in tf_extra_params to get the desired OS provisioned by Artemis.
With 9 major release in the equation, the check name would be pretty much nonsensical.
We would again need to "lie" to Packit with requesting some compose that is recognizable by the service, and overwriting the compose key, the check would look like a RHEL8 conversion is tested, however the compose value would request RHEL9-like OS.
This value is not public facing at all, which might cause confusion.
CCing @bocekm

Testing Farm is now exposing the regexes in the available composes list.
This makes the possible config option unnecessary, on the other hand, the code should be able to handle matching the requested target to the regexes on the available composes list better.

hi @danmyway ! As you mentioned, with the support of regexes, I would say this issue is no longer necessary. The support on our side was implemented in https://github.com/packit/packit-service/pull/2168 and should be in production next Tuesday. Do you think this could be closed or would you be still interested in implementing something from the initial proposal?

Awesome, I think we can close this one.
I can open another issue if something pops up.
Thank you, @lbarcziova !


Unable to Detect Images in Kohya_SS Fine-Tuning on RunPod - Need Assistance

09:08:32-695749 INFO     Start Finetuning...
09:08:32-697827 INFO     Validating lr scheduler arguments...
09:08:32-699710 INFO     Validating optimizer arguments...
09:08:32-703569 INFO     Validating /workspace/finetune/image existence...
                         SUCCESS
09:08:32-705821 INFO     Validating /workspace/finetune/log existence and
                         writability... SUCCESS
09:08:32-708157 INFO     Validating /workspace/finetune/model existence and
                         writability... SUCCESS
09:08:32-710750 INFO     Validating /workspace/model/flux1-dev.safetensors
                         existence... SUCCESS
09:08:32-712824 INFO     /workspace/kohya_ss/venv/bin/python
                         /workspace/kohya_ss/sd-scripts/finetune/merge_captions_
                         to_metadata.py --caption_extension .txt
                         /workspace/finetune/image meta_cap.json --full_path
/workspace/kohya_ss/venv/lib/python3.10/site-packages/diffusers/utils/outputs.py:63: FutureWarning: `torch.utils._pytree._register_pytree_node` is deprecated. Please use `torch.utils._pytree.register_pytree_node` instead.
  torch.utils._pytree._register_pytree_node(
2024-10-29 09:08:43.842657: I tensorflow/tsl/cuda/cudart_stub.cc:28] Could not find cuda drivers on your machine, GPU will not be used.
2024-10-29 09:08:43.873863: E tensorflow/compiler/xla/stream_executor/cuda/cuda_dnn.cc:9342] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-10-29 09:08:43.873911: E tensorflow/compiler/xla/stream_executor/cuda/cuda_fft.cc:609] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-10-29 09:08:43.873955: E tensorflow/compiler/xla/stream_executor/cuda/cuda_blas.cc:1518] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-10-29 09:08:43.880601: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-10-29 09:08:46.620549: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
/workspace/kohya_ss/venv/lib/python3.10/site-packages/diffusers/utils/outputs.py:63: FutureWarning: `torch.utils._pytree._register_pytree_node` is deprecated. Please use `torch.utils._pytree.register_pytree_node` instead.
  torch.utils._pytree._register_pytree_node(
2024-10-29 09:08:55 INFO     found 0 images.    ]8;id=638801;\merge_captions_to_metadata.py]8;;\:]8;id=416548;\23]8;;\
                    INFO     loading existing   ]8;id=922012;\merge_captions_to_metadata.py]8;;\:]8;id=399916;\29]8;;\
                             metadata:
                             meta_cap.json
                    WARNING  captions for       ]8;id=814066;\merge_captions_to_metadata.py]8;;\:]8;id=748578;\31]8;;\
                             existing images
                             will be
                             overwritten /
                             既存の画像のキャプ
                             ションは上書きされ
                             ます
                    INFO     merge caption      ]8;id=302716;\merge_captions_to_metadata.py]8;;\:]8;id=187859;\36]8;;\
                             texts to metadata
                             json.
0it [00:00, ?it/s]
                    INFO     writing metadata:  ]8;id=464358;\merge_captions_to_metadata.py]8;;\:]8;id=857842;\53]8;;\
                             meta_cap.json
                    INFO     done!              ]8;id=153694;\merge_captions_to_metadata.py]8;;\:]8;id=381527;\55]8;;\
09:08:56-474847 INFO     /workspace/kohya_ss/venv/bin/python
                         /workspace/kohya_ss/sd-scripts/finetune/prepare_buckets
                         _latents.py /workspace/finetune/image meta_cap.json
                         meta_lat.json /workspace/model/flux1-dev.safetensors
                         --batch_size 1 --max_resolution 1500,1000
                         --min_bucket_reso 512 --max_bucket_reso 2048
                         --mixed_precision fp16 --full_path
/workspace/kohya_ss/venv/lib/python3.10/site-packages/diffusers/utils/outputs.py:63: FutureWarning: `torch.utils._pytree._register_pytree_node` is deprecated. Please use `torch.utils._pytree.register_pytree_node` instead.
  torch.utils._pytree._register_pytree_node(
/workspace/kohya_ss/venv/lib/python3.10/site-packages/diffusers/utils/outputs.py:63: FutureWarning: `torch.utils._pytree._register_pytree_node` is deprecated. Please use `torch.utils._pytree.register_pytree_node` instead.
  torch.utils._pytree._register_pytree_node(
2024-10-29 09:09:10.761764: I tensorflow/tsl/cuda/cudart_stub.cc:28] Could not find cuda drivers on your machine, GPU will not be used.
2024-10-29 09:09:10.791000: E tensorflow/compiler/xla/stream_executor/cuda/cuda_dnn.cc:9342] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-10-29 09:09:10.791044: E tensorflow/compiler/xla/stream_executor/cuda/cuda_fft.cc:609] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-10-29 09:09:10.791081: E tensorflow/compiler/xla/stream_executor/cuda/cuda_blas.cc:1518] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-10-29 09:09:10.797377: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-10-29 09:09:14.533392: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
/workspace/kohya_ss/venv/lib/python3.10/site-packages/diffusers/utils/outputs.py:63: FutureWarning: `torch.utils._pytree._register_pytree_node` is deprecated. Please use `torch.utils._pytree.register_pytree_node` instead.
  torch.utils._pytree._register_pytree_node(
get_preferred_device() -> cuda
2024-10-29 09:09:20 INFO     found 0 images.       ]8;id=307420;\prepare_buckets_latents.py]8;;\:]8;id=772842;\73]8;;\
                    INFO     loading existing      ]8;id=683195;\prepare_buckets_latents.py]8;;\:]8;id=199653;\76]8;;\
                             metadata:
                             meta_cap.json
                    INFO     load VAE:                        ]8;id=193898;\model_util.py]8;;\:]8;id=655963;\1268]8;;\
                             /workspace/model/flux1-dev.safet
                             ensors
Traceback (most recent call last):
  File "/workspace/kohya_ss/sd-scripts/finetune/prepare_buckets_latents.py", line 286, in <module>
    main(args)
  File "/workspace/kohya_ss/sd-scripts/finetune/prepare_buckets_latents.py", line 89, in main
    vae = model_util.load_vae(args.model_name_or_path, weight_dtype)
  File "/workspace/kohya_ss/sd-scripts/library/model_util.py", line 1304, in load_vae
    converted_vae_checkpoint = convert_ldm_vae_checkpoint(vae_sd, vae_config)
  File "/workspace/kohya_ss/sd-scripts/library/model_util.py", line 415, in convert_ldm_vae_checkpoint
    new_checkpoint["encoder.conv_in.weight"] = vae_state_dict["encoder.conv_in.weight"]
KeyError: 'encoder.conv_in.weight'
09:09:20-950813 INFO     image_num = 0
09:09:20-952208 INFO     repeats = 0
09:09:20-953028 INFO     Max train steps: 0. sd-scripts will therefore default
                         to 1600. Please specify a different value if required.
Traceback (most recent call last):
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/gradio/queueing.py", line 622, in process_events
    response = await route_utils.call_process_api(
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/gradio/route_utils.py", line 323, in call_process_api
    output = await app.get_blocks().process_api(
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/gradio/blocks.py", line 2016, in process_api
    result = await self.call_function(
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/gradio/blocks.py", line 1569, in call_function
    prediction = await anyio.to_thread.run_sync(  # type: ignore
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/anyio/to_thread.py", line 56, in run_sync
    return await get_async_backend().run_sync_in_worker_thread(
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 2441, in run_sync_in_worker_thread
    return await future
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 943, in run
    result = context.run(func, *args)
  File "/workspace/kohya_ss/venv/lib/python3.10/site-packages/gradio/utils.py", line 846, in wrapper
    response = f(*args, **kwargs)
  File "/workspace/kohya_ss/kohya_gui/finetune_gui.py", line 874, in train_model
    lr_warmup_steps = lr_warmup / 100
TypeError: unsupported operand type(s) for /: 'str' and 'int'file:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.pyfile:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.py#23file:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.pyfile:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.py#29file:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.pyfile:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.py#31file:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.pyfile:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.py#36file:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.pyfile:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.py#53file:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.pyfile:///workspace/kohya_ss/sd-scripts/finetune/merge_captions_to_metadata.py#55file:///workspace/kohya_ss/sd-scripts/finetune/prepare_buckets_latents.pyfile:///workspace/kohya_ss/sd-scripts/finetune/prepare_buckets_latents.py#73file:///workspace/kohya_ss/sd-scripts/finetune/prepare_buckets_latents.pyfile:///workspace/kohya_ss/sd-scripts/finetune/prepare_buckets_latents.py#76file:///workspace/kohya_ss/sd-scripts/library/model_util.pyfile:///workspace/kohya_ss/sd-scripts/library/model_util.py#1268

I am unable to solve this issue.
2024-10-29 09:08:55 INFO found 0 images.
Inside the folder /workspace/finetune/image/1_example/, there are various images along with their captions. Therefore, I set /workspace/finetune/image as the image path. However, no images are being detected. At first, I thought the issue might be due to the large number of images, so I reduced it to only 4 images with their respective captions, but still, only 0 images are recognized.
I have included only four images with a resolution of 1500x1000, and I specified this resolution in kohya_ss as well.
Currently, I am attempting fine-tuning in kohya_ss (not LoRA or Dreambooth) and have encountered the issue described above. How can I get the images to be properly recognized?
P.S. I am using RunPod. Could this be related to the issue?
P.S. 2: I have a second question. How many images can kohya_ss handle? If more than 10,000 images are needed, would it still work properly with Kohya?

Thank you for the quick response. I know you're working hard, but I have just a few more questions to ask.

Does this mean that caption-based training is currently not possible? Is it not possible to conduct caption-based training not only in the fine-tuning tab but also in LoRA or other sections?

What should I change in my setup to enable the training process?

I attempted finetuning rather than using LoRA or Dreambooth, and it seems that this may have caused the error. After asking around, I learned that for Flux, being a distilled model, finetuning is currently only feasible with LoRA and Dreambooth.
My aim was not to introduce a new concept but to apply a style change across all prompts rather than focusing on specific keywords or concepts. Is it correct to say that finetuning to affect the style of the entire model's prompts is currently not possible?


per-provider defaults for dynamic configuration

Do you want to request a feature or report a bug?
Feature
What did you expect to see?
I've been working on migrating to Traefik v2 this week, and I'm so happy with a ton of the improvements made. We're redoing out backend service mapping to use the docker provider and container labels, and it's going well, but the thing I'd love is to have per-provider defaults for different dynamic sections. For instance, every router we create for every backend service has essentially the same options, just a different Host match:
    labels:
      - traefik.http.routers.someapi.rule=HostRegexp(`somehost.net`)
      - traefik.http.routers.someapi.entrypoints=https
      - traefik.http.routers.someapi.middlewares=compress@file
      - traefik.http.routers.someapi.tls=true
      - traefik.http.routers.someapi.tls.options=default

it would be really nice to define all options except the rule as defaults for the docker provider, and then all we'd have to do is set the rule on each container. and the same for server sections for different load balancing settings, etc. Would definitely simplify our config a ton. even better if we could specify the defaults for one provider from another provider, so we could set the docker provider router and service defaults from a file loaded inside the traefik container.

Related #5630


PDI example: fti_head no init value in Fortran source

In GitLab by @ksiero on Jul 30, 2021, 15:05
fti_head has no initial value in Fortran example

In GitLab by @ksiero on Aug 2, 2021, 09:11
mentioned in commit e34233899ce781cc2f475a425cfcca3b2d144ba4


Internal Essential Boundary Condition

I am solving the heat conduction equation in an unstructured mesh with a variety of materials, each with a unique thermal conductivity. The problem has two boundary conditions: a fixed temperature at the periphery and a fixed temperature for a cooling system (heat pipe).
I would like to implement this in MFEM by treating all DOFs associated with a particular attribute as essential (Dirichlet) BCs. For example, I would like to loop through the mesh and for all DOFs in an element with attribute==4, I would eliminate the row/column from the bilinear form, set the diagonal to unity, and apply the fixed temperature boundary condition in the linear form.
I was able to make this work in serial (see #2097), but I'm having trouble indexing the DOFs and implementing this in a reasonable manner in parallel. It seems like if I could collect an ess_tdof_list I could use ParBilinearForm::FormLinearSystem() and ParBilinearForm::RecoverFEMSolution().
How can I go about collecting an ess_tdof_list for all DOF associated with a particular attribute number?
Thanks!

Take a look at GetEssentialTrueDofs in ParFiniteElementSpace:
https://github.com/mfem/mfem/blob/master/fem/pfespace.cpp#L1032-L1060
and FiniteElementSpace:
https://github.com/mfem/mfem/blob/master/fem/pfespace.cpp#L1032-L1060
If I understand correctly, you just want a version of these that works with element instead of boundary attributes?

@tzanio Thanks! This seems to be it. The key piece I was missing was
parfespace->GetRestrictionMatrix()->BooleanMult(ess_dofs, true_ess_dofs);


chore(main): release 6.0.1

:robot: I have created a release beep boop
6.0.1 (2024-10-04)
Bug Fixes

add missing body_type "163" (#317) (45f7bd2)

This PR was generated with Release Please. See documentation.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 39.89%. Comparing base (45f7bd2) to head (7ae309a).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #319   +/-   ##
=======================================
  Coverage   39.89%   39.89%
=======================================
  Files          84       84
  Lines        7607     7607
=======================================
  Hits         3035     3035
  Misses       4572     4572

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Let's wait for #320 and #311 before release

:robot: Created releases:

v6.0.1
:sunflower:


Set default power-iter-steps in Tracker init

Fixes #15

Thanks! Haven't had time to actually test this, I just wrote the base implementation so far


Add a way to track pressure profile

Depending on the roast and how fresh or stale beans are I often preinfuse longer (which can be tracked already) but will then also back pressure off towards the end of the shot to avoid over bitter flavours.
In my notebook I draw a curve for the pressure.
As I said it’s niche so may not be worth implementing

Another person

option to use a ramping or decline temp profile and options for pressure profiling


Kotlin JVM client

Hey there!
I've build a "beta" version of PGMQ transport-level client for Kotlin JVM. It's based on pure JDBC, so it's pretty lightweight.
I'd be more than happy if you mention it in readme!
https://github.com/vdsirotkin/pgmq-kotlin-jvm

Want to open PR to the readme? We will accept that :) You could put it right next to the other community built clients
https://github.com/tembo-io/pgmq/blob/d393a74824a20f39522f63659caa2a9186fd5370/README.md?plain=1#L67-L74

@ChuckHend https://github.com/tembo-io/pgmq/pull/246 done!


WAYTOODANK doesn't appear in autocomplete when typing :way, but it does appear when you type :dank

Describe the bug
When ":WAY", or any amount of letters that it starts with, WAYTOODANK doesn't appear in autocomplete, however, when ":dank" is entered, it does appear.
To Reproduce
Steps to reproduce the behavior:

type :way, or any amount of the letters it starts with

Expected behavior
The emote known as WAYTOODANK should appear in the autocomplete above the text box.
Screenshots

What device are you on?
A linux pc.
Additional context
I'm using Next.dogehouse on firefox

waytoodank needs to be added to keywords for emoji,  can try :feelsdankman it should also show waytoodank emoji
{
name: "WAYTOODANK",
short_names: ["WAYTOODANK"],
keywords: ["dank", "feelsdankman"],
imageUrl: "/emotes/WAYTOODANK.gif",
},

So this shouldn't be a bug, it's behaving as configured. You can create pr adding this keyword or somebody can expand the lookup to include the name/short_names with keywords for matching.


Build fails after (recursive) clone, before git submodule sync

Details
The same mysterious build error occurs on the main project, as well as the test project.  "Fake NanoGUI" is the test project which I have admin access to, but I will include links to both build errors in case it is helpful.

Read the Docs project URL:

https://readthedocs.org/projects/fake-nanogui/ and
http://readthedocs.org/projects/nanogui/

Build URL (if applicable):

Fake NanoGUI: https://readthedocs.org/projects/fake-nanogui/builds/7329568/
NanoGUI: http://readthedocs.org/projects/nanogui/builds/7039066/

Read the Docs username (if applicable): sjm324

Expected Result
Docs build as normal.
Actual Result

There was a problem with Read the Docs while building your documentation. Please report this to us with your build id (7329568).

Unfortunately, the log gives little to no information about the actual failure.  It's a C++ project without any setup.py (which is disabled in the configs).  On the Fake NanoGUI one I'm working on a PR to merge in there, so I added a .readthedocs.yml to try and run some form of matrix testing.  I tried every combination of the image with py 2 and 3: image: {1.0,2.0,latest} x python: {2,3}, every build failed on that with the same results.
I can't help but think that it has to do with recursive cloning and submodules.  Do the system logs show anything more fruitful?  Each new build was done after a clean (wipe) of the custom_fonts branch, and the build errors occur with or without a .readthedocs.yml.
Thanks for any help :)

The error is probably because you don't have this submodule
https://github.com/svenevs/nanogui/blob/885e4fccc69bbfdd4c527009eef8ed33641d9765/.gitmodules#L7-L9
https://github.com/svenevs/nanogui/tree/master/ext
(rtd uses gitpython which is very strict with unexisting submodules)

How very interesting!  Thanks @stsewd you hit it right on the nose.
It's interesting that this surfaced recently, the GLEW submodule has been gone I think over a year now, possibly longer.  Nonetheless, it is fixed and building now, so future readers if you exist I deleted lines from .gitmodules that were not applicable anymore (that commit might be getting force pushed away).


plot() method on pd.Series objects raises AttributeError

With Pandas-Bokeh 0.3 and Pandas 0.25.0 in a Jupyter notebook, the following code produces an AttributeError:
import pandas as pd
pd.set_option('plotting.backend', 'pandas_bokeh')
pd.plotting.output_notebook()

series = pd.Series(np.random.randn(10000))
series.plot(kind='hist')

The full error message is:
AttributeError: unexpected attribute 'reuse_plot' to Quad, possible attributes are bottom, fill_alpha, fill_color, hatch_alpha, hatch_color, hatch_extra, hatch_pattern, hatch_scale, hatch_weight, js_event_callbacks, js_property_callbacks, left, line_alpha, line_cap, line_color, line_dash, line_dash_offset, line_join, line_width, name, right, subscribed_events, tags or top
Using series.plot_bokeh(kind='hist') works fine, however.
Adding a dummy reuse_plot=True argument to the plot method in pandas_bokeh/plot.py around line 154 appears to fix the problem.
https://github.com/PatrikHlobil/Pandas-Bokeh/blob/master/pandas_bokeh/plot.py#L154

Hm, this is due to some weird magic that pandas.plotting does when passing the arguments to the plotting backend. I already fixed the stuff for the Dataframes, but didn’t check the Series plots. Internally, Pandas Bokeh translates the Series to a DataFrame, but before that pandas.plotting adds some more keyword arguments for backwards compatibility with Matplotlib.
Thanks for pointing out this issue, I will try to fix it soon.
Could you try to convert your series to a DataFrame and call plot on this?
Best Patrik

I didn't have any trouble plotting DataFrame objects using the plot() method.

@lordsutch ,
Thanks again for reporting this bug. I have closed just now with the fix you mentioned. With the next release of pandas-bokeh the fix should be out.
Best,
Patrik


Cannot create data processing function for new app

Steps to reproduce:

Make a new function app using the webjobs portal
When the full portal loads, select the data processing template from the welcome page
Click the "create a new function" button.

Expected: New function is created using the data processing template
Actual: Error occurs due to 500 response from kudu for PUT request.
The error details below show a file not found error occuring for data\functions\sampledata. I looked at the filesystem of the site and the data\functions\sampledata folder does not exist.
This might be a kudu or template bug, if so please port to the appropriate location.
PUT /api/functions/QueueTriggerNodeJS1 HTTP/1.1
HTTP/1.1 500 Internal Server Error
{"Message":"An error has occurred.","ExceptionMessage":"Could not find a part of the path 'D:\home\data\functions\sampledata\QueueTriggerNodeJS1.dat'.","ExceptionType":"System.IO.DirectoryNotFoundException","StackTrace":"   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)\r\n   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)\r\n   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)\r\n   at System.IO.Abstractions.FileWrapper.Open(String path, FileMode mode, FileAccess access, FileShare share)\r\n   at Kudu.Core.Infrastructure.FileSystemHelpers.d__24.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at

already fixed:
https://github.com/projectkudu/WebJobsPortal/commit/ea448a61ccc1ce8f7e6659e2175e28166de2ee92


Add Woodpecker to Debugging section

Project URL
http://www.woodpeck.cn
Category
Debugging
Description
Add Woodpecker to Debugging section
Why it should be included to awesome-ios (mandatory)
Woodpecker is a Mac app aimed at helping us develop iOS Apps efficiently.
It can helps us:

view, modify sandbox files;
view, modify UserDefaults item;
monitor network request;
run javascript code in webView;

Checklist

[x] Only one project/change is in this pull request
[ ] Has unit tests, integration tests or UI tests
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 1 link issue, a project collaborator will take care of these, thanks :)

Link issue by awesome_bot

Line
Status
Link

1403
301
https://github.com/Hearst-DD/ObjectMapper redirects tohttps://github.com/tristanhimmelman/ObjectMapper

  Generated by :no_entry_sign: Danger

@github-xiaogang Sorry, we cannot merge your PR. Would be interesting if the project have a trial option to offer to developers. In Awesome-iOS we're always trying to not include commercial only projects.

@vsouza Okay, Thank you!


Routing issue with multiple subnets

Hi,
I have a Linux router (running pimd-2.3.1) which has addresses in multiple subnets (it's the only router in the network) and two IPIP tunnels. Here is my configuration:
/etc/pimd.conf
rp-address <IP_ADDRESS> <IP_ADDRESS>/19
rp-address <IP_ADDRESS> <IP_ADDRESS>/19
rp-address <IP_ADDRESS> <IP_ADDRESS>/19
rp-address <IP_ADDRESS> <IP_ADDRESS>/19
spt-threshold packets 0 interval 100
(10.1,253,9 and <IP_ADDRESS> are the router's addresses)
How pimd sees network interfaces:
10:29:04.143 Getting vifs from kernel
10:29:04.143 Installing eth0.100 (<IP_ADDRESS> on subnet 10.0.1/24) as vif #0-7 - rate 0
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.1.1/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.1.2/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.1.25/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.1.26/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.2.1/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.2.2/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.2.25/24) (alias for vif#0?)
10:29:04.143 Ignoring eth0.100 (<IP_ADDRESS> on subnet 10.2.26/24) (alias for vif#0?)
10:29:04.143 Installing eth2.1001 (<IP_ADDRESS> on subnet 192.130.2) as vif #1-8 - rate 0
10:29:04.143 Installing eth3.1202 (<IP_ADDRESS> on subnet 192.130.4) as vif #2-9 - rate 0
10:29:04.143 Installing eth1.251 (<IP_ADDRESS> on subnet 10.2.251/24) as vif #3-10 - rate 0
10:29:04.143 Installing eth0.16 (<IP_ADDRESS> on subnet 10.128.116/24) as vif #4-11 - rate 0
10:29:04.143 Ignoring eth0.16 (<IP_ADDRESS> on subnet 10.129.116/24) (alias for vif#4?)
10:29:04.143 Installing eth1.252 (<IP_ADDRESS> on subnet 10.2.252/24) as vif #5-12 - rate 0
10:29:04.143 Installing eth0.21 (<IP_ADDRESS> on subnet 10.128.103/24) as vif #6-13 - rate 0
10:29:04.143 Ignoring eth0.21 (<IP_ADDRESS> on subnet 10.129.103/24) (alias for vif#6?)
10:29:04.143 Installing eth0.24 (<IP_ADDRESS> on subnet 10.128.117/24) as vif #7-14 - rate 0
10:29:04.143 Ignoring eth0.24 (<IP_ADDRESS> on subnet 10.129.117/24) (alias for vif#7?)
10:29:04.143 Installing eth1.253 (<IP_ADDRESS> on subnet 10.2.253/24) as vif #8-15 - rate 0
10:29:04.143 Installing eth0.251 (<IP_ADDRESS> on subnet 10.1.251/24) as vif #9-16 - rate 0
10:29:04.143 Installing eth1.31 (<IP_ADDRESS> on subnet 10.2.231/24) as vif #10-17 - rate 0
10:29:04.143 Installing eth0.252 (<IP_ADDRESS> on subnet 10.1.252/24) as vif #11-18 - rate 0
10:29:04.143 Installing eth1.402 (<IP_ADDRESS> on subnet 10.2.233/24) as vif #12-19 - rate 0
10:29:04.143 Installing eth0.253 (<IP_ADDRESS> on subnet 10.1.253/24) as vif #13-20 - rate 0
10:29:04.143 Installing eth1.41 (<IP_ADDRESS> on subnet 10.2.241/24) as vif #14-21 - rate 0
10:29:04.143 Installing eth0.26 (<IP_ADDRESS> on subnet 10.128.114/24) as vif #15-22 - rate 0
10:29:04.143 Ignoring eth0.26 (<IP_ADDRESS> on subnet 10.129.114/24) (alias for vif#15?)
10:29:04.143 Installing eth0.31 (<IP_ADDRESS> on subnet 10.1.231/24) as vif #16-23 - rate 0
10:29:04.143 Installing eth1.42 (<IP_ADDRESS> on subnet 10.2.242/24) as vif #17-24 - rate 0
10:29:04.143 Installing eth1.602 (<IP_ADDRESS> on subnet 10.129.105/24) as vif #18-25 - rate 0
10:29:04.143 Installing eth0.336 (<IP_ADDRESS> on subnet 10.1.236/24) as vif #19-26 - rate 0
10:29:04.143 Ignoring eth0.336 (<IP_ADDRESS> on subnet 10.2.236/24) (alias for vif#19?)
10:29:04.143 Installing eth0.37 (<IP_ADDRESS> on subnet 10.1.237/24) as vif #20-27 - rate 0
10:29:04.143 Ignoring eth0.37 (<IP_ADDRESS> on subnet 10.2.237/24) (alias for vif#20?)
10:29:04.143 Installing eth0.401 (<IP_ADDRESS> on subnet 10.1.233/24) as vif #21-28 - rate 0
10:29:04.143 Installing eth0.41 (<IP_ADDRESS> on subnet 10.1.241/24) as vif #22-29 - rate 0
10:29:04.143 Installing eth0.42 (<IP_ADDRESS> on subnet 10.1.242/24) as vif #23-30 - rate 0
10:29:04.143 Installing eth0.601 (<IP_ADDRESS> on subnet 10.128.105/24) as vif #24-31 - rate 0
10:29:04.143 Installing ipiptun1 (<IP_ADDRESS> -> <IP_ADDRESS>) as vif #25-32 - rate 0
10:29:04.143 Installing ipiptun2 (<IP_ADDRESS> -> <IP_ADDRESS>) as vif #26-33 - rate 0
(...)
10:29:04.143 Interface eth0.100 comes up; vif #0 now in service
10:29:04.143 query_groups(): Sending IGMP v3 query on eth0.100
10:29:04.143 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.143 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>      to <IP_ADDRESS>
10:29:04.143 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>      to <IP_ADDRESS>
10:29:04.143 Interface eth2.1001 comes up; vif #1 now in service
10:29:04.144 query_groups(): Sending IGMP v3 query on eth2.1001
10:29:04.144 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.144 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>   to <IP_ADDRESS>
10:29:04.144 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>   to <IP_ADDRESS>
10:29:04.144 Interface eth3.1202 comes up; vif #2 now in service
10:29:04.144 query_groups(): Sending IGMP v3 query on eth3.1202
10:29:04.144 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.144 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>   to <IP_ADDRESS>
10:29:04.144 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>   to <IP_ADDRESS>
10:29:04.144 Interface eth1.251 comes up; vif #3 now in service
10:29:04.144 query_groups(): Sending IGMP v3 query on eth1.251
10:29:04.144 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.144 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.144 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.144 Interface eth0.16 comes up; vif #4 now in service
10:29:04.144 query_groups(): Sending IGMP v3 query on eth0.16
10:29:04.144 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.144 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.144 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.144 Interface eth1.252 comes up; vif #5 now in service
10:29:04.150 query_groups(): Sending IGMP v3 query on eth1.252
10:29:04.150 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.150 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.150 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.151 Interface eth0.21 comes up; vif #6 now in service
10:29:04.151 query_groups(): Sending IGMP v3 query on eth0.21
10:29:04.151 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.151 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>   to <IP_ADDRESS>
10:29:04.151 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>   to <IP_ADDRESS>
10:29:04.151 Interface eth0.24 comes up; vif #7 now in service
10:29:04.152 query_groups(): Sending IGMP v3 query on eth0.24
10:29:04.152 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.152 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.152 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.152 Interface eth1.253 comes up; vif #8 now in service
10:29:04.153 query_groups(): Sending IGMP v3 query on eth1.253
10:29:04.153 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.153 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>      to <IP_ADDRESS>
10:29:04.153 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>      to <IP_ADDRESS>
10:29:04.153 Interface eth0.251 comes up; vif #9 now in service
10:29:04.153 query_groups(): Sending IGMP v3 query on eth0.251
10:29:04.153 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.153 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.153 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.154 Interface eth1.31 comes up; vif #10 now in service
10:29:04.154 query_groups(): Sending IGMP v3 query on eth1.31
10:29:04.154 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.154 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.154 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.154 Interface eth0.252 comes up; vif #11 now in service
10:29:04.154 query_groups(): Sending IGMP v3 query on eth0.252
10:29:04.154 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.154 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.155 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.155 Interface eth1.402 comes up; vif #12 now in service
10:29:04.155 query_groups(): Sending IGMP v3 query on eth1.402
10:29:04.155 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.155 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.155 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.155 Interface eth0.253 comes up; vif #13 now in service
10:29:04.155 query_groups(): Sending IGMP v3 query on eth0.253
10:29:04.156 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.156 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>      to <IP_ADDRESS>
10:29:04.156 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>      to <IP_ADDRESS>
10:29:04.156 Interface eth1.41 comes up; vif #14 now in service
10:29:04.156 query_groups(): Sending IGMP v3 query on eth1.41
10:29:04.156 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.156 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.156 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.156 Interface eth0.26 comes up; vif #15 now in service
10:29:04.157 query_groups(): Sending IGMP v3 query on eth0.26
10:29:04.157 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.157 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.157 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.157 Interface eth0.31 comes up; vif #16 now in service
10:29:04.158 query_groups(): Sending IGMP v3 query on eth0.31
10:29:04.158 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.158 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.158 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.158 Interface eth1.42 comes up; vif #17 now in service
10:29:04.158 query_groups(): Sending IGMP v3 query on eth1.42
10:29:04.158 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.158 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.159 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.159 Interface eth1.602 comes up; vif #18 now in service
10:29:04.159 query_groups(): Sending IGMP v3 query on eth1.602
10:29:04.159 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.159 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.159 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.160 Interface eth0.336 comes up; vif #19 now in service
10:29:04.163 query_groups(): Sending IGMP v3 query on eth0.336
10:29:04.163 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.163 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.163 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.163 Interface eth0.37 comes up; vif #20 now in service
10:29:04.163 query_groups(): Sending IGMP v3 query on eth0.37
10:29:04.163 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.163 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.163 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.163 Interface eth0.401 comes up; vif #21 now in service
10:29:04.164 query_groups(): Sending IGMP v3 query on eth0.401
10:29:04.164 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.164 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.164 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.164 Interface eth0.41 comes up; vif #22 now in service
10:29:04.164 query_groups(): Sending IGMP v3 query on eth0.41
10:29:04.164 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.164 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.164 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.165 Interface eth0.42 comes up; vif #23 now in service
10:29:04.165 query_groups(): Sending IGMP v3 query on eth0.42
10:29:04.165 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.165 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.165 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>    to <IP_ADDRESS>
10:29:04.165 Interface eth0.601 comes up; vif #24 now in service
10:29:04.165 query_groups(): Sending IGMP v3 query on eth0.601
10:29:04.165 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.165 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.166 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>  to <IP_ADDRESS>
10:29:04.166 Interface ipiptun1 comes up; vif #25 now in service
10:29:04.166 query_groups(): Sending IGMP v3 query on ipiptun1
10:29:04.166 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.166 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.166 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.166 Interface ipiptun2 comes up; vif #26 now in service
10:29:04.166 query_groups(): Sending IGMP v3 query on ipiptun2
10:29:04.166 Send IGMP Membership Query     from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.166 SENT    36 bytes IGMP Membership Query     from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.167 SENT    46 bytes PIM v2 Hello              from <IP_ADDRESS>     to <IP_ADDRESS>
10:29:04.168 Interface register_vif0 comes up; vif #27 now in service
The effect is that multicasts are routed to ipiptun2 just fine, but not to ipiptun1. Digging further into the debug output I can see this for ipiptun1:
10:29:04.635 Received IGMP v2 Membership Report from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.636 accept_group_report(): igmp_src <IP_ADDRESS> ssm_src <IP_ADDRESS> group <IP_ADDRESS> report_type 22
10:29:04.636 accept_group_report(): al_pv=2
10:29:04.636 Set delete timer for group: <IP_ADDRESS>
10:29:04.636 create group entry, group <IP_ADDRESS>
10:29:04.774 Cache miss, src <IP_ADDRESS>, dst <IP_ADDRESS>, iif 10
10:29:04.775 find_route: Not PMBR, return NULL
10:29:04.775 Switch shortest path (SPT): src <IP_ADDRESS>, group <IP_ADDRESS>
10:29:04.775 create group entry, group <IP_ADDRESS>
For ipiptun2 it's a bit different:
10:29:04.237 Received IGMP v2 Membership Report from <IP_ADDRESS> to <IP_ADDRESS>
10:29:04.237 accept_group_report(): igmp_src <IP_ADDRESS> ssm_src <IP_ADDRESS> group <IP_ADDRESS> report_type 22
10:29:04.237 accept_group_report(): al_pv=2
10:29:04.237 Set delete timer for group: <IP_ADDRESS>
10:29:04.238 create group entry, group <IP_ADDRESS>
10:29:04.288 Cache miss, src <IP_ADDRESS>, dst <IP_ADDRESS>, iif 10
10:29:04.288 create group entry, group <IP_ADDRESS>
The configuration for the two IPIP tunnels as well as 10.1.231/24 and 10.2.231/24 networks is symmetrical. I don't understand why pimd treats them differently. I have noticed that in both cases the "cache miss" log entry mentions "iif 10", that doesn't seem right, does it?
Could you please help me solve this problem?
Thank you.

Hi @swiergot, it's quite hard to picture your setup and understand the problem. Do you think you could add like a topological drawing (ASCII art is fine) and describe the setup a bit more?

Unless some more information is provided in this issue, I'll close it by the end of the month.

Closing due to lack of information from reporter + timeout.


Fix queue creation with dead letter policy

This should fix #109

Released as 0.13.6. Thanks!

Thanks for this fix. This caused some confusion during our elasticmq upgrade since we were previously passing an int for maxReceiveCount. This review caused it to only accept strings. However, it's technically more correct now since SQS's sdk also expects strings.


UserProfile should include status that indicates if a Cloud instance is owned by or shared with the local user.

Depends on: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/7263
uProxy will check the UserStatus to determine if a user should see a cloud instance in their Share tab (and therefore see a URL for sharing that cloud instance with others).

:+1:


On localized cache keys an some FS types refinery will fail to store cache

To reproduce:

Localized refinery - in my case to Russian
Some encrypted fs (eCryptfs in my case) with not regular filesize limit
Bug within ActiveSupport related to convert UTF to Binary - see https://github.com/rails/rails/pull/4911

On Mac all works like expected.
But some Linux production servers are encrypted.
In this case not very long cache key will be converted to Binary to some this kind of string
%2Fru%2F%D0%B2%D1%82%D0%BE%D1%80%D0%BE%D0%B9%23nested_url

My monkey patch: to fix this
https://github.com/kalabiyau/refinerycms/commit/e5380ceb8978828757c13a82a9570b21cc37fdf1

What about performance - this will happen only on save, which is not so common for middle size site. And md5 is very fast :)
But i assume, this is ugly approach to fix a problem.

If my option is appropriate - i can add some tests cover and make a PR for it.

@kalabiyau is this issues related to latest edge please? cache_key changed now and there are no UTF characters anymore.
https://github.com/resolve/refinerycms/blob/master/pages/app/models/refinery/page.rb#L315
def cache_key
  [Refinery::Core.base_cache_key, 'page', ::I18n.locale, id].compact.join('/')
end

Cache key is now similar to refinery/page/en/1.

@simi Josef, thanx, this is not related to edge. 20 commits is so many for this speedy project :)
But as for rails and ruby & GNU/Linux - this problem will persist (

@kalabiyau yeah. That's the tax for living on the edge.