"running Legacy WhatsApp for a while" unneeded and slightly misleading

Hit Enter key after running Legacy WhatsApp for a while. Ignore invalid date warning.

Should be somehow rephrased as the old version by now it's just straight crashing and the user might go on the wrong track trying to actually have the old WA working when it isn't needed and in fact all is well.
For me:

permissions prompt for WA comes up, I gave them all
I start WA it promptly closes

I hit Enter in the script and all goes as planned. Not sure if even trying to run WA once is needed, as we need just Android to see the fact that the app allows backups (it would be good if we can avoid running the old WA altogether in case it messes up the db).
Also if one doesn't do adb over network it would be a good idea to suggest putting the phone in airplane mode.

The reason for running old WhatsApp for a while to get adb backup to work properly. I don't know how or why that worked but that did nevertheless.: https://github.com/YuvrajRaghuvanshiS/WhatsApp-Key-Database-Extractor/issues/16#issuecomment-776226594
This script launches WhatsApp main activity after installing its old version, that's why you get permissions prompt, so I guess that is enough to get adb backup to work properly but unfortunately I can't test it (don't use WA anymore). You can try granting permissions and don't run whatsapp and see.

Also if one doesn't do adb over network it would be a good idea to suggest putting the phone in airplane mode.

I did see something similar on XDA a few months ago but I didn't get the significance of that. Please elaborate...

All right, still if it has a chance to work even if WA crashes (for me it works everywhere, including on Pixels with the latest Android) maybe just add to "running Legacy WhatsApp for a while" something like (you might go ahead even if WA crashes, sometimes it works anyway). Seriously, I spent a lot of time (and messed up my WA) trying to make the old one work and then even gave up for a few months until someone told me "this really works", I was thinking I'll never make old WA work so no chance (when in fact I should've just continued and everything was fine).
As far as going into airplane mode I think it's safer because the old WA will try to connect to their servers, you might get your account flagged or even generally there would be many more branches the software can take when connecting to a server. So basically it can either leak to them that you're doing something funny or can do something unexpected to local db/key/etc. based on some info received from the mothership. Also the behavior can be unpredictable, it can work fine for years then mess up everything for everyone due to some (intended or not) change on the server.

Wow, I'm sorry I didn't mean to mislead. I will update that.
You're right, I can turn wifi and data off from within script. I am implementing those right away. Thanks.

Merged to master.


Edit Service Provider - SAML2 Web SSO Configuration UI - Too short data fields.

The fields in the UI are not long enough to see the information fully. Since we have so much space left to the right of the screen, we should make the fields longer.

Solution merged, hence closing


Bazelisk changes the PATH which breaks Bazel caching

I was trying to figure out why Bazel was always rebuilding my files and never using its internal cache. After debugging I found that is is due to Bazelisk
My use case
I am running two different Bazel targets in a pnpm run script:
"serve.bazel": "pnpm run generate.bazel-build-files && cd .. && node_modules/.bin/bazelisk run //client-source:dev_server_binary","

The generate.bazel-build-files script looks like:
"generate.bazel-build-files": "python3 nw-bazel/tools/generate_build_files.py",

That python file runs:
    exit_code = sp.call([os.path.join('node_modules', '.bin', 'bazelisk'),
                        'build', '//client-source:gen_bazel'], env=os.environ)

Every time I run pnpm run serve.bazel, it always does a full build, as if I had an expunged directory. I saw this output when using verbose mode:

Effective client environment has changed

What happens is that bazelisk keeps on changing the PATH, adding the same variables to the existing path, so I'm getting nested environment issues.
These are the items that seem to be dynamically added to my Bazel's PATH:
/Users/andrew/my-working-copy/client-source/node_modules/.bin
/Users/andrew/.cache/node/corepack/pnpm/7.6.0/dist/node-gyp-bin
/Users/andrew/my-working-copy/node_modules/.bin
/Users/andrew/Library/pnpm/nodejs/16.16.0/bin

When I'm running this, I found that these 4 entries were on the path 3 times (repeated). So it seems that somehow bazelisk was altering the PATH and not checking to see if it needed to and as a result, the PATH was changing. Since Bazel will throw the cache out if the action_env changes, the result is that none of my builds are being cached.
I'm working on coming up with a work-around, but one may be that we just stop using Bazelisk for now.

This may be more of an issue with PNPM. Here is what the pnpm/bazel file looks like as installed by pnpm:
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -z "$NODE_PATH" ]; then
  export NODE_PATH="/Users/andrew/Library/pnpm/global/5/.pnpm/node_modules"
else
  export NODE_PATH="$NODE_PATH:/Users/andrew/Library/pnpm/global/5/.pnpm/node_modules"
fi
"/Users/andrew/Library/pnpm/nodejs/16.16.0/bin/node"<EMAIL_ADDRESS>"$@"
exit $?

So this may be a PNPM issue not with bazelisk

Closing, filed https://github.com/pnpm/pnpm/issues/5352 instead after more research. It is a pnpm issue


<Branch: bug-fixes-2018-February> Not able to proceed to start server as it is not able to read csv file

hi,
We are not able to proceed to start server as it is not able to read csv file.
Following error is observed while starting server:
2018-02-27T09:36:25.595Z - INFO - Please enter a csv file path that include the test you request to run (pay attention insert the csv file without the csv suffix)
, type quit and press ctrl+c to close
2018-02-27T09:38:01.058Z - INFO - the file C:\testFiles\WINNF.FT.C.REG.3 or the jsons file inside the csv rows not found
2018-02-27T09:38:01.059Z - INFO - Please enter a csv file path that include the test you request to run (pay attention insert the csv file without the csv suffix)
, type quit and press ctrl+c to close
2018-02-27T09:40:42.026Z - INFO - the file C:\testFiles\WINNF.FT.C.REG.8 or the jsons file inside the csv rows not found
2018-02-27T09:40:42.028Z - INFO - Please enter a csv file path that include the test you request to run (pay attention insert the csv file without the csv suffix)
, type quit and press ctrl+c to close
Could you please check this issue?

Hi Pawan,
From your log, I notice:
2018-02-27T09:38:01.058Z - INFO - the file C:\testFiles\WINNF.FT.C.REG.3 or the jsons file inside the csv rows not found
It is looking for the test file in "C:\testFiles directory".  I think this means that your conf.xml file is not correct.  Since the os-independent changes, there should be no "/" leading the file paths in that file.  If there is, the program will assume the directory is in the root directory (i.e. C:).  So, please have a look at your conf.xml file and ensure it has this format:

jsonExpectedFolder
testFiles
<IP_ADDRESS>
5000
30
certificates/flaskcert1.pem
certificates/flaskcbsdiot.key
certificates/cacertidan1.pem
certificates/cpi_ca.crt

Please let me know if I am wrong and you still have the problem.  Otherwise, I am able to run the scripts so there must be some other setup issue.

sorry, some GitHub formatting issues.  Here is the example file I meant to include...
conf.zip

issue resolved after updating conf file


kb.Store::retainOrCreate() calls kb.Store::retain() twice when 'creating' and never when 'retaining'

Hi kmalalkoff,
I'm a big fan of this library. There's just one thing which is breaking our very complex app.
The quick version of this issue, is that retain() is called twice when a new viewModel is registered with retainOrCreate (once at the end of this function, line 112; and once when the viewModel is created, via useOptionsOrCreate(), line 33). When a viewModel already exists, i expect retain to be called, but instead the function just returns the found observable, line 103.

The lines above refer to src/core/store.coffee.

I'm not sure if this is how you intended to use the retain function, but let me tell why i expect this behaviour.
My complex App uses a global kb.Store to share all my viewModels. I am using Backbone.Relational to handle my Model Hierarchy.
Many of my models have a complex hierarchy of nested models (no circular structures) and sometimes I want to set a nested model, to another model. When I set a nested model to another one, the previous value gets released. Quite often that previous value is a shared viewModel which appears in another collectionObservable or nested in another model. Each time a shared ViewModel is released, the refCount is reduced until it is eventually destroyed, breaking the app.
Think of this simple scenario. Job is a viewModel, Client is a viewModel, Job has a Client as a nested model. User changes JobA.client() from ClientA to ClientB. ClientA gets destroyed and any other Jobs that held that client now references a __kb_released ViewModel. (* More accurately, you need to change the client back and forth twice because the ref_count starts at 2.)
Theres an easy way to fix this problem. 1) add a ref_count using retain whenever a viewModel is created or set on a parent viewModel (or simply call retain() when an observable is found in retainOrCreate). The double ref_count on creation is a less significant problem, but seems like a bug.
I've been logging the ref_count changes in some of my tests and i expect the changes to look like 1, 2, 3, 4, 3, 2, 1, destroyed. But they actually look like 2, 2, 2, 2, 1, destroyed.
Note that this only happens when I specify a custom global kb.Store on all my viewModels. If I don't do this and let the Framework create the stores for me, the viewModels don't get shared and way too many viewModels get created, freezing up the browser significantly.
I know the change that needs to be made to retainOrCreate (call retain when existing observable found, but not otherwise). Let me know if you agree and would like me to fork and send a pull request.
This issue is a bit of a show stopper for us, but everything else about this framework is like poetry. Great work!

I'm glad to hear that Knockback is a pleasure to use despite this issue. Also, I really appreciate the time you spent to understand and explain the problems. Thank you!
The store was implemented for handling circular dependencies in distinct pools of view models for dependent sub-sections of an application. Also, the design in mind was that there was a one-to-many relationship between models and view models since different parts of the app would have different hierarchical display needs rather than having a one-to-one mapping between models and view models causing view models to be Uber view models for all situations.
Because of these design goals, I wasn't anticipating anyone using one global store for the full app. Also, the creation cycle of first going deep through the hierarchy before getting and retaining references to view models made reference counting a little non-conventional in the order of operations around lifecycles. This is the likely reason for the order of operations that you mentioned.
Also, because view models are shared, the 1-2-3-4-3-2-1 vs 1-2-2-2-2-1 patterns seems like it might be expected if a globally shared view model is retaining one count to a dependent view model. Of course, if this isn't the case, then the handling may be wrong.
Hopefully, this information provides enough detail to make a decision on changing the reference counting logic to try to make a global store behave as you expect be spite these potential gotchas. I'm definitely not opposed to a fresh look at the reference counting code, would accept a pull request if the tests pass, and believe the tests will most likely catch potential breaking behavior cases.
Other options you could consider:

