Refactor oldLayer in SceneBuilder.push* to take an opaque key

Today, SceneBuilder.push* takes an EngineLayer as the oldLayer property. It also takes this type for addRetained. However, unlike addRetained, the oldLayer property can really just be a unique identifier for a Layer without actually retaining it. On the VM implementation, this is already the case (with an edge case about MergedContainerLayer that should be trivial to fix). On the web implementation we can make it so.
Doing this would allow for clearer static analysis about when an object is safe to use for push* and addRetained, since a disposed EngineLayer cannot be used for addRetained but you might still want to refer to its ID in push*.
This would be an API break, but likely only to impact the framework itself.
/cc @knopp @flar @yjbanov

Related to https://github.com/flutter/flutter/issues/81514

With DiffContext we need the original layer ID as well as a way to tell if the properties have changed and which children are old/new/moved. How can this be wrapped up into only tracking a single ID?
Note that we retain the original ID even if the layer's properties change because the layer is both a set of properties and a node in the tree. Properties can change and children can come and go and the layer can move within the tree and all of those issues are tracked relatively independently via the DiffContext.
Another fly in this ointment is that the property comparisons in DiffContext can be against frame N-1, or N-2, or N-k. We won't know until the Rasterizer thread gets around to rendering the layer how much older the original data is. Carrying along an "I had different properties than my previous frame" flag isn't enough to tell if that layer is different compared to the N-5th frame. You could perhaps include a Frame ID that represents "my properties have been stable since Frame ID #n" and thus we could tell if the properties changed between N and N-k, but tracking which children moved and when they moved would be much harder.

All of the oldLayer usages in the engine just rely on grabbing the ID from the layer, e.g. https://github.com/flutter/engine/blob/master/lib/ui/compositing/scene_builder.cc#L103 which does https://github.com/flutter/engine/blob/master/flow/layers/layer.h#L89 (except on MergedContainerLayers).
The assumption here is that if the engine needs that layer it will be keeping it around. We won't rely on the framework to keep it around or not. It really doesn't matter if that was from the last frame or 1000 frames ago, as long as the engine knows how to get to that layer from the ID.

With DiffContext we need the original layer ID as well as a way to tell if the properties have changed and which children are old/new/moved. How can this be wrapped up into only tracking a single ID?
Note that we retain the original ID even if the layer's properties change because the layer is both a set of properties and a node in the tree. Properties can change and children can come and go and the layer can move within the tree and all of those issues are tracked relatively independently via the DiffContext.
Another fly in this ointment is that the property comparisons in DiffContext can be against frame N-1, or N-2, or N-k. We won't know until the Rasterizer thread gets around to rendering the layer how much older the original data is. Carrying along an "I had different properties than my previous frame" flag isn't enough to tell if that layer is different compared to the N-5th frame. You could perhaps include a Frame ID that represents "my properties have been stable since Frame ID #n" and thus we could tell if the properties changed between N and N-k, but tracking which children moved and when they moved would be much harder.

For diff context, we only diff with last_layer_tree_ (which is the last successfully rendered layer tree). The N-1, N-2, ... diffs are accumulations. The area where current target framebuffer lags behind the front buffer is simply passed to diff context as additional_damage. During diffing we always compare layer instances, but the source for the old layer being compared is last_layer_tree_ (the comparison starts by comparing current tree and last tree root layer). For layers themselves all we need it original_layer_id_ so that diff context knows during the comparison that both layers are part of same layer "chain" and thus are of same type and can be compared (meaning new layer has replaced old layer at framework level).

The assumption here is that if the engine needs that layer it will be keeping it around. We won't rely on the framework to keep it around or not. It really doesn't matter if that was from the last frame or 1000 frames ago, as long as the engine knows how to get to that layer from the ID.

That seems correct, at least as far as diff context is concerned. Also MergedContainerLayer can be fixed to not require layer instance.

With DiffContext we need the original layer ID as well as a way to tell if the properties have changed and which children are old/new/moved. How can this be wrapped up into only tracking a single ID?
Note that we retain the original ID even if the layer's properties change because the layer is both a set of properties and a node in the tree. Properties can change and children can come and go and the layer can move within the tree and all of those issues are tracked relatively independently via the DiffContext.
Another fly in this ointment is that the property comparisons in DiffContext can be against frame N-1, or N-2, or N-k. We won't know until the Rasterizer thread gets around to rendering the layer how much older the original data is. Carrying along an "I had different properties than my previous frame" flag isn't enough to tell if that layer is different compared to the N-5th frame. You could perhaps include a Frame ID that represents "my properties have been stable since Frame ID #n" and thus we could tell if the properties changed between N and N-k, but tracking which children moved and when they moved would be much harder.

For diff context, we only diff with last_layer_tree_ (which is the last successfully rendered layer tree). The N-1, N-2, ... diffs are accumulations. The area where current target framebuffer lags behind the front buffer is simply passed to diff context as additional_damage. During diffing we always compare layer instances, but the source for the old layer being compared is last_layer_tree_ (the comparison starts by comparing current tree and last tree root layer). For layers themselves all we need it original_layer_id_ so that diff context knows during the comparison that both layers are part of same layer "chain" and thus are of same type and can be compared (meaning new layer has replaced old layer at framework level).

Respectfully, this is wrong. Framework generated trees are not 1:1 with engine rasterized trees.
last_layer_tree may be the last rendered, but it wasn't the last generated.
The issue here is that the framework knows what it generated, but it doesn't know what was rendered. As such, from the framework's perspective, what we think is "rasterized N-1" is actually "generated N-???>=1".
So, the framework could happily tell us that a given frame had no changes (in a given subtree) since the "last frame", but that has no bearing at all with what the engine needs to know.

@flar - the framework would be getting these LayerKey objects from the engine. E.g., EngineLayer would have a layerKey getter, which the framework could copy out and then reuse in oldLayer. All of this would be engine driven, not framework driven.
That makes a difference, right?

@flar - the framework would be getting these LayerKey objects from the engine. E.g., EngineLayer would have a layerKey getter, which the framework could copy out and then reuse in oldLayer. All of this would be engine driven, not framework driven.
That makes a difference, right?

Makes a difference for what?
Regardless of where the keys come from, the framework cannot answer "what was the last tree rendered" because there is no way to know that when it generates a frame - that information is sometimes known when the rasterizer thread catches up, but when it is behind, that information comes from the future and cannot be known.

The framework doesn't need to know what the last tree rendered was.
I have a feeling we're mixing up problem spaces here...
Today, the framework makes an API call that involves passing an EngineLayer to the native side. The engine then uses this to fish out an ID from that layer. The proposal here is to have the framework pass in that ID instead of the EngineLayer.
For this particular issue, it really doesn't matter where the rasterizer is or what the last frame is - it's meant to be a refactoring of code so that static analysis can do a better job and developers (e.g. me when I refactor framework code) won't worry about whether they're using an object that looks disposed correctly or not.

Respectfully, this is wrong. Framework generated trees are not 1:1 with engine rasterized trees.
last_layer_tree may be the last rendered, but it wasn't the last generated.
The issue here is that the framework knows what it generated, but it doesn't know what was rendered. As such, from the framework's perspective, what we think is "rasterized N-1" is actually "generated N-???>=1".
So, the framework could happily tell us that a given frame had no changes (in a given subtree) since the "last frame", but that has no bearing at all with what the engine needs to know.

During rasterization we have last_layer_tree_, which is last successfully rasterized layer tree, and let's call it current_layer_tree_, which is the layer tree that we're rasterizing now, and if rasterized successfully it will become last_layer_tree_. These are the trees relevant for diff context. It doesn't matter if framework produced another tree before  that got discarded. Or if current layer tree fails to rasterize and gets discarded.
We always diff the currently rasterized layer tree against last_layer_tree_, which is the tree that produced current front buffer. If current rasterization fails and framework produces another tree, the last_layer_tree_ doesn't change.
So yes, we may be diffing N-2 tree with N, but given that original_layer_id_ is same all the way to the original layer that started the chain, that doesn't really matter. Diffing should work as expected.

I think I have a clearer picture of the proposal now. The engine would still be keeping old trees around, but the association via the pushLayer mechanism would be by ID rather than by pointer. The engine would still have the old layer around "somewhere", but it would have to find it. It could then do the property and child diffs easily enough, but the issue is finding the old layers since they can move around in the tree.
So, with the addition of a map in the layer_tree to allow finding layers (primarily it could start with the assumption that the layers are likely in the same hierarchy and then fall back to the map when that fails), then the code would largely be unchanged from today.
Sorry if I was missing these details...

Respectfully, this is wrong. Framework generated trees are not 1:1 with engine rasterized trees.
last_layer_tree may be the last rendered, but it wasn't the last generated.
The issue here is that the framework knows what it generated, but it doesn't know what was rendered. As such, from the framework's perspective, what we think is "rasterized N-1" is actually "generated N-???>=1".
So, the framework could happily tell us that a given frame had no changes (in a given subtree) since the "last frame", but that has no bearing at all with what the engine needs to know.

During rasterization we have last_layer_tree_, which is last successfully rasterized layer tree, and let's call it current_layer_tree_, which is the layer tree that we're rasterizing now, and if rasterized successfully it will become last_layer_tree_. These are the trees relevant for diff context. It doesn't matter if framework produced another tree before that got discarded. Or if current layer tree fails to rasterize and gets discarded.
We always diff the currently rasterized layer tree against last_layer_tree_, which is the tree that produced current front buffer. If current rasterization fails and framework produces another tree, the last_layer_tree_ doesn't change.
So yes, we may be diffing N-2 tree with N, but given that original_layer_id_ is same all the way to the original layer that started the chain, that doesn't really matter. Diffing should work as expected.

I can see that now - the info for the diff would come from the old layer trees just as it does today, but we'd still need a way to find the old layers to do the diff against and since they can move around and we don't know which native tree to look in when we are constructing them, the search would have to be done at diff-time. Most. layers would have the same ID as their corresponding layer in the older tree, but some may have moved and we need to find them again.

