Custom vtable API

This is my suggestion about constructing Bytes with custom vtable. Since it's not a small modification, I want to share my direction to maintainers before writing more docs or bikeshedding etc. You can consider this PR as an executable RFC.
Related issues: https://github.com/tokio-rs/bytes/issues/359 https://github.com/tokio-rs/bytes/issues/437 https://github.com/tokio-rs/bytes/issues/526
The base idea is to expose a trait purely consists of associated functions. It's not a breaking change to add associated function with default impl to existing trait. Default impl being mandatory can be a problem, but it's an inherent problem of exposing custom vtable.
At this point this PR is consists of 5 commits. They're quite independent that I think each deserves its own PR after the consensus is made. It's possible that some of them will be advanced while others are rejected. First 2 commits are about improving current vtable signatures. it's hard to do so after stabilizing them. Next 2 commits implements custom vtable API. The last one implements downcasting.
The first commit is about changing the name of the vtable entry to_vec to into_vec to match its semantics. Changes in its signature also reduces atomic operations, though performance wasn't a goal here. I hardly expect it actually improve performance.
The second commit is to add will_truncate function to vtable. Currently promotable buffers can't discard bytes from the last without promotion, so Bytes::trucate specialize them by equality checking vtable address with 2 promotable vtable static variables. It doesn't seems like a good idea with open set of vtables.
The third commit implements the BytesImpl trait and the Bytes::with_impl constructor. It would be the main commit of this PR.
The fourth commit occupies majority of diffs this PR have, but all it does it to move functions into impl blocks. It should not add or change any behavior.
The fifth commit is about downcasting. I think round tripping between custom buffers and the Bytes is the next step people would expect. Potentially try_unsplit can also be built on top of it.
Thanks for reading. Any feedback is welcome.

Fixed minor CI issues.

Replace mem::take with mem::replace
Replace AtomicPtr::get_mut with with_mut for the loom test

There is another related request: #558

The implementation seems ok at a cursory glance. To me the main question is whether we want this or not, and if so, how should the public API of it look.

To clarify, I need this feature to run hyper with zero copy networking. The hyper uses types from the http crate which uses Bytes type everywhere, which means the HTTP headers are copied at least once unless the OS gives you incoming bytes as Bytes type. But to use io_uring optimally you need to pre-register buffers and keep reusing them over and over again, which is not possible with current Bytes interface as it deallocates buffer after the last use. With AF_XDP buffer reuse is mandatory and it has more restrictions like all the IO buffers should be equally sized slices of single large pre-registered allocation.
With custom vtables for Bytes, low level IO wrapper crates can provide its own buffer type with proper restrictions and user of that crate can convert it into Bytes. That's why impl BytesImpl requires tons of unsafe but using such types is totally safe with this PR.
I'm still not sure about those methods of the BytesImpl trait. Currently they're mostly copied as-is from the existing Vtable struct with some fixes.

@HyeonuPark - This looks great.  One concern I have is to ensure that 3rd party container implementors have everything they need to convert their containers to and from Bytes. Other than the clone method in the BytesImpl trait, I think that they should be able to.  I'll try to create an example/test that demonstrates this.
Regarding the Doc comments, I am implementing a branch against your branch that implements documentation that is more closely aligned with Tokio's conventions, and is clippy compliant.  I'll make a PR to your repo and you're welcome to merge them in if you want.
@seanmonstar -  Is there a way that we can put this implementation in a feature gate, or maybe even a major version RC so that we can incorporate it into projects for better exposure and vetting?

Thinking more about fn clone in the impl...   Maybe there should be a default implementation of clone, so that the implementor doesn't have to implement their own refcounting.
Or maybe we could implement BytesImpl for Arc where T meets certain criteria?

One more question:  Should we specify that from_bytes_parts should panic if  refcount  > 1,  or should it return a Result/Option?

For the AtomicPtr bits, we might need to re-export the relevant types fromloom::sync::atomic or core::sync::atomic to be safe.   ... and AtomicMut.
I was able to make a working impl of BytesImpl for mmap::Mmap rather easily.
I just needed to add a from_parts method to Bytes. (see below)
All that said,  I would definitely consider this the low-level  and error-prone and certainly not DRY approach to incorporating a buffer type into a Bytes container.
For basic buffer types, (both mutable and immutable) we should be able to make a much simpler interface.  clone, into_vec and from_bytes_parts could have default implementations.  We'd just need a simple intermediate wrapper type like SharedImpl.
I also think that downcast_impl and from_bytes_parts can be a footgun.  If you convert a Bytes instance back into T,  but there are still clones of Bytes around, then you create a scenario in which two different objects are responsible for dropping the buffer owned by T.    It can only work correctly if T itself had its own internal refcounting that BytesImpl uses,  but if it did, why would they need Bytes?
      pub unsafe fn from_parts<T: BytesImpl>(data: &AtomicPtr<()>, ptr: *const u8, len: usize) -> Self {
          let dptr = data.load(Ordering::Acquire);

          Bytes {
              ptr,
              len,
              data: AtomicPtr::new(dptr.cast()),
              vtable: &Vtable {
                  type_id: TypeId::of::<T>,
                  clone: T::clone,
                  will_truncate: T::will_truncate,
                  into_vec: T::into_vec,
                  drop: T::drop,
              },
          }
      }

It would be nice to make SharedImpl generic over impl AsRef<[u8]> not just for Vec<u8>. Note that it should be one from the bytes_mut.rs since the one with same name in bytes.rs is heavily optimized for Box<[u8]>. Though I'm not sure it's much beneficial since if you have custom buffer type you may want to implement refcount directly on it. It's not that hard when you have working examples on std::sync::Arc and bytes::Bytes code and you don't need to handle weak handles.
refcount > 1 on from_bytes_parts is expected on downcasting. For example if you make fresh struct MyBuffer(Arc<[u8]>, Range<usize>);, convert it into Bytes, clone it 2 times and downcast it back its refcount will be 3 on from_bytes_parts.
I haven't concerned exposing loom AtomicPtr. Maybe we need to newtype it like tokio::time::Instant?

I also think that downcast_impl and from_bytes_parts can be a footgun. If you convert a Bytes instance back into T, but there are still clones of Bytes around, then you create a scenario in which two different objects are responsible for dropping the buffer owned by T. It can only work correctly if T itself had its own internal refcounting that BytesImpl uses, but if it did, why would they need Bytes?

I really should have document if more, that multiple Bytes cloned from the same Bytes doesn't share same instance T: BytesImpl. It's like if you have #[derive(Clone)] struct Wrapper(Arc<[u8]>); multiple clones of it would share [u8] but each have its own instance of Arc<[u8]>.
The reasons why clone and drop exist as own trait methods not just implied from supertrait and automatic drop glue is to allow users to create their own StaticImpl and PromotableImpl. It's possible to make helper struct and trait to remove those methods and all that AtomicPtr and just use &self / &mut self instead. Or, maybe it would be better to make that helper trait as a sole public API, reducing API complexity a lot by sacrificing custom static/promotable buffers.

I really should have documented if more, that multiple Bytes cloned from the same Bytes doesn't share same instance T: BytesImpl. It's like if you have #[derive(Clone)] struct Wrapper(Arc<[u8]>); multiple clones of it would share [u8] but each have its own instance of Arc<[u8]>.

Right. When you convert one of the instances of Bytes back to T, but other instances of Bytes remain, you now have more than one instance that owns the inner buffer.
Let's say you have:

struct MyBuf {
    inner: Box<[u8]>,
}

When we convert MyBuf to a Bytes instance,  the new instance takes control of the [u8] from inner.  When we clone the Bytes instance,  we still have only 1 copy of [u8].  This is good.
Now let's convert one of those Bytes instances back into MyBuf  We break down the Bytes instance into its parts, then reconstruct MyBuf, giving the ownership of [u8] back to MyBuf.  So it controls the lifetime of the inner [u8]].
However, there is still an instance of Bytes, and its copy of SharedImpl also owns the [u8].
So we have a dangling pointer if either MyBuf or that instance of Bytes are destroyed.

We need to find a way to design the API such that it is impossible to convert from Bytes to T if the refcount is > 1, similar to the design of Rc and RefCell.  Also, we would need to disallow conversion from Bytes to Bytes Mut if refcount > 1.   We can use the same underlying mechanism to enforce both invariants.
If we just built and published the "Inner" Container States API:  Shared, SharedMut Promotable, PromotableMut Static, StaticMut (or whatever we end up needing to cover all use cases), then we control the transitions that are possible from each state, using a Type State.
The 3rd party implementors would be able to easily adapt their implementation without having to worry about the internals of memory management, alignment, thread-safety, etc.
Perhaps all of those above types  implement the same type, e.g. ManagedBuffer, then Bytes and BytesMut could just store a dyn ManagedBuffer, we wouldn't need to manage the VTable manually.    Is this sort of what you were referring to when you said:

It's possible to make helper struct and trait to remove those methods and all that AtomicPtr and just use &self / &mut self instead.

At a high level, we'd need a 4d matrix of functionality.  These wouldn't necessarily all be separate buffer types, but we need to ensure that we can handle them.
(de)Allocation Style:

Global Allocator        (Global Free)
3rd Party Managed  (User Supplied Drop)
Static                         (Null Drop)

Mutability:

Immutable
Mutable

Immutable -> Mutable Conversion Method

Copy on Write: Copy Buffer to Convert
Mutate Self: Assert Refcount == 1 to Convert

Clone Operation:

Naive/Optimized: Convert to into Refcounted and Increment
Refcounted:  Just Increment
Static:  No refcounting needed.

I think that we'd also need to add a method to the vtable to accomodate the potential of converting to mutable.
It'd need to be able to communicate whether or not it could mutate without copying,  then the actual operation to convert to mutable.
Converting from Mutable to immutable shouldn't need to access the VTable.. I don't think..

I'm going to attempt a version that formalizes this lower-level API, and also uses more a Typestate scheme and enum based dispatch,  which, among other things, is going to be faster than any vtable.  It should be quite a bit safer, too.   Certain state transitions will be inexpressible.

Let's say you have:
struct MyBuf {
inner: Box<[u8]>,
}
When we convert MyBuf to a Bytes instance, the new instance takes control of the [u8] from inner. When we clone the Bytes instance, we still have only 1 copy of [u8]. This is good.