no global store and one-to-many relationships between models and view models

manually retaining view models before a batch of changes and then releasing afterwards. Although this sounds like it may still suffer from the problem due to nested references being over-zealously released.

Let me know what you decide and if you want to discuss any details you discover.

The no global store and one-to-many relationship between models and view models option, was actually what we had, which was working great until we hit performance issues. It makes a lot of sense to have it that way, but unfortunately for our app, the many situations caused too many view models to be created.
I added the global store to reuse the view models because our design turns out to have 'Uber view models' anyway. e.g.
`
class Job extends extends kb.ViewModel
constructor: (model) ->
super(model, {factories: Client, store: GlobalKbStore})
getDisplayName: -> @name() + @client().getDisplayName()
class Client extends kb.ViewModel
constructor: (model) ->
super(model, {store: GlobalKbStore})
getDisplayName: -> @name()
class JobList extends kb.CollectionObservable
constructor: (collection) ->
super(collection, {view_model: Job, store: GlobalKbStore})
`
That's a very simplified example, but when designed this way, it works for both one-to-one and one-to-many type model to view model structures. I handle the context specific behaviour with the controllers for that context.
I would have liked to keep the one-to-many structure with many pools of stores, but the way i've designed it means that too many distinct pools are created and hence almost every reuse of a model creates a new view model (in the thousands in total).
I think the change I wish to make will still work for both types of relationships and I think there is indeed a bug where the first view model creates a double ref_count, where both retainOrCreate and useOptionsOrCreate are calling retain in the same flow. It might be worth checking some of your examples to see if your view models start with a ref_count of 2. If not, it must be something with my design only.
I will create a pull request and run the tests for your review.

After applying the proposed changes, I'm getting unexpected results for the refcounts in my tests. I may be making the wrong assumptions about how the store_references work. I'll get back to you.

Hi Kevin,
So i think i've worked it out.
retainOrCreate() gets called from exactly 2 places in knockback.core:

collection-observable.coffee:417
typed-value.coffee:81

I think these two calls need to behave differently.

in collection-observable.coffee, the retainOrCreate() function needs to behave like a findOrCreate. When a matching observable has been found in the store, it should just return the observable.
In typed-value, the the retainOrCreate() function is called when setting an observable with a creator. If there's a creator, we're setting an observable into another observable, so i think it makes sense to increase the ref_count for this observable, then release the previous_value. Currently, knockback only releases the previous_value. In this scenario retainOrCreate should behave exactly in that way - retain if found, create if otherwise.

So far in my personal tests the ref_counts seem to increase and decrease when necessary and view_models are released when there are no more references. View models have not been over-zealously released so far.
There is a possibility that view models may get a higher ref_count than it should meaning it will never get released. I haven't been able to produce that scenario, and I don't understand the framework well enough to be 100% sure. But if it does come up, i figure its less destructive than releasing when its not supposed to. So you might have to check this if you think it might be an issue.
My proposed fix was to add an additional parameter to the function - retainOrCreate(obj, options, retainExisting). The boolean value of retainExisting decides whether to retain the found observable or just return it.
I thought about separating this behaviour into two functions - retainOrCreate and findOrCreate, but i figured there would be too much duplicated code and it may break compatibility with other existing code/libraries that may be using the kb.Store.
pull request is here https://github.com/kmalakoff/knockback/pull/156

P.S. My app is now blazingly fast in comparison :)

Awesome! Your explanation sounds right.
I'll review the changes and will try to get the tests to pass before pushing out a new release. I'll try to get this done tonight or Saturday morning (PST).

There was one change that I needed to make to get the tests to pass: https://github.com/kmalakoff/knockback/blob/update-refcounting/src/core/store.coffee#L113
Let me know if this makes sense and works for you.
FYI: I've moved to the update-refcounting branch.

Hi Kevin,
I think that may cause the ref_count to start at 2 in some cases, but that's fine with me. If your tests show that there are view models being released, i think its working great.
I'll pull the changes and run some tests on my app.

I have noticed a lot less view models being released. But, I'm really okay with it because I'm reusing them. However i'm not sure if there are others who may be losing the memory management benefit, of releasing unused view models. Once again, if your tests seem to be releasing them fine and as long as your happy with that side of things, I guess we're all good to go :)

Thank you for confirming and explaining about the starting ref count.
It could be that the store itself holds 1 reference and then the collection holding it stores another causing it to start at 2. I'll take another pass through the failing tests without the extra retain and confirm this is the case before releasing a new version of the library, but like you say, if the tests are passing, it should be behaving properly (hopefully!).

 I totally missed that. I'm getting ref_count 1's now

OK. It's released. Thank you for tracking this problem down and submitting a solution.

Thank you! You rock!

It looks like this fix breaks https://github.com/kmalakoff/knockback/issues/157
We'll triage there if you have time to help...


Order screen overlapping fields on smaller screens

After the last change  merge, the order form elements are overlapping when the UI is used with smaller screens.

@WangLiNaruto also the CSP logos are not listed next to each other even on bigger screens


Board Orientation for Exercises not saved after leaving Application Options when it differs from Training Side

See below, I change Exercises to White but after closing the options Exercises Board is still Black:

If I leave Application Options and close Workbook with Auto Save on the setting change is remembered but without closing Chess Forge it is not

Still not fixed. I change board for Exercises to Black (workbook is for Black) and board is shown for White


Extension is not activating(Visual Studio Code)

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS: Windows 11
- Continue version:v0.8.57
- IDE version: VSCode 1.95.3

Description
I am getting an error like this ->"Error activating the Continue extension"
I have tried all the methods to check if my other extensions are conflicting with the activation of this extension, but i am still getting the same error. Below is the image of the error that is showing up.