And, thinking further, if a layer does move within the tree then that would probably be best handled as if it was new/deleted in the 2 places, so the search wouldn't really be useful anyway.

I can see that now - the info for the diff would come from the old layer trees just as it does today, but we'd still need a way to find the old layers to do the diff against and since they can move around and we don't know which native tree to look in when we are constructing them, the search would have to be done at diff-time. Most layers would have the same ID as their corresponding layer in the older tree, but some may have moved and we need to find them again.

Fortunately that is not necessary. The diffing works quite similarly to how flutter diffs element trees. It starts with top level containers from both trees and then goes there, for as long as the children can be matched. See ContainerLayer::DiffChildren. This is of course not perfect, when you reparent a layer it will be treated as if it was removed and added to different spot, but that's not necessarily a fault here, since in that case it needs to be repainted anyway.

And reviewing the current implementation, it looks like this is what is already happening anyway. We are only using "oldLayer" as a complicated holder for the ID that we carry forward. The native code doesn't really do anything else with it. The diffs aren't against the "oldLayer" that came from the framework anyway.

And reviewing the current implementation, it looks like this is what is already happening anyway. We are only using "oldLayer" as a complicated holder for the ID that we carry forward. The native code doesn't really do anything else with it. The diffs aren't against the "oldLayer" that came from the framework anyway.

That's exactly what's going on (apart from the minor exception for MergedContainerLayer). In earlier implementations instead of original_layer_id_ the layers actually stored weak reference to the layer itself. But given that it wasn't really used during diffing, it was completely unnecessary. I think it might have been you suggesting the original_layer_id_ approach instead :) (it was a while back).

Right now we are choosing the layer->unique_id() for this tracking, but really all we need is a unique tag number. It should be possible for the framework to generate these rather than asking the engine for the number. The unique_id is used both for the layer cache and to associate layers between generations, but both uses are independent.
While it might be historically accurate and nostalgic that the "original layer id" was, in fact, once the actual unique_id of an engine layer, really all that matters is that they compare == when the layer is standing in for a previous layer. The actual number used to confirm this doesn't actually need to be a native unique_id.
It might be easier to just pass the unique_id back from the native push methods, but I don't think the solution would require reusing that number if it isn't convenient.

Right now we are choosing the layer->unique_id() for this tracking, but really all we need is a unique tag number. It should be possible for the framework to generate these rather than asking the engine for the number. The unique_id is used both for the layer cache and to associate layers between generations, but both uses are independent.
While it might be historically accurate and nostalgic that the "original layer id" was, in fact, once the actual unique_id of an engine layer, really all that matters is that they compare == when the layer is standing in for a previous layer. The actual number used to confirm this doesn't actually need to be a native unique_id.
It might be easier to just pass the unique_id back from the native push methods, but I don't think the solution would require reusing that number if it isn't convenient.

This sounds good. In most places where framework keeps engineLayer around just so that it can provide it to SceneBuilder.pushXXX it could just generate and store unique id.


Expected error or warning when attempting route with null or invalid page

Ran into this one pretty quick, I had a typo in the page attribute in my routes file and the log didn't give any warning that the router was unable to find a valid page class at that filesystem location.
Log output:
2016-04-19T22:05:36.031Z - debug: [react-server.core.context.Navigator] Navigating to /home
Route:
routes: {
	Test: {
		path: ["/home"],
		page: "./pages/Hone"
	},
}

Note: it should be "Home" not home, as the page class is at ./pages/Home.js
I expected some sort of warning here in the log, particularly when not running in prod mode.

Related to #95.  Also addressed by #80.

Just landed #80.


[zh] sync tools\kubeadm\install-kubeadm.md

The file tools\kubeadm\install-kubeadm.md has been updated in this PR (https://github.com/kubernetes/website/pull/42156) ,so we will synchronize the localization.
EN upstream: content\en\docs\setup\production-environment\tools\kubeadm\install-kubeadm.md
Sync to: content\zh-cn\docs\setup\production-environment\tools\kubeadm\install-kubeadm.md

/open


Augmented output for config.around(:suite)

I am working on a coverage tool for RSpec. I want to report coverage errors as part of RSpec.
Is there some way I can hook into the RSpec output formatting?
Is there documentation regarding this?
Something like this:
config.before(suite) do
    coverage.enable
end

config.after(:suite) do
    coverage.disable
    statistics = coverage.statistics
    # log coverage issues, perhaps calling something like this
    expect(statistics).to be_complete
    # or doing it per-file?
end

I want to report coverage errors as part of RSpec.

What is a coverage error?  I've never heard that term before.

Is there some way I can hook into the RSpec output formatting?

The standard way to hook into output formatting is to write a custom formatter.  You have complete control over it.

Is there documentation regarding this?

https://relishapp.com/rspec/rspec-core/v/3-7/docs/formatters/custom-formatters
http://rspec.info/documentation/3.7/rspec-core/RSpec/Core/Formatters/Protocol.html

Something like this:

I don't understand the snippet.

Around hooks have to yield control at some point--where is that happening in your example?
What does coverage.finish do?
What are the semantics of statistics.complete?

Ah my bad it should have been after not around :) I will check the links thanks

What is a coverage error? I've never heard that term before.

So, a coverage error would be an error because the coverage wasn't good enough. The way I'm thinking about it right now is a user specified threshold, i.e. 80% coverage minimum. When test coverage falls below that, the test suite will fail due to a coverage error.
statistics.complete? just means that coverage was 100%. It's an example. There might be a better way of doing this.
So, I'm not after changing the format of the output, but I'm interested in generating a pseudo-spec which executes and generates said output.
I guess what I need to do is get the current formatter, and then interact with it like a spec. Is this reasonable?

So, here is what I got so far:
Covered::Wrapper
  passes #mark through
  passes #enable through
  passes #disable through
  passes #each through
* 9 files checked; 184/184 lines executed; 100.0% covered.

An error occurred in an `after(:suite)` hook.
Failure/Error: expect(statistics).to_not be_complete
  expected `#<Covered::Statistics:0x00007fd8761e8240 @count=9, @executable_count=184, @executed_count=184>.complete?` to return false, got true
# ./lib/covered/rspec.rb:41:in `block (2 levels) in <top (required)>'

It's not bad, I can customise the expectation error message, which should be okay.
What I want is a way to give informal output before the errors. Is that possible?
Finally, in the case that there is a coverage error, I want to do my own terminal highlighting. Essentially, I want to print out the code in question, covered lines green and failed lines red. I already have that working, but not via RSpec.

Hmm, so just to finish off tonight, here is the successful output:

Here is failed output:

Basically, I'd like to make the formatting as awesome as possible and integrate really well with RSpec. Maybe that's not possible, but hopefully you can see what I'm trying to achieve.

The other option is I just use an at_exit hook (ugh) and do everything after rspec finished. But, I'd rather have awesome integration.

Thanks for the detail; now I'm closer to understanding what you're trying to achieve.
I think the simplest way to achieve what you're looking for is to register a custom formatter and handle the start_dump notification.  That exists for cases like your where you want to produce some extra output between the test suite finishing and the printing of all the failures and the summary.

Okay, I've almost got this working how I want. Is there some way to cause RSpec to fail with an error form start_dump? One option is just to call exit, but is there a better approach?

You can use RSpec.configuration.reporter.notify_non_example_exception:
https://github.com/rspec/rspec-core/blob/v3.7.1/lib/rspec/core/reporter.rb#L156-L167
Note that it's not part of our public API, though; if you want to call it, let us know and we can declare it public.
Simplecov just calls exit, so that might not be so bad, though:
https://github.com/colszowka/simplecov/blob/994dbff2780abe420f63036a7f674c296395b6c0/lib/simplecov.rb#L206

Here is what I have:

Ideally, I can bump the failure count up by one some how, e.g.
35 examples, 0 failures, x coverage errors

RSpec.configuration.reporter.notify_non_example_exception sort of works, but it forces me to use an exception.
I wonder if it's possible to append some failure state, e.g.
module Covered
	module RSpec
		class Formatter
			::RSpec::Core::Formatters.register self, :dump_summary

			def initialize(output)
				@output = output
			end

			def dump_summary notification
				@output << $/

				$covered.print_summary(@output)

				notification.failure("x coverage issues")
			end
		end
	end
end

the key point being notification.failure to feed information back.

One more thing - is there any way to tell if the full test suite is being run vs only a subset?

RSpec.configuration.reporter.notify_non_example_exception sort of works, but it forces me to use an exception.

You can print anything you want to the console, so if that doesn't meet your needs print whatever does meet your needs.

One more thing - is there any way to tell if the full test suite is being run vs only a subset?

Nothing built in to RSpec.
I'm going to close this as there's nothing actionable for us do to change RSpec here.

Fair enough :) Thanks for your help.
Is there any other way to bump the failure count, other than RSpec.configuration.reporter.notify_non_example_exception?

Is there some way just to say "something failed"?

puts "something failed"

To bump up the failure count you need to define an example that is run, and fails, to exit non zero you simply need to cause an exception. If you raise an error with no back trace, no back trace would be printed.


Improved subtitles and last step

title of last step can be change via builder
subtitle of certain steps can be added, changed and removed (after form is created)
added optional second button in last step

Sorry about this, but I am afraid I will have to close this PR, as it is going to be impossible to merge it after the massive refactoring that the library has undergone recently. This project has been abandoned for a long time, and now that I have finally had the time to go back to it, the changes I have made to update it have been deeper than I anticipated.
Luckily, though, this feature is now available in the new version library, because currently all the subtitles can be updated in runtime by calling a simple method, and also there is an optional cancellation button that can be added to the last step.
In any case, thank you very much for your collaboration and apologies for the delay in my response!


Added new rebus hairbrush

Associated Issue: #121
Summary of Changes

Added a rebus - Hairbrush

Thanks! 👍


Suppress warnings for unsafe cert

