CouchbaseBucket::query return now a CouchbaseResult which implements Iterator

Hello,
This feature change the behavior of query to return an Iterator, that a more nice way to return the result and allow code like that :
foreach ($db->query(CouchbaseN1qlQuery::fromString('SELECT * FROM `beer-sample`')) as $document) {
        var_dump($document);
}

This would change backward compatibility.
You can make your own service wrapper around this library to have the result as an iterator right

Yes but that should be the default behavior.

I can change to this and add Countable interface yes

I added Countable interface

@oxman, I guess it's confusing if you add a countable interface and let that one return the full amount of items in that list. I do neither know if the full amount of this query or the amount of items returned is expected by the user. What do you guess?
I expect a collection to return the amount of items it has if I count it. Would yours? I guess when adding a limit, yours wouldn't return the amount of items returned.

Even if i wouldn't return the full amount of data, the C driver does it.
When the C driver would make iteration on the fly like a Mysql driver, CouchbaseResult will use it and no change will be needed.
And when you add a limit, you want the total number of items for your query (so with the limit).

@oxman yea, but that's not the case if we would take that code you wrote.
Please count the rows for the implementation of the Countable interface and return the full amount of rows in an extra parameter or method call.

Is it ok for you with this sample ?
https://gist.github.com/oxman/c0023e0bda77b812bdec

@oxman Looks good - but I have to admit, that I never tried out the n1ql feature. I was thinking about usual view-queries. Maybe the client returns other additional parameters, that are now inaccessible, when using n1ql ...

Well in view queries you can limit the result set with many options, like startkey, endkey, then the behavior is like N1QL with LIMIT.

@JordyMoos about backward compatibility, semver is designed for that.

We do not currently have plans in our roadmap to support streaming of results from Couchbase's querying API's.  Additionally, because of the nature of streaming, implementing Countable would not be possible if we did.


can't run due to chroma  issue

File "D:\Anaconda3\lib\site-packages\langchain\vectorstores\chroma.py", line 184, in add_texts
self._collection.upsert(
AttributeError: 'Collection' object has no attribute 'upsert'
PersistentDuckDB del, about to run persist
Persisting DB to disk, putting it in the save folder ./chroma.db

which version of chroma?

I think in the discord channel. Upgrade your chroma will fix the issue.

This is an old issue that can be fixed by upgrading langchain. Closing


mpv is not set to float when spawned from qutebrowser

For some reason mpv is being tiled when spawned from qutebrowser. How can I prevent this? It seems to float when I launch mpv.app directly (raycast/spotlight) but not from qutebrowser.
~/.yabairc (6.0.12):
yabai -m rule --add app="^mpv$" manage=off

$ yabai -m query --windows
{
        "id":8281,
        "pid":54841,
        "app":"mpv",
        "title":"The Dygma Defy: A Software Developer's Dream? - mpv",
        "frame":{
                "x":773.0000,
                "y":47.0000,
                "w":750.0000,
                "h":422.0000
        },
        "role":"AXWindow",
        "subrole":"AXStandardWindow",
        "root-window":true,
        "display":1,
        "space":2,
        "level":0,
        "sub-level":-20,
        "layer":"normal",
        "sub-layer":"below",
        "opacity":1.0000,
        "split-type":"vertical",
        "split-child":"second_child",
        "stack-index":0,
        "can-move":true,
        "can-resize":true,
        "has-focus":false,
        "has-shadow":false,
        "has-parent-zoom":false,
        "has-fullscreen-zoom":false,
        "is-native-fullscreen":false,
        "is-visible":false,
        "is-minimized":false,
        "is-hidden":false,
        "is-floating":false,
        "is-sticky":false,
        "is-grabbed":false
}

I found this in your dotfiles @koekeishiya, does it work for you or are you using something else nowadays?
~/.qutebrowser/config.py
config.bind(';M', 'hint --rapid links spawn open -na /Applications/mpv.app {hint-url}')
config.bind('M', 'hint links spawn open -na /Applications/mpv.app {hint-url}')
config.bind('m', 'spawn open -na /Applications/mpv.app {url}')

~/.config/mpv/mpv.conf
no-border
cache=auto

I'm not sure, I haven't used those configs in like 7 years. I would probably just copy a url in qutebrowser and use shift + cmd - m : /Applications/mpv.app/Contents/MacOS/mpv $(pbpaste) &> /dev/null

I'm not sure, I haven't used those configs in like 7 years. I would probably just copy (yank?) a url in qutebrowser and use shift + cmd - m : /Applications/mpv.app/Contents/MacOS/mpv $(pbpaste) &> /dev/null in skhd.

That's a col idea. However it does the same thing for some reason. Briefly it is unmanaged, but after 1 sec it is tiled.

 I think it's something on my system and not Yabai. Thanks for the help!


1.7.10 Server crashes when placing Conduit next to extra utils furnace generator

Issue Description:
Note: If this bug occurs in a modpack, please report this to the modpack author. Otherwise, delete this line and add your description here. If you are using an unreleased version of Ender IO (e.g. for 1.8.9), please don't open an issue for features that have not been announced as "finished" or "working".
What happens:
1.7.10 Server crashes when placing Conduit next to me energy accepter
What you expected to happen:
Conduit should be placed
Steps to reproduce:
<IP_ADDRESS> Server crashes when placing Conduit next to me energy accepter2.

Affected Versions (Do not use "latest"):

EnderIO: EnderIO-1.7.10-2.....3.0.429-batea
EnderCore:EnderCore 1.7.10-<IP_ADDRESS>_beta
Minecraft: 1.7.10
Forge: 1.7.10-1614
AE2-rv3-beta6

Your most recent log file where the issue was present:
https://pastebin.com/pBhip62m

Where did you get that 5th tier energy conduit from? We only have 3 tiers...

Its not even a Furnace generator...,
Im talking about an Energy Accepter from ae2,
Steps to reproduce:
<IP_ADDRESS> Server crashes when placing Conduit next to me energy accepter2.

The crash log is quite clear here:
-- Block entity being ticked --
    Name: extrautils:generatorbase // com.rwtema.extrautils.tileentity.generators.TileEntityGeneratorFurnace
    Block type: ID #970 (tile.extrautils:generator // com.rwtema.extrautils.tileentity.generators.BlockGenerator)

That's the block in which work cycle the crash happens.

@Alex-hawks no, vanilla can create any item or block with any meta value. However, I'm not yet sure this is the reason for the crash, that's why I asked the OP about it...

Line 256 might give some enlightenment

Is Modded: Definitely; Server brand changed to 'kcauldron,cauldron,craftbukkit,mcpc,fml,forge'


Bootstrap 4 to BSN migration

@thednp I need your help as I am struggling with this for a while in a big project where many limitations are there :)
I understood you deprecated V4, is this the legacy branch you talk about? or is it bs-4?
Could you please give a short guidance on what I have to do to make it fully working?
I have following setup [and cannot change it]
ES6+
Bootstrap 4.6.x
Webpack 5
I am curently setup with legacy branch and bs_version: 4,
If you can help me make this working it's great
[ issues:

currently accordion doesn't work,
there's another version of bootstrap 3 in the site that i should not touch at all which is getting broken by BSN it seems
]

I was not confident to install BSN@5 because it's not clear to me if it's for both bootstrap 4 and bootstrap 5 or just for bootstrap 5 and I can't update bootstrap itself; also there's another constraint that BSN@5 seems to need data-bs- type attrs which has some undesired impact into our project but I'll handle that if it's the only problem.
Many thanks in advance!

BSN@5 is Bootstrap 5+
BSN@bs4 is Bootstrap 4
BSN@legacy is an old branch with support for Bootstrap 3 and 4.
If you work with compatible markup and follow the guide, everything should be working as intended. Yes, specific attributes changed like the original for V5 (EG: data-toggle="tooltip" is now data-bs-toggle="tooltip").
If you share the markup in a fiddle I can have a look.

Thanks for clarification!
I switched to "bootstrap.native": "^4.2.0",
Even here the data attrs changed to data-bs-* but that's ok
The only problem i still cannot understand is why accordion doesn't work in my environment while i can easily have it working in the fiddle with default bootstrap4 styles
If using the markup given as example in BSN docs, then some classes are switched but not correctly and only to the first element
If using the markup given in Bootstrap 4 docs [card based], nothing is triggered on clicks


Possibility to disable setting Error Status Codes

It would be nice for jenkins if we could disable scss_lint setting error codes > 0 when a linting error happens.
As we are using checkstyle we do not want the jenkins job to fail if there are only linting errors but warn instead, which is done by the checkstyle plugin.
As a workaround we completely ignore the return status of scss_lint which is also not nice because in case there is a real error we won't notice it immediately.

I might have misunderstood something here. But if you want to treat everything as warnings, why don't you set severity to warning on all lints?

Closing due to lack of response.


ngf-dimensions seem dependant on browser window size

Hi,
I'm experiencing a strange issue whereby if I'm trying to validate an image that is larger than my browser window, then I get an validation error saying that the dimensions of the image are the size of my browser window.
For example,
ngf-dimensions="$width === 1920 && $height === 1080"
..and loading in a 1920x1080 image will produce the following validation error....
{
    "$ngfBlobUrl": "blob:http%3A//localhost%3A3000/dac0927b-528c-408b-b875-7b7d86eca72e",
    "$ngfWidth": 1440,
    "$ngfHeight": 810,
    "$error": "dimensions",
    "$errorMessages": {
        "name": true
    },
    "$errorParam": false
}

If I reduce my browser window size, then the validation error dimensions change.
Any ideas how I can fix this? Many thanks