To reproduce
-> Go to Visual Studio Code.
-> Open Extensions Section.
-> Install the extension "Continue-Codeastral, Claude, and more".
-> Try opening the extension.
Log output
2024-11-20 21:54:01.212 [info] Extension host with pid 7500 started
2024-11-20 21:54:01.330 [info] ExtensionService#_doActivateExtension vscode.git-base, startup: true, activationEvent: '*', root cause: vscode.git
2024-11-20 21:54:01.343 [info] ExtensionService#_doActivateExtension vscode.emmet, startup: false, activationEvent: 'onLanguage'
2024-11-20 21:54:01.437 [info] ExtensionService#_doActivateExtension vscode.git, startup: true, activationEvent: '*'
2024-11-20 21:54:01.655 [info] ExtensionService#_doActivateExtension vscode.github, startup: true, activationEvent: '*'
2024-11-20 21:54:01.895 [info] Eager extensions activated
2024-11-20 21:54:01.918 [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:54:01.928 [info] ExtensionService#_doActivateExtension vscode.merge-conflict, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:54:01.965 [info] ExtensionService#_doActivateExtension ecmel.vscode-html-css, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:54:32.013 [info] ExtensionService#_doActivateExtension Continue.continue, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:54:44.493 [error] Error: command 'continue.viewLogs' not found
    at mWe.n (vscode-file://vscode-app/c:/Users/dell/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:1295:1341)
    at mWe.executeCommand (vscode-file://vscode-app/c:/Users/dell/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:1295:1273)
2024-11-20 21:55:37.146 [info] Extension host terminating: renderer closed the MessagePort
2024-11-20 21:55:37.155 [info] Extension host with pid 7500 exiting with code 0
2024-11-20 21:55:37.799 [info] Extension host with pid 7524 started
2024-11-20 21:55:37.809 [info] ExtensionService#_doActivateExtension vscode.emmet, startup: false, activationEvent: 'onLanguage'
2024-11-20 21:55:37.829 [info] ExtensionService#_doActivateExtension vscode.git-base, startup: false, activationEvent: '*', root cause: vscode.git
2024-11-20 21:55:37.848 [info] ExtensionService#_doActivateExtension vscode.git, startup: false, activationEvent: '*'
2024-11-20 21:55:37.908 [info] ExtensionService#_doActivateExtension vscode.github, startup: false, activationEvent: '*'
2024-11-20 21:55:38.012 [info] Eager extensions activated
2024-11-20 21:55:38.020 [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:55:38.024 [info] ExtensionService#_doActivateExtension vscode.merge-conflict, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:55:40.391 [info] ExtensionService#_doActivateExtension Continue.continue, startup: false, activationEvent: 'onStartupFinished'
2024-11-20 21:56:26.023 [info] ExtensionService#_doActivateExtension vscode.github-authentication, startup: false, activationEvent: 'onAuthenticationRequest:github'

note, I had this error as well and fixed on this branch by adding the viewlogs command back to package.json
https://github.com/continuedev/continue/pull/2978/files#diff-288f1ebddf6afc6081e2ca910029e86e55c9cd7871b425c2a97a82a2cd77ac9e

note, I had this error as well and fixed on this branch by adding the viewlogs command back to package.json https://github.com/continuedev/continue/pull/2978/files#diff-288f1ebddf6afc6081e2ca910029e86e55c9cd7871b425c2a97a82a2cd77ac9e

Thank you for sharing the fix and pointing me to the branch! I tried adding the viewlogs command back to package.json as suggested and also done the other changes committed, but unfortunately, I'm still encountering the same error. Do you have any additional suggestions or insights on what else might be causing this? I’d greatly appreciate your help!

Have you tried removing the project and recloning? A bit of a blunt approach but that would be a good way to guarantee you're starting from scratch;

I had the same issue yesterday. In my case it was a simple solution. Due to work restrictions I always have to manually download the .vsix install file to update. Since I usually work on Windows I downloaded the windows version. However, this time I had to install on a Red Hat Enterprise Linux machine.
At first I tried to install the Windows vsix on the linux machine which triggered the same error like yours. This morning I discovered my error and downloaded the linux version. Works flawless without the error now, so you might take a look at your vsix versions.

I got the same error message. In my case the OS is Windows 11 running on ARM (Snapdragon X). Wonder if this could be a cause for the error...


Bug with Clip Content property of a Container when turning a set to current Camera2D node

Godot version: 3.2
Issue description: I have created a Container node and put some Sprite nodes in it. Then I've set the Clip Content property to true and created a current Camera2D node. The program worked and there was no errors. When I've set the Camera2D's Rotating property to true and turned the camera by 10 degrees (and zoomed it to 0.6). When I run the program, the Container's clip content rectangle is slightly (approximately by 30% of its height) moved down and is rotating with the camera, like the camera wasn't rotated. What's the problem with it?

@progyan Please upload a minimal reproduction project to make this easier to troubleshoot.

The only thing you need is a clipping control node that's rotated and visible content that is clipped (no camera needed).
It keeps the maximum bounding box of the corners of the control node, so it seems like maybe it's clipping after rotation rather than before? Or maybe non-rotated boxes were the only thing in mind with the original structure.
MRP:
rotated_clip_content_mrp.zip
Screenshot of MRP:

Closing in favor of #87902, which is more precise.


Define plugin builders & schematics schemas

Current Behavior

Expected Behavior

Related Issue(s)

Fixes #

:tada: This PR is included in version 1.0.0-alpha.1 :tada:
The release is available on:

GitHub release
npm package (@alpha dist-tag)

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-beta.1 :tada:
The release is available on:

GitHub release
npm package (@beta dist-tag)

Your semantic-release bot :package::rocket:


Update throttling-limits.md

Identified couple of corrections, modified doc accordingly, ProductGroup provided the changes.

@rwike77   could you please review this PR as well? along with https://github.com/MicrosoftDocs/azure-docs/pull/114926
changes were confirmed by Throttling SME, please let me know if you want me to add you OR FWD the email thread.

ready for content review


Unexpected behaviour in comlex prompt & hires

My example prompt is:
[A female model : [<'Cameron'><' '><'Diaz'>|<'Drew'><' '><'Barrymore'>|<'Lucy'><' '><'Liu'>] : 0.25]

After rendering I see the face that looks like the expected mix, so the extension works as expected, but without "EmbeddingMerge" in the image info:
[A female model : [ <'EM_1'> <'EM_2'> | <'EM_3'> <'EM_4'> | <'EM_5'> <'EM_6'> ] : 0.25] Negative prompt: sad, monotone, low quality, low resolution, [mutated | extra | missed | broken] fingers Steps: 30, Sampler: DPM++ 3M SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 512x768, Model hash: ce49fd5253, Model: YACAM-SR-16111.fp16, RNG: CPU, CDT: "1,1,0,0,0,0,0,0,0,0,1,-1,1,0", Eta: 0.5, Version: v1.7.0
Hires.fix changes the face so much, see below. The face looks like a1111 painted the checkpoint's default face over, so I'm not sure if the extension works correctly here. After hires.fix I see a separate string for hires.fix in the image info:
[A female model : [ <'EM_1'> <'EM_2'> | <'EM_3'> <'EM_4'> | <'EM_5'> <'EM_6'> ] : 0.25] Negative prompt: sad, monotone, low quality, low resolution, [mutated | extra | missed | broken] fingers Steps: 30, Sampler: DPM++ 3M SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 512x768, Model hash: ce49fd5253, Model: YACAM-SR-16111.fp16, Denoising strength: 0.4, RNG: CPU, Hires prompt: "[A female model : [<'Cameron'><' '><'Diaz'>|<'Drew'><' '><'Barrymore'>|<'Lucy'><' '><'Liu'>] : 0.25]", Hires upscale: 2, Hires steps: 15, Hires upscaler: 4x_NMKD-Siax_200k, CDT: "1,1,0,0,0,0,0,0,0,0,1,-1,1,0", Eta: 0.5, Version: v1.7.0

Conversation my prompt to a simple one changes the image(obviously) but doesn't have any influence on the extension
[A female model | <'Cameron'><' '><'Diaz'>|<'Drew'><' '><'Barrymore'>|<'Lucy'><' '><'Liu'>]

Why are you using <'Cameron'><' '><'Diaz'> and not just <'Cameron Diaz'>? (I'm just curious, that shouldn't cause the bug)
Why are you using "Alternating Words" syntax [ | ] in negative prompt too? (Again, I'm curious: the less steps you have, the less profit you will get of this, because the result would be biased/skewed rather than averaged equally)
You are using "Prompt editing" [ X : Y : num] with Alternating Words inside. Are you sure WebUI is not bugging on its own when abused like that? Can you confirm that the result uses all the words properly as expected when invoked without embeddings?

Can you reproduce the bug with highres but without alternating syntax or prompt editing (e.g. without using square brackets)?
We need to understand, is there a bug, where is it if yes, and whose exactly.
Maybe processing of highres prompt became different…
Oh, by the way: you can use EmbeddingMerge to pre-create embeddings as normal ones. Will your bug still manifest in the same prompt but without using <''> runtime syntax in favor of simple words to reference embeddings?

The idea of using the extension is screening my mixes from civiai automoderator. It's sooo aggressive.
I've been in an experiment right now. I decided to minimize repeating the same words in my negatives. As for now I can't say it became worse, so I'm going to leave it as it is now.
I'm not sure if I got the question correctly but I'm sure that this technique is great and works correctly. I'm writing this because I use it almost always. I see such the behavior the first time and only with the extension. All my other images works correctly as before.

A simplified prompt:
A female model <'Cameron'><' '><'Diaz'> <'Drew'><' '><'Barrymore'> <'Lucy'><' '><'Liu'>
Get an error here in the webui log but webui continue working:
*** Error running process: E:\SD\automatic1111\extensions\stable-diffusion-webui-embedding-merge\scripts\embedding_merge.py     Traceback (most recent call last):       File "E:\SD\automatic1111\modules\scripts.py", line 718, in process         script.process(p, *script_args)       File "E:\SD\automatic1111\extensions\stable-diffusion-webui-embedding-merge\scripts\embedding_merge.py", line 1336, in process         getattr(_webui_embedding_merge_,'embedding_merge_extension')(p)       File "E:\SD\automatic1111\extensions\stable-diffusion-webui-embedding-merge\scripts\embedding_merge.py", line 1255, in embedding_merge_extension         if embed[0]=='<':     IndexError: string index out of range
Image info:
A female model <'EM_1'> <'EM_2'> <'EM_3'> <'EM_4'> <'EM_5'> <'EM_6'> Negative prompt: sad, monotone, low quality, low resolution, [mutated | extra | missed | broken] fingers Steps: 30, Sampler: DPM++ 3M SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 512x768, Model hash: ce49fd5253, Model: YACAM-SR-16111.fp16, RNG: CPU, CDT: "1,1,0,0,0,0,0,0,0,0,1,-1,1,0", Eta: 0.5, Version: v1.7.0
The generated image looks OK:

Hires.fix:
The same error in the log.
Image info:
A female model <'EM_1'> <'EM_2'> <'EM_3'> <'EM_4'> <'EM_5'> <'EM_6'> Negative prompt: sad, monotone, low quality, low resolution, [mutated | extra | missed | broken] fingers Steps: 30, Sampler: DPM++ 3M SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 512x768, Model hash: ce49fd5253, Model: YACAM-SR-16111.fp16, Denoising strength: 0.4, RNG: CPU, Hires prompt: A female model <'Cameron'><' '><'Diaz'> <'Drew'><' '><'Barrymore'> <'Lucy'><' '><'Liu'>, Hires upscale: 2, Hires steps: 15, Hires upscaler: 4x_NMKD-Siax_200k, CDT: "1,1,0,0,0,0,0,0,0,0,1,-1,1,0", Eta: 0.5, Version: v1.7.0
And the upscaled image looks more generalized:

For me,
Cameron Diaz
Cameron  Diaz
<'Cameron'><'Diaz'>
<'Cameron'> <'Diaz'>
<'Cameron'><''><'Diaz'>
<'Cameron'><' '><'Diaz'>
<'Cameron'> <' '> <'Diaz'>

– Are tokenizing the same way, giving the same raw numbers in vectors.

Removing <' '> removes the error in the log and return recipe to image info:
A female model <'EM_1'> <'EM_2'> <'EM_3'> <'EM_4'> <'EM_5'> <'EM_6'> Negative prompt: sad, monotone, low quality, low resolution, [mutated | extra | missed | broken] fingers Steps: 30, Sampler: DPM++ 3M SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 512x768, Model hash: ce49fd5253, Model: YACAM-SR-16111.fp16, RNG: CPU, EmbeddingMerge: "<'EM_1'>=<'Cameron'>, <'EM_2'>=<'Diaz'>, <'EM_3'>=<'Drew'>, <'EM_4'>=<'Barrymore'>, <'EM_5'>=<'Lucy'>, <'EM_6'>=<'Liu'>", CDT: "1,1,0,0,0,0,0,0,0,0,1,-1,1,0", Eta: 0.5, Version: v1.7.0
For Hires.fix still the same — a generalized face and a separate string for Hires prompt:
A female model <'EM_1'> <'EM_2'> <'EM_3'> <'EM_4'> <'EM_5'> <'EM_6'> Negative prompt: sad, monotone, low quality, low resolution, [mutated | extra | missed | broken] fingers Steps: 30, Sampler: DPM++ 3M SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 512x768, Model hash: ce49fd5253, Model: YACAM-SR-16111.fp16, Denoising strength: 0.4, RNG: CPU, EmbeddingMerge: "<'EM_1'>=<'Cameron'>, <'EM_2'>=<'Diaz'>, <'EM_3'>=<'Drew'>, <'EM_4'>=<'Barrymore'>, <'EM_5'>=<'Lucy'>, <'EM_6'>=<'Liu'>", Hires prompt: A female model <'Cameron'> <'Diaz'> <'Drew'> <'Barrymore'> <'Lucy'> <'Liu'>, Hires upscale: 2, Hires steps: 15, Hires upscaler: 4x_NMKD-Siax_200k, CDT: "1,1,0,0,0,0,0,0,0,0,1,-1,1,0", Eta: 0.5, Version: v1.7.0

Now try pre-creating embeddings and use those instead of runtime syntax.
To do this, enter each of your words separately into EM tab, and fill the box titled "Type here a name for your new embedding …", for example em_diaz when you parse the string Diaz
Then use that instead of <'Diaz'>
At that point you can even disable EmbeddingMerge extension, since the created physical files would be accessible to WebUI as normal embeddings.

It works for the first render, hires and both image infos.
Those are static EM files but I need to work with online generation in prompts.

If that is so, then the problem is in my extension indeed.
I will take a look and reply when I'll got something or if I would need a cleaner test case.

@miasik, I fixed both of errors (<''> and hr_prompt), but did not push the production yet.
I've faced another strange issue: https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/13830#issuecomment-1853709799
Can you test something for me on the current version?

Disable all other third-party extensions.
Use simple prompt like <'dog'>
Fixed seed, no hires.fix, no negative prompt.
Generate; then change the prompt to <'cat'> and generate again.

Is the image is changing for you?
If not, that's a big problem! Then, follow the method I linked: comment-out
for cache in caches:
    if cache[0] is not None and cached_params == cache[0]:
        return cache[1]

in modules/processing.py
Then repeat the experiment.

OMG!
It had to be my second report here :-D
I faced into the issue almost immediately after I installed the extension. Here's my yesterday grid with confirmation:

I'm doing the correction and its test right now.

Not the best crocodile I've ever seen but commenting made the magic!

Good!
I wonder why it wasn't seen much earlier than now…
I'll try to fix this and push the new version.
(I also had an ongoing SDXL support edition, but there are too much of new code added, so I will postpone that for now)

Well. I'm pretty much used to this sort of thing. I start using the extension and find bugs that were not detected before.
Looking forward to seeing the corrected bug.

I'm pushing right now, please try the new version!

Looks like the bug was eliminated!
Thank you!

I was happy too early.
Enabling Adetailer breaks the extension again. Even the first step works, but doesn't decrypt the image info:
EmbeddingMerge: "<'EM_1'>=<'EM_1'>, <'EM_2'>=<'EM_2'>, <'EM_3'>=<'EM_3'>, <'EM_4'>=<'EM_4'>",

Is it possible to change the order of which extensions are called by WebUI?
I heard something about this (for example, it was one of the early purposes of https://github.com/vladmandic/automatic)
Is the any extension to set order of others? Maybe there is an Issue in the AUTOMATIC1111 repo?

Adetailer was probably mentioned in https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/13830#issuecomment-1792892322 too…

Adetailer was probably mentioned in AUTOMATIC1111/stable-diffusion-webui#13830 (comment) too…

Yes, but it was mentioned as a healer, but it breaks working now.

Have you tried renaming the folder in extensions?
What if that was just because the alphabetical order of invocations?

Have you tried renaming the folder in extensions? What if that was just because the alphabetical order of invocations?

I wouldn't play with a1111 if it's working. At least it looks like that ;-)

Also I think when installing an extension by URL, there is a textbox to set the folder name instead of using the default one.

I fixed the bug with ADetailer!
The order or naming did no matter because that extension is forcefully calling script sequences manually:
https://github.com/Bing-su/adetailer/blob/ebd69df305c20fd880a0b39333eb115369b7de76/scripts/!adetailer.py#L771
Now my decision is cease to work if EmbeddingMerge is somehow already present in the current generation info at the beginning.
Looks good.

I don't mind having as much Issues as needed.
I will close only fixed bugs; free talk could stay.

I'd like to ask some questions related to the extension but they're offtopic for the issue.
Using "Discussion" section is much better as for me

Just create an Issue titled "some questions related to the extension", etc.
As I said, I'm perfectly fine!

By the way, the dedicated Discussion page is linked at top of the main readme file of my extension.
Discussion: https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/7659

By the way, the dedicated Discussion page
That isn't the dedicated page ;-)
The dedicated Discussion page for the extension can be turned on in settings for the repository.

@miasik, I fixed both of errors (<''> and hr_prompt), but did not push the production yet.
I've faced another strange issue: AUTOMATIC1111/stable-diffusion-webui#13830 (comment)

I'm not sure if it's fixed in the a1111 v1.8
Could you check it on your side, please?


Force mobile layout for site when user agent is not enough?

Homework

[X] I took the time to write a good, descriptive issue title
[X] I read nativefier --help and API.md.
[X] I checked CATALOG.md for community suggestions & workarounds.
[X] I searched existing issues, open & closed. Yes, my question is new.
[X] I'm running the latest version.

Your question
I'm trying to view a Discourse forum https://meta.discourse.org on Mobile View.
Setting the user agent is not enough.
I can trigger it temporarily by:

open web inspector
open device toolbar
set to iPhone
refresh window
close web inspector

Is there any way I can apply this sort of setting using Nativefier config/options?
Steps to reproduce
nativefier -u safari https://meta.discourse.org

Debug info
No response
Nativefier version
52.0.0
Node.js version
20.5.1
npm version
9.8.0
OS
macOS 12.6.8

Try with this user agent (latest safari iOS one)
Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1

Did this user agent work for you with the above URL?

from what I understand, -u safari generates a computer useragent (MacOS), not a phone useragent (but I'm just a random person here)
I tested:
nativefier -u "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" https://meta.discourse.org
and it works as you wish!

Thanks! It turns out that --honest (which I think I was using to ensure login with Google worked) will cause the user agent to be ignored. So I used your one, and removed honest from this particular browser and I am logging in using username and password.
Cheers!


docs: deleted unnecessary round bracket

Closes #
📝 Description

Add a brief description

⛳ Current behavior (updates)

Please describe the current behavior that you are modifying

🚀 New behavior

Please describe the behavior or changes this PR adds

💣 Is this a breaking change (Yes/No):

📝 Additional Information

Hey @GKosheev, thanks for your contribution 💖 This looks fine, I will be merging 🚀


chore: bump zio-prelude from 1.0.0-RC35 to 1.0.0-RC36

About this PR
📦 Updates dev.zio:zio-prelude from 1.0.0-RC35 to 1.0.0-RC36
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio", artifactId = "zio-prelude" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio", artifactId = "zio-prelude" }
}]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, commit-count:1

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.90%. Comparing base (715db6b) to head (90f39bb).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #322   +/-   ##
=======================================
  Coverage   67.90%   67.90%
=======================================
  Files          79       79
  Lines        1087     1087
  Branches      126      126
=======================================
  Hits          738      738
  Misses        349      349


Error following “Configure a Pod to Use a PersistentVolume for Storage”: storageclass.storage.k8s.io "manual" not found

Environment:
Kube cluster is running on local Lan.
Symptom
So I followed with the official tutorial about creating a PVC, but after I created PV and PVC,  I got this error saying "manual" not found.
On that page it defines a StorageClass in PV's config file (listed below), I think this might be very confusing because there is no information about where this manual StorageClass comes from, is it a StorageClass already defined somewhere?, or we just declare a new one here.
apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

The error clearly says "manual" StorageClass is not found, when I query kubectl get storageclass, it says No resources found.
Can you make "manual" here more sense?
Another observation
After I delete PV and PVC, and recreate them, the error disappears, wow, I am even more confused.

/sig storage
/remove-kind support
/kind bug
/language en
Thanks for reporting this @winkee01
I think that page is out of date and does need fixing.

/retitle Error following “Configure a Pod to Use a PersistentVolume for Storage”: storageclass.storage.k8s.io "manual" not found

Hi @winkee01 ,

Another observation
After I delete PV and PVC, and recreate them, the error disappears, wow, I am even more confused.

In my env i got the same error after recreating the pv and pvc . PV and PVC get created while i use a different name only even i don't have that SC in my env. I am looking into it. why it's this so.
Thanks

@sftim  for more clarification on this is this a good idea to add a note for  SC  ?

@Kartik494 perhaps you could explain your question more?
The page at https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ is out of date, and we need to fix it. Someone can check that it is fixed by performing the task and observing that you can complete it without any issue.

@sftim For new users it might seems confusing from where they are getting storage class named manual, i think we should add a note for clarification , but not sure on this

Hi @winkee01 ,

Another observation
After I delete PV and PVC, and recreate them, the error disappears, wow, I am even more confused.

In my env i got the same error after recreating the pv and pvc . PV and PVC get created while i use a different name only even i don't have that SC in my env. I am looking into it. why it's this so. Thanks

SO did I -- deleting, uninstall, reinstall, redeployment still show the same error.

Hi @winkee01 ,

Another observation
After I delete PV and PVC, and recreate them, the error disappears, wow, I am even more confused.

In my env i got the same error after recreating the pv and pvc . PV and PVC get created while i use a different name only even i don't have that SC in my env. I am looking into it. why it's this so. Thanks

I tried to delete PV & PVC, but unfortunately, I can create PV & PVC without error, thus not being able to recreate your errors. I don't know why. So, to my understanding at this point, if you specify a non-exist SC in PV, it virtually defines it, and you can specify it in PVC so that they can be bound. But I have no idea why the error says "manual not found". Very misleading and confusing error information.

When a page has a prerequisite, we should document it. For this task, I recommend that we cover how to set up any StorageClass that the task requires. The exception would be if we can direct readers to a different task and recommend that they follow the other task page first.
/triage accepted

@sftim Adding a page reference for how to create a storage class first is good direction to proceed?

When a page has a prerequisite, we should document it. For this task, I recommend that we cover how to set up any StorageClass that the task requires. The exception would be if we can direct readers to a different task and recommend that they follow the other task page first.

I think there is already mentioning of creating a storage class in doc before creating PV.

I'm also affected by this issue when trying to setup a hostpath based pv for local development. Actually understanding the problem is hard enough because this is the first hit on google and to my mind, no one has actually answered the original question.
My understand so far is that there isn't actually a StorageClass named "manual", rather the hostpath based PV is provisioned statically and "manual" is used purely for naming purposes. Is this correct?
One reason I've identified for this error is that if any other accessMode apart from ReadWriteOnce is used (which I know isn't valid but I recently did by mistake), any PVC using this will be stuck in the pending state with this as a somewhat misleading error. Sadly, this also seems to happen at random when tearing down and setting up the PV/PVCs ...

/remove-lifecycle stale

I was also following the linked tutorial, and hit the same error.  After reading this thread, I am still not clear on how to proceed.

i have the same error
storageclass.storage.k8s.io "manual" not found
what is the solution ?

For this task, I recommend that we cover how to set up any StorageClass that the task requires. The exception would be if we can direct readers to a different task and recommend that they follow the other task page first.
The Kubernetes project can help people here by adding more explanation to the existing web page. This is similar to the point in
https://github.com/kubernetes/website/issues/30912#issuecomment-1031395765

The problem isn't necessarily one of setting up the StorageClass though, it's that if the PVC cannot bind to the hostpath PV for ANY reason the error is a very generic and misleading one of storageclass.storage.k8s.io "manual" not found.
In the case of @winkee01 if sounds like repetition of the tutorial failed probably because the PV was already bound. Possibly the best solution is to add a warning that before attempting the steps again the Clean up instructions should be followed.

/remove-lifecycle stale

I also came here after following the example at kubernetes.io linked above. I did not encounter errors, but was surprised that when I listed my storageclasses using k9s no "manual" was found. It's pretty hilarious that there is still no explanation on this issue.
Based on  https://www.kubermatic.com/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/ and https://www.kubermatic.com/blog/keeping-the-state-of-apps-5-introduction-to-storage-classes/, are these only required for dynamic provisioning and can I use whatever I want for manual PVs (such as hostPath) as long as the two match?

by default, if you don't define StorageClass (SC) in your PersistentVolumeClaims (PVC) the PVC will use the default SC called standard https://kubernetes.io/docs/concepts/storage/storage-classes/#default-storageclass.
This default SC is then used to dynamically provision storage for PVC that does not require any specific storage class https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/#why-change-the-default-storage-class
To my understanding, if you define storageClassName: manual  in spec of yaml file for persistent volume, it also needs to be defined for PVC.  This SC manual won't get created and is used to bind persistent volume claim requests to this persistent volume.

/sig storage /remove-kind support /kind bug /language en
Thanks for reporting this @winkee01
I think that page is out of date and does need fixing.

Hey Tim can we please connect on linkedin or via mail  i am facing the same issue in  performing task https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

use storageClassName: "" will fix


Exponential backoff for multiple restarts

Idea is to not get into a horrible infinite restart loop when you have a syntax error or similar. First restart happens immediately. Second restart within a certain time window happens with a short delay.


Incompatible with Snowy Pigs

https://pastebin.com/1HGA1KXa
https://www.curseforge.com/minecraft/mc-mods/snow-pig-fabric

@DeflatedPickle hello?

I also have the same issue. I disabled hungry pigs for now until it is fixed.

Not stale, but the dev hasn’t gotten around to it


Support CRLF output for codegen of nodes.

This commit allows the user to specify an option on the command line (--crlf) that will turn on CRLF line endings for the output of the compile step.  I had a lot of trouble getting things going on windows, so I wasn't really able to run tests to cover this change.  If you want it as is, I'm offering it, as I'm pretty sure you could modify the tests pretty easily (if even needed) to test this feature.  If you'd rather tell me a bit more about how you'd like this commit to look, I'll be happy to go back and get my linux VM set up to compile coffeescript and make the appropriate changes to the tests.
We needed this change for our usage of coffeescript since we use CRLF throughout our project's JS files and it was giving us fits in git using the CS compiler to compile files that we checkin (stupid core.autocrlf crap in git that I'm pretty sure everyone hates).
Anyway, you're welcome to take this as is, or recommend how I can improve it and I'll try to do so.

.... I'm very iffy on this one. In the age of the web, I thought that \r\n's were dying a slow but necessary death.
If you really need this, can't you just: code.replace("\n", "\r\n") as part of your build process?

I feel the same way as @jashkenas... \r\n is a legacy approach to linebreaks. Why not just make the switch to using \n in your JS files? Surely your text editor supports this.

I'm sorry, but \r\n is not a legacy approach to linebreaks, it's the standard way of doing a linebreak.  The fact that unix systems have an alternative approach is fine, but it's only the sheer popularity of unix systems that makes anyone think that LF is a line break.  The ASCII definitions of CR and LF are fairly clear.  RFC 2822 is pretty clear as well.  The HTTP standard mandates CRLF.
For the record, I don't think the pull request is a big deal.  It's just annoying on a windows box that doesn't have unix2dos installed by default.  However, you're probably underestimating the sheer pain that can be caused by mixing LF and CRLF, which is what normally ends up happening when a windows program accesses a unix text file.  I won't be the first person to attempt a commit only to discover it believes every line in the file has changed.

OK, "legacy" is overstating it. But supposing you have a git project that devs with both Windows and Unix-based systems are contributing to, surely the common approach is for the Windows devs to set their text editors to use \n only, rather than for the Unix-based devs to use CRLF?
On Nov 4, 2011, at 10:46 AM, Julian<EMAIL_ADDRESS>wrote:

I'm sorry, but \r\n is not a legacy approach to linebreaks, it's the standard way of doing a linebreak.  The fact that unix systems have an alternative approach is fine, but it's only the sheer popularity of unix systems that makes anyone think that LF is a line break.  The ASCII definitions of CR and LF are fairly clear.  RFC 2822 is pretty clear as well.  The HTTP standard mandates CRLF.
For the record, I don't think the pull request is a big deal.  It's just annoying on a windows box that doesn't have unix2dos installed by default.  However, you're probably underestimating the sheer pain that can be caused by mixing LF and CRLF, which is what normally ends up happening when a windows program accesses a unix text file.  I won't be the first person to attempt a commit only to discover it believes every line in the file has changed.

Reply to this email directly or view it on GitHub:
https://github.com/jashkenas/coffee-script/pull/1823#issuecomment-2631660

@JulianBirch, to be clear: HTTP only mandates CRLF for protocol data which is headers, not response body.

Sorry guys, I didn't intend to start a war.  The reasoning for this is that I assume you wouldn't mind people in the .NET community being interested in using coffeescript - we fall in that category.  For teams that are working on projects that are windows centric, CRLF is the standard line endings, and git is VERY annoying if you have tools that produce LF only (and don't have a way to tell it to do CRLF).    This is what @JulianBirch was referring to in his few sentences.
It's certainly true that we could "fix" this by renormalizing line endings in our build script, but I can't imagine that everyone who runs into this problem (which will basically be ANYONE who attempts to use coffeescript in a .NET environment) will want to change their build scripts to massage the line endings.
In any case, I'll leave it up to you guys, but I do think it's a useful feature, regardless of your opinions of CRLF vs. LF in the wild.

@JulianBirch: There's a git config option that tells git to ignore those kinds of differences when committing or diffing or whatever. Too lazy to look through git's massive list of config options, though...

autocrlf=input, perhaps?

To quote from that answer:

In both cases, your Git repository will have only LF, which is the Right Thing.

@TrevorBurnham Yes, standardizing on LF tends to work a lot better than the other way around.  Usually you try to set appropriate autocrlf settings.  Trying to set the text editors is an exercise in frustration, sadly.  Visual Studio is a particular problem in this respect (and, frankly, in others as well).
@patrys Yes, HTTP doesn't mandate content format, but I think you'd find it hard to name a single internet protocol that doesn't specify CRLF as the correct line ending.  SMTP is the same, for instance.  I've always regarded the LF convention as a very un-unixy aspect of unix.
I don't understand what the use case that the pull actually addresses, since I don't touch the generated files ever.  It could be related to the fact that Notepad doesn't understand LF files, and on a production machine that will be all you've got to examine code.
More generally, I understand and am comfortable with the fact that CoffeeScript is a unix-based tool.  As a developer who has to work with Windows all of the time, and wants to use modern technology, you'd be amazed how often simple things like this and other meta get in your way (filenames are another pain).  This, sadly, only gives more ammunition to the developers and managers who question you wanting to do anything other than the "Microsoft Way".

Ok... unfortunately, none of the git solutions work (actually we're sortof using one right now).
For our purposes, the best thing to do is to ensure that all line endings for all files in our codebase are appropriate on all checkins - if you don't do this, it leads to inconsistencies due to differences in editor settings, etc.  We do this via a .gitattributes file that allows us to manage the line endings.  The .gitattributes file requires CRLF in our case, as that makes it much easier in the long run, as all of our development is on windows and tooling works best with CRLF.  This means our autocrlf = none and .gitattributes says *.js are eol=CRLF.
Unfortunately, now that we're trying to start using coffeescript, we have some JS that is legacy and some that is generated from coffee files.  The JS generated from coffee files would be fine as eol=LF, but we have this other JS that we don't want to allow to be also eol=LF due to the tooling issues we'll encounter.  This means that the easiest thing for us is to ask coffee to generate CRLF on its output.
I guess I'll just maintain a version of coffee that does this - I did change it, at least, to be a very minimal patch instead of the one I originally submitted.  If you change your mind and wouldn't mind including it, I'd be very happy not to have to maintain it separately myself.  It's on kellypleahy/coffee-script@33b02033609c901072b1c8faec9b022a730671c1.
Sorry again for starting a war.

If you could put your new JS in one folder and the old JS in another, you could specify a wildcard to identify which setting to use for which file.  That or explicitly name the new-style files in the .gitattributes.
e.g.
oldjs/.js
newjs/.js

Hey Kelly -- no worries ... it's good to be aware of these potential stumbling blocks. Two quick ideas.
If you have some JS which is legacy ... why not simply convert all of its CRLF to LF all at once? You'd have a single whitespace-only commit, and never have to worry about the mismatch again.
If that's not feasible, and this is just giving you trouble in Git, that's exactly what Git commit hooks are for: http://progit.org/book/ch7-3.html ... a small script in pre-commit could sort this out in either direction.


Not working on Safari 4, 5

Hi, Thank you for plugin! It's great, the only issue that it's not working on Safari 4 and 5.1(windows). All elements get "opacity:0". Can you please offer a solution for that? Thanks in advance

Hey @Arpi123 Thanks! Unfortunately AOS does not and won't support Safari 4 and 5.1, these are very old browsers and according to http://caniuse.com/usage-table their usage sums up to to barely 0.03%. If you want to fix it on them you can use disable option:
AOS.init({
  disable: function() {
    // This weird line should return true for safari <= 5 and false for anything else
    // Based on http://browserhacks.com/
    return /a/.__proto__=='//';
  }
});


Not all the categories are displayed in the Extraction

Precondition:
More than 100 categories are created.
STR:

Start to create an Extraction
In the Category try to find a category (e.g. text) by scrolling
In the Category try to find a category (e.g. text) by typing the name of the category

AR:
Category is not displayed
ER:
Category can be found and can be selected while scrolling

duplicate of #432


Complex Divide by Zero Returns Zero

Most languages/libraries that include the concept of 'infinity' will return a value of infinity when dividing a non-zero value by zero.  For example in JS:
> 5 / 0
Infinity
> Infinity / 0
Infinity
> 0 / 0
NaN
>

But when I divide a Complex by zero it returns zero:
> new Complex(3, 4).divide(0).toString()
'0'

Seems like this is a bug.

Sorry, my require() statement grabbed the wrong complex library.  I am closing this issue as 'pilot error'.


No way to include subtrees that are not managed by BDC

This is solved by webcomponents, but need to provide documentation and guidance.

Added Web Components example


duration of fillet is long due to is_valid

When performing a fillet on a complex object in the later stages, it takes a very long time due to the is_valid check.
In the first image you can see that the program spends 51% of the time in is_valid. (1.12 of a 2.21 execution). The second image shows that is_valid is executed in the fillet function. I do not know if it is possible to optimize this (different check?, toggable?). maybe it is an issue in the OCP python bindings. I had a quick look at the FreeCad code, they do exactly the same (but in C++). If I export my model and do the fillet in FreeCad, it is way quicker (under 10 sec instead of minutes).
I am aware this issue lacks a lot of information, it is just an observation. If you think it is worth looking into, I can provide more info but I will also accept a "won't fix" label.

profiler tool:
https://www.speedscope.app/
profiler file:
profile.speedscope.tar.gz

is_valid is essentially an OCP method so there isn't much that I can do about that. Are you using an Apple Silicon Mac? There have been some other slow-downs on Macs that I don't understand.

No, I am not using an apple silicone.
I'll close this issue as it is not related to this project.


[release/1.2 backport] Update runc to 6635b4f (CVE-2019-5736)

backport of https://github.com/containerd/containerd/pull/2997 for the 1.2 branch
Includes https://github.com/opencontainers/runc/commit/6635b4f0c6af3810594d2770f662f34ddc15b40d,
which fixes a vulnerability in runc that allows a container escape (CVE-2019-5736)
golang.org/x/sys was at a different version on this branch, so I re-ran vndr for that dependency to resolve that
⚠ verify if including the x/sys change is ok, otherwise I can just include the runc bump here

Codecov Report

Merging #2998 into release/1.2 will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/1.2    #2998   +/-   ##
============================================
  Coverage        43.66%   43.66%
============================================
  Files              101      101
  Lines            10754    10754
============================================
  Hits              4696     4696
  Misses            5329     5329
  Partials           729      729

Flag
Coverage Δ

#linux
47.35% <ø> (ø)
:arrow_up:

#windows
40.75% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Widget Opacity

Is your feature request related to a problem? Please describe.
It seems that is currently not possible to easily set the opacity of a widget
Describe the solution you'd like
Would be nice if we can set the opacity with a set_opacity() method
Describe alternatives you've considered
Tried using colours to match background colours or use the alpha parameter in the premultiplied function but this is a bit tedious if you just want to change the opacity for a set of elements
Additional context

Of course. A widget opacity option would allow me to create fade transitions more easily using the egui_animations crate.
I use a workaround currently where I animate an overlay the size of my widget with the same color as the background color but this does not scale well.


feat: Support WeChat Official Accounts login on PC

guide

Set the second client key in WeChat configuration and enable QR code scanning
Set <domain>/api/webhook in the WeChat official account interface configuration, and receive the configuration successfully.
Scan the QR code to log in

Support test account
https://github.com/casbin/casdoor/issues/2656

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

@xhyqaq fix CI:

@xhyqaq fix linter

@xhyqaq can you provide a demo video to show this new feature?

sorry,I'm a newbie，I caused you trouble during the testing process.
Don't worry about the "WeChat official account failure..." that appears in the demo video. This is caused by not setting it correctly before.
demo：
https://github.com/casbin/casdoor/assets/73917396/a9a12220-8319-4174-b515-5a7a91fe2f3a

sorry,I'm a newbie，I caused you trouble during the testing process.
Don't worry about the "WeChat official account failure..." that appears in the demo video. This is caused by not setting it correctly before.
demo：
2073f2b791a60d2454e5f9c764942c26.mp4

@hsluoyz

Replaced by: https://github.com/casbin/casdoor/pull/2674


Relinquishment with response code:102 should not include grant id

Hi,
Relinquishment with response code:102 should not include grant id.
Tried test case no : WINNF.FT.C.RLQ3 Unsuccessful Relinquishment, responseCode=102

3
The SAS Test   Harness sends the Relinquishment Response Message to UUT with:   ·           cbsdId   as in the request   ·           No   grantId   ·           responseCode = 102
--
--

Step 3 for this test case stats that no grant id should be included with response code:102
But relinquishment response received was:
2017-12-06T12:13:59.697Z - INFO - engine sent successfully, the response to CBRS  : {
"relinquishmentResponse": [
{
"cbsdId": "S9GQ710US01Mock-SAS401629000040",
"grantId": "427115433",
"response": {
"responseCode": 102
}
}
]
}
log file is also attached here for reference.
WINNF.FT.C.RLQ3_2017-12-06T12.11.09Z.zip

issue fixed ...


Mesos edits

@errordeveloper made some edits for you and added in the bash code styling --much easier to use btw.

Amazing, thank you @abuehrle!

I really have a great dislike of git


#665 Show glyph with two dots over 'XL' when x-linked inheritance pat…

…tern for female proband.

quarantest build successful. Demo link at
http://f150c86c.quarantest.iobio.io


Add files via upload

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

rd/media/nicki-borell.jpg
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

rd/media/nicki-borell.jpg
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


M1 Native

Have you tested Grainflow v3 with M1 Native? I noticed the problem when I tried to run the Live Input tutorial, and the Record Buffer function doesn't work, among other various crashes. I switched back to Rosetta and it was fine.
There is not a notice in the Package Manager that it is not Apple Silicon compatible so i am wondering if you are aware of this and if so, if you plan on updating.

I unfortunately have no way of testing apple silicon on my own and will not in the foreseeable future. My guess is there is an issue with gen~ on the M1 since most of the heavy lifting is done with gen~ objects that should compile when audio loads. I will likely put a notice on the next update.  You should also send a bug report to C74 I am sure they would appreciate the crash report files so they can iron out any bugs on their end.

Thanks for the follow-up. That's most unfortunate! Grainflow is the only software I am using that requires Rosetta. Is there no one in the Max community who can help you test on their M1 machine?? If there is anything I can do I would be happy to help. I have invested a lot of time incorporating Grainflow into my workflow, it's really fantastic and I haven't found any other Max granular patches that I like as much.

I just opened up the Gen~ help patch in Native mode and went through it without any problems. So it's not clear that Gen~ is the problem.

It would not be an issue with gen~ generally, but there is likely something in my gen~ code that when transpiled in to C is not playing nice with the M1 chipset. My guess would be something with buffer access, data registers, or decision trees.  I will have to try to narrow down some possible issues that can be reliably reproduced and send a report to C74 to see what they can do or if there is a way for me to avoid whatever issue is causing the crashes.  I may post some files to test in the coming days that try to confirm what is going on.
There is also a potential that the parallel processing is causing an issue. If you use the "@parallel 0" on grainflow it will turn off the parallel processing that is done with poly~.
It also may be worth trying to load in these gen~ patches and their mc versions on their own and see if there are any errors.

gen~ grainFlow.record
gen~ grainflow.voice

Thanks Chris! Am happy to work on this with you. I have gone through MUBU in some detail and am not finding any problems while running native. With Grainflow, I noticed particularly with live input patches, in which the playhead gets stuck and the grainflow.util.record~ object doesn't output anything. Your patches are so deep that it's difficult to know where things are getting stuck, but I will follow your suggestions to see what I can come up with.

I did some work with a friend and we found there is a bug in gen~ that causes input defaults to be ignored which was causing an issue in grainflow.util.record.  I changed how it works to avoid this issue.  The crashes are likely being caused by the jsui waveform object which seems to be part of a greater problem with the schedular dealing with graphics on the M1 devices (number~ and waveform~ are pretty laggy without audio interrupt enabled). I am not 100% sure how to fix this issue short of writing that object as an external.

Hey Chris, just tested v 3.3 to see if it might be stable in native M1, but it now crashes when you try to save. Any plans to release an M1 version? Grainflow is such an awesome granular package.
Randall

The big is unfortunately a greater problem with JSUI in general and that is
out of my control unless I rewrite the grainflow.waveform object as an
external which is not on the table for me at the moment. C74 is aware and
are hopefully working on a fix. If you remove grainflow.wafeform objects
and think things should work fine.
Chris
On Sun, Apr 24, 2022, 1:00 PM Randall Packer @.***>
wrote:

Hey Chris, just tested v 3.3 to see if it might be stable in native M1,
but it now crashes when you try to save. Any plans to release an M1
version? Grainflow is such an awesome granular package.
Randall
—
Reply to this email directly, view it on GitHub
https://github.com/composingcap/grainflow/issues/15#issuecomment-1107888876,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE5U35I6FVPGW65GXVPEF5TVGWD37ANCNFSM5KL3IWRA
.
You are receiving this because you commented.Message ID:
@.***>

Would you suggest replacing your grainflow.waveform with the regular waveform~ object?

If you need a display, I would use a waveform and a multislider. The second
outlet has a message starting with grainPositions or something similar you
can send to the multislider
On Sun, Apr 24, 2022, 3:32 PM Randall Packer @.***>
wrote:

Would you suggest replacing your grainflow.waveform with the regular
waveform~ object?
—
Reply to this email directly, view it on GitHub
https://github.com/composingcap/grainflow/issues/15#issuecomment-1107913297,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE5U35PAVAJU6NUZYZO4OFDVGWVWFANCNFSM5KL3IWRA
.
You are receiving this because you commented.Message ID:
@.***>

Not sure I am following you. Do you by any chance have a help file with a standard waveform object instead of the jsui waveform? Or perhaps you could post a little example or include one in the package? Many thanks for your time on this.


Updating the workspace settings to remove deprecated python options

Removes the deprecated python settings in favor of the options recommended in https://github.com/microsoft/vscode-python/wiki/Migration-to-Python-Tools-Extensions

/merge


Enhance ext_proc filter to support M:N streaming

This PR is for issue: https://github.com/envoyproxy/envoy/issues/32090.  One of the use case is,  like compression by the external processing.
This is to let the side stream server be able to buffer M request chunks from Envoy first, processing them, then send N chunks back to Envoy in the STREAMED mode.
The ext_proc M:N streaming works this way:

Enable the M:N streaming by configuring the enable_more_chunks field in the ext_proc filter config to be true.

Envoy ext_proc filter sends M data chunks to the side stream server one by one, as usual.

The side stream server sends a clear_body https://github.com/envoyproxy/envoy/blob/56021dbfb10b53c6d08ed6fc811e1ff4c9ac41fd/api/envoy/service/ext_proc/v3/external_processor.proto#L386  response back to the Envoy for the 1st to (M-1)th chunk, as usual.

After receives the Mth chunk, the side stream server processes the buffered data, and splits the mutated data into N chunks and sends them back to Envoy one-by-one.

(Above steps 2 to 4 are well supported by existing Envoy ext_proc filter code and API. No code change needed for them.)

The Side stream server sends the 1st to (N-1)th response data with “more_chunks” set to true. And it sends the Nth response data with “more_chunks” set to false.

After receiving each of the 1st to (N-1)th response, i.e, the responses with “more_chunks” set to true, Envoy ext_proc filter will stop the existing request timer, and launch a new timer. It then injects this response data to the filter chain for further processing.

After receiving the Nth response with “more_chunks” set to false, Envoy ext_proc filter will stop the running request timer, pop the Mth request from the chunk queue, and inject this Nth response to the filter chain for further processing.

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/assign @gbrail @htuch @jmarantz @tyxia @yanavlasov

/assign @tyxia
As codeowner for first pass.

/assign @tyxia
As codeowner for first pass.

The design is under internal review and discussion.
My opinion here is that we should remove the ext_proc internal buffering here, which is essentially ask in https://github.com/envoyproxy/envoy/issues/32090.  But it is also good to hear other reviewers' opinions. (not a gating factor if other reviewers approve it)
Adding wait here to avoid daily ping on maintainer on-caller.
/wait

I agree; I think internal buffering or MxN complicates the model and how to reason about it.

IMHO,, I am not sure if no internal buffer, how to support the case if the side stream server ask Envoy to send the original data as it is for certain sequence of data during the streaming.  However, it is okay for me to put this on wait.

I am not sure if no internal buffer, how to support the case if the side stream server ask Envoy to send the original data

IMHO sidestream server can just send back the original data, as the original data has been forwarded sidestream server.
The injected data is totally under sidestream server's control : add, remove, compress, or keep (even just keep certain part) , etc.

I am not sure if no internal buffer, how to support the case if the side stream server ask Envoy to send the original data

IMHO sidestream server can just send back the original data, as the original data has been forwarded sidestream server.
The injected data is totally under sidestream server's control : add, remove, compress, or keep (even just keep certain part) , etc.

Send back the original data has network bandwidth and CPU processing implications.  I guess to avoid that's one of the reason we have this buffer in the first place.

I am not sure if no internal buffer, how to support the case if the side stream server ask Envoy to send the original data

IMHO sidestream server can just send back the original data, as the original data has been forwarded sidestream server.
The injected data is totally under sidestream server's control : add, remove, compress, or keep (even just keep certain part) , etc.

Asking the side stream server to send back the original data has network bandwidth and CPU processing implications. Is that a concern? IIUC, to avoid that is one of the reason Envoy ext_proc filter has this buffer in the first place.

To your initial point, are we in (or close to) agreement that there is no hard blocker from functionality perspective to remove internal buffer? Besides, from design perspective, internal buffer is probably hard to be reasoned about, as pointed out by Josh
Regarding performance,

First, no internal buffering solves the one major perf issue that large amount of data is buffered in Envoy. This issue will be amplified in this mode/use case when sidestream server want to buffer more data.
Second, transmission overhead depends on customer use case. If they compress the data, the overhead is already smaller than existing request path. If they want to amplify data, internal buffering also will not help here
Third, it is probably wrong use of this mode when there is very little/no mutation. They can use observability mode for such purpose. Though it is still supported and up to customer's choice. i.e., not the blocking issue of removing the internal buffer.

@tyxia , thanks for the detail comments!
For 3), I think there are use cases like security validation, which ext_proc server will examine the data content.  If the data contains bad content, it sends back an immediate response to tell Envoy to send back a local reply and close the downstream client connection. If the data is legit, it sends back an empty body response to tell Envoy to send the original data as it is.  So, with this internal buffer, it has network bandwidth and performance gain. IIUC  this case can not use observability mode even no data mutation.
For 1) and 2), the ext_proc filter chunk_queue only buffers the downstream data to a certain point(until watermark is raised).  Is there any functional problem with this today?