MyBuf should not be converted to a Bytes since it doesn't satisfy requirements of the Bytes implementations.

All Bytes implementations must fulfill the following requirements:

They are cheaply cloneable and thereby shareable between an unlimited amount of components, for example by modifying a reference count.
Instances can be sliced to refer to a subset of the the original buffer.

Bytes doesn't have builtin refcounting mechanism. SharedImpl provides one and PromotableImpl relies on it by storing it on one if its (logical) enum variant. If MyBuf is converted to Bytes the Bytes::clone() should clone the stored MyBuf itself. Note that I used struct MyBuffer(Arc<[u8]>, Range<usize>); as an example. It provides cheap cloning via refcounting and subslicing on itself.

Now let's convert one of those Bytes instances back into MyBuf We break down the Bytes instance into its parts, then reconstruct MyBuf, giving the ownership of [u8] back to MyBuf. So it controls the lifetime of the inner [u8]].
However, there is still an instance of Bytes, and its copy of SharedImpl also owns the [u8].
So we have a dangling pointer if either MyBuf or that instance of Bytes are destroyed.

Maybe you want to convert SharedImpl<MyBuf> into Bytes instead? SharedImpl already provides Arc<Vec<u8>>-ish functionality and it's desirable to exploit it but replace the storage type. But in this case downcasting will returns SharedImpl<MyBuf> not MyBuf and like Arc<MyBuf> you should not be able to take ownership of inner type while other shared handle to it is still alive.

We need to find a way to design the API such that it is impossible to convert from Bytes to T if the refcount is > 1, similar to the design of Rc and RefCell. Also, we would need to disallow conversion from Bytes to Bytes Mut if refcount > 1. We can use the same underlying mechanism to enforce both invariants.

BytesMut can have refcount > 1 by ensuring each instance owns disjoint slice of the shared storage. I don't think it's possible to support un-freeze Bytes back to BytesMut without changing the BytesMut's structure. But disallowing refcount > 1 means BytesMut::split() allocate every time.
At this point I think those promotable impls are special enough that 3rd party promotables are not something we need. I think its purpose, besides historical reasons, is to make round trip between Vec<u8> and Bytes as cheap as possible for interoperability. If we remove it from the custom vtable's goal, the BytesImpl trait can be something like this:
unsafe trait BytesImpl: Clone + 'static where Vec<u8>: From<Self> {
    fn into_bytes_parts(this: Self) -> (*mut (), *const u8, usize);
    unsafe fn from_bytes_parts(data: *mut (), ptr: *const u8, len: usize) -> Self;
}

I don't think we don't need abstraction on mutable conversion. BytesMut doesn't seems for unified mutable buffer type with custom implementations. Each BytesImpl implementations can handle it after downcasting.

MyBuf should not be converted to a Bytes since it doesn't satisfy requirements of the Bytes implementations

Fundamentally, it's the point of this whole exercise. There are a dozen 3rd party APIs that only work with Bytes, and they're not going to change that.  We need to figure out how to use Bytes/Mut as an interface/contract for almost all refcounted buffer activities.
How we convert into Bytes is an implementation detail.  I don't care if the developer has to convert MyBuf into a SharedImpl (or SharedMutImpl or whatever).  If we're making SharedImpl a first class citizen,  then Bytes looks more and more like an Ext trait similar to FuturesExt  (like I mention in approach 4 in #437)

Maybe you want to convert SharedImpl into Bytes instead? SharedImpl already provides Arc<Vec>-ish functionality and it's desirable to exploit it but replace the storage type. But in this case downcasting will returns SharedImpl not MyBuf and like Arc you should not be able to take ownership of inner type while other shared handle to it is still alive.

If we go the route of making SharedImpl generic over <T: BytesInterop>, then each Bytes instance would need to own its own copy of SharedImpl,  so effectively Bytes would need to be generic T, or at least have some way to dynamically size itself over the container that it holds.
If the T were just a PhantomType that makes it safe to convert from SharedImpl back to T,  it's rather pointless since we'll lose the type information when we construct a Bytes instance with the SharedImpl instance.
In short, I think a generic SharedImpl is a non-starter.
I think it would be simpler and more general if all containers wrapped by Bytes operated only on *const [u8], len, and a data pointer to the original MyBuf. The developer of MyBuf would need to define a way to reconstruct their instance from those items.
It is perfectly okay for the result of  try_downcast<MyBuf>() to be Err(Error("refcount > 1")) similar to arc/rc/refcell.

BytesMut can have refcount > 1 by ensuring each instance owns disjoint slice of the shared storage. I don't think it's possible to support un-freeze Bytes back to BytesMut without changing the BytesMut's structure.

Then we should change BytesMut's structure.

But disallowing refcount > 1 means BytesMut::split() allocate every time.

It is also perfectly ok if  Bytes::try_unfreeze(other_buf)  returns Err(Error("refcount > 1"))

At this point I think those promotable impls are special enough that 3rd party promotables are not something we need.

I agree.  I don't think that the users of MMap and others care if they get an optimization that skips refcounting.  They're converting their buffer to Bytes instance expecting it to get the Atomic refcounting baggage.
That said,  I think if a developer wants to implement the Promotable functionality for their buffer type, then they should be allowed to be.  I think it would be a matter of implementing Into<PromotableShared>  or similar.
I think that we can have a handful of types for

It wasn't intended to make generic SharedImpl a first class citizen. If we decide to make it, it would be a helper type on top of the BytesImpl API for users who don't want to reinvent whole refcounting stuff on their own since we already have one. It at least doesn't cover my own use case.
Let me describe my own use case. First user creates a context. The context mmap a large memory, do some mlock stuff, split them into aligned chunks and push them all into its own queue. Each chunk stores inline refcount and pointer to the context on its first few bytes. User acquire new mutable buffer from context by pop the queue, write into it, and freeze it to construct clonable, sliceable and immutable buffer type. On drop with refcount 0 it pushes itself into the context queue. And I want to make this immutable buffer BytesImpl.

I don't think that the users of MMap and others care if they get an optimization that skips refcounting. They're converting their buffer to Bytes instance expecting it to get the Atomic refcounting baggage.

I'm not sure about it. Single thread runtime or runtime per thread users may want to have hybrid refcount and optimistically use unsynchronized field on original thread. Will it actually boost performance? I don't know but I don't want to prevent it. Also my own use case is an example to manage refcount internally to not have separate allocation for refcount. If user don't want to handle atomic refcounting baggage they may use helper libraries, like generic SharedImpl.

It is perfectly okay for the result of try_downcast() to be Err(Error("refcount > 1")) similar to arc/rc/refcell.

Semantically it's perfectly ok, but is it useful? One of the major use case of BytesMut is to reduce allcations on handling unsized data. To do so each allocations should be large enough to host about 4 to dozen expected size of BytesMut handles. Which means they rarely have refcount 1.

You mention the downcasting approach for Bytes -> ByteMut conversion.  I guess we should try to implement that for SharedImpl and see how it works.

I made a PR with my proposed module and naming changes:  https://github.com/HyeonuPark/bytes/pull/2
I will make an additional PR following that with some takes at implementing try_resize and try_into_mut to support the  unfreeze and unsplit methods.

One other side effect of this module refactoring is that it makes it very simple to put any allocations behind a feature flag.

What's the status of this change? Seems stale for a year now, I'm waiting on this, is this abandoned?


Consider adding runtime APIs

It would be super convenient if our resource types also exposed the runtime APIs for those types.  For instance, aws.sqs.Queue could have send, etc. functions on it.  These would be thin wrappers that basically just merge the Pulumi SDK with the target SDK in the language of choice.  For example, that SQS example would just export a subset of these functions directly: https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SQS.html
There are alternative designs, of course, such as separate libraries.  I'll admit that's where my mind was previously, but at this point, it feels like "low risk" to depend on the actual official AWS SDK libraries -- they version presumably far less frequently than we do, and probably have a better breaking change discipline -- and it's very appealing for this sort of thing to "just work."  It also significantly highlights a unique aspect of Pulumi's platform, which is the use of real languages.

@joeduffy is this still something we need now that we have awsx?

I’d say we should close this out in its current form. We’ve added aws.sdk which provides a handle to an AWS SDK instance at runtime which in practice is a substitute for this (but without inventing a new API surface area).


Close shader in Shader Editor tab when deleting shader file in FileSystem panel

Fixes #72595
It works as the same with built-in script editor, when you delete the file in the filesystem panel, the editor should close the relating tab.

Thanks!

I just discovered that set_meta() is used wrongly here. It gets attached to shaders and saved in the file, which shouldn't be happening.


Is there anyone who could explain the benefits of stack-based GP over other GP methods?

In the GP domain, there are numerous types of GP methods. However, I was unable to find a systematic review of the appropriate application scenarios for those methods. I discovered that the majority of the current literature prefers the tree-based method. However, it is obvious that the tree-based representation may be difficult to modify using the mutation or crossover operators. Stack-based, linear-based genetic programming methods or grammar evolution appear to be a competitive alternative to traditional tree-based methods. However, is there any literature that illustrates the advantages or disadvantages of these three similar methods? In my opinion, stack-based methods appear more promising in recent years because there is still a lot of work being done in this domain, whereas the other two methods receive little attention, but I am not sure if this is correct.

Typically the "issues" page for a GitHub repository is intended for discussion about the development of codebase. Your question doesn't related to PyshGP specifically, but rather the GP field as a whole. For future reference, I am sure you will get a more complete answer to your question in a different community. Perhaps the genetic programming tag on the data science stack exchange.
Lucky for you, the question you asked is something I am passionate about and have spent a long time researching and communicating so I will give you a brief answer. :)

As you mentioned, trees are difficult to modify for a few reasons: 1) they bloat and 2) that are difficult to keep type-safe.

The reason why most of the literature uses trees is because most of literature is focused on the symbolic regression/classification problem domain where there programs are arithmetic formulas that only contain one data types: numbers. Therefore, it is trivial to modify a tree and keep it type-safe. Stack-based and grammar-based methods were developed to evolve programs that use a "general" set of types, and thus can solve "general program synthesis" tasks.

There is a lot of active research in stack-based, grammar-based, and linear GP. In case you haven't seen it, this paper covers all 3 families of methods in a wonderful comparison that coder the relative trade-offs.