Hi, when using untrusted cert, we get a lot of warnings
/opt/bookstack-venv/lib/python3.12/site-packages/urllib3/connectionpool.py:1099: InsecureRequestWarning: Unverified HTTPS request is being made to host 'docs.redacted.org'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#tls-warnings
i added some suppression to make the output of the log readable.
vim /opt/bookstack-venv/lib/python3.12/site-packages/bookstack_file_exporter/common/util.py
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

when we configure to be insecure means we know the risk. so it makes sense to me to suppress them by code
what do you think?

I think this is something that can be incorporated. I will take a look and get to you on this


Extendable GitHub w/ interface

Continuation of https://github.com/tinacms/tinacms/pull/1950
I forgot to update the Bridge interface (and other backends) to use methods instead of props, so that they can be overridden.

@jamespohalloran Looks good to me. It looks like there is a danger issue and it looks like the build is stuck. I am guessing neither one of these is because of this PR. Maybe you need to update the branch to reflect the current main? We have been doing some changes around our CI builds. I am guessing this branch got caught in a weird state.


MINOR: remove unnecessary #remove overrides

Iterator#remove has a default implementation that throws UnsupportedOperatorException so there's no need to override it with the same thing.
Should be cherry-picked back to whenever we switched to Java 8

@mjsax @guozhangwang @vvcephei @cadonna @abbccdda

I think you missed RocksDBDualCFIterator within RocksDBTimestampedStore.

I did, thanks for catching. Pretty sure that should be all of them (or IDEA is lying to me)

Java 11/12 and Java 11/13 passed, Java 8 failed with
org.apache.kafka.connect.integration.ErrorHandlingIntegrationTest.testSkipRetryAndDLQWithHeaders
kafka.api.SaslClientsWithInvalidCredentialsTest.testManualAssignmentConsumerWithAuthenticationFailure
kafka.api.SaslSslAdminClientIntegrationTest.testIncrementalAlterConfigsForLog4jLogLevels
kafka.api.SaslSslAdminClientIntegrationTest.testIncrementalAlterConfigsForLog4jLogLevelsCanResetLoggerToCurrentRoot
retest this please


Model name "object" throws error

Sails v 0.11.0
Just started with Sails and got the following error, took me a while to figure out its probably the api name that is causing it. I can run with other names just not "object"
sails new testproj
    info: Created a new Sails app `testproj`!
cd testproj/
sails generate api object
    info: Created a new api!
sails lift

module.js:161
  var exts = Object.keys(Module._extensions);
                    ^
TypeError: Object #<bound> has no method 'keys'
    at Function.Module._findPath (module.js:161:21)
    at Function.Module._resolveFilename (module.js:336:25)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Function.load [as cookieParser] (/usr/lib/node_modules/sails/node_modules/express/node_modules/connect/lib/connect.js:97:27)
    at /usr/lib/node_modules/sails/lib/router/index.js:109:39
    at /usr/lib/node_modules/sails/lib/app/private/after.js:91:14
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:251:17
    at done (/usr/lib/node_modules/sails/node_modules/async/lib/async.js:132:19)
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:32:16
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:248:21
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:572:34
    at handlerFn (/usr/lib/node_modules/sails/lib/app/private/after.js:78:13)
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:567:21
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:246:17

Found another word: string
sails generate api string