@yanjunxiang-google Thanks for reply!
I think your security validation case  is already supported by existing mode and doesn't effectively use this feature because it doesn't mutate the data at all.  You could have some tweak to existing mode to have one response to allow all (which helps when you scan large chunks of data)
I hope we can jump out of one particular use case and bring back to broad view and motivation of this feature: which I understand it as arbitrary mutation. This means sideStream server injected data is independent of mainstream data. And still buffering mainstream data in Envoy is redundant.
But again, my opinion is not gating/blocking factors here :)  It is probably good to convince other reviewers.

hello, @yanjunxiang-google any updates on this PR, thanks?

hello, @yanjunxiang-google any updates on this PR, thanks?
Thanks for checking. We are changing the design a little bit for this feature. Will be updating the PR soon.

PR needs main merge - CI is breaking due to too much change

/assign @yanavlasov @tyxia @htuch

/assign @jmarantz

Adding @adisuissa For API changes

KInd Ping!

Kind ping!

/retest

Kind Ping!

Will wait for other approvals and then submit.
/wait-any

/wait

Kind Ping!

@adisuissa I did an upstream merge. It needs your API approval again.  Thanks!

LGTM, as a WIP/good start.
I think those open comments need to be addressed (and some more tests/loadtest) to complete this feature.


Data Preparation crash using CARS Docker