Also, using Upload.imageDimensions produces the same results, as I thought I may be able to use as a workaround, but it's seems not.
Upload.imageDimensions(file)
                .then(function(dimensions){
                    console.log(dimensions); // produces Object {width: 1440, height: 810}
                });

...and just for the sake of it, here's the media info to show the images actual dimensions.....
General
Complete name                            : arsenal_1920x1080.jpg
Format                                   : JPEG
File size                                : 290 KiB

Image
Format                                   : JPEG
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Compression mode                         : Lossy
Stream size                              : 290 KiB (100%)

OK, I've narrowed it down, and managed to reproduce the error in a plunk.
It seems that the error only occurs when some ui frameworks are introduced, in this case, the foundation css.
So if you open the plunk, you'll see that the ngf-dimensions are set to validate for 1920x1080. If you don't have a 1920x1080 image to hand, there's a link to cone below. Choose the file in the plunk, and you see (provided that the plunker preview viewport width is less than 1920px) that the image fails validation and shows some erroneous fail dimensions.
Now, if you try the plunk without the foundation.css (or just comment it out), it will work just fine. Strange eh? Any ideas anyone?
1920x1080_picture
Plunkr - Not working with foundation.css
Plunkr - Working with no css

Right, I know it seems I'm talking to myself here, but hopefully not!
I've further narrowed it down to a single css entry....
img {
    max-width: 100%;
}

With it, the issue is there. Remove or set to none, and the issue is gone! Hopefully I can override in my app's css and get round this issue.

Fixed at 12.0.3