util.js:35
  var str = String(f).replace(formatRegExp, function(x) {
            ^
TypeError: Property 'String' of object #<Object> is not a function
    at exports.format (util.js:35:13)
    at bound (/usr/lib/node_modules/sails/node_modules/lodash/dist/lodash.js:957:21)
    at eachController (/usr/lib/node_modules/sails/lib/hooks/blueprints/index.js:330:24)
    at forOwn (/usr/lib/node_modules/sails/node_modules/lodash/dist/lodash.js:2106:15)
    at Function.forEach (/usr/lib/node_modules/sails/node_modules/lodash/dist/lodash.js:3303:9)
    at Hook.bindShadowRoutes (/usr/lib/node_modules/sails/lib/hooks/blueprints/index.js:172:9)
    at bound (/usr/lib/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21)
    at /usr/lib/node_modules/sails/lib/app/private/after.js:91:14
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:251:17
    at done (/usr/lib/node_modules/sails/node_modules/async/lib/async.js:132:19)
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:32:16
    at /usr/lib/node_modules/sails/node_modules/async/lib/async.js:248:21
    at Sails.<anonymous> (/usr/lib/node_modules/sails/node_modules/async/lib/async.js:572:34)
    at Sails.g (events.js:180:16)
    at Sails.EventEmitter.emit (events.js:117:20)
    at Sails.emitter.emit (/usr/lib/node_modules/sails/lib/app/private/after.js:50:11)

@osteenbergen As far as I know, by default sails is putting models, services, etc in the global namespace.  So if the name of your model is a reserved word (like Object, String, etc), it will literally rewrite that reserved word with whatever the model is.
Try setting the options in config/global.js to false.
IMO, sails should have them default to false.  Even though it is convenient to have models and such in the global namespace, it is a bad practice which sails shouldn't encourage.

Yep, imho those globals should be false by default.

I thought so, but i just renamed my model. Putting things in the global namespace should be discouraged.

I thought so, but i just renamed my model. Putting things in the global namespace should be discouraged.

Calling a domain model string is only slightly less weird than calling it constructor or prototype. So then we'd have complains about sails.models.prototype being really confusing.
When you start naming stuff after reserved words in the language, there's just no way to win.


Field reference operator only works on qualified name references with a single level

Desc table schema.
presto:test_db> desc test_orc_table;
Column    |                                                                       Type                                                                        | Null | Partitio
-------------+---------------------------------------------------------------------------------------------------------------------------------------------------+------+---------
uid         | varchar                                                                                | true | false
information | ROW(Optional[name] varchar, Optional[gender] varchar, Optional[education] ROW(Optional[primary_school] varchar, Optional[middle_school] varchar)) | true | false
(2 rows)

Query Success.
presto:test_db> select uid, information from test_orc_table limit 3;
uid   |                                                        information
---------+----------------------------------------------------------------------------------------------------------------------------
100 | {name=Jack, gender=Male, education={primary_school=xx1, middle_school=xx2}}
101 | {name=Lisa, gender=Female, education={primary_school=xx1, middle_school=xx2}}
102 | {name=Todd, gender=Male, education={primary_school=xx1, middle_school=xx2}}
(5 rows)

Query Success.
presto:test_db> select uid, information.name from test_orc_table limit 3;
uid   |                   name
---------+------------------------------------------
100 | Jack
101 | Lisa
102 | Todd
(3 rows)

Query Failed.
presto:test_db> select uid, information.education.primary_school from test_orc_table limit 3;
Query 20140218_071429_00114_cqskj failed: Column 'information.education.primary_school' cannot be resolved

This is a known issue with the way the field reference operator is implemented. It's super hacky right now. It looks like the issue is in ExpressionAnalyzer.tryVisitRowFieldAccessor on this line:             QualifiedName base = new QualifiedName(node.getName().getParts().subList(0, node.getName().getParts().size() - 1));
It's only stripping one level of the qualified name when doing the lookup, so probably what we need to do is keep stripping them until we find a match, and then possible patch TranslationMap as there's more handling of ROWs there. This will all go away when we rewrite the parsing of qualified names, to handle the "."  When you've finished with your other tasks lets discuss with @martint the best way to fix this

In the mean time, for anyone encountering this issue. I think you can work around it by adding parentheses, or using a subquery like
SELECT nested_row.my_field
FROM (
SELECT my_row_column.nested_row AS nested_row
FROM my_table
)

Here's a test case:
assertQuery("SELECT a.col2.col0 FROM (VALUES ROW(test_row(1.0, ARRAY[2], test_row(3, 4.0)))) t(a)", "SELECT 3");

This is fixed in https://github.com/facebook/presto/pull/3636


Add TBTCSystem event log

Refs: https://github.com/keep-network/keep-ecdsa/issues/574
Added a TBTCSystemEventLog allowing to access past events emitted by the TBTCSystem contract. This is a temporary workaround because contract bindings generated by the keep-common generator don't support this feature yet.

Holding off with this one until discussion in a PR using this functionality is resolved.

Merging to do not block application-specific actions implementations in the client (https://github.com/keep-network/keep-ecdsa/pull/585). This is not a final solution, and we'll have to update keep-common generators to generate the code from this PR, as we discussed here.


Implement decompression of DEFLATE and ADOBE_DEFLATE.

I'm sure this can be made both nicer and faster but this should at least get the functionality started.
Fixes #42.

Awesome! Thanks for the PR. Could you add some tests?
I believe the underwater_bmx.tif in https://github.com/tlnagy/exampletiffs uses Deflate compression.

I was about to make a test with that image but it doesn't seem to actually be there.

Oh weird. It is still available at the original link: https://people.math.sc.edu/Burkardt/data/tif/tif.html

Codecov Report

Merging #50 (422aecf) into master (6dec118) will decrease coverage by 2.31%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
- Coverage   89.72%   87.40%   -2.32%
==========================================
  Files          12       12
  Lines         545      548       +3
==========================================
- Hits          489      479      -10
- Misses         56       69      +13

Impacted Files
Coverage Δ

src/TiffImages.jl
0.00% <ø> (-100.00%)
:arrow_down:

src/compression.jl
75.00% <0.00%> (-20.00%)
:arrow_down:

src/utils.jl
70.37% <0.00%> (-5.56%)
:arrow_down:

src/layout.jl
86.53% <0.00%> (-1.93%)
:arrow_down:

Continue to review full report at Codecov.

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

Added underwater_bmx.tif to the exampletiffs repo, https://github.com/tlnagy/exampletiffs/commit/0ca553559c925dc3e4e84597e99990d0d83bc7bb

Testcase added. Feel free to replace the DEFLATE test with something nicer or to patch it up properly.

Btw, you may want to check if the exampletiffs README has the size of underwater_bmx correct. I had to switch width and height to get the test to pass.

BTW, the [compat] entry for Inflate.jl is missing.

Thanks for the heads up @kimikage, added in #52


Create Basic Feed View

Check Instagram feed for reference.
Swipe right to messages view not included.
Example:
https://user-images.githubusercontent.com/35423900/155878081-35ec13b0-259f-4593-9bc6-6bf5ef432c33.mp4
Component

Feed Top Sticky Header

Already created in issue #19, now make it stick.

Feed Stories Bar

Already created in issue #15, simply add it in.

Posts

Already created in issue #12 , now generate a list of it.

Tab View (inline)

Home, feed-view.
Search, search-view (Disabled).
Reels, reals-view (Disabled).
Heart, activity-view (Disabled).
Profile, profile-view.

Feed Stories Bar


series list command cuts of series name with --porcelain option

Expected behaviour:
Series names are always printed unabbreviated with the --porcelain option.
Actual behaviour:
Series names are still abbreviated.
Steps to reproduce:

Step 1: Add a series with a long name.
flexget series begin 'Aqua Something You Know Whatever' S01E01
Step 2: Check the list of series in porcelain mode.
flexget series list all --porcelain

Name                           | Latest     | Age        | Downloaded
Aqua Something You Know Wha... | N/A        | N/A        | N/A

Additional information:

Flexget Version: 2.2.1
Python Version: 2.7.12
Installation method: pip
OS and version: Fedora 24 x86_64

That's kinda by design. Did you consider using API?

That's kinda by design.

What is the usefulness of shortening with the porcelain mode? It breaks the expectation that I can feed it's output back to other commands.

Did you consider using API?

I just wanted to write a command that looped through all the series and showed them. Seems like the API is overkill for that case.

I guess you have a point, ill see about expanding it dynamically.

Since #1311 has been merged, this issue should be fixed. Re-open if not.


Fail to upload one append blob to one HNS blob container with the setting 'Enable ADLS Gen2 append blob (Preview)' enabled

Storage Explorer Version: 1.19.0-dev
Build Number: 20210315.8
Branch: main
Platform/OS: Windows 10/ Linux ubuntu 18.04/ MacOS Catalina
Architecture: ia32/x64
Regression From: Not a regression
Steps to Reproduce

Open Storage Explorer.
Go to 'Settings -> Services' -> Enable the setting 'Enable ADLS Gen2 append blob (Preview)'.
Expand one ADLS Gen2 storage account -> Blob Containers.
Create one blob container -> Upload one append blob to the blob container.
Check whether succeed to upload the append blob.

Expected Experience
Succeed to upload the append blob.
Actual Experience
Fail to upload the append blob.

Show a failed activity log.

Show the append blob with 0 B size in the editor after manually refreshing.

Additional Context
This issue also reproduces when coping & pasting one append blob.

You need to enroll in the feature to be able to use it. You can find a form to enroll a subscription here https://azure.microsoft.com/updates/append-blob-support-for-azure-data-lake-storage-preview/

OK, got it. We are going to close this issue.


cannot find lotus_lca.tax

Hi,
I am trying to run through your pipeline and I managed to get to the point where taxonomic assignment is done.
The rule lca is using a taxref file /data/db/pr2/gb203/lotus_lca.tax but I am a bit puzzled as to how this file was created.
Do you have a script for that, or could you tell how the format of that file is defined?
Thanks in advance!

Hi Joris,
Thanks for filling in an issue.
I assume you are using the blast option for classification. You are right  a hardcoded path is used here, that shouldn't be like that. In Hydra the blast option can only be used to classify against the PR2 database.
Note that here also a older release of PR2 has been used. That project got a new repo on github with update code: https://github.com/pr2database/pr2database. The file that has been used here as input is the qiime formatted taxonomy file of PR2, which was downloaded on february 2015.
Then this file was formatted:
sed 's/Eukaryota;//g' < qiime_gb203_taxo.txt > qiime_gb203_taxo_7levels.txt
python2.7 ../../Silva/123/Misc_Code/SILVA_to_RDP/prep_silva_taxonomy_file.py qiime_gb203_taxo_7levels.txt lotus_lca.tax

It looks like:
AB353770.1.1740_U       D_0__Alveolata;D_1__Dinophyta;D_2__Dinophyceae;D_3__Dinophyceae_X;D_4__Dinophyceae_XX;D_5__Peridiniopsis;D_6__Peridiniopsis_kevei
KC672520.1.1801_U       D_0__Opisthokonta;D_1__Fungi;D_2__Ascomycota;D_3__Pezizomycotina;D_4__Leotiomycetes;D_5__Leotiomycetes_X;D_6__Leotiomycetes_X_sp.
AY584669.1.2159_R       D_0__Opisthokonta;D_1__Fungi;D_2__Ascomycota;D_3__Pezizomycotina;D_4__Arthoniomycetes;D_5__Simonyella;D_6__Simonyella_variegata

What database are you as input? If you are using the newer release of PR2, a different tax for the lca step should be used. I need to make this into an option you can specify in the config file.
Let me know if this helps you.
P.S.
You have been at NIOO isn't it?


Sounds not loading

While testing for compatibility with your mod i noticed that none of your custom discs work, at least in development environment.

The error about missing sound files is printed to the console on startup
I was not able to find the .ogg files in your project
There is no sounds.json manifest in resources/assets/blindsmusicdiscs

Music files for the discs are found in a separate resource pack linked in the dependencies of the mod.
I've done it this way to avoid copyright issues since the music belongs to C418.
There's no way of stopping the startup issue due to this unfortunately.


Does this package support GRPC streaming? or just unary requests?

Yes, it should work with any combination of unary / streaming in and unary / streaming out.  However, I have only tested streaming APIs via unit tests, as I don't have a full application that uses them.


Sub-MenuItem does not close when clicked while using Items binding

Code to reproduce:
<MenuItem Header="_File" IsVisible="{Binding Project, Converter={Static converters:IsNullConverter.Instance}}">
    <MenuItem Header="_New" Command="{Static Editor:Commands.NewCommand}" CommandParameter="{Binding}"/>
    <Separator/>
    <MenuItem Header="_Open..." Command="{Static Editor:Commands.OpenCommand}"/>
    <Separator/>
    <MenuItem Header="_Recent" Items="{Binding RecentProjects}">
        <MenuItem.DataTemplates>
            <DataTemplate DataType="Recent:RecentFile">
                <MenuItem Header="{Binding Name}" Command="{Static Editor:Commands.OpenCommand}" CommandParameter="{Binding Path}"/>
            </DataTemplate>
        </MenuItem.DataTemplates>
    </MenuItem>
    <Separator/>
    <MenuItem Header="E_xit" Command="{Static Editor:Commands.ExitCommand}"/>
</MenuItem>

Screenshot before clicking Sub-MenuItem:

Screenshot after clicking Sub-MenuItem:

I have found that this only happens when the bound Items collection has changed after used clicked.
<MenuItem Header="_Recent" Items="{Binding RecentProjects}">

In my case when user clicks on one of the items I open the bound item (a path to a project file) and update accordingly the RecentProjects collection so the opened project is first item in the list. As the RecentProjects collection is immutable array, so to propagate collection changes I set RecentProjects to a new value.

This should have been fixed by https://github.com/AvaloniaUI/Avalonia/pull/1812!


Non 201 status code during passive scan request to burpbuddy

I've been using your tool for a while now, and when i scan a folder it gives me this error:
Non 201 status code during passive scan request to burpbuddy
But, when i do with different code if gives ok, and the instance of burpbuddy its the same, is there any limitation to the burpbuddy that i'm not aware off?

Hi @Etraud123, you're saying when you send a POST to /scan/passive in different code you get a non 201 response?

Going to close this as I haven't heard back from you yet. Feel free to re-open if you have more details :)


[release-1.9] Don't report when alpha annotations are used

This is an automated cherry-pick of #30415

@googlebot I consent.

@googlebot I consent.


Feature(?): Generate new screens from CSS media queries

This unlocks a really interesting workflow where you can:

Click "Generate from Media Queries"
Click "Screenshot All"
Have screenshots for all of the sizes you designed for

Possible solution for retrieving the breakpoints: https://www.lullabot.com/articles/importing-css-breakpoints-into-javascript


captureAWSClient adding significant latency to lambda invocations

When testing the durations of our lambda invocations we are noticing a difference of close to a second in duration time when the lambda clients are wrapped with captureAWSClient. We are using version 3.3.1 of aws-xray-sdk-core

Hi @JohnDupuis
I'm trying to understand your application architecture. Do you have 2 lambda functions, with Lambda1 invoking Lambda2 via an AWS Lambda client? And it is the Lambda1 invocation duration that is increasing by ~1 second when using the lambda client instrumentation?
Can you provide some more details like code snippet for client instrumentation, debug logs from the AWS X-Ray SDK, etc?
Thanks!

Similar symptom here, but not sure it's the same root cause:
We have noticed our lambda execution times are slowed down significantly when we use captureAWSClient. Tracking down the problem, we have isolated it to the X-Ray SDK attempting to capture a stack trace upfront of any AWS client request. Since we have compiled TypeScript code with source maps enabled, capturing the stack trace triggers source maps parsing and resolution, which is extremely expensive, especially that the traces are only useful in case an exception is actually thrown, which is an extremely rare occurrence.
After we have changed the following line in the X-Ray SDK from:
  var stack = (new Error()).stack;

to
  var stack = "";

our lambda execution time went from >18sec to <6sec.
We understand this is a workaround for the well known node issue that truncates the stack traces to the event loop ticker but perhaps there is a way to make it optional, or find a way to get the stack trace cheaper, and resolve it with the source maps only in case there is an error.
Here's the offending line: https://github.com/aws/aws-xray-sdk-node/blob/ffb0d2abdcb2b8971c31cdbc8fadd9fdec0768ee/packages/core/lib/patchers/aws_p.js#L78

any updates on it?

I had exactly the same issue and @georgeionita solution helped.


Add adapter design pattern

The adapter design pattern is a function or a class specifically made to safely convert information of a type into another for compatibility reasons for example:
OpenGL's coordinate system is not compatible with Vulkan's so if you are developing a cross platform game engine you are going to need to use an adapter function to convert between the two. OpenGL's system is like this (x, y, z), compared to OpenGL, Vulkan's is like this(x, -y, z)
I will submit a PR for this issue :)

Merge was unsuccessful be careful!

Ye will submit a fix


OS Provider

GuPM should have a special protocol os:// that switches provider based on the host os.
The default provider to switch to will be added to the configuraiton file of gupm.
{
 "defaultProvider": "os",
  "osProviders" : {
    "windows": "chocolatey",
    "darwin": "brew",
    "linux": "flathub",
  }
}

whenever you will use os:// the proper package manager will be chosen.
g i os://mysql
g i mysql

For repo, add subfolder system:
{
  "linux/node": "0.0.1",
  "windows/node": "0.0.1",
  "mac/node": "0.0.1",
}

when installing, in http-provider check if subfolder is OS and replace by the os name.
g i https://azukaar.github.io/GuPM-official/repo:OS/provider-npm

when publishing,
g publish -- main repo

g publish mac -- sub repo mac/

sub-repo are not limited to OSes
g publish java

g i https://azukaar.github.io/some-repo-yo/repo:java/my-json-lib
g i https://azukaar.github.io/some-repo-yo/repo:node/my-json-lib

Done so far:

[*] config file for os providers
[*] switch providers when using os://
[*] config for default provider
[ ] switch provider when using OS in http-provider
[ ] repo to support subfolders


[PE-D][Tester A] Delete 0 command

Nothing changes when I try delete 0. There should be an error message for it.

Labels: type.FunctionalityBug severity.Medium
original: Diatbbin/ped#3

#159


Buttons 6,7,8,9 are not shown

Hi
What is the problem?

Hello, it looks like there is a problem with the application scaling incorrectly.
What resolution and interface scaling do you have set in Windows?

Yes, you were right, scaling is 300%.
I decreased it and it shows th buttons.

I'm glad we identified the problem.
Also, If you want to unlock buttons (6) and (7) you have to enable SuperUser mode by triple-clicking the version number label (11).


Get media likes and hashtags per image

How do I get each like and caption per image?
try {
	$result = $instagram->getUserMedia('self');
	$i = 1;
	foreach ($result->data as $media) : ?>

			<a href="<?php echo $media->link ?>" target="_blank"><img src="<?php echo $media->images->thumbnail->url ?>" alt="<?php echo htmlentities($media->caption->text) ?>">

		<?php
	endforeach;
} catch (Exception $e) {
	// Do something with Exception
}

Hey @guardadoe - INSANELY sorry that I haven't gotten back to you until now.
Everything that the Instagram API returns is available, so you would want to use $media->likes->count to get the number of likes a photo has, and $media->comments->data (you'll want to loop through that to get all of the comments ($comment->text for example)) to pull out the comments for a photo.
For a more detailed example of exactly what is returned by the API, take a look at https://instagram.com/developer/endpoints/users/ or just var_dump($result).


Update zio, zio-test-sbt to 1.0.14

Updates

dev.zio:zio
dev.zio:zio-test-sbt

from 1.0.10 to 1.0.14.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

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

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

Superseded by #113.

Superseded by #117.


Release notes for 1.10.0 on Github don't list breaking changes concerning OpenShift

Describe the bug:

The release notes on GitHub for 1.10.0 do not mention the breaking changes concerning deployment to OpenShift.
Expected behaviour:

Read the release notes on GitHub for 1.10.0
Understand that there are breaking changes concerning deployment to OpenShift

Steps to reproduce the bug:

Read the release notes on GitHub for 1.10.0
Think that it's good to go for OpenShift
Deploy to OpenShift
Pods are not admitted b/c of SCCs

Anything else we need to know?:
The release notes for 1.10.0 on cert-manager.io, on the other hand, are great and helped me address the issue. Once I understood the problem I was able to include appropriate SecurityContextConstraints and RBAC.
I would love for all the available release notes to be same, not necessarily to the letter but at least as far as the quality of changes is concerned. I am also ok with a big sign saying "there are breaking changes, go here 🔗 for details".
Environment details::

Kubernetes version: OpenShift 4.10, 4.11
Cloud-provider/provisioner:
cert-manager version: 1.10.x
Install method: static manifests

/kind bug

Thanks @mamachanko , agree this should appear in Github release notes!
I've updated the breaking changes section there https://github.com/cert-manager/cert-manager/releases/tag/v1.10.0 hopefully it'll help future users. Thanks for pointing this out!

Thank you @irbekrm!
I will close this as completed then.


Create a desktop shortcut to the view/table in a database, (with focus on the data tab)

Drag and drop table/view, to the desktop to create the shortcut.
Or, right click on the table/view, and select "create shortcut on the desktop"
(or the "data" tab in the data viewer, drag it to the desktop to create the shortcut)
When you click on the shortcut, you would open program with the focus on table in the data view.
or use command line:
for example:
load database inventory from the databases list:
program.exe -database inventory -table v_computers
with optional switches to
-jump to display query/data/triggers/ddl, data being the default: -tab data
-order by field(s): -order column_name, or: -order column1,column2, default as defined in the view, if view is the target.
-select sqlite file not in the list of databases: -file "path to file name"
This is not something that is very important, but it would be a nice feature to have :)
Thanks.

Thank you for the idea.
As an alternate solution, you can use bookmarks.


[explorer] Update transaction to use new block terminology

Description
Describe the changes or additions included in this PR.
Test Plan
How did you test the new or updated feature?

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)

[ ] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

Current dependencies on/for this PR:

main

PR #9958   👈

This comment was auto-generated by Graphite.


SecurityEventNotification.req

https://aftersales.alfen.com/servicedesk/customershim/secure/attachment/1024186/1024186_OCPP+1.6+security+whitepaper+edition+3.pdf?fromIssue=390054
Seems that ocpp1.6 does not handle SecurityEventNotification. Is it planned to integrate this? Issue here is with Alfen stations that keep sending SecurityEventNotification and stack does not respond.

We had the same issue with ABB, so we modified the library to support OCPP 1.6j security extension, but it does not include unit tests. We tested it in production and so far, it worked fine (https://github.com/GLCharge/ocpp-go)

@xBlaz3kx would you like creating a PR for the security extension? It's been on my ToDo list but didn't get to it yet. Happy to include it and then write some tests for it.

@lorenzodonini Sure, I can do that.
The only thing I'm a bit unsure of is the way I implemented/added additional handlers for incoming messages, specified in the extension.
The extension's specification doesn't really mention if the functionalities should be split into different profiles (like in the original specification), nor does it specify any additional SupportedFeatures variable (as far as I understood the specification), that would indicate support for the security extension.
So I did this:
// OCPP 1.6j Security extension
	chargePoint.SetCertificateHandler(handler)
	chargePoint.SetLogHandler(handler)
	chargePoint.SetSecureFirmwareHandler(handler)
	chargePoint.SetExtendedTriggerMessageHandler(handler)
	chargePoint.SetSecurityHandler(handler)

I'd like to hear your thoughts regarding the implementation approach.

@xBlaz3kx thanks a lot for opening the PR. I'll have a detailed look in the next few days.
Regarding the structure, since the security extension is backported from v2, it's technically up to us where we want to put it.
If we go by the book, the features should be structured like:

security

SecurityEventNotification
SignCertificate
CertificateSigned

iso15811

GetInstalledCertificateIds
DeleteCertificate
InstallCertificate

diagnostics

GetLog
LogStatusNotification

firmware

SignedUpdateFirmware
SignedFirmwareStatusNotification

remotecontrol

ExtendedTriggerMessage (this is a special kid, since it's technically just the TriggerMessage feature from v2, but since v1.6 already has it, they had to name this one differently)

Just FYI the structuring is derived from the functional blocks as presented in the 2.0.1 specs, which are identified by letters A - P.
If we follow this split I would recommend leveraging at least the existing firmware package in v1.6. Alternatively we can just group all of these features in a dedicated security-extension package. I guess as a developer I would prefer the latter, but happy to take what exists already.
Your point about the SupportedFeatures not being mentioned is valid and I agree with your current approach to stay on the safe side. We could dare adding the Security profile in the list, as it should be straightforward to understand.

@lorenzodonini Of course, no problem. I'll have to fix a couple of details (I've renamed the module because we're using it in our product) before it can be merged.
Regarding the structure - it is essentially what I've done, with minor naming differences, so I think we are mostly aligned. Take a look when you can, and let me know if I should fix anything :smile:

We had the same issue with ABB, so we modified the library to support OCPP 1.6j security extension, but it does not include unit tests. We tested it in production and so far, it worked fine (https://github.com/GLCharge/ocpp-go)

Couldn't comment directly on your fork, but I noticed that the types.CertificateUse enum for CentralSystemRootCertificate does not match specifications
const (
	CSMSRootCertificate         CertificateUse = "CSMSRootCertificate"
	ManufacturerRootCertificate CertificateUse = "ManufacturerRootCertificate"
)

We had the same issue with ABB, so we modified the library to support OCPP 1.6j security extension, but it does not include unit tests. We tested it in production and so far, it worked fine (https://github.com/GLCharge/ocpp-go)

Couldn't comment directly on your fork, but I noticed that the types.CertificateUse enum for CentralSystemRootCertificate does not match specifications
const (
	CSMSRootCertificate         CertificateUse = "CSMSRootCertificate"
	ManufacturerRootCertificate CertificateUse = "ManufacturerRootCertificate"
)

Thanks for catching this! What I've essentially done is copy most of thecode from the 2.0.1 folder, as the functionality and naming conventions are the same as the security extension, so I guess I need to double check.

@xBlaz3kx I created PR against your fork, with a few fixes. Given how #266 is using types from 2.0.1 exclusively it will need some updating. Do you have plans on updating the PR?

@xBlaz3kx I created PR against your fork, with a few fixes. Given how #266 is using types from 2.0.1 exclusively it will need some updating. Do you have plans on updating the PR?

Hey @atschabu, thanks! Unfortunately I don't work for the company anymore, so I can't do much about the PR. Instead, you can make a PR against my repository, and I'll merge the fixes.

@xBlaz3kx I created PR against your fork, with a few fixes. Given how #266 is using types from 2.0.1 exclusively it will need some updating. Do you have plans on updating the PR?

Hey @atschabu, thanks! Unfortunately I don't work for the company anymore, so I can't do much about the PR. Instead, you can make a PR against my repository, and I'll merge the fixes.

Hey @xBlaz3kx, tried to create a PR to include @atschabu changes into your fork to speed up things, but I noticed that your fork is not quite a mirror of (GLCharge/ocpp-go)
I can't find the charge center

SetSecurityHandler
SetSecureFirmwareHandler
SetLogHandler

And I can't find the charge point

SetCertificateHandler
SetLogHandler
SetSecureFirmwareHandler
SetExtendedTriggerMessageHandler
SetSecurityHandler

@xBlaz3kx I created PR against your fork, with a few fixes. Given how #266 is using types from 2.0.1 exclusively it will need some updating. Do you have plans on updating the PR?

Hey @atschabu, thanks! Unfortunately I don't work for the company anymore, so I can't do much about the PR. Instead, you can make a PR against my repository, and I'll merge the fixes.

Hey @xBlaz3kx, tried to create a PR to include @atschabu changes into your fork to speed up things, but I noticed that your fork is not quite a mirror of (GLCharge/ocpp-go)
I can't find the charge center

SetSecurityHandler
SetSecureFirmwareHandler
SetLogHandler

And I can't find the charge point

SetCertificateHandler
SetLogHandler
SetSecureFirmwareHandler
SetExtendedTriggerMessageHandler
SetSecurityHandler

Hey @AhmedAbouelkher,
correct, its not a direct mirror of the repository. I've implemented the changes in a separate branch, not in the main.

@xBlaz3kx I created PR against your fork, with a few fixes. Given how #266 is using types from 2.0.1 exclusively it will need some updating. Do you have plans on updating the PR?

Hey @atschabu, thanks! Unfortunately I don't work for the company anymore, so I can't do much about the PR. Instead, you can make a PR against my repository, and I'll merge the fixes.

Hey @xBlaz3kx, tried to create a PR to include @atschabu changes into your fork to speed up things, but I noticed that your fork is not quite a mirror of (GLCharge/ocpp-go)
I can't find the charge center

SetSecurityHandler
SetSecureFirmwareHandler
SetLogHandler

And I can't find the charge point

SetCertificateHandler
SetLogHandler
SetSecureFirmwareHandler
SetExtendedTriggerMessageHandler
SetSecurityHandler

Hey @AhmedAbouelkher,
correct, its not a direct mirror of the repository. I've implemented the changes in a separate branch, not in the main.

That's great. I can confirm that this is indeed the branch that I cloned and did not find these missing functions.

Hey @AhmedAbouelkher,
I 'm not sure how, but I guess I forgot to transfer (copy) the newly added interface methods. I'm working on the fix(es) now.


(Re-add) Only compile Sass files that have been modified

In 0.5.x, we dropped support for only recompiling Sass files that have changed. This is pretty painful during gulp serve in the material-sprint branch :)
This feature was reverted because users were running into issues with it not correctly reloading on save.
Let's try adding back in support. We'll probably want to look at updating paths and any open issues around browser-sync in this area.

cc @sindresorhus who wrote gulp-changed and IIRC, added in our support for it for thoughts on the above comments. Thanks @DominicBarnard.

I have this issue with BrowserSync & Gulp alone following BrowserSync's guide for Gulp.
http://www.browsersync.io/docs/gulp/
If I have two files with .scss extention and I change either one, it will recompile both:
[BS] 2 files changed (main.css, secondary.css)

The same thing happens with Web-Starter-Kit.

Yes, gulp-changed only handles 1:1 relationships. Maybe try using gulp-cached + gulp-remember instead.

I found this thread after attempting to solve this same problem on my own. I'm no where near as experienced with the codebase as @sindresorhus.
I've found [https://github.com/xzyfer/sass-graph] which builds a dependency chart for @imports.This seemed like a good method to explore. before i start watching for file changes I save the graph into a variable
var graph = sassGraph.parseDir(config.paths.src + '/scss/pages');
gulp.watch('public_html/src/scss/**/*.scss').on('change', function(file){
    var imports = config.graph.index[file.path].importedBy;
    return sass(imports).pipe(gulp.dest('public_html/dist/css'));
});

Of course that doesn't work, but the idea might. That would at least cut down on the number of files sass is building on each change.

@cmndo Yup, having the dependency graph is the only way to reliably cache the Sass compilation.

Because:

libsass maintainers suggest that libsass is fast enough to not worry about caching.
Because Sass has its own import system, comparing file timestamps doesn't work. As mentioned above, if you really want to get incremental you need a dependency tree.

Would we gain enough speed to make adding a couple more plugins and complexity to the styles task worth it?
Based on my experience I would be happy only filtering changed files for CSS.


[Feature Request] Tool types are renamed since openai==1.14.0

Required prerequisites

[X] I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
[ ] Consider asking first in a Discussion.

Motivation
This upgrade makes some types no longer exists https://github.com/camel-ai/camel/blob/9c0f5987d7c07e2cd59361b6e3a4583c8cfcc482/camel/functions/openai_function.py#L198
See: https://github.com/openai/openai-python/pull/1233
Solution
No response
Alternatives
No response
Additional context
No response

raise one issue in https://github.com/openai/openai-python/issues/1242 since I couldn't find information where ToolAssistantToolsFunction  has been moved in new openai version

@Wendong-Fan it is here https://github.com/openai/openai-python/commit/5429f69670e4db70f0cb7420ddb27c9bd11b9508#diff-c862600fd0c97be504a55cc2ae7dfc98f748ef445d53568b60b04a330e5aa55cL55-L59


Loading hanging

The app is not loading after the project is created and WORDPRESS_GRAPHQL_ENDPOINT is configured.
It does not return any error, the browser page starts to load and doesn't stop.
First thought that endpoint url was wrong, but after install the basic version with the same configuration, it works.
Anyone with this problem?
My node version is: v14.17.4 (have 17.3.0 also installed but npm run dev returns error:03000086:digital envelope routines::initialization error error
NPM version: 6.14.14
OS: Windows 10 20H2

I've also went to check the basic version and it worked with the same config.
With this version it get's stuck in infinite loading after the project was created.

hey @ncosta40 @alexandruvisan19 would either of you happen to have your homepage set as static instead of the blog posts?
i ran into a similar issue while debugging this https://github.com/colbyfayock/next-wordpress-starter/issues/322
wondering if it's the same issue 🤔

Hey, I had it set to latest posts from the beginning.

Had the same issue with the hanging... Found out it was caused by a secondary menu I had created for the footer.  Once I removed the 'display location', I was able to get it running.

oh strange - were you able to tell if it was an issue with the code or if it was a WP request issue?

@colbyfayock I am also facing the same issue.
Added a new menu location inside functions.php and localhost:3000 gets stuck at infinite loading. Removing it fixes the infinite loading. But when I query menus inside GraphQL IDE I still see 2 menus.
Dug a little deeper and found the following.
I tried this query "QUERY_ALL_MENUS" inside graphQL IDE as well. It spits out
"message": "Internal server error",
      "extensions": {
        "category": "internal"
      },

when I remove "locations" from the query the error is gone. Can you please help?
Thank you for all your effort.

hey @2xSamurai not sure what you're asking for help with - the query itself throws an error? I'm not sure how to help with that one, I would recommend trying to see if you can find a similar issue on the WPGraphQL repository or if not, create a new issue there

@2xSamurai @colbyfayock I have the same loading issue. If I use just one menu everything works fine, If I'll create another one (for the footer) the app stil loading because there is some infinte loop I'm looking for.

thanks @eliawk  - put it in a PR, anyone up to see if it fixes their issue?
https://github.com/colbyfayock/next-wordpress-starter/pull/388


Closing tag for DIV inserted in a wrong place inside UL/LI

This HTML fragment:

A

B

When parsed with Nokogiri and spit out using to_html, generates slightly different HTML:

A

B

Notice that the
 closing tag was inserted, but not in the correct position. The typical web browser would auto-close the DIV tag as soon as it encounters the first
. But Nokogiri fails to do that, and instead auto-closes the DIV when it encounters the
.
The resulting HTML can break web page layouts as now the browser thinks that more than 1 DIV was closed here.
The behavior is the same in Nokogiri 1.5.11 and 1.6.3.

This behavior is definitely coming from libxml2's HTML parser which has complex logic around implicit closing tags and autocorrection.
FWIW, the HTML5 parser does the right thing and generates:

A

B

I'd like to close this issue since there's nothing Nokogiri can easily do to change this behavior.
As is customary in these situations, I'm offering to assist in filing a bug report upstream; but the libxml2 maintainers have not been very responsive lately, especially since Steve Checkoway stepped down from maintaining, and so I'm not confident we'll get the result we want.

Just for the record, I haven't had any involvement with libxml2 other than as a user of the library.

Ahhhhh! Sorry, I didn't mean Steve Checkoway, I meant Nick Wellnhofer. Total brain fart, my apologies.


trunc second when timestamp

This is a non-obvious change. Please add a unittest to show how this works.

please add a unittest for this special case

@mrmasterplan , I have now provided a testcase, where the datetime column had been date_trunc(). It tests that it only has seconds, and no miliseconds.


Event fire as user inputs

Hi! Is there a way to fire an event everytime the user changes something in the input and get the input value? (eventListener?)

Yes, check out how it's done in this code:
https://github.com/publiclab/PublicLab.Editor/blob/cfbd44b2c6ccc8c2b06100da3a421ce9c3515c74/src/modules/PublicLab.RichTextModule.js#L142-L152
On Wed, Aug 1, 2018 at 12:53 PM Gabriel Afilipoie<EMAIL_ADDRESS>wrote:

Hi! Is there a way to fire an event everytime the user changes something
in the input and get the input value?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bevacqua/woofmark/issues/68, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABfJz-OAcDpHKvXN7O0Fyb_v4ng67ouks5uMdzcgaJpZM4Vq3Ty
.


feat(helm): add ingressClassName value to ingress resource

Hello,
this PR will introduce the ingressClassName to the ingress template.
Docs on this: https://kubernetes.io/docs/concepts/services-networking/ingress/
I added a semverCompare since it is available beginning k8s 1.18 and only on v1 of ingress resource and we also make this check for deciding what apiGroup to use.
if .Values.django.ingress.ingressClassName is either non-existent or empty, the key will not appear in ingress resource

Lint Helm chart fails because of some unrelated error

@valentijnscholten ?

Please revise against dev branch

@valentijnscholten Hi, did the changes. Thanks :-)

thanks, no need to bump the chart version in dev. better not to actually.

@valentijnscholten okay, reverted the change and cleaned up commit history

@KarstenSiemer  This looks nice, I wanted to push the same, to avoid post patching (as we do now).

Thanks @KarstenSiemer


Add image loading events to image sources

This follows up on #3248 and adds support for image based sources as well.

Looks good to me, please merge.


feat(scully): Add config property for architect target

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/scullyio/scully/blob/main/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the current behavior?

Currently if you change architect to targets in workspace.json the scully build will fail.
Issue Number: https://github.com/scullyio/scully/issues/1394
What is the new behavior?
You can now optionally add a new configuration item called target to specify what target scully should use for the build.
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

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


Sorry ik begrijp (nog) niet wat je bedoelt message

The 'Sorry ik begrijp (nog) niet wat je bedoelt’ response should not be triggered when people send something (that the coach doens't understand) during a dialogue with the coach. For example in some dialogs the coach says something that people may respond to, e.g. "Weet je nog hoe dat er uit zag? Probeer dat weer voor je te zien." (and people might say yes) or ""Succes, je kan het!" (and people might say thanks). If the coach then sends the sorry message with all the options, that's confusing
I think it’s better if the coach ignores the user's message and just continues with the dialogue; and save the Sorry message for when people start typing things outside of a dialog. If the user is supposed to say something within a dialogue (e.g. type 1 for this 2 for this etc) and type something else, the response seems ok (i.e. answer options are repeated).

For notifications, it's also confusing if the VC sends the Sorry etc message after people respond to the notification. It's better if the VC then repeats the message that instructs users what to send (e.g. 'Typ verder als je klaar bent om verder te gaan)

@emeijerperfectfit If the VC responds with the Sorry message is indeed a bug. It should not happen inside a dialog. In the example you reported, this happens because of the 10s delay. In those 10s the user is actually out of the dialog. A solution would be to get rid of that delay. Could that work?

For notifications, it's also confusing if the VC sends the Sorry etc message after people respond to the notification. It's better if the VC then repeats the message that instructs users what to send (e.g. 'Typ verder als je klaar bent om verder te gaan)

@emeijerperfectfit A response to the notifications is not expected. The moment the notification is sent, the dialog ends. If an answer is expected, the dialog will hang for 1h and a response is then mandatory. Let me know which is the solution you prefer.

Hi Walter, in some dialogs we do need the delay (e.g. 10 sec) to sort of force people to think about something, they won't do that if the dialog just continues. Would it be possible to disable the Sorry reponse during these delays? I believe that only a few dialogs have this

Would it be an option to disable the Sorry response for about 1 minute after people have read a notification? Or do you think that people will then need the menu and won't get it?

I am not sure if it is possible to disable the responses. I will look into it, hopefully it is not too complicated

Good news! It is possible to pause and resume the conversation, I am implementing it


Missspelled Access-Control-Allow-Origin Header

Hi,
your Access-Control-Allow-Origin header is missing an "i": "Access-Control-Allow-Orgin"

Wow, thanks for noticing! It's fixed now.


syntax error

root@srv0:~# go get -u github.com/odeke-em/drive/cmd/drive
# github.com/odeke-em/semalim
gopath/src/github.com/odeke-em/semalim/semalim.go:84: syntax error: unexpected range, expecting {
gopath/src/github.com/odeke-em/semalim/semalim.go:92: syntax error: unexpected (, expecting semicolon or newline
gopath/src/github.com/odeke-em/semalim/semalim.go:94: non-declaration statement outside function body
gopath/src/github.com/odeke-em/semalim/semalim.go:95: syntax error: unexpected }
root@srv0:~#

Hello there @onetigr, thanks for reporting this and welcome to drive!
Would you mind mentioning what OS you are on, go version and other information that could be useful to reproduce this?

debian 8.2

Go version? uname -a?

root@srv0:~# go version
go version go1.3.3 linux/amd64
root@srv0:~# uname -a
Linux srv0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux
root@srv0:~#

Please re-run the go get -u, I've fixed this in an external package with commit https://github.com/odeke-em/semalim/commit/637f9719b4ca40f719b12c40fbec72e95021e3e3.

now it compiled well.
Thank you very much for your help, and for your tool at all!

Awesome! Thank you for the kind words and for reporting this. Have a good one and enjoy, cheers!


added improved error handling

This commit includes improved error handling for blast, similar improvements were not possible for busco or kraken2, but instead there is more elegant logging.
It does not rely on the blast perl script anymore, I recreated the download function with curl and wget instead. This makes it less dependent on external dependencies.
There are also a few new functions.

Should we explicitly set timeout for curl and wget
I can not see what happens if one step fails. Do you try again same link or proceed to next and report the error

wget: I can add "--retry-connrefused --wait=2h --timeout=900" - It will retry on "connection refused", wait 2h between the attempts to give the file or server some time to come back, and upon timeout errors it will wait for 15 minutes before it retries. The default is that it retries 20 times for errors other than "connection refused" and 404.
curl: I can add "--retry 20 --retry-delay 7200 --connect-timeout 900" - It will retry 20 times, wait 7200 seconds, i.e 2 hours, between the attempts and wait for 900 seconds on timeouts.

I found no clean way of catching errors from busco or kraken2, the solution there is to rely on the email that the cron job sends and sift through the log files if the database is incomplete. If you look closer at the blast download function you will see the algorithm that handles the retry attempts.


Ability to customize the deployment

closes #15
And a fix about the image.

@babykart
I don't have a strong opinion about adding annotations and labels below a new deployment section. There is no general approach that is followed everywhere, some charts use podAnnotations, others nest it below global: and others have it at the root of values.yml.
But replicaCount should stay at the root IMO - due to the breaking changed mentioned.
If you're ok with this, do you want to update the PR?
You can also create a new one if that feels cleaner - or close, up to you 🙂


404 error in a linked page

It says Look up the documentation to learn more but this link is not valid.

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

ID: 3a2ad993-c879-8128-fc56-3523b33eaef3
Version Independent ID: 85b08da1-23de-388d-b08d-5aefa587cc48
Content: Search REST API for Azure DevOps Services - Azure DevOps Services REST API
Content Source: docs-ref-conceptual/7.1/search/index.md
Product: devops
Technology: devops-ref
GitHub Login: @wnjenkin
Microsoft Alias: pnechvatal

This issue has been fixed


dapr dashboard add address option

Description
dapr dashboard add "--address" option, such as dapr dashboard -k -p 9999  --address <IP_ADDRESS>
Issue reference
close: #780
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Extended the documentation

@marviniter Please, open a docs issue for this new flag.

@marviniter  Also, please, open a new PR adding integration test for this feature.

@marviniter Also, please, open a new PR adding integration test for this feature.

Ok，I will submit new PR for this later.


Unable to upload coverage report in a PR from a fork; missing $VIP_VAP_ACCESS_TOKEN?

First seen in #1849, see logs here. To compare, here is a successful run.
A good upload step starts like this:
Cloning into '/tmp/tmpl2fucvud'...
remote: Enumerating objects: 285976, done.
remote: Counting objects: 100% (1523/1523), done.
remote: Compressing objects: 100% (354/354), done.

A bad one starts like this:
Cloning into '/tmp/tmpducdsii0'...
warning: redirecting to https://github.com/neondatabase/zenith-coverage-data.git/
remote: Enumerating objects: 286848, done.
remote: Counting objects: 100% (2395/2395), done.
remote: Compressing objects: 100% (557/557), done.

So it looks like the bad one decided to strip out auth token from the URL altogether, so the following git pushes are waiting for credentials and fail.
My current suspicion is that $VIP_VAP_ACCESS_TOKEN was not specified for some reason, which turned the<EMAIL_ADDRESS>URL from the CI script into<EMAIL_ADDRESS>(mind the @ symbol), which is then redirected as above. At least, the exact same message is printed on my system under those circumstances.
Few questions/suggestions here:

We should probably check that $VIP_VAP_ACCESS_TOKEN is not empty in the script and fail loud if it is. If it's of username:token format, we should also check that the variable contains a colon.
Why was VIP_VAP_ACCESS_TOKEN not provided in the first place?
Why did the git-upload script fail git push fast first two times (Username for 'https://github.com': fatal: could not read Username for 'https://github.com': Success) and then got stuck for ten minutes on the third attempt which started just like the previous two?

Answer to no. 2: the original PR is from another repository. CircleCI does not share secrets (including VIP_VAP_ACCESS_TOKEN) with arbitrary PRs for a good reason: otherwise a malicious actor could easily extract them by crafting a special script, altering config.yml and sending us a PR.
So, the immediate mitigation is to avoid PRs from forks.
However, that leaves us with another question: how do we receive PRs from external contributors in the future?

Splitted this issue: #1860 (and also found #1861), #1863, and #1862.

I think we should stop uploading the coverage reports to a git repository. Publish them as an artifact in the CI, instead, just like e.g. log files. We're not trying to build a database of old coverage reports for historical analysis, we just want to see the coverage report for a particular commit or CI run. Historical analysis would be cool too, but not urgent, and if we wanted to do that we could collect the results for that from the CI artifacts too.
But we should probably finish https://github.com/neondatabase/neon/pull/1647 first. If we're switching away from CircleCI anyway, it doesn't seem worth it to tweak the CircleCI configs now, just to have it be rewritten again.


Adds soft_delete configuration option

@jnicklas I don't expect this to get merged, but I would like your feedback so I can improve the feature. I added a config option to refile.rb called soft_delete; it defaults to false. I check for this option before running line https://github.com/refile/refile/blob/master/lib/refile/attachment/active_record.rb#L44, when then after_delete callback executes. See issue #309 for reference.
Some feedback would be nice...

It feels wrong to add soft_delete to the config when it only works with ActiveRecord. It seems like soft_delete should work regardless of the adapter. The only other place I can think of implementing this is https://github.com/refile/refile/blob/master/lib/refile/attacher.rb#L134. Perhaps I'm wrong.
Should there be more tests? For example, that soft_delete defaults to false and that it can be set? Where would we add those? refile_spec.rb?
Is the one test in spec/refile/attachment/active_record_spec.rb sufficient for this feature?
Is soft_delete a good name?

I would rather have this as a config option to the attachment method, rather than a global config.
Yes, a few more tests would be good, I think spec/refile/attachment/active_record_spec.rb is the right place.
I've wanted this kind of option for a while (in fact I though it already existed and was surprised to find out it didn't), but I think it's more general than soft deletion. Someone might want to keep files around just in case, without implementing a soft deletion strategy. I think this is quite common. Some options could be:

attachment :foo, old_files: :keep # explicit but a bit wordy
attachment :foo, prune: true # difficult to understand, assumes the user knows what prune means
attachment :foo, destroy: true # destroy what exactly?
attachment :foo, dependent: :delete # Rails-alike, but maybe a bit confusing?

Not sure I really super like any of these.

@jnicklas thanks for the feedback. I like attachment :foo, dependent: :delete, but I think it can be confusing.  IMO old_files: :keep is too verbose. How do you feel about:
attachment :foo, keep_file: true    # seems explicit enough
attachment :foo, file: :destroy
# or, depending on which default behaviour we want... ?
attachment :foo, file: :destroy

Also, should file not be singular? We're dealing with one.

After thinking about this some more, I think that maybe I like destroy: true|false the best. What do you think?

I think that sounds good! I'll start a new branch, and close this one once I make a new pull request.

Closing in favour of #362


Use short help as tooltip in PowerShell completion

Also fixed some small issues with subcommand detection.

This change is

I also manually tested these changes with ripgrep (my primary use case) and it works great.
I was going to try with rustup, but that turns out to be a little harder to build on Windows, so I haven't verified the output there yet.
The PowerShell tests were disabled, so I'm guessing they'll fail again in CI. If they do, I'm open to discussing how to fix as it'd be nice to keep them enabled.

Awesome! I'm super excited for these fixes, as PowerShell isn't my strong suit.
As for the CI piece, yes they fail in CI due to strange line wrapping behavior (maybe due to Windows using \r\n and the tests only using \n?). I haven't dug too far into it though.

Also the github.com/habitat-sh/habitat people may be interested in these fixes too as I believe they use the PowerShell completions on Windows too. cc @smurawski @fnichol

It looks like the rust compiler converts CRLF to LF inside strings (https://github.com/rust-lang/rust/commit/8a8e497ae786ffc032c1e68fc23da0edcf6fa5e3), so it seems like there shouldn't be any weird problems.
If the tests fail in the future, @ mention me and I'll investigate.


Fix out-of-tree testing symlinks on Windows

Some of the symlinks in PR #1470 were being accidentally created as directory symlinks on Windows, this adds a check to create the symlink of the correct type.
Backports will be needed for 2.7 and 2.1

As defined by MSDN, there are three different types of links as you can read here and here.
To do a very dumb and very quick summary, they are:

Symbolic links - for files or directories and can span volumes, but needs additional privileges (SeCreateSymbolicLinkPrivilege), so really needs to be a local Admin or a specially created account.

Hard links - only for files on the same volume

Junctions - only for directories on the same volume

We originally had symbolic links, which were changed to junctions in #688 to remove the need for Admin privileges, because it they didn't work on some development machines.
This PR is changing the junction to a symbolic link. e.g. from making a junction :
set(command cmd.exe /c mklink /j ${link} ${target})

to a symbolic link:
set(command cmd.exe /c mklink ${link} ${target})

(Please see the mklink definition).
I think that line needs to be changed to the following to form a hardlink:
set(command cmd.exe /c mklink /h ${link} ${target})

This passes the internal release and Windows CI, and is the change I requested, so I approve.

@dgreen-arm - I don't believe this needs backports, as the breaking change was never backported. You marked it as needing backports, so can you please confirm?

I marked it as needing backports as #1470 has backports, at least for 2.1 here #1465. I see it hasn't been merged yet, so no backport is currently needed.

In the interest of getting CI working again, we should merge this now and fix 2.1 and 2.7 in the PRs that would break them instead of waiting to break them and fixing them with a backport of this PR.

I've pushed the fix for mbedtls-2.1 branch to #1465, so no backport is needed for that, and for mbedtls-2.7 branch, the original PR #1470 hasn't been merged yet, but when it is, this PR can be used as a fix as mbedtls-2.7 hasn't diverged far from development.
Therefore no backports needed!

Merged into development.

Merged PR into mbedtls-2.7.


[cleanup][3] some unused files can be deleted

We have refactored the storage layer, so class RowBatchInterface is no longer needed and we can delete it
we should delete files:
be/src/runtime/row_batch_interface.hpp

Welcome newcomers to solve this issue

yes i can
send me details

@852hamza great, I will assign this to you.

is this closed or open

@852hamza
this issue solved by #3165, so we close it


Give some interaction to the end user when waiting for GetFeatureInfo

In the GXP based viewer, there would be a cursor change. We should at least give some indication to the end user that something is happening

See: https://github.com/boundlessgeo/sdk/commit/0c18959b09cde4d19222230fe5f22c87c1fc60ef will be pulled in with the next release of SDK

Pulled in.


[HELP]fields of subclasses

Hello,
I'm new to rust and gtk-rs and during my exploration, I encountered a problem.
If a define my subclass in imp.rs such as:
#[derive(Default)]
pub struct CustomButton {
    pub number: Cell<i32>,
}

and I'd like to use it somewhere in some other function I'd define for the CustomButton, for example, in file mod.rs:
glib::wrapper! {
    pub struct CustomButton(ObjectSubclass<imp::CustomButton>)
        @extends gtk::Button, gtk::Widget;
}

impl CustomButton {
    pub fn get_count(&self) -> i32 {
        self.number.get()
    }
}

which would give me an error saying that

available fields are: 0

Is that the expected behavior? Is there any way I can retrieve the value inside the struct?
Thanks.

Is there any way I can retrieve the value inside the struct?

Yes, via ObjectSubclass::from_instance, see e.g.
https://github.com/gtk-rs/gtk4-rs/blob/9540e4dd72e1fa8a99bb519b3518b52ce65fa221/examples/composite_template/ex_application_window/mod.rs#L16-L23


Feature Request: Config flag for Enum Keys #4296

Feature Request: Config flag for Enum Keys #4296
https://github.com/samuelcolvin/pydantic/discussions/4296
Change Summary
added a config flag that allows the use of enums as model keys
Config:
    use_enum_values_as_keys = True

This allows the use of model such as:
class Color(Enum):
    RED = "red"
    GREEN = "green"
    BLUE = "blue"

class ColorModel(BaseModel):
    rgb: Dict[Color, int]

Related issue number
fix #4296

Checklist

[x] Unit tests for the changes exist
[x] Tests pass on CI and coverage remains at 100%
[x] Documentation reflects the changes where applicable
[x] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

**PR is ready for review, pending issue discussion

Best to wait for response to an issue before creating a PR.
My concern would be over performance, if we start allowing this, we'll have to continue supporting it long term.
I think on balance I'm inclined to refuse the request, in V2 we intend to support a custom function for serialising data which should allow this.
@hramezani what do you think?

Agree with you @samuelcolvin. as we are preparing V2 I think it does not make sense to add this.

Sorry @EvanSchalton I'm closing this PR, but the need for features like this is absolutely on my radar for V2.
The best thing you can do is test V2 as soon as the first alpha is out and confirm it can do what you want.

Hey @samuelcolvin, no worries - I'll run it on my fork until there's a beta to checkout; I appreciate your consideration and all your hard work


Big oops in swap chain and other issues.

https://github.com/GodotVR/TiltFiveGodot4/blob/11eedc20c351fcaf35a35eecdbbcb7fb6511a28c/extension/T5Integration/Glasses.cpp#L544-L562
There is a bug here that is actually producing better looking results.
These lines revel a bug where the system was not advancing though the swap chain. the line  _current_frame_idx = (_current_frame_idx + 1) % _swap_chain_frames.size(); really needs to be moved to just under the t5SendFrameToGlasses call.
I did try this fix but discovered that weird tracking distortions appeared in the Vulkan output. I'm not sure what the problem is yet. It could be that something about this config is fighting with the predictive pose estimation in the glasses or it could be that we need to set up some Vulkan barrier before submitting the frames.
So as it stands only one frame in the swap chain is being used and that bug actually produces the best results under Vulkan. There is still some small jitter in the Vulkan output so it seems there is still some sort of problem there.

Could indeed be a timing issue, as you're doing a texture copy, that copy won't have completed when you're submitting.
Do we still need to do the copy? Aren't arrays implemented for Vulkan now as well?


React Create Element type is invalid

https://github.com/irohitb/rn-formly/commit/194de542f5f32b000669feaf065b90be589b24fd


2.0.0-pre4

Reliable platform API

Platform implementations for Bukkit and BungeeCord
More planned in the future
Separated platform implementation out into a SquirtgunPlatform class (global to the server) and a SquirtgunPlugin class (plugin-specific logic)
Additional platform-specific logic can be created by extending the Platform interface and relevant implementations

fixes #17