Hello
I installed the CARS Docker and run it with the Cairo sample successfully. The result is nice so I tryed to test it with my hown Pleiades data.
Unfortunatly the pipeline crashed during preparation step, just after the matching was performed.
The log says "lowres_dsm" is None, but I do filled a SRTM file in the config file.
Any ideas would be welcome
Thank you
Guillaume
(base) gdespine@ubuntu-vpo-001:~/projects/3_CARS/GUD-Tests$ docker run -v /home/gdespine/projects/3_CARS/GUD-Tests/Singapour:/data cnes/cars prepare -i /data/Config.json -o /data/1_prepareOutdir
WARNING: You are using pip version 21.2.4; however, version 22.1.2 is available.
You should consider upgrading via the '/cars/venv/bin/python -m pip install --upgrade pip' command.
Computing epipolar grids ...: 100% [**************************************************] (2s)
Performing matching ...: 100%|██████████| 3500/3500 [24:31<00:00,  2.38it/s]
22-06-29 10:35:29 :: ERROR :: CARS terminated with following error
Traceback (most recent call last):
File "/cars/cars/cars.py", line 746, in main_cli
run_prepare(args, dry_run)
File "/cars/cars/cars.py", line 546, in run_prepare
prepare.run(
File "/cars/cars/pipelines/prepare.py", line 813, in run
lowres_dsm.to_netcdf(lowres_dsm_file)
AttributeError: 'NoneType' object has no attribute 'to_netcdf'
2022-06-29 10:19:56 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f4e806bd9a0)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f4e800447e0): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:24:28 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f4e80483b40)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f4e80789420): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:26:42 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f4e80410d10)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f4e81a8c870): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:31:32 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f4e809815e0)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f4e8076c1b0): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:32:00 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f4e809815e0)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f4e8059b570): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:33:54 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f4e807598c0)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f4e8054c790): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:11:47 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f668053b370)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f6680418a40): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:18:15 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f66807eca20)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f668040ff20): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)
2022-06-29 10:18:52 (WARNING) EpipolarSparseMatching: Warning: tile ignored because of the following error
itk::ExceptionObject (0x7f6680418be0)
Location: "unknown"
File: /usr/include/ITK-4.13/itkEuclideanDistanceMetric.hxx
Line: 64
Description: itk::ERROR: EuclideanDistanceMetric(0x7f6680584b40): The two measurement vectors have unequal size (128 and<PHONE_NUMBER>)