multithread_publisher with custom_transport

Hello,
I would like to use the multithreaded publisher example with custom_transport via a usb cable. We are using the latest foxy branch.
Unfortunately I get a continuous reconnection on the host side with the publishers being created but then the client getting deleted.
Does anyone know what the issue may be?
Thanks

Hi @shecker, a few questions:

Did you modify the example in any way? (I see three publishers are created instead of two as in the example).
Does your code works with the default UDP or the provided serial transport?
Could you elaborate on how your custom transport works?

I believe the issue occurs when I change this line from ON to OFF:
"-DUCLIENT_PROFILE_MULTITHREAD=ON"

That is expected, this option enables micro-ROS multithread support.
It needs to be enabled for any multithreaded app.


gitops add app --help output is wrong --url or  at least one is required

./gitops version
Current Version: 0.5.1-rc3
GitCommit: b9e1433c0c1a5ee82481e1beb16f0a5bff66a42c
BuildTime: 2021-12-08T20:51:00Z
Branch: HEAD
Flux Version: v0.21.0

Getting the help output for add app :
./gitops add app --help
Associates an additional application in a git repository with a gitops cluster so that its contents may be managed via GitOps

Usage:
gitops add app [--name ] [--url ] [--branch ] [--path ]  [flags]
This is wrong one of --url or  is required. The correct syntax guidance could look like this :
Usage:
  gitops add app [--name <name>] (--url <url> [--branch <branch>] [--path <path within repository>] | <repository directory>) [flags]

Though it might be better to include two lines to keep readability :
Usage:
  gitops add app [--name <name>] --url <url> [--branch <branch>] [--path <path within repository>] [flags]
  gitops add app [--name <name>] <repository directory> [flags]

Thanks for raising @LutzLange. Minor point of clarification is that path and branch can also be set when using a local repository i.e. gitops add app --path ./deploy/kubernetes/helm-chart --app-config-url https://github.com/sympatheticmoose/tmp-gitops --branch blah
So I believe the usage should be:
gitops add app [--name <name>] (--url <url> | <repository directory>) [--branch <branch>] [--path <path within repository>] [flags]

I'm not sure which lib you are using for parsing cmd options, and did not test ordering of options.


I don't know if this is a issue related to the addon, anyhow you will recognize ant tell me if not. I get this warning on the  log a the addon startup :

Version of the add-on

Configuration

Add your configs here.

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
If applicable, describe the steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Debug log

Add your logs here.

Additional context
Add any other context about the problem here.