I am having the exact same issue. And I am on 12.0.4 but the issue still there. In my case, I am using Angular Material (https://material.angularjs.org). Could you look into the issue and see what is going on? Thanks!

BTW, I try to set
  img {
max-width: auto !important;
 }

on the entire page, it still does not solve the issue. My code:
Upload.imageDimensions($scope.file).then(function(dimensions){
$scope.fileWidth = dimensions.width;
$scope.fileHeight = dimensions.height;
});
for the dimensions keep return the max of the browser window, but not the width of the upload file. Thank you!

@hughred22 what version of the plugin? what operating system and device?

12.0.4
I test this on Google Chrome latest version on a Mac.

@hughred22 could you create a jsfiddle with steps to reproduce.


Get subscribed topics of a client

Hi, this is more of a question than an issue
I'm writing a plugin and would like to know if it is possible to get a list of subscribed topics of a given client
Particularly in my use case this would need to be done during on_client_gone hook
I need to know which topics the client is subscribed in order to take specific actions
Thanks

I was able retrieve this info using
Subscriptions = vmq_subscriber_db:read(SubscriberId, [])
But it seems that during on_client_gone hook the subscriptions are already cleaned up
I had to use the on_client_offline hook and change the client config to clean: false


Next.js (13.2.3) -<EMAIL_ADDRESS>Uncaught TypeError: Cannot read properties of undefined (reading 'backdrop')

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
I'm currently utilizing Next.js version 13.2.3 alongside<EMAIL_ADDRESS>However, I am encountering an issue whereby attempting to close the offcanvas triggers an error message to appear on my development console:

Here is how I setup bootstrap on my .tsx file:
'use client';

import { useEffect } from 'react';

export default function Script() {
  useEffect(() => {
    typeof document !== 'undefined' && require('bootstrap/dist/js/bootstrap');
  }, []);
  return null;
}

Please take note that the dropdown is functioning properly, therefore the issue is not related to how I configured bootstrap.
Reduced test cases
https://user-images.githubusercontent.com/121255432/223431257-1a4af3ab-ef3a-423c-8cc4-4f5edb4ffdf7.mov
What operating system(s) are you seeing the problem on?
macOS
What browser(s) are you seeing the problem on?
Chrome
What version of Bootstrap are you using?
<EMAIL_ADDRESS>

@devhoussam1998 if it can help, this is most likely due to targeting invalid/non existing elements
the constructor does a very bad job at telling you and fails silently (it should really throw an error)
These related issues can help
https://github.com/twbs/bootstrap/pull/37794
https://github.com/twbs/bootstrap/issues/37305#issuecomment-1457705848

@devhoussam1998 if it can help, this is most likely due to targeting invalid/non existing elements the constructor does a very bad job at telling you and fails silently (it should really throw an error)
These related issues can help #37794 #37305 (comment)

thank you I fix the problem

@GeoSot Anything to revisit here based on the related issues/PRs mentioned?

@devhoussam1998 if it can help, this is most likely due to targeting invalid/non existing elements the constructor does a very bad job at telling you and fails silently (it should really throw an error)
These related issues can help #37794 #37305 (comment)

thank you I fix the problem

how did you fix it?.........

I not using attributes, I use Modal.getOrCreateInstance(), how to fix the issue in this case?....


Plant Gatherer gathering way more trees than it should

Industrial Foregoing Version: industrialforegoing-1.12.2-1.12.13-237
TeslaCoreLib Version: tesla-core-lib-1.12.2-1.0.15
Crashlog (If Any):

Hi, as you can see on the pictures above, I installed 3 plant gatherers next to each other and into them i have put range addon +12. The gatherers gathered way more trees than it was supposed to and it didnt gather the trees in range, only their leafs.
I guess that its a bug.

I replaced the gatherers and it works normally now. I have no clue what that was.

You can change the range of the machine in the config


remove the 'ignore errors' for running the taints task in gke

ansible's boolean evaluation is 'short circuit-able' so we can test
for the parent object being defined and parsing will stop before
checking for the child.  this will prevent error messages that get
ignored and make the system slightly safer

@coffeepac thanks, I couldn't figure out how to stop that from erroring out. LGTM


[fix] Special characters in url getting escaped - Remove regex match feature

Issue : #27
The purpose of this PR is to avoid unwanted escaping of the special characters in the url field and to remove the functionality of identifying and generating strings based on regex inside the url string.

@sarathm09 Could you please review this once?

@rahulbhargav I had approved the PR already

@sarathm09 Is this PR dependent on another PR/issue? Or, can we merge this?
I don't have access to merge.

@sarathm09 Is this PR dependent on another PR/issue? Or, can we merge this?
I don't have access to merge.

Ohh, I'm sorry, I didn't know that you didn't have access to merge. I hadn't added any restriction other than one approval per PR
I've given you access, also, merging this change.

btw, @rahulbhargav why does the author come as JackFrost?


Launch as default terminal with Dolphin File Manager [Manjaro Gnome]

Hello, I have tried to added a custom action for Hyper to use with Dolphin, however it will not recognize the arguements and is unable to move to the current directory when invoked.
Below is the config file:
[Desktop Entry]
Type=Service
X-KDE-ServiceTypes=KonqPopupMenu/Plugin
MimeType=inode/directory;
Actions=openTerminalHere;
X-KDE-AuthorizeAction=shell_access
[Desktop Action openTerminalHere]
TryExec=hyper
Exec=hyper --workdir %f
Icon=utilities-terminal
Name=Open Hyper Terminal Here

I have solved it. If anyone is stuck here is my config
[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=inode/directory
Actions=openHyper;
X-KDE-Priority=TopLevel
X-KDE-StartupNotify=false
Icon=com.gexperts.Hyper
[Desktop Action openHyper]
Name=Open Hyper Here
Icon=com.gexperts.Hyper
Exec=/usr/bin/hyper %f


Issues with UI development

I dound error in code

We are re-reviewing the code to keep you posted.
@vemuladev1 pls check this on priority.

Fixed the bugs all good now.


Terraform aws_security_group false negative

Sorry for not submitting a PR, Rego learning in progress.
Expected Behavior
File: terraform/main.tf
Line 56
Expected: 'aws_security_group[cowrie]' is used
Found: 'aws_security_group[cowrie]' is used

Actual Behavior
File: terraform/main.tf
Line 56
Expected: 'aws_security_group[cowrie]' is used
Found: 'aws_security_group[cowrie]' is not used

Security Group Not Used, Severity: INFO, Results: 1
Description: Security group must be used or not declared
Platform: Terraform

	[1]: terraform/main.tf:56

		055:
		056: resource "aws_security_group" "cowrie" {
		057:   name        = "CowrieSSH"

$ terraform show -json | jq '.values.root_module.resources[0].values.security_groups'
[
  "CowrieSSH",
  "default"
]

https://github.com/konstruktoid/ansible-cowrie-rootless/blob/main/aws/main.tf#L56 is used at https://github.com/konstruktoid/ansible-cowrie-rootless/blob/main/aws/main.tf#L86 as a variable (https://github.com/konstruktoid/ansible-cowrie-rootless/blob/main/aws/main.tf#L32).
Specifications
Tested with 1.5.1 (https://github.com/Checkmarx/homebrew-tap/issues/1) and 1.5.5 (Docker).

Hello Thomas, this is indeed a false positive, thank you for being so attentive! I hope this PR fixes your issue. Also, do you mind if we use the sample you provided as a negative sample?

Thanks @cxAndreFelicidade and you're of course welcome to use the sample.


Memory leak in CreateRef

Memory leak
In Base.h the CreateRef<> function, make_shared actually creates a new copy to be held by the pointer.
This creates a leak whenever used as this way opening a new scene (either empty or from a save file) does not free the previously loaded scene.

This can be noticed by following the memory usage.

Hello, I don't think smart pointers can leak memory, because they are designed to solve problems with memory leaks.
Although, constexpr is clearly superfluous here.
Perhaps you should read about smart pointers to understand me.
In any case, you can check if there really is a memory leak or if these pointers are being held somewhere, just prolog the calls to the scene's destructors.

As @NIKEA-SOFT said, there is no memory leaking

Compiler inlines this function (constexpr)
std::shared_ptr uses reference counting -> previous scene gets deleted
example shows:

#include <iostream>
#include <memory>

struct Test {
   Test(int i) {
      std::cout << "Test Constructor! " << i << '\n';
   }
   ~Test() {
      std::cout << "Test Destructor!\n";
      std::cin.get();
   }
};

template<typename T>
using Ref = std::shared_ptr<T>;

template<typename T, typename... Args>
constexpr Ref<T> CreateRef(Args&&... args) {
   return std::make_shared<T>(std::forward<Args>(args)...);
}

int main()
{
   Ref<Test> test = CreateRef<Test>(5);
   // Equivalent of:
   // std::shared_ptr<Test> test = std::make_shared<Test>(5);
}


index.query.max_nested_depth=20 in 3.0

Issues Resolved
#6346
it documents 3.0 change https://github.com/opensearch-project/OpenSearch/pull/11670
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks, @mkhludnev !


Stops working at low frequencies

First, thanks very much for this nice PIO code, it does a very accurate job and is perfect for my application of measuring the frequency of audio tones, with one exception - it stops responding at 7 Hz and below.   8 Hz and up works fine.
I was expecting that the algorithm would fill the FIFO with zeros when the input signal stopped but that's not the case.  I need a means of detecting when the applied PWM signal has stopped i.e. assumed a DC level.   I may have to do this with a separate GPIO read but if there's a way that it can be done by modifying the PIO code that would be preferable.   I understand the basic algorithm but am not skilled enough in the PIO to know if this is possible or how to do it.    If you have time to respond I'm curious why the algorithm won't go below 8 Hz also.
I should add that the console does stop displaying measurements when the input stops,  even though the actual value of pulse width (or period) never actually go to zero.     So the console display stops because no more data is being sent through the FIFO, not because of the if statement.    Thanks again!
Bob

Do you mean the PwmIn code? If so, for me it works fine at 7Hz (I've tested it down to 0.5 Hz).
You want to know when the PWM has stopped. Of course PWM can have an arbitrary low frequency. In the pio code, if the counter goes through 0 (at lines 28 and 34), that could somehow be used to signal that the PWM has stopped (currently it restarts the measurements at line 21).

Thanks for taking the time to reply.   My face is red - I was using a PC-based wave generator and in fact IT stops at 7 Hz, not the code, sorry!    I've since written code that looks for pulses at the same pin and then use the PIO code for precise measurements, so I should be good to go.   Bob

No problem, good to see that it works!


Add new body parameters to PATCH /api/v1/feeds/{feed_id}/

To support the option to manually edit

pretty_url (always optional) -- there is a cosmetic URL. It is designed to show the actual blog link to browse to in a web browser (not the feed)
title (optional) -- if not passed, will inherit this from the feed
description (optional) -- if not passed, will inherit this from the feed

introduced in
https://github.com/muchdogesec/history4feed/issues/76
We should allow users to also pass these to the PATCH /api/v1/feeds/{feed_id}/ to change values.
Note, all values optional and will not be changed unless the value is passed in the PATCH request (i.e. title will stay the same, unless title passed in the PATCH request)

@fqrious missing profile id

@fqrious i am proposing
https://dogesec.slack.com/archives/D05L8JEAM1N/p1732703326108849


⚠ Bofrost.at has degraded performance

In 881f648, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1269 ms

Resolved: Bofrost.at performance has improved in 672fdd9 after 6 minutes.


chore: Remove divan::black_box from benchmarks

Description

The benchmarking code was calling black_box when:

It is not necessary to use black_box when generating inputs since that part of the code isn't being measured, so you're running less optimal code for no benefit.
Benchmark inputs have already been passed through black_box, so there is no need to call it again for inputs.

Also, thanks for using Divan! I'm excited to see how folks are using it. ❤

coverage: 79.696%. remained the same
when pulling 1532d3e35c0a209fb806fddcb96ff35e86a792d0 on nvzqz:patch-1
into c8cef90453293e1b1ce30ed92f02c5e43dd3c62e on pomsky-lang:main.

@nvzqz Thanks for taking a look, and for making divan!
I really like the clear output generated by divan, and how fast it is (criterion took several seconds for each benchmark).
By the way, is it possible to parameterize benchmarks by something other than numbers (e.g. strings)? I don't particularly like the macros I had to write.

I really like the clear output generated by divan, and how fast it is (criterion took several seconds for each benchmark).

Those two aspects were very intentional, thanks!

is it possible to parameterize benchmarks by something other than numbers (e.g. strings)? I don't particularly like the macros I had to write.

Not yet. I plan to support runtime parameters similar to the consts parameter:
#[divan::bench(args = ["a", "b", "c"])]
fn bench(s: &str) {
    ...
}

Note that the arguments will be printed verbatim in the hierarchy using std::fmt::Display.
example
╰─ bench
   ├─ a
   ├─ b
   ╰─ c

So I recommend having them be either:

the names of cases, like "groups" and "special"
enum cases

By the way, is it possible to parameterize benchmarks by something other than numbers (e.g. strings)? I don't particularly like the macros I had to write.

Divan now supports args like in my previous comment. 🙂


[Feature][UI] More robust validation of endpoint URL

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Use case
The "Endpoint URL" of plugins is something the users specify on the UI. The issue is, any working URL can be entered there as long as it is accessible via a GET request with the specified credentials; however, the same URL is used as the base endpoint for all queries made by blueprint executions. These can conflict with each other. For example, a user recently tried out jenkins.mydomain.com/api/ which passes validation but fails at execution. jenkins.mydomain.com by itself works though.
Description
The simplest solution will be to enforce no appendment of extra paths, e.g. /api/. This may have drawbacks though depending on the server's networking configuration. Feel free to suggest alternatives.
I think we furthermore should normalize the URL paths so that regardless of a "trailing slash" in the URL, the backend connections work. Right now, some connections will fail (despite passing the test) in the presence or absence of a /, which is a trival thing that can cause errors or strange behavior in the backend.
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Another case reported by a user in the Slack:  the user forgot to the trailing slash behind https://api.github.com, the connection test and git extractor handled this, but graphql plugin didn't and threw an error.

bump


Refactor to introduce CassandraStatement that doesn't inherit from PreparedStatement

Refactored to introduce CassandraStatement which doesn't inherit from PreparedStatement.  This is useful for upstream frameworks (ie, Mule's database connector) that has internal logic to create PreparedStatement's differently from Statements.

Thanks for your contribution! The changes look good to me. Will merge the PR in weekend along with some minor changes for 0.6.2.


Jonmv/deployment orch adjustments

@mpolden please review.

PTAL, snook a little something more in there.


provide a spinner

Large map requests take a long time.
Normal users won't know this.  They expect instant gratification.
When clicking make map the app should go all grey (no more clicking on stuff) with a spinner in the middle waiting for the result to wrap up.
Perhaps if we are caching previous map results other users have done and have thumbnails you could amuse them with a gallery slide show while they wait.

"clipping from the wms... this may take a while" # generic message to say above spinner.
get all fancy and have a variables in it:
"clipping a (X by Y) image from (feed)"
Get all fancy with them and have different messages based on max width/height
1000 -> 3000 : "one sec, extracting that image"
3000 -> 6000 : "serious map extraction happing.. hope you are ready for it"
6000 -> 10000 : "creating a ridiculously enormous map extraction.  this will take some time.  "

Basic spinner added


update EOF container specs with variable-length encodings

Summary
this updates the EOF container specs to use variable-length encodings. a lot of hard-coded sizes could go away now, which is nice. VLQ was used because it has a wikipedia page, is easy enough to understand and has reference implementations. Prefix VLQ is also a possibility, but I suspect there are fewer standardized implementations, and I also doubt that VLQ encoding/decoding will really be a performance hotspot.
Motivation

almost always improves code size
improves forwards compatibility. if we want to update hard limits in the future, it can be done without needing to change opcode layout (e.g., increasing the size of RJUMP immediate to 3 bytes).
improves spec simplicity, don't need to spend as much effort finding the "perfect balance" between number of opcodes vs opcode immediate sizes.
as an example of the above point, it removes the need to have separate EXCHANGE vs SWAP_N opcodes.

open questions:

[ ] encoding for signed VLQs
[ ] reference implementation
[ ] sentinel value for non-returning functions. i kept this as 0x80, but it limits the number of stack items which can be returned to 127, which is inconsistent with everywhere else, where i relaxed the size constraints. i suggest that outputs == max_stack_height + 1 signifies that the function is non-returning.
[ ] header terminator can probably be removed since it seems to be redundant with the length annotations. but i am not sure, so i left it in.
[ ] i would suggest that various PUSH0-PUSH32 instructions be phased out in favor of a single, variable length PUSH instruction. this can be done with just 5 bits of overhead. as it is, it seems cheaper in general to use DATALOADN, since it costs only 2 gas.
[ ] we can probably refactor SWAP_N vs EXCHANGE into a single opcode now.
[ ] keeping the pointers in RJUMPV table all the same width

i just benchmarked this in cpython and pypy by the way. it looks like decode looks about 600ns per decode in cpython, and about 10ns per decode in pypy (and the resolution is not that great -- loop overhead in my test is about 4ns for pypy and 90ns for cpythong).

i just benchmarked this in cpython and pypy by the way. it looks like decode takes about 500ns per decode in cpython, and about 6ns per decode in pypy.
(my timer resolution is not that great -- loop overhead in my test is about 4ns for pypy and 90ns for cpython, which i subtracted to get the reported values above).

just for fun, i also tested python's int.from_bytes() and int.to_bytes() functions. i got 10ns decode per item for cpython after subtracting out loop overhead, and 19ns decode per item in pypy, which is actually slower(!) than the vlq decode implementation.

Thanks, this is interesting! My only comment regarding the technical part:

We keep the instruction gas cost the same regardless of the immediate size. Is this OK? It probably is, but we might want to make sure of this in the future. A sentence clarifying this in the spec would be good, or an entry on the TODO list

As for the next steps here, my feeling is like this is more of an EOFv2 proposal. From the EOF implementers call, it seems there's a lot of R&D yet to be done here (including collecting hard data to back the estimated gains up) and we may not have the capacity now to handle this properly. Another thing is EOFv1 is a big change already.
Lastly, can you include here a detailed motivation paragraph for this change? When we have that, we could identify the most critical issues this solves and think of potential stop-gap solution. (e.g. if 2-byte immediate of RJUMP is proven the biggest issue, a 1-byte immediate version could be considered to mitigate the problem in EOFv1, at a small expense of elegance).

We keep the instruction gas cost the same regardless of the immediate size. Is this OK? It probably is, but we might want to make sure of this in the future. A sentence clarifying this in the spec would be good, or an entry on the TODO list

i'll add something. i think the runtime gas cost can be the same regardless of the immediate size, especially if the sizes are bounded. like i don't think there is a material performance difference between decoding a 1-byte vlq and a 2-byte vlq.

As for the next steps here, my feeling is like this is more of an EOFv2 proposal. From the EOF implementers call, it seems there's a lot of R&D yet to be done here (including collecting hard data to back the estimated gains up) and we may not have the capacity now to handle this properly. Another thing is EOFv1 is a big change already.

regarding EOFv1 being a big change already -- this PR only changes new opcodes and the header/container format. so i don't think it makes EOFv1 any larger (in fact i would personally argue that it streamlines and simplifes the spec).

Lastly, can you include here a detailed motivation paragraph for this change? When we have that, we could identify the most critical issues this solves and think of potential stop-gap solution. (e.g. if 2-byte immediate of RJUMP is proven the biggest issue, a 1-byte immediate version could be considered to mitigate the problem in EOFv1, at a small expense of elegance).

code size, need for different EXCHANGE vs SWAP opcodes, forwards compatibility, spec simplicity.

Lastly, can you include here a detailed motivation paragraph for this change?

updated the motivation paragraph in the PR description!

i did a bit of "estimating" how much VLQ encoding would save for rjump/rjumpi -- tl;dr for jumps, it is about 0.8% codesize improvement.

i patched v0.3.10 of the vyper compiler https://github.com/vyperlang/vyper/tree/vlq-tests
counts jumps and how many bytes the immediate would need with VLQ encoding
uses a bit of heuristics to filter out jumps which would likely be replaced by CALLF in EOF

example output:
$ vyper -f bytecode_runtime tmp/CurveStableSwapMetaNG.vy | wc
number of jumps counted: 297 (aka 594 bytes)
theoretical bytes used by vlq: 402
savings: 192 bytes (0.83%)
      1       1   46285

(that 46285 quantity is the length of the hex encoding of the bytecode. to recover number of bytes, subtract 3 and divide by 2).

VLQ is a lot of work for less than 1% code size savings, especially if we aim to launch a test net by march.
Forward looking to uncapped EOF I think a path forward would be to add alternate VLQ section IDs to the header (0x81, 0x82, 0x83, 0x84) and then add VLQ variants of the jump instructions.  This allows for larger than 64k sections and larger than 32k jumps, which addresses the primary uncapping concerns.
I don't see uncapping happening any sooner than the fork after verkle (Bogota), so that gives us time to ensure it works properly.

VLQ is a lot of work for less than 1% code size savings

that's just for JUMPs btw. i'd guess for all things being done in VLQ (including headers and RJUMP*), it would be closer to 2-5%.

Comparison of LEB128 decoding implementation with big-endian 16-bit loading. https://godbolt.org/z/d1GbsfPTP

Comparison of LEB128 decoding implementation with big-endian 16-bit loading. https://godbolt.org/z/d1GbsfPTP

just for fun, here is a branchless version for special case where the size is bounded at 4 bytes (just to get the idea, there might be some bugs like wrong order of unpacking - i didn't test) https://godbolt.org/z/qcnEGW5PP

by the way, i moved the work that i did for this pull request to a different branch: https://github.com/charles-cooper/eof/tree/feat/vlq.


v4.0

Hello
I wonder if there is going v4 be released someday?
I am not pushing anyone, just asking!
thanks

Maybe? There will definitely be additional releases. What would you like to see in a new version that's not available now?
I've been so busy with work and two kiddos that I haven't had time to give this library the attention it deserves. As soon as things calm down I'll definitely get back to maintenance, feature requests, new versions, etc. There are some really great pull requests from @mikegreiling, @oxigenka, and @nyamsprod that can give you an idea of features/updates that will be added as soon as I can get back to them.

(I'm going to close this, but please feel free to reopen for any additional questions or comments you'd like to add.)

@jeremykendall If v4 is still a thing I'd like you to consider this idea I had about the package I believe It would even solve many current issues. This is just a proposal feel free to reject everything if you don't like it 👍
The main "issue generator" is the PublicSuffixListManager class which have too many responsabilities:

It downloads the data from mozilla
It caches the downloaded data
It parses the downloaded data
it returns the data to be consumed by other parts of the library

This gives the class too many responsabilites and explain many of the current bug found. I would suggest rewritten this class is this manner
<?php

use Pdp\HttpAdapter\HttpAdapterInterface;
use Pdp\PublicSuffixList\ParserInterface;
use Psr\SimpleCache\CacheInterface;

public function PublicSuffixListManager::__construct(
        ParserInterface $parser = null,
        HttpAdapterInterface $client = null,
        CacheInterface $cache = null,
);

This way:

SRP is enforced on the PublicSuffixListManager and it would be only responsible for returning the data to be consumed by other parts of the library.
The cache is done using PSR-16 so to resolve all current caching issues and also enable better caching solution.
The PDP parser is also made into a interface to enable switching it too if needed.

last but not least I would consider bumping PHP requirements to either PHP5.6 or PHP7 👍
What do you think ?

I love everything about that idea. Want to open an issue with the necessary tasks in a list of checkboxes?


"Couldn't parse VM stack trace line 'null'." in pub get

This error has come up a couple times. The full error looks like this:
    d:\Open Source\i_dart>pub get
    Resolving dependencies.......
    Downloading unittest 0.9.2+1...
    Downloading stack_trace 0.9.1...
    Downloading path 1.0.0...
    Uncaught Error: FormatException: Couldn't parse VM stack trace line 'null'.

    Stack trace:
    null
    #0      _rootHandleUncaughtError.<anonymous closure>.<anonymous closure> (dart:async/zone.dart:677)
    #1      _asyncRunCallback (dart:async/schedule_microtask.dart:18)
    #2      _asyncRunCallback (dart:async/schedule_microtask.dart:21)
    #3      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:119)
It looks like there's at least one entry in a Chain where the stack trace is null. This means that somewhere "null" is being parsed as a stack trace, which is wrong.

This issue has been moved to dart-lang/pub#814.


test_client.set_cookie does not seem to work

Expected Behavior
The test client should be able to set cookies in a manner that the application object can read them. There's a .set_cookie(...) method but it doesn't seem to work -- after stepping through it I think the issue is that cookies aren't getting signed?
import flask

app = flask.Flask("test")

@app.route("/")
def index():
    assert "thing" in app.session
    return "okay"

def test():
    with app.test_client() as client:
        client.set_cookie("example.com", "thing", "value")
        response = client.get("/", base_url="http://example.com")
    assert response.status_code == 200

test()

Actual Behavior
The assertion is tripped due to an empty session, despite set_cookie() seemingly succeeding.
Environment

Python version: 3.6.7
Flask version: 1.1.1
Werkzeug version: 0.15.4

Oops, I'm conflating sessions and cookies a bit here, but I think the point still stands that this appears to be missing functionality.

Using sessions with the test client is documented.


Project takes too long to load or remove files in the  Android Editor

Tested versions
Reproducible in godot 4.3 beta 3
System information
Sansung galaxy s23+
Issue description
While it sure the android editor is not made for big project with more than 300mb  or 500 , it kind of weird than in the tps demo it takes just a minute to remove 1 file , meanwhile when going on play mode  save  all scenes doesn't take nearly as much , so that 's why i think this might be more or less a bug.
In other instance in the pc version in a igpu( rx vega 3) it works way faster to load the project or doing the same adjustments despite being 4 times slower than the s23 and  even in vulkan the s23 is faster despite the drivers ineficences.
Prob partial fix
https://github.com/godotengine/godot/pull/93064 ?
Edit: testing it last artifact and it doesn't make much difference in performanxe when removing a resource or loading the scene
Steps to reproduce
Open a big project like the mrp of the tps demo modifed  https://github.com/godotengine/tps-demo
Load the scene or try to remove files to notice the massive slowdown.
Minimal reproduction project (MRP)
"N/A" ( Too big for mrp, download the tps demo link) https://github.com/godotengine/tps-demo )

I wonder if this is due to Android scoped storage bottlenecking I/O performance somehow. Unfortunately, there's no way to opt out of this in Android 11 or later.

I wonder if this is due to Android scoped storage bottlenecking I/O performance somehow.

Idk, what i think could happen is that the android editor  might  be reloading the scene every time you want to acces it storage or when you  go from  one window unrelated to the editor , and then back to  the editor , as it loading it similar to when you want to load your project.
It a really weird case  noticeable on big project with all scripts. Shaders etc, because , for example in the sun temple modified project, it not taking as long as the tps or my project.

I can reproduce this on the Truck Town demo on 4.3.beta 92c8e87cd (Android 14, Samsung Galaxy Tab S9 Ultra). Renaming or moving a single file takes 3+ seconds despite that demo only have a few dozen files. Deleting a file (such as a newly duplicated image that isn't used in any scene) doesn't seem to take any significant amount of time though.

Deleting a file (such as a newly duplicated image that isn't used in any scene) doesn't seem to take any significant amount of time though.

Weird, have you  tried  on the tps demo?  I think for removing files, that were the most noticeable speed slowness happens as it way bigger than the truck demo( way more files) , trying on the igpu  in the past was instant (1 sec).

I think i could figure out the problem testing  this pr that fixes the  window making it possible to see the reimporting window when loading and kinda when removing files, which what i feel it does is reload all the entire project just to remove something, which would explain why i get the same errors when loading the project  as the ones from removing an file,sadly cant drag the window while on progress but we can have an idea of why this happens

I don't have access to an Android to test it, but from what I see, my guess is that FileAccess::get_modified_time returns a different value even if the files are not updated or maybe the date is not perfect if read just after the file is written on disk. I saw that the storage was upgraded for Android in beta 3 and a PR merged that adds a new check on the date of the .import file when scanning the project.

CC @m4gr3d @KoBeWi

I saw that the storage was upgraded for Android in beta 3 and a PR merged that adds a new check on the date of the .import file when scanning the project.

To confirm that hypothesis, could someone affected test earlier beta snapshots to see if this is indeed a regression in beta 3?

To confirm that hypothesis, could someone affected test earlier beta snapshots to see if this is indeed a regression in beta 3?

Testing on the tps demo modifed project( lurked from the forge final collaboration pr tests,. Take into account seconds may vary a bit as it not accurate enough, because i am just using the watch cronometer without a tool script)
On 4.3 beta 3 it takes 1 minute  20 seconds
On 4.3 beta 1 it takes  16  seconds  and removing files is instant this time without the whole project reloading itself
Then to test if regression was between  beta 2 it takes just like beta 1 17 seconds.
So it seems's this is a regression, in my opinion it more on the side of reimporting assets than scanning, as reimport is clearly what takes the most time here.

So it seems's this is a regression, in my opinion it more on the side of reimporting assets than scanning, as reimport is clearly what takes the most time here.

I was suggesting scanning because reimport assets should not occur at all when opening a project, renaming files or returning to the editor after going to another window, if no changes are made on the disk. But seriously, without debugging, I can be in the absolute wrong!!

This is getting real weird here, like after i installed 4.3 beta 2 and 1 and then after doing the test there and turning on beta 3 project, now it has the same loading speed and  the slowdown on removing files is gone.
I have a theory that  this might have happened  : because these project were first opened in 4.3 beta 3( which looks to be the faulty one as beta 1 and 2 never seemed to run on this), they were fixed when they were transfered to the older versions which might explain why when transfering it back to beta 3 it fixed.
So here's the what we can do
Install a zip largue project ( for example the tps demo one) and extract it. Also keep the zip folder
Procced to install godot 4.3 beta 3 and launch the project, ( notice how slow is it as it reimporting the entire project)
Now uninstall godot 4.3 beta 3( to allow the older version to be installed) and delete the extracted project( as if we used this one in the older beta it will be fixed when going back to beta 3)
Then install beta 2 or 1, launch it, quit, and then extract the project to import it into these versions( notice how when it loads it goes much faster and theres no slowdown when removing filws).
Sorry if this is confusing i try what i can and
this bug is kind of rare to reproduce

Wow, this is a very intriguing turn of event!!
I finally was able to test on my Samsung A14 on Android 14. I tested the TPS demo project and unfortunately, I was not able to reproduce the long project loading and rescanning when removing a file or opening a scene.
I used a custom build from master.

I used a custom build from master.

Interesting , what custom build did you use ? You got any artifact from it?

Interesting , what custom build did you use ? You got any artifact from it?
I build locally from master with scons platform=android arch=arm64 production=yes target=editor

I just tested on my device using this artefact: https://github.com/godotengine/godot/actions/runs/10022669772
Maybe I do something wrong to reproduce the problem.
This is what I did:

Remove Hodot
Deleted the tps folder
Download TPS from https://godotengine.org/asset-library/asset/2710 on my computer
Unzip TPS on my computer
Upload the tps demo folder to my android device via Android Studio (on SD card)
Launch Godot
Import the tps demo folder
Wait a couple minutes to let Godot reimport everything (this is normal that the first time it's long because the .godot folder is not there)
Try to close Godot et reopen the project, it's super fast
Try to rename level.tscn to level2.tscn, it's super fast
Try to rename a node in level.tscn (it took 10-15 sec, I'm on a low spec phone, I guess it could be normal)

But... then I tried to start the game... it worked, but, when I closed it and got back to Godot, it took a couple of minutes with a file system rescan and a black screen, exactly as the first load.
I'll try to add more print log now that I'm able to reproduce the problem.

After much testing, I'm really not able to reproduce the original problemof this issue on my device, even if I use the artefact https://github.com/godotengine/godot/actions/runs/10022669772.
I thought I was able to reproduce the problem, but it was only the fact that when the running game is closed, Godot is completely restarted and opening the scene from TPS demo takes around 15 seconds on my device. I don't known if it's normal that Godot must be restarted at each start/stop of the game? I never had the problem where files are being reimported even if not modified.
The other thing I find strange is the fact that scanning the project takes around 3 seconds which is not that fast considering that the project contains only 588 files.
Sorry, maybe someone else will have more luck or maybe it's a problem on some device only.

when the running game is closed, Godot is completely restarted and opening the scene from TPS demo takes around 15 seconds on my device. I don't known if it's normal that Godot must be restarted at each start/stop of the game? I never had the problem where files are being reimported even if not modified.

Weird that the only part where you can reproduce this too( i have the same  problem when you leave the edutor window or  run and then quit the game,which doesn't happen in beta 2 and 1 and it took me minutes for the project to load after that)

The other thing I find strange is the fact that scanning the project takes around 3 seconds which is not that fast considering that the project contains only 588 files.

Well the device is not that slow, though for me and my  s23+ it takes more , and that kind of similar to my time rescanning in pc.

Sorry, maybe someone else will have more luck or maybe it's a problem on some device only.

It's ok, it can be more or less workarounded by doing what i said , but it pretty annoying and more if new people run into this stuff..though i  didn'rt really mean about renaming files, just when you remove them from file system  which is when editor redraws itself
Also about the android studio thing , what do you meanv by that?  Did you install something or moved from file manager?

when the running game is closed, Godot is completely restarted and opening the scene from TPS demo takes around 15 seconds on my device. I don't known if it's normal that Godot must be restarted at each start/stop of the game? I never had the problem where files are being reimported even if not modified.

Weird that the only part where you can reproduce this too( i have the same problem when you leave the edutor window or run and then quit the game,which doesn't happen in beta 2 and 1 and it took me minutes for the project to load after that)

The other thing I find strange is the fact that scanning the project takes around 3 seconds which is not that fast considering that the project contains only 588 files.

Well the device is not that slow, though for me and my s23+ it takes more , and that kind of similar to my time rescanning in pc.

Sorry, maybe someone else will have more luck or maybe it's a problem on some device only.

It's ok, it can be more or less workarounded by doing what i said , but it pretty annoying and more if new people run into this stuff..though i didn'rt really mean about renaming files, just when you remove them from file system which is when editor redraws itself
Also about the android studio thing , what do you meanv by that? Did you install something or moved from file manager? And also why did you unzip it in  your computer instead of on android? You can do that simply by clicking extract from the three dots that appear on the right when you select the zip folder. Maybe it has to do with not being able to reproduce the removing files load time.

So I did some testing and I can reproduce the issue in 4.3.beta3 and latest master with a custom build.
The symptoms I see are that any filesystem operation triggers a rescan (that's expected, or at least not a new issue - #50576), but since 4.3.beta3 that rescan takes much longer (like a minute), or seems to be stuck at around 100% for a long time.

I saw that the storage was upgraded for Android in beta 3 and a PR merged that adds a new check on the date of the .import file when scanning the project.

To confirm that hypothesis, could someone affected test earlier beta snapshots to see if this is indeed a regression in beta 3?

I confirmed that hypothesis. @Hilderin was referring to #84974, and indeed reverting that PR fixes the issue. After the revert, there is still a rescan on any operation, but it takes 2-3s.
Now, that's a bit surprising as #84974 should be triggering reimports, not just rescans. I wonder if on the Android editor imports are "hidden" and bundled in the FS dock rescan, at least visually?

Now, that's a bit surprising as #84974 should be triggering reimports, not just rescans. I wonder if on the Android editor imports are "hidden" and bundled in the FS dock rescan, at least visually?

So that was indeed the case, the ProgressDialog was not rendering on Android specifically. #94662 will fix that.
So the problem is indeed caused by a reimport of project assets after the (expected) rescan of all the project. Importing assets in a big project like the TPS demo takes a long time, but the fact that it wants to reimport after any simple operation like creating a folder is indeed a bug caused by #84974.

This is getting real weird here, like after i installed 4.3 beta 2 and 1 and then after doing the test there and turning on beta 3 project, now it has the same loading speed and the slowdown on removing files is gone.

So I experienced the same too, which confused me initially, but my hypothesis is that 4.3 beta 2 and 4.3 beta 3 generate something different in the .godot folder when importing. When opening a project in 4.3 beta 2, all files are properly imported, and then after opening the project in 4.3 beta 3, the pre-existing .godot folder with imported files prevent the bug from happening.
Deleting the .godot folder should cause the issue again in 4.3 beta 3, even if you used beta 2 in the meantime.
I haven't yet had time to try it out (might do tomorrow), but my next debugging idea was to open the project in 4.3 beta 2, copy the .godot folder to my desktop, delete it on Android, open the project again in 4.3 beta 3, copy the .godot folder to my desktop, and diff both folders to see if there's a difference.

the fact that it wants to reimport after any simple operation like creating a folder is indeed a bug caused by https://github.com/godotengine/godot/pull/84974.

No, it's another bug that surfaced because of this PR. Creating a folder does not change .import files.
Either it does change them on Android or the cached import modified time is wrong.

Either it does change them on Android or the cached import modified time is wrong.

I think it's the latter. It's not just creating a folder that triggers this issue, but also simply closing Godot and reopening it.
As in, anything that triggers as fs scan will do a full reimport.
So either the cached import modified time is wrong, or the modified time for the .import files is wrongly calculated (or both use different and incompatible methods?).

BTW the TPS demo is really overkill for testing this bug it's reproducible also with smaller projects. I suggest Kenney's 3D platformer starter kit from the AssetLib (with #94662 to make the progress dialog visible).

So either the cached import modified time is wrong, or the modified time for the .import files is wrongly calculated (or both use different and incompatible methods?).

I would say it more that the project itself is not taking into account the .godot folder and it might just think that we are importing a new project, as the only thing that seems faster after project reloading are the files scans.

Interestingly enough ,though this is for a different issue, after testing https://github.com/godotengine/godot/pull/94662 i noticed that in the project manager when you want to import a project you can't browse anything and this what you see on screen

I already created an issue for that: https://github.com/godotengine/godot/issues/94570

Added some prints and confirmed that the cached import modified time is wrong:
diff --git a/editor/editor_file_system.cpp b/editor/editor_file_system.cpp
index 0b2cf1424b..44b4a8dad8 100644
--- a/editor/editor_file_system.cpp
+++ b/editor/editor_file_system.cpp
@@ -722,8 +722,11 @@ bool EditorFileSystem::_update_scan_actions() {
 				String full_path = ia.dir->get_file_path(idx);

 				bool need_reimport = _test_for_reimport(full_path, false);
+				print_line(vformat("*** TEST REIMPORT ***: _test_for_reimport: %s", need_reimport ? "true" : "false"));
 				if (!need_reimport && FileAccess::exists(full_path + ".import")) {
 					uint64_t import_mt = ia.dir->get_file_import_modified_time(idx);
+					print_line(vformat("*** TEST REIMPORT ***: get_file_import_modified_time: %d", import_mt));
+					print_line(vformat("*** TEST REIMPORT ***: FileAccess::get_modified_time: %d", FileAccess::get_modified_time(full_path + ".import")));
 					if (import_mt != FileAccess::get_modified_time(full_path + ".import")) {
 						need_reimport = true;
 					}

07-24 10:30:57.380 21724 21764 I godot   : *** TEST REIMPORT ***: _test_for_reimport: false
07-24 10:30:57.381 21724 21764 I godot   : *** TEST REIMPORT ***: get_file_import_modified_time: 0
07-24 10:30:57.382 21724 21764 I godot   : *** TEST REIMPORT ***: FileAccess::get_modified_time:<PHONE_NUMBER>

I made a proper MRP with a single glb file, so it's easier to test and compare the effect of different builds:
testreimportbug.zip

I haven't yet had time to try it out (might do tomorrow), but my next debugging idea was to open the project in 4.3 beta 2, copy the .godot folder to my desktop, delete it on Android, open the project again in 4.3 beta 3, copy the .godot folder to my desktop, and diff both folders to see if there's a difference.

I did that with the above MRP, but didn't find anything conclusive in the differences of the .godot folder. Both the build with the bug and a build with the regression reverted seem to properly populate .godot/editor/filesystem_cache8 with modified times.
I can still reproduce the fact that:

Opening the MRP with a build including #84974 shows the bug. Reopening it, or creating folders, triggers the bug.
Opening the same project with a build with #84974 reverted fixed the bug.
Going back to a build with #84974 on the same project folder does not reintroduce the bug.
Copying the now "fixed" folder to a new name, and opening it, exhibits the bug again.

So "fixing" the bug by opening it with a reverted build doesn't seem to be tied to the contents of files in .godot, but something else. Some hypothesis:

Editor cache outside the project folder (thumbnails, etc.)
Actual file modification dates for the files in the folder

I don't have time to keep poking at this myself, so I'd appreciate help from folks familiar with EditorFileSystem (@KoBeWi, @Hilderin) and/or debugging Android-specific issues (@m4gr3d). In particular I don't know if it's possible to step through the editor code from Android Studio, but that could help understand why the import times are 0 at this step.
For 4.3.rc1, I will just #ifndef ANDROID_ENABLED the code that reimports when the import time is a mismatch.

For 4.3.rc1, I will just #ifndef ANDROID_ENABLED the code that reimports when the import time is a mismatch.

I've done that with #94691, so this is no longer a release blocker IMO.

Thanks a lot @akien-mga for your tests and debug.
I'm still not able to reproduce the problem on my side so I created a draft PR #94717 if someone wants to use the artefact from the PR and test on their device and paste me the output logs, I would be able to better comprehend the problem and maybe find a solution.

I debugged the logic flow and found out that FileAccessUnix::_get_modified_time(...) seems to alternate between different modified time values for the same file.
This causes the logic in EditorFileSystem::_process_file_system(...) to invalidate the file cache and reset the modified time causing the reimport.
For some reasons, the issue causing FileAccessUnix::_get_modified_time(...) to alternate between values seems to only occur on Android; I was unable to replicate that issue on a linux machine.

@Saul2022
Can you try to see if #95678 fixes the problem where all the assets are reloaded each startup on your Android device. In this PR, I removed the code added in the commit 7acb61d that disabled the check on last modification date for .import file on Android.

@Saul2022 Can you try to see if #95678 fixes the problem where all the assets are reloaded each startup on your Android device.

Yep tried on the latest artifact and it's gone and time is 1:22 minutes on startup and 13 on second , scanning being pretty fast etc..load being again just the tps scene not being cached, great improvement. Feel free to close this one when it gets merged.

Hey considering this is merged and  seem’s to be fine working last i have tested, i think it would be good to close it already.


What does it means this Error

I have this ERROR but uploaded work
[2111][2018.10.16 15:43:40]:[MainProcess][ERROR   ]:[root] After CYCLE Up/Reuploading:[0/10 attempts].
What does it's mean?

Hello @ManuCart,

It's not actually an ERROR. It's a WARNING in fact. I'm fixing that for future versions.
It tells us on which upload attempt are we at. In this case "0/10" (first attempt) which is ok! If an error actually occurred, it would be reported on the following messages.

Let know if you have any more difficulties.


Skip identical backtraces from "re-raised" exceptions

Using sentry in a rails application I noticed that recorded exception contain a lot of duplicated backtraces blowing up the submitted JSON unnecessary.
This happens because in the great big rails onion there are a lot of places where exception are rewrapped preserving the backtrace.
E.g. all errors in views get wrapped in an ActionView::Template::Error
Depending on used gems and middleware the JSON payload gets quite big.
I'm seeing reported exceptions with 300KB of json containing 9 exceptions but only three distinct stacktraces.
I'm not sure if this PR is the best solution for tackling this but I wanted to have this elicit some feedback on how this could be improved.

@nateberkopec thoughts on implementation? For correctness I realize this isn't great, but from a usability point of view I def agree with it. The approach to me seems pretty ok. We can def maintain the list of exceptions, and just not dupe the stacktrace.


Need applicable subscription details

Can we enable account lock feature with free subscription or do we need premium
This page should tell us that

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2b526157-3403-0211-9fda-9072bda47466
Version Independent ID: f0ab253a-616c-b1ae-62ba-45f6500e69dd
Content: Manage threats to resources and data - Azure AD B2C
Content Source: articles/active-directory-b2c/threat-management.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

@Akshat59
Thanks for your feedback! We will investigate and update as appropriate.

@Ashkat59 Good question and thanks for the feedback! It is on for everyone already, regardless of license. This is documented in the Azure AD page but not this B2C page. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout
I made a pull request to add this to the document. https://github.com/MicrosoftDocs/azure-docs-pr/pull/158669
@msmimart please review.
Hope this helps!


tsconfig.json with comments not supported

When a tsconfig file contains comments it cannot be parsed by this plugin.
Could you maybe add some regex to strip all the comments before parsing?

Makes sense. Added here: https://github.com/smacker/esbuild-plugin-ts-references/commit/d98f86ee450cc4632b503b869db6cbdfb9eae890


Make prost a no_std compatible library, and prost-build able to gen…

…erate no_std code
The alternative is to get collections types from core and alloc.
In the no_std mode in prost_build, we force it to always use BTreeMap
since HashMap was not stabilized in alloc::collections library.
The functionality is identical and the only incompatibilities in the interface
are that we cannot use std::error::Error or std::io::Error in no_std mode
because these types have not been moved to alloc and there is no alternative.

Hi -- would love feedback on this experimental patch.
Are you guys interested in supporting no_std in this way?
I believe that this patch is not a breaking change, and it would help us a lot to be able to use prost in a no_std environment.
We are currently using serde and rmp but it is very painful, we have to patch rmp extensively because it uses std::io::Read and std::io::Write traits and there is seemingly no well-maintained core-only analogue of these. Your decision to base prost on bytes makes it very easy to port it to no_std environment. Now that alloc is stabilized the bytes crate can easily be made #![no_std] and just pull the buffer types it needs from alloc.

Hi @danburkert I realized that the tokio/bytes crate actually currently does implement some std::io traits that don't have analogues in core. You aren't using any of that so that won't make this patch invalid, but this PR is premature until there is a feature to turn that stuff off in bytes.

fyi: our no_std patch in bytes crate got merged today, so hopefully after forthcoming bytes 0.5 release we can revive this PR
https://github.com/tokio-rs/bytes/pull/281
one thing worth mentioning is, in discussion in that PR, bytes 0.5 is expected to have an MSRV of rust 1.36. Is that going to be okay with prost, or would that be a blocking issue for prost upreving its version of bytes?

I'm fine with bumping the MSRV to 1.36; I consider both that and moving to a new breaking change of bytes to be a breaking change for prost, but that's no big deal.  My sense is the community has just recently moved from 1.32 to 1.36 as a standard version (and I expect everyone will rapidly move to 1.39 as soon as it's released).

@danburkert so one thing worth noting is, bytes 0.5 removed the IntoBuf trait in favor of adding a to_bytes method in Buf which does something related: https://github.com/tokio-rs/bytes/pulls?q=is%3Apr+is%3Aclosed
that's going to require some changes in prost because prost was using IntoBuf for some reason
It's not actually clear to me why prost was using this trait
Would you like to see a separate PR that gets rid of IntoBuf and gets us building against bytes 0.5 first, or are you okay with one big PR that does that and no_std in prost ?

@danburkert so one thing worth noting is, bytes 0.5 removed the IntoBuf trait in favor of adding a to_bytes method in Buf which does something related: tokio-rs/bytes#288

That's interesting.  I can't tell from that PR or the linked issue what the motivation there is.  If I recall correctly, the Message trait takes IntoBuf instances instead of Buf so that you can pass in types which impl IntoBuf and not Buf, notably &[u8] and &Vec<u8>.  All in all it's a much more ergonomic API that way.  I can't tell from that PR what the proposed equivalent in 0.5 is.

I think &[u8] does implement Buf now, and they've made it so that when you advance the slice, it drops one bytes off the front:
https://github.com/DoumanAsh/bytes/blob/300ca5d0933f970ae94a64674a6ce0e7590d1a3b/src/buf/buf.rs#L945
I think treating slice this way as Buf may be more efficient than using IntoBuf because IIUC IntoBuf would usually allocate a new Bytes object which might be an unnecessary allocation, maybe I'm missing something though

Gotcha.  It appears that's only the case of the 0.5.x branch, in which case I think you'll be forced to make the change inline with this PR.  The tests pass &[u8] to these APIs pretty pervasively, and I'd prefer not to switch all those over to something like Bytes.

yeah so what I'm finding is &[u8] works directly, and when passing reference to Vec<u8> I just do something like &v[..] to coerce it to &[u8] and then it builds.

@danburkert I'm considering the following possible resolution which would change prost-derive from how I currently did it:
In current master, the "dummy const" code in prost-derive looks like this:
After my most recent commit, it looks like this:
    let expanded = quote! {
        #[allow(non_snake_case, unused_attributes)]
        const #dummy_const: () = {
            extern crate prost as _prost;
            use _prost::_bytes;

I'm considering whether a good solution is:
    let expanded = quote! {
        #[allow(non_snake_case, unused_attributes)]
        const #dummy_const: () = {
            extern crate prost as _prost;
            use _prost::_bytes;
            extern crate core as _core;
            extern crate alloc as _alloc;

and then prost-derive would unconditionally emit names like _alloc::vec::Vec and _core::option::Option etc. And only in the cash of hash_map would it use std::collections::HashMap. prost-derive would not have cfg features after this.
I think this achieves the goal that users of prost who upgrade from previous version don't need to add extern crate alloc everywhere, and prost-derive doesn't require an std flag (which appears not to work AFAICT). And since alloc is stable after 1.36 we don't need the nightly compiler for this, if we bump MSRV to the same compiler version as bytes 0.5.
LMK if this sounds good to you -- I will think about it a bit more, maybe I'm missing a simpler way. But I think this would resolve the concern I posted earlier yesterday.

Any news on this? Would love to see it get merged!
Thank you!

I fixed all of the merge conflicts, you can decide whether to merge https://github.com/cbeck88/prost/pull/1 or https://github.com/danburkert/prost/pull/286

@dflemstr so I guess what I was hoping was that after alloc crate is stable, we don't need to use alloc attributes in the proc macro, we can just always refer to alloc for things that live in alloc. Maybe there's a reason I'm wrong. I'm going to try iterating in that direction. If you guys all decide you prefer to make the alloc attributes a requirement for the users, then you should merge #286 without changes I think

@danburkert ^

@dflemstr I'm starting to come around to your way of doing things, I'm going to try adding alloc attributes as appropriate in our project and see how that goes

@dflemstr I guess I'm going to think about it some more tomorrow

@danburkert I think that you are right, that we can make this require no "std vs. alloc" configuration.
I'm going to try to work through that in prost-derive, see how that goes, and see if I can get it to build against our project. Then I think I will go back and try to remove the "alloc collections lib" stuff from prost-build as well. I agree that we should avoid cargo features / configuration options and just do the right thing now that we are on the new rust MSRV. When I think I've got the simplest possible thing I will ping you again.

Sounds great, that's exactly what I had in mind.  Thanks @cbeck88!

Our project is building and passing tests against prost at this revision
I'm going to go back now and try to address review comments, and remove any remaining config interface for std vs. alloc from the prost-build crate

@danburkert okay, I think I've made as much progress as I can :)
Let me know what you think about the tests-alloc stuff. I'm not sure if it's actually a very good test, one way to strengthen the test may be to like, explicitly declare a panic handler or something, that would cause the build to actually fail if std is being subtly linked in.
I don't want to create test infrastructure that you aren't interested in carrying. At this point the alloc vs. std stuff is not actually a separate "mode" of prost-derive or prost-build, so I'm not sure if it really needs like super rigorous coverage in that sense -- it's up to you.
It is annoyingly difficult in rust to make a good test of whether your supposedly no_std crate configuration is actually no_std.
Anyways I think I addressed your comments, lmk if you see any more problems or want any other changes. Thanks!

@danburkert it appears to me that linux builds passed, but OS X builds failed, unable to find the ninja build tool. so maybe something is wrong with how .travis.yml is installing ninja using homebrew? not sure, I don't think I broke that:
error: failed to run custom build command for `protobuf v0.0.0 (/Users/travis/build/danburkert/prost/protobuf)`
Caused by:
  process didn't exit successfully: `/Users/travis/build/danburkert/prost/target/debug/build/protobuf-adbffe319d68f00a/build-script-build` (exit code: 101)
--- stdout
patching file cmake/conformance.cmake
-- Configuring incomplete, errors occurred!
See also "/Users/travis/build/danburkert/prost/target/debug/build/protobuf-b93b07f23ad48037/out/protobufU1xNFd/protobuf-3.11.2/CMakeFiles/CMakeOutput.log".
--- stderr
CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
thread 'main' panicked at 'protobuf CMake failed', protobuf/build.rs:174:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
The command "cargo build --verbose --all --exclude benchmarks" exited with 101.

@danburkert it appears to me that linux builds passed, but OS X builds failed, unable to find the ninja build tool. so maybe something is wrong with how .travis.yml is installing ninja using homebrew? not sure, I don't think I broke that:

Yeah, I don't think this is specific to this PR.  It's on my plate to look into that.

@danburkert I've reviewed what happened in tests crate in more detail -- it appears that during merge resolution, all upstream (prost) changes to tests were taken, and now tests-alloc and test-infra has no code-sharing purpose.
I'm going to push a commit that nukes both of those crates, then I think you should tell me what if any "alloc" configuration test coverage there should be and we'll develop that from the ground up as needed. It's possible that the answer is none because there are no additional configuration options now.

I removed leading :: in prost-types and prost-build, which allows to avoid extern crate alloc; in src/tests/lib.rs. However, I still can't get rid of it in protobuf, I think because of leading :: in prost-derive, but I'm not sure.
I had been under the impression that when using rust macros, identifiers outside of the macro e.g. to the standard library are supposed to be fully qualified, because macro expansion can occur at any possible scope, so you either use e.g. $crate:: or :: usually:
https://doc.rust-lang.org/reference/macros-by-example.html#hygiene
However maybe this doesn't actually apply for proc-macros? Since they are more like code-gen than macros?
I'm not totally sure, we're reaching the limits of my understanding of rust. I'm considering trying to remove :: in prost-derive as well, then trying to build against that in my project and see if it works. If so I think we might be able to remove any need for extern crate alloc; except in rust-2015 edition.
@tarcieri I suspect you might know this better than me :)

@cbeck88 yeah, it's probably safer to use absolute paths in that case so as to avoid clashing with other things that might be in local scope

but if i use absolute paths, does that mean that all prost users (even std users) must do like extern crate alloc; or else they get build errors like I did in protobuf crate?
error[E0433]: failed to resolve: could not find `alloc` in `{{root}}`
   --> /home/chris/prost/prost/target/debug/build/protobuf-0d3e1b26d91b17a5/out/protobuf_unittest.rs:911:30
    |
911 |     pub unpacked_sfixed64: ::alloc::vec::Vec<i64>,
    |                              ^^^^^ could not find `alloc` in `{{root}}`

error[E0433]: failed to resolve: could not find `alloc` in `{{root}}`
   --> /home/chris/prost/prost/target/debug/build/protobuf-0d3e1b26d91b17a5/out/protobuf_unittest.rs:913:27
    |
913 |     pub unpacked_float: ::alloc::vec::Vec<f32>,
    |                           ^^^^^ could not find `alloc` in `{{root}}`

IDK, I'm willing to try removing even the leading :: in prost-derive, and run that against our project, if that will make it nicer for prost users that don't care about no_std, but if there's some reason that removing those is definitely broken I'd prefer to spend my time doing that

You could re-export the types you need via prost

Ooh, that sounds good

Yeah I think that sounds reasonable.  See e.g. how bytes is now handled: https://github.com/danburkert/prost/blob/master/src/lib.rs#L82-L84

@danburkert i ran our project against this revision of prost and all tests are passing
lmk if you see anything you want to be different! thanks

could we merge this already? :P

Would love to see it merged as well!

Closing in favor of #319, which is simply this branch squashed, rebased over master, and with some cleanups applied.  Thanks again to @garbageslam and @dflemstr for iterating on this, and sorry it took so long for me to merge.  Your contributions are really appreciated.


401 on HEAD call resets file progress

Describe the bug
Due to weirdness with our reverse proxy we occasionally have http/2 or CORS exceptions returned while uploading a chunk (PATCH) instead of a 401.  On that failure it's retrying the HEAD request, receiving a 401 which then resets the file.  After re-authentication the file starts over rather than resuming.
Screenshot shows "Finished" just because of the HAR file but the original browser showed a CORS exception.

To Reproduce
Steps to reproduce the behavior:

Start a file upload and have more than 1 chunk upload
Encounter an exception on a chunk that results in a retry (network exception or disconnect during the next PATCH)
Receive a 401

Expected behavior
It looks like any 4XX response for the HEAD request removes the file from storage.  Can we check for 401/403 errors and exclude that from the logic at https://github.com/tus/tus-js-client/blob/master/lib/upload.js#L605

Setup details

Reproduced in Chrome and Edge
Used tus-js-client version: 2.2.0
Server is using tusdotnet with authentication

Instead, it would be good if TUS throws an authentication error and lets the user decide how they want to handle it.

Handling a 401 different than other 4XX status codes is not ideal in my opinion. I would prefer a more generic option, such as removeFingerprintOn4xx, which controls whether a 4xx response causes the fingerprint to be removed, similar to how we have removeFingerprintOnSuccess. You could then disable this setting, catch the error using onError and decide how to proceed. Does this make sense?

@Acconut Thanks for the suggestion. That would help.
For the argument's sake, I would still prefer having that control in the user's hand specifically for the authentication failure. TUS is very powerful for chunk uploads and resumeability. There are scenarios where user would work on the local copy and upload it in parallel. And also that they may want to do it across multiple browser sessions. So auth expiry is a common phenomenon. Letting the user authenticate and resume (instead of restarting the upload from the first byte) would reduce the pain by a bit IMHO.
Nevertheless, you are in a better situation to make a judgment on this. Thanks once again for agreeing to add the removeFingerprintOn4xx flag. :)

Restarting an upload should not be necessary. You can just resume the upload where it left off using start() again. The authentication credentials can be injected into the request header using onBeforeRequest, allowing you to check the lifetime of authentication tokens and obtain new ones if necessary. This might even be the better option for you.

Thanks @Acconut.


Rivera tf orb cmd updates to fix [semver:minor]

Updated the orb to handle state locally or by remote. The original orb schemes around local terraform workspaces were conflicting with the execution of TF code if a remote state backend such as Terraform cloud or AWS s3 are defined. I added a new parameter to act as a toggle flag that specifies if a user wants to use local or remote state backends.
@KyleTryon + @aedifex pls review and test my changes. I tested the orbs using live repos and the changes solved the issue I was experiencing.

@KyleTryon @aedifex working on a different solution to this. One that is not as extreme as the one I'm proposing.

@KyleTryon + @aedifex I reverted all of the local_state parameter changes I made in prev commits because it changed the orb too much. Instead I created a new usage example to show how to leverage the existing backend-config-file parameters which is the proper way to create remote backend state management per this TF doc https://www.terraform.io/docs/language/settings/backends/remote.html#using-cli-input
This is ready for review and I have tested all the changes on my test repo.


Fix: Setting control for TS01 when running outside challenge route

Check if control loss scenario is running independently or is a part of challenge route

Modified ChangeNoiseParameters behaviour, so that control is applied via behaviour  if not a part of challenge route.

Fix
Throttle and steering were not getting applied when we run TS01 outside challenge route
Where has this been tested?

Platform(s): Ubuntu 18.04
Python version(s): 3.5
CARLA version: 9.5

This change is

I close this PR for now. If we decide to come back to this update, we can just re-open it.


Bluetooth, cameras, wifi...

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
I would like to contact flutter developers. I hope you read github.
You are creating a cross-platform framework that should behave the same on all platforms and have common interaction mechanisms. Now there are more than 10 options for plugins for working with bluetooth on pub.dev. I believe that you, as developers of a cross-platform framework, are obliged to develop and make part of the framework all the basic mechanisms for working with such things as bluetooth, cameras, wifi, and the like, as is done for example in QT.
Proposal
I would like to contact flutter developers. I hope you read github.
You are creating a cross-platform framework that should behave the same on all platforms and have common interaction mechanisms. Now there are more than 10 options for plugins for working with bluetooth on pub.dev. I believe that you, as developers of a cross-platform framework, are obliged to develop and make part of the framework all the basic mechanisms for working with such things as bluetooth, cameras, wifi, and the like, as is done for example in QT.

I believe that you, as developers of a cross-platform framework, are obliged to develop

I would encourage you to read https://github.com/flutter/flutter/wiki/Issue-hygiene#when-will-my-bug-be-fixed, as the first paragraph discusses Flutter's development structure.

and make part of the framework all the basic mechanisms

While bundling every piece of functionality into the framework is a possible approach, it is not the one Flutter chooses to use. We believe that modular access to specific OS features via plugins provides a number of advantages.

such things as bluetooth, cameras, wifi, and the like

Bluetooth is tracked in https://github.com/flutter/flutter/issues/53493.
The Flutter team already maintains the camera plugin.
Wifi was previously a first-party plugin, but was migrated to the community-owned network_info_plus plugin; we have no plans to reverse that decision.

Closing as there is no specific feature request to track here. Please feel free to file individual issues for any other specific functionality you believe should be implemented.


in zone overrides for image resizing add option to control "resize images from any origin"

Current Terraform version
0.14.7
Description
currently when running overrides, I can enable the image resizing, but I cant control "resize images from any origin". when i add this manually in the UI, it gets reset after every run to not set
Use cases
we run the overrides few times a day as part of the zone refresh and not having this option requires manually going into UI to add this feature.
Potential Terraform configuration
no configuration exists
References
No response

hi @jacobbednarz , any plans to get this fixed?

this functionality is already available (added in #639) and v2.5.1. please see documentation at https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/zone_settings_override#image_resizing

@jacobbednarz I am referring to the option to "resize from any origin" which is not available, can you please reopen?

here is the image for the context.  I am referring to the checkmark below the on/off toggle

that is the option I've referenced above. see the documentation for examples and you can try it out for yourself.

I have tried and when i set this option with "on" it turns it on if it was off or unchecks this checkmark if it was on and had the
"resize images from any origin" checked.  which option on zone overrides would keep it on? is it "open"?


compose: Add clear button for topic name (Fixes #21464)

Created an x button to clear the topic name field of the compose box.  The button is only present when there is text in the box.
static/js/compose.js

Added update_topic_clear_button_display() which checks to see if the topic input box is empty to show/hide the clear button.
Added call to above function when focus is given to topic input
Added keyup listener inside the topic input to call above function
Added click listener for clear button

static/js/compose_actions.js

Added a few lines to unhide the clear button when the compose box is closed. Otherwise clearing the box, then closing the compose box and reopening it resulted in the button remaining hidden.

compose.css

Added padding to make sure text doesn't overflow into the clear button
Added selector to adjust width/padding when empty class is applied. This keeps the box from changing sizes when the button is shown/hidden.
Default padding was causing the box to be unstable and change size when hiding/showing the button. So I overrode it.

Fixes: #21464

Screenshots and screen captures:
Empty Input Box

Full Input Box

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Thanks for working on this! I noticed one situation where the x doesn't appear (and should):

Clear the topic with x. The x disappears.
Click on a topic in the left sidebar, which immediately populates the topic in the compose box.

Expected: x should appear immediately
Actual: x appears only when you click into the topic field

@alya good catch, I just updated the PR.

@riedldsr  Would you be up for posting a GIF demonstrating that the behavior has been fixed? Thanks!

Closing, since https://github.com/zulip/zulip/issues/21464 was closed a few months ago as a stale plan.


Pretty much allow any form src

Apparently the behaviour when forms get redirected is inconsistent between browsers - but OIDC works by literally redirecting forms until it gets to the institute login. So this seems to work fine locally but then is failing when deployed.
Am trying here with a very broad approval of anything that is https


k3d docs are missing details about the GitHub & GitLab token permissions

What type of suggestions?
Missing Information
What page is concerned?
https://docs.kubefirst.io/k3d/quick-start/install/?git_provider#github
What version of the docs?
2.4
What is the issue?
k3d docs is missing details about the GitHub & GitLab tokens permissions, and GitLab prerequisites doesn't even mention it.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Actually, it's there, but the k3d install page need a serious revamp as it's all over the place.


Two separate panels

I would like to able to have two separate panels open (in addition to the sidebar), one at the bottom and one at the right side.
Why would I need this? I would move the integrated terminal to the bottom since sometimes it outputs long text lines which get a lot of line breaks when it's on the side since then panel is too narrow. Expanding the panel all the time is a bit annoying. If I could move the terminal to the bottom, it gets the space to get much wider and less line breaks are required. In addition to that I would like to keep open a few other panes which then I could put into the second panel at the right.

Looks like duplicate of #26777

Ah, you are right. Didn't find it before. While the initial request in that issue is kinda already possible by having the sidebar and the panel, the later suggestion especially https://github.com/microsoft/vscode/issues/26777#issuecomment-576998706 is what I'm looking for. Three places to attach stuff to (left, right and bottom).