Hello @GuDesp, thanks for reporting the problem here. Please could you send us your Config.json file and your data ?
Thank you in advance for your answer

Hello @GuDesp, sorry for delay too.
I found the solution : it seems that the Orfeo Toolbox that we use for read images does not manage to read the model.
To avoid this, you can use Orfeo Toobox on DIM.XML to extract the band (I see you use the first channel to extract DEM) (available in cars docker image) :
otbcli_ExtractROI -in IMG_PHR1B_PMS_001/DIM_PHR1B_PMS_201410010333168_SEN_1898108101-001.XML -out CARS_INPUTS/img1.tif uint16 -cl Channel1 otbcli_ExtractROI -in IMG_PHR1B_PMS_002/DIM_PHR1B_PMS_201410010333419_SEN_1898108101-002.XML -out CARS_INPUTS/img2.tif uint16 -cl Channel1
Then, you can launch CARS on img1.tif and img2.tif (without forget .geom which contains geometrical model).
Regards,
David

PS : Here's the screenshot of the result :

Hello David
Thank you for your answer and for the recommandations. I'll try it very soon and let you know about the results
Best regards
Guillaume

Hello @GuDesp, have you tried with the recommendations ? Can we close the issue ?
Best regard,
David

I close this issue : @GuDesp : if you don't manage to obtain your DSM, you can re open it.
Best regard,
David