/usr/local/bin/monitor: line 1987: [: : integer expression expected

I use NUC hassoos 3.9 and Hassio 0.104.3

I'm sorry, this issue does not apply to the addon, but to the main script. I can not help you. It’s more correct to open a new issue here: https://github.com/andrewjfreyer/monitor/issues/new
And please... templates are created so that developers can get all the necessary information about your problem in a form convenient for fixing it as quickly as possible. Please do not be surprised if your bug report is left unanswered if you ignore the proposed template.


feat(curriculum): adjust info-sec for gitpod

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Related to: https://github.com/freeCodeCamp/freeCodeCamp/issues/53470

This should be good to go once the links and text for the Port Scanner and SHA-1 Password Cracker projects are update.


Disable Shared Folder (shares)

Is there an option to disable shared folder (shares) in case if we allow multi users ('allow_multi_user'      => true) but we don't want to have shares folder?

Haven't support this feature for now.
You can modify files in /vendor/unisharp/laravel-filemanager/src/views/ to hide shares folder.

@g0110280  Ok, thanks! I just removed:

       {{ Lang::get('laravel-filemanager::lfm.title-shares') }}

from tree.blade.php and it seems that's all I have to do (for now).

You can also set the config option shared_folder_name to ''. When I did that, I changed the images_url to remove the trailing slash as it would make urls like files//directory. Due to the reuse of the function that handles this, I couldn't adequately get it to stop appending that extra /. I likely could if I had more time.
I think setting it to null or having it optional would be useful. When you click Back you can't go up to the parent directory with shares/ in it. I think shares makes sense under a multi user scenario but in my case with no multi users I'd rather there it default to having no shares folder and everything is just in the root.

@w0rd-driven Thanks for your advice!
We might add your suggestion to v1.7.

Is there a new workaround for removing the shared folder?

Please follow the upgrade document and upgrade to v1.7.1.


enhancerow policy support catalog and match name instead id

Proposed changes
Follow up #32137
storage name instead id to meta,Prevent table deletion and reconstruction and  causing ID changes
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall


Upgraded pcodec to 0.2 and used new ModeSpec configuration

Upgraded Pcodec to 0.2. The main API change is replacement of individual mode specs with a single spec for all modes.

It seems the lines the coverage report is complaining about are deliberately unreachable (with correct mypy typing)

Now this is confusing

Oh it looks like it's failing due to unrelated changes from the merge (something zfpy). And I can't tell why ruff is complaining with this last commit... it passes locally, and the "Details" page doesn't say what file it's failing on. @rabernat @normanrz are we good to merge this?

Thanks for your patience with our over-eager CI @mwlon! 🙏
Yes, you're right that #540 broke our coverage test, so we can ignore that. I wish we could fix pre-commit though. I'll see what I can do.


Switch between express forms when creating and updating entries

This pull request enables switch between available express forms when creating or updating express entity entry.

I'm not sure what this is meant to do. Can you explain?
Additionally with this pull request applied I get this error when trying to view a detail form report entry in the Dashboards:
Argument 3 passed to Concrete\Controller\Element\Dashboard\Express\Forms::__construct() must be an instance of Concrete\Core\Entity\Express\Form, null given, called in /home/vagrant/projects/concrete5/concrete/single_pages/dashboard/express/entries/update.php on line 5

Hi, the idea is to have a posibility to switch between different express forms when creating or updating an entry. Right now you can only add a new entry through default express form fot the given enitity. I see there is an error, maybe i should create a new pull request, of cours if you think that makes sense.

I think we want to stick with the current behavior, at least for the time being. I could see there being a use case for letting you choose different forms, but we want to be really thoughtful about how we do it and the use case for it.

Alright,thanks for your time.
On 29.08.2018. 16:33, "Andrew Embler"<EMAIL_ADDRESS>wrote:

I think we want to stick with the current behavior, at least for the time
being. I could see there being a use case for letting you choose different
forms, but we want to be really thoughtful about how we do it and the use
case for it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/concrete5/concrete5/pull/6947#issuecomment-416975635,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJEkJpfhK9J35tP_oFa0BPqijP-CqzN3ks5uVqYzgaJpZM4VvWY1
.

Let me follow up on that:
We made that change because we have some fields in the express object that should only show up for the content editor but not on the form for the user. Let's say some extra internal comment or field to store the source of the entry. Yet once you have defined a form this becomes the default form and thus the only way to edit the entry. Our change uses the same logic and controls as for switching between express objects and allows to select the form you want/need.


Don't short cut prepared stream insertions

Now that they're foreign tables, the normal prepared insert path should just work

Where are they being short circuited? This should have already been taken care of when we moved to the FDW.

Oh, I thought we hadn't. Invalid issue.


Raspberry camera doesn't work with Jetson nano

2020-02-07 21:51:26,091 - DEBUG - V4l2 device input: Camera 0:2
2020-02-07 21:51:26,092 - INFO - v4l2 device /dev/video0 is a camera, autoselecting
2020-02-07 21:51:26,092 - DEBUG - V4l2 device input: Camera 0:2
2020-02-07 21:51:26,092 - DEBUG - driver: tegra-video
2020-02-07 21:51:26,092 - DEBUG - card: vi-output, imx219 6-0010
2020-02-07 21:51:26,093 - DEBUG - Camera format: 10-bit Bayer RGRG/GBGB
2020-02-07 21:51:26,094 - DEBUG - Format: yuv : 10-bit Bayer RGRG/GBGB
2020-02-07 21:51:26,094 - DEBUG - Format: mjpeg : 10-bit Bayer RGRG/GBGB
2020-02-07 21:51:26,094 - DEBUG - Format: h264 : 10-bit Bayer RGRG/GBGB
2020-02-07 21:51:26,094 - CRITICAL - Error constructing pipeline: ValueError('Error detecting camera video format'), retrying in 10 sec

Moved to https://github.com/goodrobots/visiond/issues/6


Delete submission 65fd9a92db8d9f000196d674

This submission is attached to body of work GCP000853.
I (Elliot) created the submission by mistake under my own user name while trying to investigate an issue that the user was having when trying to create a submission. There is no data in the submission yet.
This submission needs to be deleted, and the body of work needs to become open for submission again, so that the user can create a submission under their own user name.

@eks-ebi done


Minor developmental update

Allow later versions of selenium on local
Readme minor style tweaks
Cleanup spec_helper and alter default formatter to documentation
Remove default JS driver to be selenium (Already set)

ping @TheMetalCode


Magnifying glass at the bottom of the page

Magnifying glass at the bottom of the page.
Action: investigate and fix CSS.

This was a button for closing the search modal that was on top of the documentation before the split. Search is now a separate url, so this button had to go.


Update?

Is this still in development? downloaded it from flipc.org but nothing on the addon is working.

yes, it's still in development, and it's going to be for a long time join
flipper xtreme discord there are more information there in the bounty
channel
On Sat, Dec 16, 2023, 11:53 p.m. Roast247 @.***> wrote:

Is this still in development? downloaded it from flipc.org but nothing on
the addon is working.
—
Reply to this email directly, view it on GitHub
https://github.com/mavenboard/flipperesl/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/A6CIWFKT3IWPK7ZQVXNU3ADYJ2QHHAVCNFSM6AAAAABAYFMF4GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2DKMJRGY4TIOA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


added API to allow encoding and decoding to/from Generic record, to a…

…llow integration with Schema Registry (AWS Glue)

Good to merge when CI passes!


Infer/Assign relevant RIDs for the user

Right now, for the most efficient framework-dependent containers, a user has to enter a command like
dotnet publish -c Release --os linux --arch x64 -p:PublishProfile=DefaultContainer

manually specifying the OS and Arch (or, alternatively the entire RID via -r). In cases where we know something about the destination container (through inference?) is it possible to perform the build/publish cycle with a RID taken from that image's metadata?
Ideally, I'd like for the command dotnet publish -c Release -p:PublishProfile=DefaultContainer to have the same information as the command above.

Is it possible to infer this? Aren't there Windows-based containers with the same multi-arch image name, for example mcr.microsoft.com/dotnet/runtime:6.0 is an alias for both Debian 6.0.8-bullseye-slim-amd64 and Windows Sever Core 6.0.8-windowsservercore-ltsc2022. I was hoping we could infer which of those was right from the RID 🙃

That's a good point - RID should influence base image selection (and that's not something we're doing quite yet). It's very common for users to put these kinds of properties in a PublishProfile so that it's all wrapped up in a nice bow, so we could just lean into that.
Of course, that means that we'll likely need a doc section on customizing the publish profile for use in this way.

We do this inference assumption now.


Duplicated tests to be executed on workspace

Type: Bug

Create a workspace
Add two projects on it with their respective tests
Go to "Testing" section (flask icon) and discover tests from both projects.
Click on the "Run Tests" icon (two play icons one placed below another) located in the upper part next to the TESTING title.
Below the filter it'll begin to run the tests up to finishing with the "Running tests, N/N passed (100%)" where N is the amount of tests from both projects.
Run tests again but this time of only one of the projects clicking on the "Run Test" icon that appears once you hover on one of  the projects name.
The "Running tests"'s numbers now will be higher than initial N, being N+K where K is this selected project's amount of tests.
It'll be reset again to N once those tests have finished.

The expected behavior would be to begin the step 6 with N - K to reach again the desired and total N.
To explain this in a better way, take a look to the existent workspace with two projects that are identical (pypika and its clone). There are 2236 between both projects:

So if one project is removed from the workspace then the amount of tests is the half then:

However when both projects' tests have been executed and the tests from one particular project are re-executed, the amount of total tests while they're running is increasing:

Once finished the total amount of tests back to the right value.
VS Code version: Code 1.70.0 (da76f93349a72022ca4670c1b84860304616aaa2, 2022-08-04T04:38:48.541Z)
OS version: Linux x64 5.15.0-46-generic
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz (8 x 1900)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
15.51GB (1.55GB free)

Process Argv
--crash-reporter-id 6e680e2a-6a43-41d5-8e91-5904f8b850ea

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
x11

Extensions (19)

Extension
Author (truncated)
Version

increment-selection
alb
0.2.0

Bookmarks
ale
13.3.1

vscode-eslint
dba
2.2.6

gitlens
eam
12.1.2

EditorConfig
Edi
0.16.4

RunOnSave
eme
0.2.0

prettier-vscode
esb
9.5.0

randomeverything
hel
0.0.3

smarty
imp
0.3.0

python
ms-
2022.12.0

vscode-pylance
ms-
2022.8.20

jupyter
ms-
2022.7.1102252217

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.9

remote-containers
ms-
0.245.0

vscode-selfhost-test-provider
ms-
0.3.10

vsliveshare
ms-
1.0.5683

autodocstring
njp
0.6.1

vscode-yaml
red
1.9.1

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30542924
vsaa593:30376534
pythonvs932:30410667
wslgetstarted:30449410
cppdebug:30492333
pylanb8912:30545647
vsclangdf:30486550
c4g48928:30535728
d7fjc500:30543455
dsvsc012cf:30540253
azure-dev_surveyonecf:30545436

Hello! Could you please provide the logs for this problem? Additionally the repo you are running is pypika correct and you are running all tests in that repo with a cloned version? Thanks!

Hello! I just wanted to follow up to see if you are still having this problem and if so could you provide the logs so I can investigate further? Thanks!

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.


Barrier for local device buffer question.

Hello,
Is it a typo in function VulkanTexturedQuad::CreateMeshBuffers in barrier specification? Here you're setting the source stage as VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT and destination stage as VK_PIPELINE_STAGE_TRANSFER_BIT. Shouldn't it be the other way around? As I see it, if (for the vertex buffer, for example) the pipeline reached a point where it needs to read a vertex (dstAccessMask = VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT) it can get the wrong data because VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT stage already passed even if transfer was not completed. Even more, the documentation mentions that VK_ACCESS_TRANSFER_WRITE_BIT access can happen only in VK_PIPELINE_STAGE_TRANSFER_BIT stage which is definitely lower that VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT. And even even more - the layers are complaining:

layer DS: vkCmdPipelineBarrier(): pBufferMemBarriers[0].srcAccessMask (0x1000) is not supported by srcStageMask (0x1). The spec valid usage text states 'Each element of pMemoryBarriers, pBufferMemoryBarriers and pImageMemoryBarriers must not have any access flag included in its srcAccessMask member if that bit is not supported by any of the pipeline stages in srcStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkCmdPipelineBarrier-pMemoryBarriers-01184)
layer DS: vkCmdPipelineBarrier(): pBufferMemBarriers[0].dstAccessMask (0x4) is not supported by dstStageMask (0x1000). The spec valid usage text states 'Each element of pMemoryBarriers, pBufferMemoryBarriers and pImageMemoryBarriers must not have any access flag included in its dstAccessMask member if that bit is not supported by any of the pipeline stages in dstStageMask, as specified in the table of supported access types.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkCmdPipelineBarrier-pMemoryBarriers-01185)

Upd.: and for the VulkanQuad::CreateMeshBuffers you're not using any barriers at all and I could't find any waiting for idle queue or device. Why?

Sorry I didn't see this earlier. The vertex buffers etc. don't need a further sync, because the work only kicks off after the CPU side is done (notice they're in CPU memory in VulkanQuad, but in GPU memory in VulkanTexturedQuad, and hence that needs a barrier.) I just checked with VK SDK 1.1.73 and the validation layer is not complaining. Is the validation failure in VulkanTexturedQuad or VulkanQuad?


Launch and immediate quit crashes "OmniCore-Qt quit unexpectedly" on Mac OS X.

To reproduce:

Launch OmniCore-Qt by double-clicking
As soon as the start screen with the 'Verifying Blocks' message appears, type Command-Q (quit)
It will take a while before the quit command is received and acted upon, but when it is the app crashes.

Attached is the crash log.
MacOSCrash.txt

After step 2, I assume there is a new window, indicating a shutdown?
My guess right now is that this is an upstream issue, because the Omni parts are not yet initialized at this stage. Nevertheless, we should take a look at this.
Could you please try to add debug=1 and omnidebug=all to your bitcoin.conf, then try again and paste the last lines of the debug.log and omnicore.log (if there is any content)?

Also, are you able to reproduce the issue with a stock Bitcoin Core 0.10.4 build?
Here are the binaries for 0.10.4-rc1 (which was then released as release): https://bitcoin.org/bin/bitcoin-core-0.10.4/test/

After step 2, I assume there is a new window, indicating a shutdown?

Yes.

Also, are you able to reproduce the issue with a stock Bitcoin Core 0.10.4 build?

I have stock Bitcoin Core Qt 10.2 and yes it crashes, too.

I created an upstream issue. It would be nice, if you could try it with Bitcoin Core 0.11 (or master) as well, and attach the debug.log.

No problem switching back and forth between Bitcoin Core Qt 0.11 and Omni Core Qt 0.0.10RC3?

No problem switching back and forth between Bitcoin Core Qt 0.11 and Omni Core Qt 0.0.10RC3?

Yes, this isn't a problem and switching back and forth is supported.

Looks like this was resolved https://github.com/bitcoin/bitcoin/issues/7163#issuecomment-259925664.


Cancelable navigation

Looks like we were both working on this at the same time!
See  https://github.com/Windows-XAML/Template10/commit/28a003670a2b535bcdab494fb9d96f5532430009


Add .whitesource configuration file

NACK
IDE config files should be kept locally to avoid polluting contributors source trees with unnecessary files.


CocoaPods could not find StartupReasonReporter (~> 0.2.0)

CocoaPods can find StartupReasonReporter 0.1.0 but Unable to read the license file LICENSEfor the specStartupReasonReporter (0.1.0)``
Besides, CocoaPods can't find StartupReasonReporter (~> 0.2.0)
Analyzing dependencies
[!] CocoaPods could not find compatible versions for pod "StartupReasonReporter":
  In Podfile:
    StartupReasonReporter (~> 0.2.0)

None of your spec sources contain a spec satisfying the dependency: `StartupReasonReporter (~> 0.2.0)`.

You have either:
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

Note: as of CocoaPods 1.0, `pod repo update` does not happen on `pod install` by default.

I'm also seeing this

@michaeleisel @Marvae The documentation is incorrect.
There is no 0.2.0 version of this.
Best is to add   pod 'StartupReasonReporter'
Ps: Current version is (0.1.0)


The name 'Response' is defined in the libraries 'package:dio/src/response.dart (via package:dio/dio.dart)' and 'package:get/get_connect/http/src/response/response.dart'.

Describe the bug
Should there be a conflict here?
Reproduction code
Test the following
example:
import 'package:dio/dio.dart';
import 'package:logger/logger.dart';
import 'package:get/get.dart';

final ourApi = Dio();
final Logger logger = Get.find<LoggerController>().logger;

final handleExpiredTokenInterceptor =
    InterceptorsWrapper(onError: (error) async {
  if (error.response?.statusCode == 403 || error.response?.statusCode == 401) {
    logger.d('Access Token not active. Getting a new one via a Refresh Token.');
    AuthController c = Get.find();
    final accessToken = await c.refreshMyToken();
    return _retry(error.request, accessToken);
  }
  return error.response;
});

// ISSUE IS HERE
Future<Response<dynamic>> _retry(
    RequestOptions requestOptions, String accessToken) async {
  final options = new Options(
    method: requestOptions.method,
    headers: requestOptions.headers,
  );
  options.headers['Authorization'] = 'Bearer $accessToken';
  logger.d('Sending request again with new token');
  return ourApi.request<dynamic>(requestOptions.path,
      data: requestOptions.data,
      queryParameters: requestOptions.queryParameters,
      options: options);
}

To Reproduce
Not needed
Expected behavior
No conflict.
Flutter Version:
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel dev, 1.26.0-1.0.pre, on Microsoft Windows [Version 10.0.19042.685], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.8.3)
[√] Android Studio (version 4.1.0)
[√] VS Code (version 1.52.1)
[√] Connected device (1 available)

Getx Version:
3.23.1
Describe on which device you found the bug:
Window Desktop
Minimal reproduce code
Not needed
Workaround:
If I do:
import 'package:get/get.dart' as GET;

and then something like:
final Logger logger = GET.Get.find<LoggerController>().logger;

all is well.

Do:
import 'package:get/get.dart'  hide Response;

Do:
import 'package:get/get.dart'  hide Response;

And if I was using GetConnect?

And if I was using GetConnect?

import 'package:dio/dio.dart‘ hide Response;

import 'package:dio/dio.dart‘ hide Response;

Thanks

Thanks

@eduardoflorence Thanks for the great package! Basically this is the most loved flutter package we use so far, well done!
Regarding this issue, just curious would it be better for user to import separately if they need to use the GetResponse? as Dio is quite a common and popular package.

@eduardoflorence Thanks for the great package! Basically this is the most loved flutter package we use so far, well done!
Regarding this issue, just curious would it be better for user to import separately if they need to use the GetResponse? as Dio is quite a common and popular package.

Hi @itwondersteam, I'm glad you like Getx, I love him too. I am not the owner of this package, I am just a contributor. Jonny has already explained in another issue about the reason for incorporating GetConnect, please take a look at it:
https://github.com/jonataslaw/getx/issues/850

Hi @itwondersteam, I'm glad you like Getx, I love him too. I am not the owner of this package, I am just a contributor. Jonny has already explained in another issue about the reason for incorporating GetConnect, please take a look at it:
https://github.com/jonataslaw/getx/issues/850

@eduardoflorence thanks for the pointer, and it is great to see where Getx is heading to. The idea of integrate everything in one place without it breaking due to incompatibility is just awesome!
Having said that, I still feel it might be better to import Response separately, for the reason

some project have already using Dio before Getx
auto import is easy (when we need to use GetConnect)
putting hide Response is no fun, and you will not expect to have error until you compile the program
so it is better to name common term with prefix, e.g.XResponse to avoid such issue.

Just my 2 cents, but understand that there might be other consideration that I have not thought of!
 Well done Sir, @jonataslaw

@eduardoflorence thanks for the pointer, and it is great to see where Getx is heading to. The idea of integrate everything in one place without it breaking due to incompatibility is just awesome!
Having said that, I still feel it might be better to import Response separately, for the reason

some project have already using Dio before Getx
auto import is easy (when we need to use GetConnect)
putting hide Response is no fun, and you will not expect to have error until you compile the program
so it is better to name common term with prefix, e.g.XResponse to avoid such issue.

Just my 2 cents, but understand that there might be other consideration that I have not thought of!
 Well done Sir, @jonataslaw

import 'package:dio/dio.dart‘ hide Response;

Thanks dude.

Since I'm using Response from Dio for type hinting, then I prefer to hide Response from Get with this
import 'package:get/get.dart' hide Response;

Since I'm using Response from Dio for type hinting, then I prefer to hide Response from Get with this
import 'package:get/get.dart' hide Response;

sorry to say, but it was answered in previous comment 😂

Since I'm using Response from Dio for type hinting, then I prefer to hide Response from Get with this
import 'package:get/get.dart' hide Response;

sorry to say, but it was answered in previous comment

It's different actually. The previous hide from Dio, but mine hide from Get

Do:
import 'package:get/get.dart' hide Response;

@ghenry this is previous answer.

Ah yes, sorry, missed that :+1:

You have to add prefix to the Response when you are using get library.
add one more line for dio and give name to it
import 'package:dio/dio.dart' as DIO;
now add it Response,
DIO.Response

Do:
import 'package:get/get.dart' hide Response;

THANKSSSS ...

You have to add prefix to the Response when you are using get library. add one more line for dio and give name to it import 'package:dio/dio.dart' as DIO; now add it Response, DIO.Response

Thanks this worked in my case I got this error:
The name 'FormData' is defined in the libraries 'package:dio/src/form_data.dart (via package:dio/dio.dart)' and 'package:get/get_connect/http/src/multipart/form_data.dart'. Try using 'as prefix' for one of the import directives, or hiding the name from all but one of the imports.
Then I fixed it with the help of this comment:
import 'package:dio/dio.dart' as dio;
var data = dio.FormData.fromMap({
'mobile': phoneNumber,
});

You have to add prefix to the Response when you are using get library. add one more line for dio and give name to it import 'package:dio/dio.dart' as DIO; now add it Response, DIO.Response

Thanks this worked in my case I got this error: The name 'FormData' is defined in the libraries 'package:dio/src/form_data.dart (via package:dio/dio.dart)' and 'package:get/get_connect/http/src/multipart/form_data.dart'. Try using 'as prefix' for one of the import directives, or hiding the name from all but one of the imports.
Then I fixed it with the help of this comment:
import 'package:dio/dio.dart' as dio; var data = dio.FormData.fromMap({ 'mobile': phoneNumber, });

Thank you !

Try this
import 'package:dio/dio.dart' hide Response, FormData, MultipartFile;


Replace Exceptions with an error metric and log

I love this mod, but I have one issue with it. Currently the exporter script doesn't catch file read exceptions, and will also write the entire stacktrace to STDOUT. This is a major problem since a newly created save file will not contain a metrics.json object, and will immediately throw a FileNotFoundError when the exporter is deployed.
This can cause the container to fail, and Kubernetes will reschedule the pod (including the Factorio server itself).
This handles these file read errors more gracefully, and provides a permanent record of them as a metric.

I love this mod, but I have one issue with it. Currently the exporter script doesn't catch file read exceptions, and will also write the entire stacktrace to STDOUT. This is a major problem since a newly created save file will not contain a metrics.json object, and will immediately throw a FileNotFoundError when the exporter is deployed.
This can cause the container to fail, and Kubernetes will reschedule the pod (including the Factorio server itself).
This handles these file read errors more gracefully, and provides a permanent record of them as a metric.

Nice, I'll take a closer look here in a bit. I've been wanting to perform a general cleanup of the rough edges of the mod.
Haven't thought about this particular case as I personally run the exporter in a separate pod, but having them in the same pod would be a common approach as well.

@ZCK12 This (with some minor cleanup) was given some smoke tests and released in v0.1.2 of the mod, and I'll start working on cleaning up and smoothing over some of the other issues I want to tackle in another branch. Thanks again!


[docs/tutorials/essentials/part-2]: grammatical error fixed

We don't use "that" in descriptive clause.
Thanks for the PR!
To better assist you, please select the type of PR you want to create.
Click the "Preview" tab above, and click on the link for the PR type:

:bug: Bug fix or new feature
:memo: Documentation Fix
:book: New/Updated Documentation Content

Thanks!


Doesn't support Windows

i cannot install @google-cloud/translate on windows
npm install --save @google-cloud/translate
->
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

It's just a warning and an optional dependency. Have you noticed any errors?

after that warning
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Users\XXXXX\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js" "install" "--save" "@google-clou d/translate"
npm ERR! node v7.1.0
npm ERR! npm  v4.0.2
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the grpc package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs grpc
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls grpc
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\XXXXX\npm-debug.log

Can you open this issue on the grpc repo mentioned in the error? https://github.com/grpc/grpc

node-pre-gyp ERR! Tried to download(404): https://storage.googleapis.com/grpc-precompiled-binaries/node/grpc/v1.0.1/node-v51-win32-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(no de-v51 ABI) (falling back to source compile with node-gyp)

on my mac it works fine

Yes, please report this over on the gRPC repo and link back.


Add 'Segoe UI'

Almost every other app in Windows uses 'Segoe UI' and it'd be nice if WebTorrent Desktop uses the same.

Nice, makes a big difference!

Before:

After:

The only change I'm going to make to this PR is to put the 'Segoe UI' font in an .app.is-win32 CSS selector so some poor designer who owns a Mac and has 'Segoe UI' installed doesn't somehow end up with the UI using that font. Because I'm not sure if the 'BlinkMacSystemFont' works on prior versions of OS X.

Fixed here: https://github.com/feross/webtorrent-desktop/commit/9ad0316dffe9ac189a310f4a42d0dd89fbd14259

Thanks for the fix and quick approval!

Will be part of the next release, probably v0.13.0 or v1.0


Function to get the connection status of one of the device among  set of devices sharing same connection ID

Hi,
We are using 3 devices connected to the same IP address and Port. But they are having different address and using the same connection ID. If one of the intermediate device is down, will the ControlPanel.IsOnline() function provide us the connection status of that particular device which is down?
Is there any other way to know that one out of the 3 device is down/Communication is offline? They are all using the same connection ID and other 2 devices status is online.
Regards,
Deepa

There are two methods of getting the online status
For ad-hoc query, call IsOnline method from the ControlPanel object
        /// <summary>
        /// Is the PD online
        /// </summary>
        /// <param name="connectionId">Identify the connection for communicating to the device</param>
        /// <param name="address">Address assigned to the device</param>
        /// <returns>Returns true if the PD is online</returns>
        public bool IsOnline(Guid connectionId, byte address)`

To get real-time status updates, subscribe to the ConnectionStatusChange event. An example of this is in the Test Console project
     _controlPanel.ConnectionStatusChanged += (_, args) =>
            {
                DisplayReceivedReply(
                    $"Device '{_settings.Devices.SingleOrDefault(device => device.Address == args.Address, new DeviceSetting() { Name="[Unknown]"}).Name}' " +
                    $"at address {args.Address} is now " +
                    $"{(args.IsConnected ? (args.IsSecureChannelEstablished ? "connected with secure channel" : "connected with clear text") : "disconnected")}",
                    string.Empty);
            };

Let me know if there are any issues with either of these methods.

Thanks for this information. I used both these methods to get the status of the device. But when one device is down, IsOnline function is returning false for all the devices(with other address) which are using the same connection ID.
Please find the sample code and the screenshot of the output attached.

SampleProgram.txt

This is the same issue as #87 that you submitted earlier. I need to find out more about your hardware in order to figure out a resolution. Please contact me directly at<EMAIL_ADDRESS>


Danieli - "Stergeti" button not functional

ENVIRONMENT: Validator.ui
URL: URL: Validator
Company_careers_url: Danieli
Desktop:
OS: Sonoma 14.6.1
Browser: Chrome
Version: 129

STEPS TO REPRODUCE:

Type "Danieli" in the search field.
Click on "Vizualizeaza Joburi".
Click on "Stergeti" button on the job listing card.

EXPECTED RESULTS:
Job listing is deleted from the list.

ACTUAL RESULTS:
Clicking the "Stergeti" button does not delete the job listing.
Job remains active in the list and in production.

Fixed...


The page for library available in KnowledgeCafe dropdown is not accessible

Describe the bug
Empty page is displayed when accesing Library available in KnowledgeCafe dropdown
Refer screenshot

To Reproduce
Steps to reproduce the behavior:

Go to KnowledgeCafe
Click on Library

Expected behavior
The page for Library should be loaded with content associated with it

The issue is fixed please refer screenshot


Update about page to include scope, updated mission

This PR will add a scope statement, and updated language for the mission (since we have clarified scope). Note this is not quite ready to merge yet, as the mission language may change slightly based on additional feedback from the FIT committee.

Feedback from FIT committee recieved, so updating scope and mission statement


Added profiler + heroku config

Coverage decreased (-0.4%) to 66.667% when pulling 2d2e2d4ae88a8e57b97eef4c352b7abcd2778ef3 on pancho111203:master into 3e684d7ba5b52160f759442bdbf98ff9a6b18527 on eclipsesource:master.

Coverage decreased (-0.4%) to 66.667% when pulling 4735aaf1f020f63b076fe2afdb1f562dc9dd4449 on pancho111203:master into 3e684d7ba5b52160f759442bdbf98ff9a6b18527 on eclipsesource:master.


feat(json): introduce MarshalJSONHex

A bit of an edge case, but cannot seem to get payload unmarshalling to be happy.

I don't quite see the point of this. The MarshalJSONHex is not part of any interface that I know of, so it cannot be auto-detected and used by encoders. And if you need to explicitly use it, you might aswell just use Hex() directly.

In geth right now you have to write a custom marshal function if the consensus side type of your ExecutionPayload uses a uint256, else geth will freak out.

How does this PR make any difference, though?


add calico support for DC/OS

High-level description
As comments and conversation of the earlier PR is lengthly, I created this PR to give you a more simplified view to review.
Changes in this PR:

introduce Calico CNI plugin and calico-IPAM for Mesos UCR containers
add dcos-calico-node service per node as the control panel of Calico network
refactor test_networking.py to included calico container network test
add integration tests and e2e test for calico networking
add vxlan support for calico in DC/OS

exposed configurations:

Parameter
Description

calico_enabled
Indicates whether to enable Calico networking.[Default: 'true']

calico_network_cidr
Subnet allocated for calico. The subnet specified by calico_network_cidr should not overlay with those for VXLAN backends or virtual networks defined for DC/OS virtual networks. Default: '<IP_ADDRESS>/16']

calico_vxlan_enabled
Control, whether IP-in-IP or VXLAN mode is used for calico, by default IP-in-IP, is suggested to be used instead of VXLAN. calico_vxlan_enabled is supposed to set to 'true' for the environment that IP in IP is not supported, like Azure. [Default: 'true']

calico_ipinip_mtu
The MTU to set on the IPIP tunnel device. This configuration works when calico_vxlan_enabled is set to be false. Please refer to this for a suitable MTU configuration. [Default: 1440]

calico_vxlan_port
The UDP port used for calico VXLAN. This configuration works when calico_vxlan_enabled is set to be true. [Default: 64001]

calico_vxlan_vni
The virtual network ID used for calico VXLAN. This configuration works when calico_vxlan_enabled is set to be true. [Default: 4096]

calico_vxlan_mtu
The MTU to set on the VXLAN tunnel device. This configuration works when calico_vxlan_enabled is set to be true. Please refer to this for a suitable MTU configuration [Default: 1410]

calico_veth_mtu
The MTU to set on the veth pairs created by calico CNI. Please refer to this for a suitable MTU configuration [Default: 1410]

Corresponding DC/OS tickets (required)

DCOS-58582 calico plugin installation for Mesos UCR.
DCOS-58583 Installation of Calico Control plane
DCOS-59113 enable l4lb  of calico network container
DCOS-58585 add e2e tests

Related tickets (optional)

DCOS-ID JIRA title / short description.

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain.
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

@mesosphere-mergebot label Ready For Review

@mesosphere-mergebot request-review  @ichernetsky @vespian

This PR relies on https://github.com/mesosphere/dcos-enterprise/pull/7095 because it helps fix EE bump PR CI.

@ichernetsky @vespian  could you please take another look?

@mainred What is the plan regarding the CI failures for EE:
[2019-12-12 13:23:18,987|dcos_e2e._subprocess_tools|DEBUG]: E         '<IP_ADDRESS>': {'dcos-adminrouter-agent.service',
[2019-12-12 13:23:18,987|dcos_e2e._subprocess_tools|DEBUG]: E         -                 'dcos-calico-bird.service',
[2019-12-12 13:23:18,987|dcos_e2e._subprocess_tools|DEBUG]: E         -                 'dcos-calico-confd.service',
[2019-12-12 13:23:18,987|dcos_e2e._subprocess_tools|DEBUG]: E         -                 'dcos-calico-felix.service',

Open DC/OS tests are run also in EE, and with no calico in EE yet, they will inevitably fail.

@mainred What is the plan regarding the CI failures for EE:

@vespian  could you please take a look at This PR https://github.com/mesosphere/dcos-enterprise/pull/7095? This explains why. Thanks a lot.

@orlandohohmeier , please switch the base branch to the intermediate branch from master, thanks.

@vespian @ichernetsky could you please give another look?

@mesosphere-mergebot request-review  @wavesoft

@mainred I just noticed that this went into the master - I though that Calico changes were meant for the intermediate branch as we are targeting 2.2  for the release?

@vespian , yes, we were supposed to merge this PR into the intermediate branch, but we find it's pretty hard to have PRs on an intermediate branch to inherit the CIs we have for the master branch.
And as we are not going to support Calico in windows, and calico components are excluded in windows packages, so we decided to switch to the master branch.
CC @orlandohohmeier


How to use Oauth for Server to Server as Google do

How to use OAuth for server to server as below ?
https://github.com/surjit/google-api-php-client
$client = new Google_Client();
$client->setApplicationName("Client_Library_Examples");
$client->setDeveloperKey("YOUR_APP_KEY");
$service = new Google_Service_Books($client);
$optParams = array('filter' => 'free-ebooks');
$results = $service->volumes->listVolumes('Henry David Thoreau', $optParams);
foreach ($results as $item) {
echo $item['volumeInfo']['title'], " \n";
}

two legged oauth  example

I'm not sure what you are asking. The link you provided is for a Google API client, this plugin does not interface with Google APIs in any way, but rather allows you to implement your own OAuth2 server for your own API.


Templates on spin for rust need to point at main for their spin-sdk dependency

Reported on Discord here by @ThorstenHans

I looked up the source code for the install script at https://github.com/fermyon/developer/blob/main/downloads/install.sh. It executes spin templates install --git url --upgrade in line 130
So my first naive attempt was to execute
spin templates intall --git "https://github.com/fermyon/spin" --upgrade --branch main

Which will force cloning the main branch as implemented in crates/templates/src/source.rs#L141-L147
https://github.com/fermyon/spin/blob/089e135f7fc4e76bf67561c079cc6bfd184a9b4c/crates/templates/src/source.rs#L141-L147
So at this point, users will end up with templates from the main branch. Unfortunately, those pin the spin-sdk also to tag = "v1.4.2"
https://github.com/fermyon/spin/blob/089e135f7fc4e76bf67561c079cc6bfd184a9b4c/templates/http-rust/content/Cargo.toml#L19
After that I tried digging deeper to find the proper branch 😄. So I stumbled upon llm-sdk, however http-rust template of this branch pins spin-sdk to tag = "v1.4.1:
https://github.com/fermyon/spin/blob/ca520925df9dd57524041a0cecbed704341253a9/templates/http-rust/content/Cargo.toml#L19

This should be
spin-sdk = { git = "https://github.com/fermyon/spin", tag = "canary" }

Our templates system does not currently support pointing to canary IIRC so this is not a simple install script update (unless we want to do some wild sed parsing). We could add a note to the script when the canary flag is passed that templates will need to be updated to use the canary tag.

I don't understand the difference between canary and main.  If you install canary Spin, you get main, unless you hit it in the brief window between a commit landing in main and the resulting canary being built.
I agree with pointing to main but we need to fix the automation for it to work.  Currently there is makefile (called from a GH action) that revs the SDK references in the Rust and Go template SDKs, but when looking for references to update it currently looks for a v* pattern:
https://github.com/fermyon/spin/blob/09de06b9fc20bda3dc24fb05918530046d0443dd/templates/Makefile#L19
https://github.com/fermyon/spin/blob/09de06b9fc20bda3dc24fb05918530046d0443dd/templates/Makefile#L8
This would need to be changed to allow replacing main as well.  (Which is not a blocker, just a thing to be aware of.)

As @itowlson mentions, we'd need to update the templates Makefile and automation for this.
Do I have the ideal world picture right?

Templates should reference the v* SDK versions when the ref of Spin or Spin version is itself also v*, e.g.

spin templates install --git https://github.com/fermyon/spin --branch v1.5.0 regardless of spin version installs templates using v1.5.0 SDK versions
spin templates install --git https://github.com/fermyon/spin using spin version v1.5.0 installs templates using v1.5.0 SDK versions

Templates should reference the main branch for their SDK versions when the ref of Spin is main or Spin version itself is a pre-release version (eg canary or built from main), e.g.

spin templates install --git https://github.com/fermyon/spin --branch main regardless of spin version installs templates using main SDK versions
spin templates install --git https://github.com/fermyon/spin using spin version v1.6.0-pre0 installs templates using main SDK versions

Which seems like it would boil down to main SDK versions being referenced in the templates in all git refs (branches/tags) of spin unless the ref is a v* tag (in which case, they are pinned to v* SDK versions).  Does that sound right?

That last sentence sounds about right, though I think you may be thinking of spin/template/v* refs rather than v* refs - that is the tag format that spin templates install uses to locate templates that match the Spin version.
In process terms, I believe templates on main should always point to the SDK at main, but templates at a spin/templates/* ref should point to a numbered SDK (and so that ref should probably be on the release branch rather than on main).


⚠ Bofrost.fr has degraded performance

In c03422e, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1543 ms

Resolved: Bofrost.fr performance has improved in 396de51.


Resize height of bar depending on its contents

50773ae366fa29d9d66b156453acc52948d018c8 takes a stab at this, but there's still some funniness - see the commit message/comments.
Will keep this open for now and take another look once I'm able to use this with Lanta, to rule out QTile oddness.

This seems to be working fine now.


adds autoscaling group id and arn

I cannot create a load balancer for this module's ASG without additional outputs.

Closing. Got it working with just the name :)


[spaceship][docs] update spaceship app store connect docs

[x] I've updated the documentation if necessary.

Motivation and Context
This was exposed as an issue here: https://github.com/fastlane/fastlane/issues/17879#issuecomment-754101484
Description
Simple docs updating. Removed a comment that said that something was not working (but it is), and update param name.

Actually I'm not sure whether the "not working" part should be removed. Looks like it doesn't work with ASC, but the same function does work with regular authentication credentials. 🤔

Actually I'm not sure whether the "not working" part should be removed. Looks like it doesn't work with ASC, but the same function does work with regular authentication credentials. 🤔


After upgrading td-agent 3.8 to 4.1, the CPU utilization of td-agent is getting increased drastically.

Describe the bug
td-agent 3.8 and elasticsearch 7.8 are deployed in the Kubernetes environment, after upgrading td-agent to 4.1 the CPU utilization of td-agent is getting increased and the indexing rate is getting decreased. The configuration used in td-agent and elasticsearch before and after the upgrade is the same
In the td-agent version 3.8.0, average CPU utilization is 0.5 core and the average indexing rate is 5000 events/second
In the td-agent version 4.1.0, the average CPU utilization is 1 core and the average indexing rate is 1000 events/second
To Reproduce
Deploy td-agent 3.1 with elasticsearch 7.8 in the Kubernetes environment and try to upgrade td-agent 4.1 with the same td-agent and elasticsearch configuration. Once the upgrade is successful monitor the CPU utilization of td-agent and also monitor the indexing rate of elasticsearch. The CPU utilization of the td-agent would be increased and also elasticsearch indexing rate will be decreased.
Expected behavior
After upgrading td-agent from 3.8 to 4.1, there shouldn't be any impact in the CPU utilization of td-agent and also elasticsearch indexing rate shouldn't decrease.
Your Environment
- TD Agent version:4.1.0-1
- Operating system: CentOS 7
- Kernel version: 4.18.0-<IP_ADDRESS>9211817.el7_8.emrs.altmvl.x86_64

Your Configuration
Deploy td-agent with below configuration, ensure that same configuration is used before and after upgrade
     <source>
         @type http
         @log_level debug
         @id input_http_ipv4
         port 9000
         bind <IP_ADDRESS>
     </source>

    <source>
        @type http
        @log_level debug
        @id input_http_ipv6
        port 9000
        bind ::
    </source>

    <filter pmdata>
       @type record_transformer
       enable_ruby
       <record>
          date ${ require 'date'; DateTime.rfc3339(record["measurement_time"]).strftime('%Y-%m-%d') }
       </record>
    </filter>

    <filter {*security_logs*,*debug_logs*,*LI_logs*,*audit_logs*}>
        @type record_transformer
        enable_ruby
        <record>
          date ${ require 'date'; DateTime.rfc3339(record["log_event_time_stamp"]).strftime('%Y-%m-%d') }
        </record>
    </filter>

    <filter fmdata>
        @type elasticsearch_genid
        hash_id_key _hash
     </filter>

     <filter pmdata>
         @type elasticsearch_genid
         hash_id_key _hash
     </filter>

     <filter {*security_logs*,*debug_logs*,*LI_logs*,*audit_logs*}>
            @type elasticsearch_genid
            hash_id_key _hash
     </filter>

      <match pmdata>
      @type copy
      <store>
      <buffer tag, date, vnf_name>
        @type file
        path  /var/log/fluentdlogs/pm
        timekey      1d
        flush_thread_count 4
        chunk_limit_size 4MB
        overflow_action block
        flush_mode interval
        flush_interval 5s
        total_limit_size 1GB
      </buffer>
        @type elasticsearch
        @log_level debug
        index_name ${tag}-${vnf_name}-${date}
        type_name pm_data
        host ****
        port 9200
        id_key _hash # specify same key name which is specified in hash_id_key
        remove_keys _hash # Elasticsearch doesn't like keys that start with _
        logstash_format false
        bulk_message_request_threshold 5M
        request_timeout 30s
        reconnect_on_error true
        reload_on_failure true
        reload_connections false
        user ****
        password ****
        scheme https
        ssl_verify true
        ssl_version TLSv1_2
        ca_file ****
        suppress_type_name true
      </store>
      </match>

      <match fmdata>
      @type copy
      <store>
      <buffer tag, date, vnf_name>
        @type file
        path  /var/log/fluentdlogs/fm
        timekey      1d
        flush_thread_count 4
        chunk_limit_size 4MB
        overflow_action block
        flush_mode interval
        flush_interval 5s
        total_limit_size 2GB
      </buffer>
        @type elasticsearch
        @log_level debug
        index_name ${tag}-${vnf_name}-${date}
        type_name fm_data
        host ****
        port 9200
        id_key _hash # specify same key name which is specified in hash_id_key
        remove_keys _hash # Elasticsearch doesn't like keys that start with _
        logstash_format false
        bulk_message_request_threshold 5M
        request_timeout 30s
        reconnect_on_error true
        reload_on_failure true
        reload_connections false
        user ****
        password ****
        scheme https
        ssl_verify true
        ssl_version TLSv1_2
        ca_file ****
        suppress_type_name true
      </store>
      </match>

      <match {*security_logs*,*debug_logs*,*LI_logs*,*audit_logs*}>
      @type copy
      <store>
      <buffer tag, date, facility, vnf_name>
        @type file
        path  /var/log/fluentdlogs/logs
        timekey      1d
        flush_thread_count 4
        chunk_limit_size 4MB
        overflow_action block
        flush_mode interval
        flush_interval 5s
        total_limit_size 5GB
      </buffer>
        @type elasticsearch
        @log_level debug
        index_name ${tag}-${facility}-${vnf_name}-${date}
        type_name logs_data
        host ****
        port 9200
        id_key _hash # specify same key name which is specified in hash_id_key
        remove_keys _hash # Elasticsearch doesn't like keys that start with _
        logstash_format false
        bulk_message_request_threshold 5M
        request_timeout 30s
        reconnect_on_error true
        reload_on_failure true
        reload_connections false
        user ****
        password ****
        scheme https
        ssl_verify true
        ssl_version TLSv1_2
        ca_file ****
        suppress_type_name true
      </store>
      </match>

Your Error Log
There are no error messages

Additional context
No response

Hi @ashie ,
Please help us to resolve this issue.
Regards,
Varun S

Because I'm not sure whether we can reproduce it, could you narrow down the context?

It is reproducible also on td-agent 4.0.1?
Could you minimize the reproducible configuration as much as possible?
Could you fetch more information by reading following articles?

https://docs.fluentd.org/deployment/trouble-shooting#dump-fluentds-internal-information
https://docs.fluentd.org/deployment/trouble-shooting#high-cpu-usage-issue


Implementation of EIP-2929

PR description

store warmed addresses and slots in the MessageFrame
probably need to do a gas calculator refactor at some point

Signed-off-by: Danno Ferrin<EMAIL_ADDRESS>builds off of #1386
Changelog

[ ] I thought about the changelog and included a changelog update if required.

Should this have a changelog entry?

Changelog entry added.


Getting several errors when running policy extractor

When running Build-DefinitionsFolders.ps1 I am getting the following errors
Line |
32 |                  $definedHashtable = $definedObj.Clone()
    |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    | Method invocation failed because [System.Collections.Specialized.OrderedDictionary] does not contain a method named 'Clone'.
Remove-EmptyFields: C:\Code\Architecture\Azure\enterprise-azure-policy-as-code\Scripts\Helpers\Confirm-ObjectValueEqualityDeep.ps1:33
Line |
33 |                  Remove-EmptyFields -definition $definedHashtable
    |                  ~~~~~~~~~~~~~~~~~~
    | The term 'Remove-EmptyFields' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
InvalidOperation: C:\Code\Architecture\Azure\enterprise-azure-policy-as-code\Scripts\Helpers\Confirm-ObjectValueEqualityDeep.ps1:45
Line |
45 |                  $existingHashtable = $existingObj.Clone()
    |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    | Method invocation failed because [System.Collections.Specialized.OrderedDictionary] does not contain a method named 'Clone'.
Remove-EmptyFields: C:\Code\Architecture\Azure\enterprise-azure-policy-as-code\Scripts\Helpers\Confirm-ObjectValueEqualityDeep.ps1:46
Line |
46 |                  Remove-EmptyFields -definition $existingHashtable
    |                  ~~~~~~~~~~~~~~~~~~
    | The term 'Remove-EmptyFields' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Edit

The Remove-EmptyFields -definition error was fixed by updating Build-DefinitionsFolders.ps1 to use Add-HelperScripts.ps1 instead of the common functions list.
Still getting the clone() method error

Was this using the modified version of Build-DefinitionsFolders.ps1 I gave you yesterday?

@gregslack78 - please try with the version of Build-DefinitionsFolder.ps1 and this updated version of Confirm-ObjectValueEqualityDeep.ps1 . It is working for me at the moment - if it gets you past the issue I'll push a new module version containing both fixes. This functionality will be replaced in V7.0 though....

Getting the same issue.  Also getting this
InvalidOperation: C:\Code\Architecture\Azure\enterprise-azure-policy-as-code\Scripts\Helpers\Get-AzPolicyResources.ps1:250
Line |
250 |                          $uniquePrincipalIds[$principalId] = $true
    |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    | Index operation failed; the array index evaluated to null.
Want to also note that the errors originally reported were happening in the policy assignment extraction.

Policy extractor is a work in process. I'll try to get to it soon.

I'm unable to replicate this right now - so let's just wait until V7.0 is released (very soon) to continue this.

@gregslack78 - please try with the version of Build-DefinitionsFolder.ps1 and this updated version of Confirm-ObjectValueEqualityDeep.ps1 . It is working for me at the moment - if it gets you past the issue I'll push a new module version containing both fixes. This functionality will be replaced in V7.0 though....

@techlake - this is what I did yesterday to try and fix the issue although I think it has caused other problems - will leave it alone now and just wait for V7.0


Godot 4 extremely slow with Vulkan drivers

Godot version
v4.0.stable.mono.official
System information

Manjaro with dual GPU (Intel and NVidia)
KDE Plasma
Linux kernel 6.5.5-1
GeForce GTX 1650Ti (Mobile) GPU installed with proprietary drivers
CometLake-H GT2 Intel GPU installed
video-hybrid-intel-nvidia-prime, video-modesetting installed for both cards

Issue description
Godot 4 seems extremely slow - for example, when I click on the Editor menu, it takes around five seconds for it to respond. Similarly, clicking the X to close Godot, takes a long time. Everything takes a long time.
I did some quick googling, and tried running it with --rendering-driver opengl3. This seems to resolve the problem. From which I understood, that this is somehow related to my Vulkan drivers.
I recently went through a lot of drama for reinstalling the latest Vulkan drivers on my system. I'm fairly sure I got it right (TL;dr DOTA2 used to terminate with an obscure graphics error on run, and now it runs fine), but I could be wrong.
If this is the wrong channel for getting help with my issue, please redirect me to the appropriate one.
Steps to reproduce
Launch Godot. Click on any menus, X button, CTRL+SHIFT+O and type something (see how it takes a couple of seconds to respond to everything).
Minimal reproduction project
Not required.

This is likely because Godot is using llvmpipe instead of hardware-accelerated Vulkan. Run Godot from a terminal and look at the output.

This is likely because Godot is using llvmpipe instead of hardware-accelerated Vulkan. Run Godot from a terminal and look at the output.

And then paste the output here for us to see please

And then paste the output here for us to see please

For most of the instances where I clicked on a menu and it made me wait, I didn't see any output. Towards the end though, some errors appeared.
 ./Godot_v4.0-stable_mono_linux.x86_64
Godot Engine v4.0.stable.mono.official.92bee43ad - https://godotengine.org
libGL error: glx: failed to create dri3 screen
libGL error: failed to load driver: nouveau
OpenGL API 4.6 (Core Profile) Mesa 23.1.9-manjaro1.1 - Compatibility - Using Device: Intel - Mesa Intel(R) UHD Graphics (CML GT2)

Editing project: /home/nb/code/customizable-jrpg/source
Godot Engine v4.0.stable.mono.official.92bee43ad - https://godotengine.org
~/utils/godot-4.0.0 Vulkan API 1.3.242 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1650 Ti

WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:70)
Loading GdUnit4 Plugin success
GdUnit4: Test server successfully started checked port: 31002
Scan for GdUnit4 Update ...
Unload GdUnit4 Plugin success
ERROR: Timer was not added to the SceneTree. Either add it or set autostart to true.
   at: start (scene/main/timer.cpp:109)
ERROR: Condition "_first != nullptr" is true.
   at: ~List (./core/templates/self_list.h:106)
ERROR: Condition "_first != nullptr" is true.
   at: ~List (./core/templates/self_list.h:106)
WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
     at: cleanup (core/object/object.cpp:1982)
ERROR: Resources still in use at exit (run with --verbose for details).
   at: clear (core/io/resource.cpp:489)
ERROR: Pages in use exist at exit in PagedAllocator: N7Variant5Pools12BucketMediumE
   at: ~PagedAllocator (./core/templates/paged_allocator.h:140)
ERROR: Pages in use exist at exit in PagedAllocator: N7Variant5Pools11BucketSmallE
   at: ~PagedAllocator (./core/templates/paged_allocator.h:140)

@nightblade9 Can you try again without the GDUnit4 plugin enabled and see if that helps?

@nightblade9 Can you try again without the GDUnit4 plugin enabled and see if that helps?

Yep. The problem reproduces, even with a brand-new, empty project.
If it matters, attached is the zip of my empty project, and the log.
Test.zip
Godot Engine v4.1.2.stable.official.399c9dc39 - https://godotengine.org
libGL error: glx: failed to create dri3 screen
libGL error: failed to load driver: nouveau
OpenGL API 4.6 (Core Profile) Mesa 23.1.9-manjaro1.1 - Compatibility - Using Device: Intel - Mesa Intel(R) UHD Graphics (CML GT2)

Editing project: /tmp/Test
Godot Engine v4.1.2.stable.official.399c9dc39 - https://godotengine.org

---

Vulkan API 1.3.242 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1650 Ti                                ✔

WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:73)

Any updates on this?
I'm happy running Godot from the CLI with OpenGL. Vulkan is painfully unusable at this point.
Did anyone else report this? If not, it could be an issue specific to my hardware or drivers.

Can you test other Vulkan projects and run tests like vulkaninfo and vkcube?

Can you test other Vulkan projects

Can you provide some examples?

vulkaninfo and vkcube were the examples, you can run them from the commandline 🙂

For this issue, on the compatibility renderer, isn't it using the iGPU?

OpenGL API 4.6 (Core Profile) Mesa 23.1.9-manjaro1.1 - Compatibility - Using Device: Intel - Mesa Intel(R) UHD Graphics (CML GT2)

But Vulkan is using the Nvidia GPU:

Vulkan API 1.3.242 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1650 Ti

I don't know if this is expected of this issue, but I would imagine it would be interesting to know the performance with OpenGL and Vulkan with both the iGPU and dGPU (as the Intel GPU will use Intel's ANV driver as part of Mesa, and the Nvidia GPU will use the proprietary Nvidia driver).
I'm not at my PC at the moment, but fwiw the latest Godot 4 (4.1.2?) worked fine on my Arch PC as of a few days ago, with an AMD 7900XTX and Mesa 23.2.1, though that's a single GPU system and I don't have any dual GPU systems to test on.

I don't know if this is expected of this issue, but I would imagine it would be interesting to know the performance with OpenGL and Vulkan with both the iGPU and dGPU (as the Intel GPU will use Intel's ANV driver as part of Mesa, and the Nvidia GPU will use the proprietary Nvidia driver).

I don't understand what this means.
Anecdotally, the performance on Vulkan is very poor (4-5s wait times to click on anything) and the performance with OpenGL is normal/good/expected. If I'm completely misunderstanding your question, feel free to rephrase it or provide detailed steps/tests you would like me to perform.

Results of vulkaninfo: vulkan.txt. Note that it segfaults (zsh: segmentation fault (core dumped)  vulkaninfo > /tmp/vulkan.txt).
Results of vkcube: Selected GPU 0: NVIDIA GeForce GTX 1650 Ti, type: DiscreteGpu.  Plus, this smoothly-spinning cube:

Please let me know if there's anything else you would like me to do/provide.

For different reasons, I booted into Manjaro from the latest USB today. Godot seems to run buttery smooth.  Here's what the console output says:
Godot Engine v4.1.2.stable.official.399c9dc39 - https://godotengine.org
OpenGL API 4.6 (Core Profile) Mesa 23.1.9-manjaro1.1 - Compatibility - Using Device: Intel - Mesa Intel(R) UHD Graphics (CML GT2)

Editing project: /tmp/Tmp
Godot Engine v4.1.2.stable.official.399c9dc39 - https://godotengine.org
Vulkan API 1.3.246 - Forward+ - Using Vulkan Device #0: Intel - Intel(R) UHD Graphics (CML GT2)

I noticed that - contrary to what I initially posted - it's now using the Intel GPU instead of the NVidia one.
I don't know if this is helpful in any way, other than to suggest that I should reimage my Manjaro install and not touch the drivers. Maybe that will Just Work :tm:. I'll lose a lot of personal files, though, if I go that route.

It does sound like a driver setup issue. The intel integrated GPU you have is too old to support Vulkan properly. And it seems your Nvidia GPU is configured to use the badly performing nouveau open source driver, and not the proprietary ones from Nvidia. So it won't work well for either OpenGL or Vulkan.

OK, thanks. Since it's very specific to my setup, I don't see any value in keeping this open any further. Feel free to reopen if you see something of value to do here.

And it seems your Nvidia GPU is configured to use the badly performing nouveau open source driver, and not the proprietary ones from Nvidia. So it won't work well for either OpenGL or Vulkan.

Nouveau lacks any form of Vulkan support in its stable releases, so I doubt it's that. (Its GPU name would also report differently compared to the NVIDIA driver.)

Why is this closed? This is still a problem.
I ran into the same problem running Godot v4.2.1 on my PopOS machine.
I have an NVIDIA 2080 Ti for context with the latest v550 drivers.
When I run the default launcher for Godot 4 (which I assume uses Vulkan drivers) the editor is unusably slow.
When I run godot4 --rendering-driver vulkan same thing it's super unusably slow.
When I run godot4 --rendering-driver opengl3 then the editor works perfectly and it's buttery smooth running at the full 144 fps of my monitor.

It's closed because it's a driver issue. Not specific to Godot.

When I run the default launcher for Godot 4 (which I assume uses Vulkan drivers) the editor is unusably slow.

The project manager always uses OpenGL unless told to use Vulkan with --rendering-driver vulkan.


Add the ability to splat into keyword arguments

Hello,
As mentioned on discourse, it would be useful to splat a ComponentArray into the keyword argument of a function. Here is an example of the desired behavior:
using ComponentArrays

x = ComponentArray(a = 1, b = 2)

f(;a, b) = a + b

f(;x...)

@jonniedie, wow! Thanks for adding this so quickly.
By the way, I was wondering if this would be a slightly better test since it tests whether the values are correctly mapped to the keyword arguments:
kw_fun(; a, b) = a / b
x = ComponentArray(b=1, a=2)
@test merge(NamedTuple(), x) == NamedTuple(x)
@test kw_fun(; x...) == 2

Oh, good point. Yeah that probably would be better. Or even a // b to avoid potential floating-point issues with the end comparison.


feat: add update command for Starchart version management

#21  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @MickVanDuijn and the rest of your teammates on  Graphite

Merge activity

Aug 19, 1:49 PM GMT+2: @MickVanDuijn merged this pull request with Graphite.


Implement load balance for cgroup2

Keep existing functionality for v1, copied from the oslat bench repo so other benchmarks can reuse this common function.

I'm fine with it, but I'm curious why it kept failing?

unrelated, kind of cdm bug looks like