Hello David
Thank you for this info
The process worked fine now
Best regard
Guillaume
Envoyé à partir de Courrierhttps://go.microsoft.com/fwlink/?LinkId=550986 pour Windows
De : David @.>
Envoyé le :lundi 17 octobre 2022 14:14
À : @.>
Cc : DESPINE Guillaume @.>; @.>
Objet :⚠ Re: [CNES/cars] Data Preparation crash using CARS Docker (Issue #11)
I close this issue : @GuDesphttps://urldefense.com/v3/__https:/github.com/GuDesp__;!!La4veWw!yhlQmLnrL7TygAbeqolbmJx1bbNnKkjgJxA-PIGzC6eIqaXiWNmhGxrl4Nj_yUDSjyz9SEoSVUBy1oUu0Ke2qZCh$ : if you don't manage to obtain your DSM, you can re open it.
Best regard,
David
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/CNES/cars/issues/11*issuecomment-1280762974__;Iw!!La4veWw!yhlQmLnrL7TygAbeqolbmJx1bbNnKkjgJxA-PIGzC6eIqaXiWNmhGxrl4Nj_yUDSjyz9SEoSVUBy1oUu0Jhe-hWy$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AZBCTD4Y7ULKFPRLBNNZVNLWDU7J7ANCNFSM52GD3VRQ__;!!La4veWw!yhlQmLnrL7TygAbeqolbmJx1bbNnKkjgJxA-PIGzC6eIqaXiWNmhGxrl4Nj_yUDSjyz9SEoSVUBy1oUu0NNYIBQd$.
You are receiving this because you were mentioned.Message ID: @.***>
⚠ This symbol is automatically added to emails originating from outside of the organization. Be extra careful with hyperlinks and attachments.
ENGIE Mail Disclaimer: http://www.engie.com/disclaimer/


Fix: no spatial mapping is yielded when user-provided spatial mapping size exceeds the layer size.

Small fix on spatial mapping generation:

Correct the calculation for spatial_mapping_int in SpatialMappingConversionStage.
Upper-bound the spatial mapping size to the layer size in SpatialMappingGeneratorStage.generator, even though the mapping is user-provided.
Fix a typo in the cost_model*.py (self.spatial_mapping_int-> self.spatial_mapping_int.mapping_dict_origin)


Pre-commit don't runt ktlint if nothing changed

If no kotlin files has changed, then it shouldn't run ktlint. As in the case where you just edited a README for example
Description

This changes the pre-commit hook so that it only runs ktlint if any kotlin files have been changed.
Existing behavior will run ktlint on all files in the event that no kotlin files were present in the changed files. For example, if the commit only changes a README file.
Checklist

[x] PR description added

Yeah, the reason for using back-ticks instead of $(...) was to make it as backward-compatible as possible (since the file interpreter is #!/bin/sh).
Also, in order to be as defensive as possible, I guess it should probably be something like:
[ "x`...`" != "xDarwin" ] ...

just in case a system type ever has a leading hyphen. astonished (Not likely I know.)

I seriously doubt that any shells that old are in wide use.But if you feel strongly about it I can change it.
And guarding against leading hyphens just seem like Voodoo programming.

I seriously doubt that any shells that old are in wide use.But if you feel strongly about it I can change it.

Oh, no strong opinion here.  I was just keying off the defined shebang interpreter.  I didn't know how far back compatibility was supposed to go.  If you are fine with '$-notation' then so am I. 💯

And guarding against leading hyphens just seem like Voodoo programming.

I hear yah.  It's certainly justified for unstructured data but OS names really should not be an issue.
👍

@spacecowboy and @ntr-ross Tnx for your contributions! The change is merged.


Simplify Logging Structure

Entry Points:

Reduce number of abstractions
Replace reference to log queue from logger
No "Internal Log", log4net could be hidden within LoggerManagement without any additional abstractions
Remove logger configuration
Replace IModuleLogger with ILogger -> maybe own implementation with child support and hierachies
Remove logging thread

Done


data URL scheme not supported (Fix supplied)

Minify version: 2.1.1
PHP version: 5.2.6

What steps will reproduce the problem?
1. Create a CSS file with the following code

#prevLink{ height: 100%; background-image: url(data:image/gif;base64,AAAA);
display: block; }

2. Run this through minify
3. Output will have changed the URL to the full path (e.g. as follows)

#prevLink{ height: 100%; background-image:
url(/path/to/directory/data:image/gif;base64,AAAA); display: block; }

Expected output:

#prevLink{ height: 100%; background-image: url(data:image/gif;base64,AAAA);
display: block; }

Actual output:

#prevLink{ height: 100%; background-image:
url(/path/to/directory/data:image/gif;base64,AAAA); display: block; }

Did any unit tests FAIL?

Didn't test them.

Please provide any additional information below.

Following fixed the issue for me.
min/lib/Minify/CSS.php
~line 275 change

            if (strpos($url, '//') > 0) {
                // probably starts with protocol, do not alter
            } else {

to

            if (strpos($url, '//') > 0) {
                // probably starts with protocol, do not alter
            /**
             * Fixing bug in minify that breaks
url(data:image/gif;base64,AAAA);
             */
    		} else if( preg_match( "#^data:(.+?)/(.+?);base64,#i", $url ) ) {
    			// This is a data: scheme and not a path
            } else {

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 23 Jan 2009 at 7:31

Nice thx

Original comment by<EMAIL_ADDRESS>on 22 Feb 2009 at 9:03

Fixed in R279

Original comment by<EMAIL_ADDRESS>on 25 Jan 2009 at 4:23

Changed state: Fixed
Added labels: Release-2.1.1


V2.6 branch - add microsecond precision to zsock_select() consistent with Linux

The following discussion describes the issue with the zsock_select() implementation, which accepts a microsecond precision timeout value, but then rounds up to milliseconds and uses zsock_poll() under the covers.  This request it then to restore the fidelity of this timeout to the microsecond precision from the original Linux implementation of select().  Jukka Rissanen comments here on this topic and outlines a strategy for implementing these changes, with an internal zsock_poll() to add fidelity back to the zsock_select() implementation.  Refer to the following URL for this conversation:
https://github.com/zephyrproject-rtos/zephyr/discussions/36072

This was more of a wish request manifesting as a PR as suggested by Jukka.

Please change (and test) the code and then send the result to review (as a PR), we can then discuss how it works / what needs to be changed.
I am closing this as there is no change here.


Change Rate Us page

Describe the feature
Hello Project Admin
I would like to Enhace Rate Us page in this way according to our website
can you assign me this issue under GSSOC'24
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Ya, its better start working on this..

Yeah okk @hustlerZzZ


New proc_macro attribute front end

Currently only run at nightly.
Depend https://github.com/rust-lang/rust/issues/15701 and https://github.com/rust-lang/rust/issues/54727
#[html] "{{> some_template }}"

Remove in favor of include


DBFlow 3.0.0-beta5 not found on maven

DBFlow Version: 3.0.0-beta5
The application we have uses DBFlow 3.0.0-beta5 but is not found anymore on the maven
repository, so we cannot longer compile the source code. I found an issue that mentions
that other users have the same problem.
We cannot just upgrade from 3.0.0-beta5 to 3.0.0-beta6 because with newer library, source code
simply does not compile without modifying the code, since 3.0.0-beta6 changed almost all the transaction implementation, and our code cannot be modified any longer.
Is there any possibility that you can fix the 3.0.0-beta5 so it can be compiled in
jitpack.io?  this specific version is the only one missing, it seems it is a problem in the javadoc
not in the functional code.
there is a reference to the same issue here for more info about the same error:
https://github.com/Raizlabs/DBFlow/issues/1132
I will really appreciate if can take a look to this issue.
Thanks in advance!
Alex

it never built successfully. you can reference a specific 10-digit commit hash to grab the version you need or youll have to update.


Regression: wait (--wait) with custom editors seems to be broken

Not sure when this started, but in recent Insiders versions, custom editors opened with --wait seem to no longer stop waiting when they are closed.
You can reproduce this using GitLens and its rebase editor.

Install GitLens and make sure you haven't disabled the rebase editor
Set VS Code as your default Git editor: git config --global core.editor "code-insiders --wait --reuse-window"
Start an interactive rebase: git rebase -i HEAD~5 or something along those lines
Once the GitLens interactive rebase editor opens, either start or abort the rebase
:bug: Git will still continue to wait even though the editor has been closed

@bpasero I'm not sure how to investigate this to be honest. I see the issue that @eamodio is experiencing, but I can't find a simple repro with other custom editors so I'm not sure what's special about the git case.

I did push a change this milestone to a method that is used for --wait: some code that observes all opened editors for a resource to close (the one --wait is waiting on). I thought that code should only track file editors and not custom editors but I did not realise that we also want to support custom editors.
I still think the code is fishy because we should not track the resource for closing but the editor that is being used to edit the file being waited on and that could be either a file editor or a custom editor.
Anyway, I pretty much reverted the code to how it was before.


App briefly displays default theme colors when changing the theme

[x] I have verified there are no duplicate active or recent bugs, questions, or requests
[x] I have verified that I am using the latest version of Aesthetic (see the README).
[x] I have given my issue a non-generic title.
[x] I have read over the documentation (before asking questions on how to do something).

Affected device(s): Xiaomi Mi A2, Android 8.1.0

When running the following code, the colors flicker for a bit, briefly showing the default colors of the theme. A bit of a deal breaker for me. (I'm using a dummy theme here, as activityTheme call doesn't seem to detect that DayNight theme has been changed.)
Aesthetic.Companion.get()
    .isDark(nightThemeEnabled)
    .activityTheme(nightThemeEnabled ? R.style.MainTheme: R.style.MainTheme_Dummy)
    .colorPrimary(0xff123456)
    .colorPrimaryDark(0xff654321)
    .colorNavigationBar(0xff654321)
    .colorStatusBar(0xff654321)
    .apply();

The activity is recreated only once. If I manually set the colors on the views, there is no flickering. The same behavior is observed if I call recreate() or getDelegate().applyDayNight() without calling activityTheme(). This seems to affect the sample project as well, open it and tap on the “Dark theme” switch.
It seems that the time gap in which the theme colors can be seen is affected by the run time of Activity's onCreate. When and how the colors are actually applied?
Reproduction Steps
Call activityTheme() as well as colorPrimary() and other methods
Expected Result
Colors are applied at once
Actual Result
Default colors can be briefly seen

There probably is not a whole lot that can be done for this. The library waits for views to attach to their window before they go out and subscribe to color changes.

i'm not really sure how this works. as far as i can see from the code, which is not much, the library is interception view inflation; why can't colors be set at this point or in onResume?

Because the lifecycle has to be respected - the views have no concept of onResume, just onAttachedToWindow() and onDetachedFromWindow(). They subscribe to color changes when attached, and unsubscribe from color changes when detached. If it was done at inflation time, it would be a one time thing and they would not get further updates.

Setting view color in the view's init block can fix this issue.