DNS-Name instead of IP

Thank you very much for your work and the adapter!
But I can't get a connection to my Traccar-instance.
My setup: I have a Docker-container for ioBroker and on the same system a Docker-container for Traccar. Traccar is available via DNS-Name from the internet.
The communication between the containers is not possible so I would like to try the external DNS-Name for access.
Would it be possible to use an DNS-Name instead a fix ip-adress?
Best regards

I have a similar setup, however my containers can communicate with each other.

And there I already use the DNS name, but currently no support for https and wss (websoket) is implemented.
I would have to program and test that first.

I get the error "(26596) Server is offline or the address is incorrect!" with the NAS IP-adress or localhost

When I click on "Adapter-Webseite öffnen" the right page open.
I think the problem is, that IoBroker is in a Host-Network and Traccar in a Bridge-Network.
Regulary I use Traccar with a subdomain tracking.xxx.com and use a reverse-proxy for SSL-Encryption. If I try this configuration and port 443 it doesn't work but you already wrote, that is not implemented yet.
So I think I have to wait until SSL is implemented.

If the containers are in the bridge network, they must be able to communicate with each other.

but via their inetrne dns

@o0shojo0o With update on version 0.07 the connection works! Thank you very much.

But not via https?
Because that is still not implemented


podman: fix events help string

make it uppercase as all the other ones.
Signed-off-by: Giuseppe Scrivano<EMAIL_ADDRESS>

and of course, since this is a one char fix to a string, all the tests are unhappy....

Filter before image is broken on master

LGTM

Holding until rootless goes green

/lgtm


Firefox error

I get an error in my uglifyed code:
TypeError: 0 is read-only

Error occurs only in Firefox 39.0.
In Firefox 37.0 all working well.
gulp-uglify v1.2.0
My task:
uglify({
    compress: {
        unsafe: false,
        warnings: false,
        conditionals: false,
        comparisons: false,
        evaluate: false,
        if_return: false
   }
})

Which options I should use to get no error?

gulp-uglify is a wrapper around UglifyJS. Please report your issue on their issue tracker with a reproducible case so their developers can take a look.


parquet page level skipping (page index pruning) doesn't work with evolved schemas

Describe the bug
parquet page level skipping (page index pruning) panic's  with evolved schemas
To Reproduce
Enable setting like
        pub enable_page_index: bool, default = true

And then run test:
cargo test -p datafusion --lib -- evolved_schema_disjoint_schema_filter

Which fails
test physical_plan::file_format::parquet::tests::evolved_schema_disjoint_schema_filter ... FAILED

failures:

---- physical_plan::file_format::parquet::tests::evolved_schema_disjoint_schema_filter stdout ----
thread 'physical_plan::file_format::parquet::tests::evolved_schema_disjoint_schema_filter' panicked at 'index out of bounds: the len is 1 but the index is 1', /Users/alamb/.cargo/registry/src/github.com-1ecc6299db9ec823/parquet-31.0.0/src/file/metadata.rs:251:10

Expected behavior
Test should pass
Additional context
I found this while working to enable this feature by default
https://github.com/apache/arrow-datafusion/pull/5099

FYI @Ted-Jiang -- I plan to fix this

I am pretty sure the issue is that the page pruning is trying to use a column index into the merged schema to find the relevant statistics, but each file schema can be slightly different. I think the fix will be to look up statistics based on name rather than index

@alamb Thanks for ping me! i got some time to fix this this weekend! 😄

The tests that fail are:

failures:
    physical_plan::file_format::parquet::tests::evolved_schema_disjoint_schema_filter
    physical_plan::file_format::parquet::tests::evolved_schema_disjoint_schema_with_filter_pushdown
    physical_plan::file_format::parquet::tests::evolved_schema_intersection_filter
    physical_plan::file_format::parquet::tests::evolved_schema_intersection_filter_with_filter_pushdown


[all] Upgrade Gophercloud to v2

What this PR does / why we need it:
This PR upgrades Gophercloud to v2. While this new version enables context.Context for cancellation and tracing, this PR does not tackle that just yet, but rather just enables that follow-up work.
Special notes for reviewers:
This is currently a bump to a release candidate, just to kick the tires and get some feedback from the CI. I will update this pull request to import v2.0.0 once it's out. Thank you!
NONE

/hold

/hold cancel
Tests pass 🎉
This is ready for review.

/hold
Everything going according to plan, we are releasing v2.0.0 on Monday. I will update the tag in go.mod as soon as it's done, and then we can merge if the maintainers are OK with it.

/hold cancel
Updated to Gophercloud v2.0.0, which has been released this morning.
PTAL!
/cc @zetaab @kayrus

/lgtm


@go.show_subcommands returns only subcommands from the first command

Due diligence

[x] I am familiar with the "Reporting issues" section of CONTRIBUTING.md
[x] I have searched the existing issues and haven't found one that matches what I'm reporting or requesting now.
[x] If this is a bug report, I have searched the Bash changelog for information that may explain or provide clues to the behavior I'm observing and reference it in the body of the report.

Framework, Bash, and operating system version information
_GO_CORE_VERSION:         v1.7.0
BASH_VERSION:             4.4.12(1)-release
OSTYPE:                   linux-gnu
_GO_PLATFORM_ID:          arch
_GO_PLATFORM_VERSION_ID:

Description
Given a script structure like this:
scripts/
  command
  command.d/
    subcommand1
    subcommand2
    subcommand2.d/
      subsub1
      subsub2

adding:
. "$_GO_USE_MODULES" 'subcommands'
@go.show_subcommands

to subcommand2 will print:
Available subcommands of "subcommand2" are:

subcommand1   No description available
subcommand2   No description available

when
Available subcommands of "subcommand2" are:

subsub1   No description available
subsub2   No description available

should be printed.
The reason seems to be that @go.show_subcommands uses the $_GO_CMD_NAME to find the subcommands.

+1


Change Karavi references to CSM.

Description
Update the documentation to reflect the new naming of the product under the Container Storage Modules (CSM) umbrella.
There were also few typos and grammatical updates included with the changes.
GitHub Issues
List the GitHub issues impacted by this PR:

GitHub Issue #

#46

Checklist:

[ ] I have performed a self-review of my own code to ensure there are no formatting, vetting, linting, or security issues
[ ] I have verified that new and existing unit tests pass locally with my changes
[ ] I have not allowed coverage numbers to degenerate
[ ] I have maintained at least 90% code coverage
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

How Has This Been Tested?
Documentation updates only.

You found and corrected a lot of typos we didn't catch in the last review. Thanks!

The IDE helped a lot with that :)


sky130: skip xschem files copy when disabled

Fixes #214
Note this add multiple if blocks in order to keep the existing # comments structure, let me know if you'd prefer to have a single one.

I would have put everything there in a single "if" block, but anyway, it looks like it works.

me too, but then it messes with the # comments as everything needs to get folded into oneline, any Makefile-fu to workaround this?

No, I'm okay with your syntax.  Any chance you could fix the problems with the other disable options?  : )

@RTimothyEdwards sure! in a different PR?

Yes, please.  I already merged this one (into my repo at opencircuitdesign.com).


[Question] How use for/range on a resultset?

Description
Reading the documentation i don't understand how use for/range on a result set.
My intent is to create a new map with some fields of a model.
Steps to Reproduce the Problem
In my action I'm doing this:
tx, ok := c.Value("tx").(*pop.Connection)
if !ok {
    return fmt.Errorf("no transaction found")
}

db_mymodels := &models.MyModels{}
if err := tx.All(db_mymodels); err != nil {
    return err
}

m := make(map[string]string)
for _,rt := range db_mymodels{
    m[rt.Name] = rt.ID
}
c.Set("mymodels", m)

Expected Behavior
I want a map with a [Name]=ID for each item in MyModel table.
Actual Behavior
I get this erorr:
cannot range over db_mymodels (type *models.MyModels)
Info
pop v4.11.3

Hello! db_mymodels is declared as a pointer, and you can't use range on a pointer of slice.
Try moving the & to where it's needed, and it should work fine:
db_mymodels := models.MyModels{}
if err := tx.All(&db_mymodels); err != nil {
    return err
}


Proxy server feature

Context
One of the most requested features by our users is to implement a "proxy server" feature
(reasons below).
On the one hand, as the mock server is something you need to build up (provide) as you develop your API, sometimes there are some endpoints that are not already defined on the mock server configuration, so you might want to let the mock do a request to the "real" implementation when that happens.
OTOH, you might even want to have a "flag" that allows you to switch on-off the mock server.
Proposed implementation
Both situations can be solved by providing a configuration section named proxy_server with two attributes.

The first one named mode (or similar) with the following choices:

all (all the requests will be redirected)
missing (only the missing requests will be redirected)
none -or off (no proxy, default value).

The second one named base_url (or similar) to configure the origin of the "real" implementation.

For the proxy's implementation itself, there are many examples over internet about how to implement a proxy server with Go. Ideally, we won't want to add new third-party dependencies.
Any suggestion about that will be welcome.

The most important concern here is flexibility in my opinion. But I think we can for now stick to proposed behaviour, it seems not very difficult to make more fine-grained control if users will need this (for example, they may want to have option for each endpoint - is it mandatorily proxied or not).
Technical detail about implementation proposed above:
Add to server new field - proxy, that will contain it configuration and detail for actual implementation
Add in server.Build method at the end new route matcher:
s.router.PathPrefix("/").Handler(proxyHandler)

Proxy implementation can reside in separate file.

Yeah! That sounds really good!
Regarding the httputil.ReverseProxy, I never had the oportunity to play with it, but I'd vote for it as the first option (also for #34) as it'd avoid us from having to add new third-party dependencies.
Finally, I'd go for a simple proxy implementation (and keeping Killgrave simple). I wouldn't give "too much" flexibility if it does not worth for users (not requested by them).
Thanks for your contributions :innocent:


Note on updating clusters timestamps

Should the query be expressed with "==" ? https://dev.folio.org/faqs/explain-cql/#field

If it was a text in in RMB, yes. But not here (== is fine too).


ninja install error

Hi I am trying to install bamtools which requires jsoncpp which requires meson which requires ninja. meson was successfully installed and I followed jsoncpp's manual to install it like no problem until the last one below (https://github.com/open-source-parsers/jsoncpp/blob/master/README.md)
sudo ninja install
I don't have permission as this is a cluster administered by admin but it will take a long time for admin to install it (to the /usr/local/lib64/) so I wanted to try to install it in my own directory (/scr1/users/guoy/bin/) - however I don't see how to do it from the ninja manual. Can anyone help me on this, esp. installing jsoncpp without error? Thank you very much!
$ ninja install
[0/1] Installing files.
Installing libjsoncpp.so.19 to /usr/local/lib64/libjsoncpp.so.19
Traceback (most recent call last):
File "/scr1/users/guoy/bin/meson/meson", line 26, in
sys.exit(main())
File "/scr1/users/guoy/bin/meson/meson", line 23, in main
return mesonmain.run(sys.argv[1:], launcher)
File "/scr1/users/guoy/bin/meson/mesonbuild/mesonmain.py", line 322, in run
sys.exit(run_script_command(args[1:]))
File "/scr1/users/guoy/bin/meson/mesonbuild/mesonmain.py", line 278, in run_script_command
return cmdfunc(cmdargs)
File "/scr1/users/guoy/bin/meson/mesonbuild/scripts/meson_install.py", line 375, in run
do_install(datafilename)
File "/scr1/users/guoy/bin/meson/mesonbuild/scripts/meson_install.py", line 190, in do_install
install_targets(d)
File "/scr1/users/guoy/bin/meson/mesonbuild/scripts/meson_install.py", line 316, in install_targets
do_copyfile(fname, outname)
File "/scr1/users/guoy/bin/meson/mesonbuild/scripts/meson_install.py", line 126, in do_copyfile
shutil.copyfile(from_file, to_file)
File "/scr1/users/guoy/bin/Python-3.6.2/Lib/shutil.py", line 121, in copyfile
with open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: '/usr/local/lib64/libjsoncpp.so.19'
FAILED: meson-install
/scr1/users/guoy/bin/Python-3.6.2/python3 /scr1/users/guoy/bin/meson/meson --internal install /scr1/users/guoy/bin/jsoncpp/build-shared/meson-private/install.dat
ninja: build stopped: subcommand failed.

Ninja only executes the commands that Meson tells it to.  From your above trace, it looks like maybe the instructions you have from jsoncpp or meson are leading you down the wrong path, but this is not a Ninja issue.


Order processing automation

This implements AuthBot2, an order automation tool that provisions users and user access to groups based on their store order.

Also, is there a reason we aren't using EventBridge? https://shopify.dev/apps/webhooks/configuration/eventbridge

Also, correct me if I'm wrong, but as configured, there are no logs or metrics anywhere I can see indicate orders being processed. Is this expected? It seems undesirable


Keda HPA is creating and immediately terminating pods

Report
I have a function that scales based on a topic. It gets created and immediately terminates the newly created pods.
I send 1000 messages to topic to try to get it to scale.
Expected Behavior
Create pod, finish work.
Actual Behavior
Created pods are immediately terminated.
Steps to Reproduce the Problem

Logs from KEDA operator
example

KEDA Version
2.7.1
Kubernetes Version
1.22
Platform
Microsoft Azure
Scaler Details
azure-servicebus
Anything else?
snippet from HPA
 conditions:
    - type: AbleToScale
      status: 'True'
      lastTransitionTime: '2022-08-22T20:30:40Z'
      reason: SucceededRescale
      message: the HPA controller was able to update the target scale to 4
    - type: ScalingActive
      status: 'True'
      lastTransitionTime: '2022-08-22T20:30:40Z'
      reason: ValidMetricFound
      message: >-
        the HPA was able to successfully calculate a replica count from external
        metric
        s0-azure-helloworld-topic(&LabelSelector{MatchLabels:map[string]string{scaledobject.keda.sh/name:
        hello-world,},MatchExpressions:[]LabelSelectorRequirement{},})
    - type: ScalingLimited
      status: 'True'
      lastTransitionTime: '2022-08-22T20:31:27Z'
      reason: ScaleUpLimit
      message: >-
        the desired replica count is increasing faster than the maximum scale
        rate

It's strange that the same config when I apply manually using kubectl apply -f deploy.yaml (with secret, deploy, scaled obj) vs using argoCD, it actually works as expected and scales fine.
Removing from Deployment, spec.replicas, also makes it work as expected.
spec:
     replicas: 1 # <-

This is the first time I encountered this.
I wonder if ArgoCD is trying to sync and is fighting with Keda.

I concluded that ArgoCD was fighting with deployment replicas value and ended up removing the value. I'm letting the scaled object set the value for the deployment.


Error message on Windows 11

Description
When invoking the copilot command-line option on a Windows 11 machine, a TypeError is raised indicating a missing argument for the function build_conversation().
Expected Behavior
Executing the copilot command should not produce any errors, and it should function as intended.
Steps to Reproduce

Activate the virtual environment with (.venv)
Run the copilot command without the -q switch: copilot list files
Observe the error output

Actual Behavior
Upon execution, the following error is displayed:
(.venv) PS C:\Users\Owner\zgit\terminal-copilot> copilot list files
Traceback (most recent call last):
  File "C:\Users\Owner\zgit\terminal-copilot\.venv\Scripts\copilot-script.py", line 33, in <module>
    sys.exit(load_entry_point('terminal-copilot==1.4.0', 'console_scripts', 'copilot')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Owner\zgit\terminal-copilot\.venv\Lib\site-packages\terminal_copilot-1.4.0-py3.11.egg\copilot\main.py", line 74, in main
    conversation = build_conversation(context)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: build_conversation() missing 1 required positional argument: 'usermessage'

Additional Observations
When using the -q switch, the error does not occur. For instance:
(.venv) PS C:\Users\Owner\zgit\terminal-copilot> copilot -q hello copilot
> Hello! How can I assist you today?
Hello! How can I assist you today?

NOTE: Windows installation steps are slightly different from the documentation

Instead of source .venv/bin/activate use . .\.venv\Scripts\activate
Instead of export OPENAI_API_KEY=<your key>, use $ENV:OPENAI_API_KEY = "YOUR_KEY"

Environment

OS: Windows 11 Pro 22H2 22621.2428
Shell: PowerShell 7.3.8
Python Version: 3.11.6 (from Microsoft Store)
Commit: 50c1f6cd5cadbccc84b2d88a43501fac6e284152 (HEAD -> main, tag: v1.4.0, origin/main, origin/HEAD)

Ahh, it seems we already have a similar issue mentioned here:
https://github.com/opensouls/terminal-copilot/issues/49

I beleive this is now fixed. @EmpathicSage can you verify it works as expected now?


Remove duplicated code

code duplicated from lines 96:105 (Fix Mac OS X 10.9 (mavericks) font issue)
code duplicated from lines 145:146 (define defaultSettings), now in lines 131:132

:+1:
Thanks for your contribution.
Before it could be integrated, please update the commit message to specify that the duplicated code has been integrated as part of 002addc7681
Something like this would be nice:
Remove duplicated code

This commit removes duplicated code introduced as part of 002addc (Update Applications/App
files to bring changes from latest Slicer ).

More specifically, it removes
- code duplicated from lines 96:105 (Fix Mac OS X 10.9 (mavericks) font issue)
- code duplicated from lines 145:146 (define defaultSettings), now in lines 131:132

Done

Thanks @agirault


New oneDAL interfaces are not reflected in the docs

There is no information about new interfaces in the docs and help messages.
I think we need to:

shortly explain differences between content in daal and oneapi/dal folders in README.md
add documentation (at least notes for short-term?) about new interfaces
update makefile help messages about how to build oneDAL.
in makefiles for oneDAL examples, cleanup old wordings e.g. "DAAL", "Intel Data Analytics Acceleration Library".

@michael-smirnov  @rlnx  @outoftardis   - guess we can close this issue now?

@michael-smirnov @rlnx @outoftardis - guess we can close this issue now?

I guess so, yes. However, I'm not sure about makefiles.


CIP-0118? | Validation Zones

We propose a set of changes that revolve around validation zones, a construct for allowing certain kinds of underspecified transactions. In particular, for the Babel-fees usecase we discuss here, we allow transactions that specify part of a swap request. A validation zone is a list of transactions such that earlier transactions in the list may be underspecified, while later transactions must complete all partial specifications. In the Babel-fees usecase, the completion of a specification is the fulfillment of a swap request. We discuss how validation zones for the Babel fees usecase can be generalized to a template for addressing a number of use cases from CPS-15.

thanks @polinavino ... really happy to see the continuation of this work.  I'm marking the title with the obligatory ? because until merged the number (or its assignment at all) cannot be certain.  Also I'm marking the prior version Likely Deprecated and will close as such with your confirmation:

https://github.com/cardano-foundation/CIPs/pull/780

cc (for continuing review from the old proposal) @Quantumplation @fallen-icarus

You cannot combine intents into a single transaction since they are already complete transactions. Instead, Validation Zones enables batching transactions but this adds cost to the aggregator since each transaction has a minimum 0.15 ADA fee. The fact that all Validation Zone intents are separate transactions means this cost can quickly add up.

This is true. Since zones are limited in size to the size of a single transaction, we should consider charging 0.15 ADA per zone (or perhaps slightly more, but not like, 0.15 PER transaction). I will bring this up with the ledger team.

You cannot perform other actions in the intent transaction, even if the intent owner is actually okay with it. If Alice just wants the above atomic swap, she doesn't care if the aggregator also satisfies someone else's intent in the same transaction. The aggregator could also do a swap of their own and Alice still wouldn't care. Forcing each intent to be an isolated transaction seems like a waste of space and money.

I dont really get this. You can do whatever you want inside a zone, except use old-version Plutus scripts. For regular atomic swaps, no aggregator is needed, it is just between two parties. The point of designing Validation Zones in the way we did is to reduce the off-chain communication required between parties that want to perform a transaction.  This is definitely more streamlined than co-constructing a transaction that everyone needs to sign, or a zone that everyone needs to sign. No need for the use of expensive contracts, either. Moreover, the offer and the acceptance of it is done in the same block. You are right in that it might be more expensive because of the number of transactions, however, we may be able to reduce the per-transaction cost.
I think, actually, all of what you are suggesting is already possible in the current model using co-constructed transactions and smart contracts?

The intent owner has to guess what the missing inputs and outputs would look like and place these holes in the transaction. If they guess wrong, this places enormous friction (aka, increased cost) on how an aggregator can actually fulfill this intent. Specifically, the aggregator must contort (ie, break up or merge) other UTxOs to fit the holes set in each intent. The batched transactions in Validation Zones is also meant to address this, but this means the previous bullets are exacerbated since each Validation Zone intent actually requires multiple transactions to fulfill it.

Non-communicating parties that want to perform some exchanges already have to construct individual transactions to put their offers on-chain. I am not sure if multi-party co-constructing of a single transaction that includes their offers and liquidity from an exchange is current practice, but it sound cumbersome, and would still be a big expensive transaction that takes a lot of off-chain communication. In our design, everyone constructs a single small transaction and sends it off. The exchange then constructs two (big) transactions, spending everyones offers and requests. Exchanging lots of peoples offers will always require a transaction with lots of UTxOs (at least one per user).

I think, actually, all of what you are suggesting is already possible in the current model using co-constructed transactions and smart contracts?

@polinavino Sorry, I should have been more clear about this. Yes, you are right. Everything you can do with transaction pieces can also be done using Validation Zones, and vice versa. Transaction pieces is a competing intent settlement system to Validation Zones. I think you, @michaelpj, and the community need to consider it as an alternative approach. They both cover the same use cases so the community needs to consider which one has better trade-offs.
Perhaps I am wrong, but I am currently arguing that the transaction pieces' design has a significantly better trade-off profile due to more accurately capturing what an intent is. IMO all of the downsides to Validation Zones are due to it requiring intent creators to also guess what their counter-party will look like in addition to specifying their intent (ie, unlocked requests and unlocked outputs must be set aside for the counter-parties). Users will likely never be able to accurately guess who their counter-party will be so this creates an extreme friction that places a burden on both users and aggregators. The zone is only required to compensate for these guesses likely being wrong. The zone enables aggregators to find/create the appropriate counter-party UTxOs in order to fulfill the intent. But this finding/creating step is a waste of resources since it takes up space that could go to satisfying more intents. Also, this finding/creating step places a tremendous burden on DApps since they must be updated to support breaking-off/merging liquidity UTxOs; as I've said before, this would dramatically increase the DApp's attack surface just to compensate for a limitation in Validation Zones. Even the unlocked request and unlocked output only seem necessary due to the Validation Zone design forcing the intent creator to guess what the counter-party will look like. Transaction pieces have none of the above issues, and can therefore cover the same use cases even without zones, unlocked request, and unlocked outputs.

I am not sure if multi-party co-constructing of a single transaction that includes their offers and liquidity from an exchange is current practice, but it sound cumbersome, and would still be a big expensive transaction that takes a lot of off-chain communication. In our design, everyone constructs a single small transaction and sends it off.

Perhaps me referring to the decentralized multisig was misleading. Transaction pieces does not require "co-constructing" a transaction. Zero coordination is required. It actually functions very similar to how intents work with Validation Zones.  Since this piece is signed, the aggregator can use this piece in any transaction it wants; it does not need to go back to Alice once it settles on an aggregation. It can pair her piece with Bob's, Sarah's, and Mike's pieces. They are giving the aggregator permission to spend their inputs as long as certain conditions are met in the same transaction. It is conceptually no different than how on-chain batching works for DApps. The off-chain processing is virtually identical to the intent processing required for Validation Zones. But since there was no counter-party guessing with transaction pieces, it is significantly easier and cheaper to batch transaction pieces than Validation Zone intents.
I am going to create a CIP draft to further elaborate how I see transaction pieces working.

@Quantumplation Actually all of your criticisms are not accurate. I should have explained these points, but I was trying to cut back on total words. It seems I should have just said it anyway.

First, the assembler has freedom to choose in which order to assemble the pieces

No, it doesn't. The cddl would have a list of pieces where the order of the list is significant. Then, as long as we all agree on a Monoid instance for the pieces, the whole transaction can be deterministically derived from just this list. It is the same as how the order of the output list in the cddl is currently significant.

Additionally, it's impossible to construct the script context to evaluate transactions

This is also wrong. It is easy to derive the whole transaction from the list of pieces. Then this whole transaction can be converted to the script context. Currently, the process is basically:

parse the cddl to get the whole transaction
do stuff with the whole transaction

I am suggesting changing it to:

parse the cddl to get the list of transaction pieces
deterministically derive the whole transaction from the pieces
do stuff with the whole transaction

Since we can still deterministically derive the whole transaction, none of the interfaces need to change. The smart contracts would get the exact same information they currently do.

whoever provides collateral might be putting their collateral at risk

The aggregator of the transaction pieces would be the one to put up collateral and pay the fee. Again, since the whole transaction can be deterministically derived, these values can be calculated before submitting the transaction. In my view, the intent creator would get to decide the order of items within their transaction piece while the aggregator would get to decide the order of the pieces themselves. Once submitted in a transaction, the order is set just like with outputs right now. For example, if Alice creates a piece with input1 followed by input2 and Bob creates a piece with input3 followed by input4, then Charlie the aggregator only has two options:
[input1, input2, input3, input4]  OR  [input3, input4, input1, input2]

Charlie cannot put input2 before input1 because that would violate Alice's intent. This would require CIP-128 since the order of the inputs would need to be preserved.

a nontrivial thing to spec out a dramatic (almost complete) change to the ledger rules / execution model for plutus scripts

The only thing that needs a decent size change is the cddl. Since the whole transaction can be deterministically derived from the new cddl, everything else can remain mostly untouched. This includes the execution model for plutus scripts. Also, since the transaction pieces design doesn't need the temporary data structures or zone level logic, it may actually be a smaller change on net than what is required for Validation Zones. The transaction pieces design can even cover the same use cases without needing input "holes" (aka requests), although this could still be added if desired.

I'll try to explain more of this in the CIP. We currently operate in a paradigm where the entire transaction needs to be signed by all parties. I am trying to argue this is unnecessary. The atomic blockchain action is actually not a transaction, but rather an intent (eg, Alice pays Bob 10 ADA, Alice swaps 10 DJED for 30 WMT, etc). A transaction is then just a collection of these atomic intents. Only the individual intents need to be signed. Signing the whole transaction effectively does the same thing, but if we actually enable signing intents directly, we get a lot more flexibility with what can happen in a single transaction. Again, I am asserting a collection of signed transaction pieces (aka intents) is functionally equivalent to a single transaction signed by all parties. Since they are equivalent, we actually don't need everyone to sign the whole transaction. We can allow users to create and sign pieces separately, and submit them to an aggregator off-chain for submission as a single collection (aka transaction). This enables users to batch their intents together without needing to coordinate anything. Babel fees and high-frequency off-chain trading become easy in this new paradigm.

Here is a possible change to this design that may address some of the concerns, in particular, (1) paying per-transaction cost multiple times in a zone, and (2) aggregators having to split up and recombine their liquidity pools to participate in an exchange (3) zone features being incompatible with current plutus version contracts (4) the requirement that two separate transactions are needed to accept an offer and cover a request
Simplify Validation Zones to be more in line with what you are suggesting/be more implicit with value flow :

revert changes to the UTxO rule, UTxO State, and Transaction data structures (leave them the same as in the current non-zone ledger design)
remove new Plutus version requirement
move the produced = consumed computation to the ZONE rule, and aggregate across all transactions in the zone, that is Sum_{tx \in zone} consumed tx = Sum_{tx \in zone} produced tx
replace the cycle detection in the ZONE rule by in independency check, which checks that "for all inputs (txid, ix) in all transactions in a zone, txid is not the ID of another transaction in the zone
only require the per-transaction component of the transaction fee to be paid once per zone

The validation zones simplification will all remove the need for the weird requireTxs song and dance, and an aggregator would be able to spend their liquidity pool once per zone to provide any missing value and claim any extra value within a single transaction. Scripts would operate without any changes. Flash loan attacks would be prevented by the independency check.

I am still unsure how your explanation of transactions behaving like commits contradicts the example I presented with the "out of thin air" role token,
Suppose
script allows a transaction to spend output (assets, script, auctionOpen) and make output (assets, script, auctionOver) whenever 1RoleToken is also in the output of that transaction. That is, the role token allows the transaction author to close an auction. Now, in the following zone [Tx1 ; Tx2] , 1RoleToken appears and disappears, allowing a rando to close an auction :
Tx1 -
(Resolved) inputs : txIn -> (assets, script, auctionOpen)
Outputs: (1RoleToken, …)_{index1} , (assets, script1, datum2)_{auctionOver}
Tx2 -
(Resolved) inputs : (hash (Tx1), index1) -> (1RoleToken, …)

I still don't know what (Resolved) means. If it is a placeholder of any kind, that is the problem. There is no need for placeholders. Placeholders are what create the possibility for flash loans.
If I have a transaction (tx1) that spends i1 to produce o1, and I know I am going to want to spend o1 in a later transaction, I don't have to wait for tx1 to be processed in order to build tx2. I have tx1 so I can generate its hash: tx_hash1. I also know that o1 is the only output in tx1 so I know ahead of time that the output reference for o1 will be tx_hash1#0.
I can use this to construct tx2 before I even submit tx1. It would spend input tx_hash1#0 and produce o2. As cardano is now, even though I have them both ready ahead of time, I need to submit them one at a time. But with zones, I can submit them together and get the exact same result. The transactions tx1 and tx2 in the zone would be exactly the same as the non-zone versions. That means tx2 would still spend tx_hash1#0 even though it doesn't exist until after tx1 is processed.
When I said the transactions in a zone would be applied sequentially, I meant the zone logic would actually calculate the new UTxO set after applying each transactions. This enables the later transactions to spend those output references as if they were real outputs. There is no "resolving" going on. So to reword your example, if you have a zone [tx1, tx2]:
Tx1

spends input tx_hash0#0
produces output o1 with the auction (index 0)
produces output o2 with the role token (index 1)
executes S to check the auction is valid

The zone logs that tx_hash0#0 has been spent and tx_hash1#0 and tx_hash1#1 have been created.
In order for Tx2 to actually behave as if it has the role token, it must spend tx_hash1#1:
Tx2

spends input tx_hash1#0 with the auction
spends input tx_hash1#1 with the role token
produces output o3 with the closed auction assets (index 0)
executes S to close the auction

If Tx2 does not spend tx_hash1#1, script S is guaranteed to fail. When you apply the transactions sequentially and squash the results, the output references and value may cancel out, but the intermediate states are still important. The script S that is executed in Tx2 sees a different script context than when it was executed in Tx1. If the script context does not contain the role token, script S will know and fail. It doesn't matter that transactions in a zone can be unbalanced, the unbalanced transaction must still spend the proper UTxO, even if it will cancel out later.

I realized my misunderstanding with the "out of thin air" role token.

Tx1 -
(Resolved) inputs : txIn -> (assets, script, auctionOpen)
Outputs: (1RoleToken, …){index1} , (assets, script, auctionOver){index2}
Tx2 -
(Resolved) inputs : (hash (Tx1), index1) -> (1RoleToken, …)

I get what this means now. "Resolved" is just a normal input; it isn't a placeholder. So Tx1 is unbalanced in that it has the role token among the outputs, but not the inputs. Tx2 has the role token among the inputs, but not the outputs. Therefore, the zone is balanced while the role token is misused. I appreciate your patience with this @polinavino :sweat_smile:.
It seems like this can be addressed at the DApp level though (provided there is a new plutus version to prevent old DApps from being used this way). If an account style DApp is using a role token, it can check that it is among both the inputs and the outputs, even in the unbalanced transaction. The DApp can enforce the role token is always "self-balanced". This would make the above attack impossible since it would not be possible to balance against invalid usages of the role token, would it not?

Sorry, i dont even know if "resolved" terminology is used much, but what i meant there is that it's the pair (input, output) that you get from looking up the transaction input in the UTxO .
You are right to mention a new Plutus version - in the original validation zones design, we definitely need it. Requiring a new Plutus version here as well will require existing apps to be entirely re-developed, with all the new architecture, testing, deployment, and potential downstream effects, all for the purpose of using a new Plutus version that plays well with validation zones.
However, we can actually get away here without a new Plutus version - I think - if we can guarantee that all tokens have a legitimate source (i.e. do the transaction independence check)

Is it possible to use the cddl from transaction swaps and just process it differently? The issue with having the aggregator pay the collateral was the possible man-in-the-middle attack (mentioned here). But if the order of the list was signed, this attack is not possible. For example, the cddl could be:
transaction_body =
  { ....
  , 23 : [* zone_transaction]
  }

The zone transactions would each be applied to the ledger sequentially (as described by this CIP), then the outer transaction's information would be applied. The outer transaction info is always applied last, but it can still be used to balance the zone transactions. With this approach, the aggregator can cover the collateral for all smart contracts in the zone, and since the aggregator actually signs the order of the zone transactions, it cannot be changed after submission.

The transactions included because of being required by requiredTxs are
not actually validated or applied to the ledger state. They are only
included because they are data required by scripts. It doesn’t matter if
the tag is set correctly.
On Sun, Aug 11, 2024 at 2:14 PM Alexey Kuleshevich @.***>
wrote:

@.**** commented on this pull request.
In CIP-0118/README-implicit.md
https://github.com/cardano-foundation/CIPs/pull/862#discussion_r1713033892
:

+- covers the size-based fee for the transactions corresponding to requiredTxs transactions
+in addition to itself

Same comment. isValid is set by cardano-node, not by the people building
the transaction
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/862#discussion_r1713033892,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AES5BH46WURXL6LF6KN4WZ3ZQ6SW5AVCNFSM6AAAAABLKR5PW6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDEMZRHA3DOOJTHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

ZoneID is only a possible way to organize transactions in a block so that
block structure remains the same. You are right in that the mempool still
has to deal with zone logic, and network still has to transmit full zones,
but we already talked to them about this, and they said it’s fine.
On Sun, Aug 11, 2024 at 2:04 PM Alexey Kuleshevich @.***>
wrote:

@.**** commented on this pull request.
In CIP-0118/README-implicit.md
https://github.com/cardano-foundation/CIPs/pull/862#discussion_r1713032499
:

+The transaction balancing must also be modified in a way that lets the user explicitly
+(locally) specify the amounts they want to be missing or extra in a transaction.

Yeah, perhaps the zoneID solution would be better.
ZoneId won't solve this, as far as I can imagine this solution. Ledger
will still have to do the validation of each individual transaction in the
zone and then the zone as a whole. mempool will need to be able to get the
information of validity individual transaction in the zone in order to make
other decisions about the zone, like at which piint to drop transactions.
Moreover, ZoneId removes the guarantee that mempool will receive all of the
transactions in the zone, unless requirement is to submit all necessary
transactions with the same ZoneId at the same time. The the question is
what happens with the ZoneId when transactions from the zone need to be
dropped, that would be a problem, unless there is no connection between the
ZoneId and the contents of the zone (i.e. ZoneId is just some random token)
At that point the question is who is responsible for generating the ZoneId?
In any case, the ZoneId design is just not clear to me.
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/862#discussion_r1713032499,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AES5BHZVUCGRH4KWSSY2HNDZQ6RRZAVCNFSM6AAAAABLKR5PW6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDEMZRHA3DMNJXHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

You are totally missing my point. Any transaction can only be included on chain if it was fully validated at least once!Who pays for the collateral of valid transactions in the zone that are not included in the requiredTxs that contains a phase2 invalid transaction?
The transactions included because of being required by requiredTxs are
not actually validated or applied to the ledger state. They are only
included because they are data required by scripts. It doesn’t matter if
the tag is set correctly.

My point is that they are not included at all. They are just provided as
data for running scripts on - the scripts of only the one invalid
transaction. This one invalid transaction does pay collateral for all those
scripts, and it also pays for the memory needed to include the extra data
(requiredTxs) in a block. But the scripts in requiredTxs are not run
themselves.
On Sun, Aug 11, 2024 at 3:28 PM Alexey Kuleshevich @.***>
wrote:

You are totally missing my point. Any transaction can only be included on
chain if it was fully validated at least once!Who pays for the collateral
of valid transactions in the zone that are not included in the
requiredTxs that contains a phase2 invalid transaction?
The transactions included because of being required by requiredTxs are
not actually validated or applied to the ledger state. They are only
included because they are data required by scripts. It doesn’t matter if
the tag is set correctly.
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/862#issuecomment-2282863999,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AES5BH3KR2FDUFGFH7FKM53ZQ63PHAVCNFSM6AAAAABLKR5PW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBSHA3DGOJZHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@fallen-icarus @lehins @disassembler
Some thoughts on running the Babel service alongside your mempool (as a distributed service), rather than as a centralized service :
let us assume that

with the right careful design, we can make sure that the phase-2 work of that service (and not just the work of the mempool on a complete zone) can always be compensated with with the collateral mechanism (e.g. each transaction in a zone has enough collateral to cover preceeding ones)

then, the risk of "having unfulfilled exchange offers hang around forever" becomes significantly reduced by being able to set your own custom Babel offers filter that only keeps certain offers around :

individual SPOs can have a custom filter on what partially balanced things their Babel service accepts without even validating them, e.g. they only accept offers of tokens they themselves want to trade, and are able to fulfill the exchange offer themselves
larger operations such as exchanges (that can afford to absorb the cost of more transactions waiting around) can have filters that accept only certain kinds of token trade offers, based on market price and popularity (as the expect the popular ones to eventually be accepted, but can throw them away after a certain amount of time anyways)

so, a Babel service discards offers they're not interested in, and also phase-1 invalid offers. Phase-2 invalid offers can go on-chain immediately for collateral collection, without the need to be fulfilled. This feels like a decent compromise and addresses multiple usecases.

I don't think this design addresses what I consider to be the biggest issue: there is a fundamental mismatch of incentives between service providers and end-users. What is good for the babel service is bad for the end-user, and vice versa.
A distributed system with badly aligned incentives can still result in a centralized ecosystem. Ethereum's staking situation is a real world example of this. Ethereum requires users to lock up ETH, but no one actually wants to do this. So companies like Lido were created to fill the incentives gap, and as a result, ethereum is still centralized despite using a distributed network.
I think this design will end up the same way and it is the assumption itself that is the problem. Specifically, this part: each transaction in a zone has enough collateral to cover preceeding ones.

so, a Babel service discards offers they're not interested in, and also phase-1 invalid offers. Phase-2 invalid offers can go on-chain immediately for collateral collection, without the need to be fulfilled.

This is assuming end-users will actually submit "offers" to the babel network that satisfy the collateral requirement, and I think that is a completely unrealistic assumption. The collateral requirement is not possible for end-users to satisfy without coordination. Since this is supposed to be a distributed/global network, coordination among end-users is totally impractical.
What I think will likely happen instead is Company A will be created to fill the incentives gap (just like Lido). Company A will use its centralized servers to coordinate the collateral among users and then submit the zone to Cardano directly, totally bypassing the distributed babel service. (Why would Company A submit the transactions to the babel network when it has already coordinated the zone?) So instead of this:
flowchart LR
    Alice --> BabelNetwork
    Bob --> BabelNetwork
    Charlie --> BabelNetwork
    BabelNetwork --> Cardano

we effectively have this:
flowchart LR
    Alice --> CompanyA
    Bob --> CompanyA
    Charlie --> CompanyA
    CompanyA --> Cardano

The ecosystem ends up in the exact same scenario as with transaction swaps except it is actually worse for three reasons:

This design added extra complexity to cardano that goes mostly unused. It may still be used for offers without scripts, but it is unusable for offers that do contain scripts.
Company A will actually create the transactions on the users' behalf and ask the users to sign them (how else can the collateral amounts be coordinated?). Transaction swaps trivially enables all users to create the transactions themselves, not just transactions without script. Therefore, this design actually requires users to trust Company A more then they would have to trust companies built around transaction swaps.
Requiring users to coordinate collateral creates a stronger incentive for centralization than just balancing transactions against each other. This means there will be fewer companies acting as intermediaries with this design than with transaction swaps. For example, with transaction swaps, Alice can send the same swap transaction to multiple different aggregators. That is not possible with this design because the collateral requirement forces each transaction to be context dependent.

This is assuming end-users will actually submit "offers" to the babel network that satisfy the collateral requirement, and I think that is a completely unrealistic assumption. The collateral requirement is not possible for end-users to satisfy without coordination. Since this is supposed to be a distributed/global network, coordination among end-users is totally impractical.

The (forthcoming "nested transactions") design will operate in a slightly different way, that is somewhere between validation zones and swaps. Instead of a zone, there will be a (fully phase-1 valid) top-level transaction that contains a list of transactions (which are instead of swaps). This is how I picture a Babel service working in that case  :

users will submit transactions (that are not necessarily balanced, do not necessarily pay enough fee, and do not necessarily cover required collateral - this is up to the builder). This submission could be either to a specific babel fees service, or possibly to some kind of network that propagates them to multiple babel fee services (this is up to the folks building the off-chain stuff).
anyone running a babel fees service that receives such a transaction is able to configure their software to either accept or reject transactions based on any property they choose, including collateral payment, fee payment, running certain scripts, exchanging certain tokens, etc. Let us assume some Babel service configuration lets transaction tx through
the babel service can either

if they want to balance the transaction, they would build a top-level transaction tx' that covers the collateral and contains tx, and submit tx' to the Cardano network
if they only want to exchange some of the offer, they would add another transaction tx1, and send the list [tx ; tx1] onwards to other Babel services that might want to build a top-level transaction with [tx ; tx1]

In step 3, the service has a choice of whether to cover the collateral of tx1 to increase their chances of another service wanting to validate [tx ; tx1], or cover just their own collateral, or cover no collateral at all. They can also decide how much fees they want to pay.
The idea here is that the very minimum requirement is that that when a top-level transaction is sent across Cardano network, it has to have enough collateral. Many other constraints what on non-top-level transactions Babel fee services accept are up to the Babel fee service developers.

if they only want to exchange some of the offer, they would add another transaction tx1, and send the list [tx ; tx1] onwards to other Babel services that might want to build a top-level transaction with [tx ; tx1]

Will the list [tx ; tx1] be signed? What is preventing a man-in-the-middle from making changes to the list, or another batcher from just using the transactions separately?

The complexity here is reduced by making swaps full transactions - ...

Plultus script logic is simpler in this design including local predictability of ExUnits needed, and the ability to predict if it's even possible to make a Plutus contract validate within a given transaction

I don't know enough about the ledger to comment on the ledger-related points, but I disagree with the plutus script comment. I think writing smart contracts for either transaction swaps or validation zones would be very easy (it ultimately depends on the new script context), but I would actually prefer if smart contracts always saw the whole transaction because it would enable more use cases.
Perhaps I am missing some low-level nuance, but I don't think there is a need to keep ExUnits constant between local execution and full scope execution. AFAIU the point of the ex units is to sign off on how much you are willing to pay in fees for your scripts. But in this context, even without the ex units, I can still sign off on how much I am willing to pay in fees by controlling how many assets are unbalanced in my transaction piece. I am still incentivized not to waste ex units since the babel service is incentivized to fit as many orders in a transaction as possible; they would just omit my order if I use too many ex units.
Depending on what the new script context will be, it should be very easy to write a smart contract where the ex units between the local execution and full scope execution vary only slightly. For example, if the smart contract is shown the entire transaction (ie, not just its own piece), the ledger can tell the smart contract being executed which internal transaction it is from (using an index for location in the internal transactions list). Then the smart contract can just focus on that piece. The only variability would be how many steps it takes to get to the required internal transaction. But constant-time lookups would eliminate this variability entirely.
Also, the eUTxO model guarantees high assurances for smart contracts being executed locally to have the same result in the full scope. Breaking the transaction into pieces doesn't change this. I think it would be very easy for me to update all of my DApps to execute in a piece and know with 100% certainty that it will have the same result in the full scope context (there would be slight variability in ex units as described above).
The only smart contracts that may have a different result are those that actually care about the full transaction. But if they do care about the full transaction, why would you expect the local result to be the same as the full scope result? If this kind of smart contract actually did behave the same, it would be a defective smart contract. Besides, I think this variability is actually fine:

Account style DApps are already using batchers. These batchers can easily double as babel service providers and execute the account style DApp in the top-level transaction to finish balancing the internal transactions.
There are possible use cases for having smart contracts see the full transaction scope even when executed in a piece. For example, Alice may not want her piece batched in a transaction where X happens. Therefore, she can create a smart contract that fails if it is executed in the same transaction as X. She can submit this smart contract with her piece to the babel service. So her smart contract may succeed locally but fail when included with a batch, but that is the whole point. This feature enables Alice to have a say in how her piece is used, even after giving her piece to the babel service. This feature isn't possible with the previous requiredTxs design since Alice doesn't know the other transactions; she just wants her smart contract to check any and all other transactions in the batch.

The role token example you mentioned before is just a result of smart contract devs taking a (valid) short cut based on the assumption that the smart contract will always be executed against a fully balanced transaction. That shortcut obviously can't be used for unbalanced transactions, but it may not even be necessary since the inputs and outputs would be fractured across the top-level transaction and internal transactions. Instead of having to look through an aggregate list of outputs with 20 entries, it can look through both the inputs and outputs from that specific scope. This scope may only have 2 entries in each list. This actually saves ex units despite now looking through both inputs and outputs of a specific scope. Therefore, proper usage of role tokens is actually very easy and cheap to guarantee, even with transaction swaps.

Will the list [tx ; tx1] be signed? What is preventing a man-in-the-middle from making changes to the list, or another batcher from just using the transactions separately?

nothing - this is no different from either zones or swaps. In any of the three designs, transactions can be transmitted in whatever format off-chain, really. Lists is one option to combine them into a single data structure for transmission. Anyone making a block can always build a new top level transaction (or last zone transaction) that contains whatever other swaps/transactions they want. They just have to provide enough collateral for all transactions. Anyone checking a block will (in phase-1 checks) see whether enough collateral has been provided by the top-level tx.

The only smart contracts that may have a different result are those that actually care about the full transaction. But if they do care about the full transaction, why would you expect the local result to be the same as the full scope result? If this kind of smart contract actually did behave the same, it would be a defective smart contract.

Showing scripts within a swap the full transaction will never be advantageous over running scripts in the full sub-transactions, because if

contract does not care about full transaction : no difference in this case except that potentially the nested tx design will save on ex-units
contract cares about the full transaction : the builder of the top-level tx needs to inspect the script to see how the transaction they are building will affect the outcome. The swap builder will have to  additionally transmit info like "to make my scripts validate, you need to add an output to the top level tx that spends a specific input" or something like that, whereas a sub-tx can inspect existing transactions and condition on those without expecting the top-level tx builder to try to figure out how to make your script validate
since ex-units required are not known ahead of time for scripts in your swap, you have no way of knowing how much you owe the top-level tx builder in script fees, and therefore cannot build a swap that is guaranteed to pay them correctly. You have to trust them to "give you change" maybe?

Note that for swaps, allowing top-level transaction to affect script semantics has the effect that now they are not just the problem of the programmer or the person that wants to run the script. Script semantics become also the problem of the builder of the top-level tx, since they have to either figure out what the script expects from their top-level transaction construction in a (hopefully) automated way, or figure out that the script can never be satisfied by any top-level transaction.

Note that for swaps, allowing top-level transaction to affect script semantics has the effect that now they are not just the problem of the programmer or the swap-builder. Script semantics become also the problem of the builder of the top-level tx, since they have to either figure out what the script expects from their top-level transaction construction in a (hopefully) automated way, or figure out that the script can never be satisfied by any top-level transaction.

I don't think this is an insurmountable obstacle. Here are a few options I would personally try:

The tx builder can supply the (open-source) scripts for users to choose from. Effectively, these scripts act as trustlessly enforced settings for how the tx builder can use your piece. Since the tx builder is the one that created the scripts, they already know what the scripts expect.
The tx builder can have an automated "dialogue" with the user's smart contract. Smart contracts allow users to supply their own error/trace messages. The tx builder can require these error messages to follow some standardized formatting/syntax. Then, when the tx builder validates the transaction locally, it can adapt the transaction based on the error messages given by the scripts. This process can be fully automated and doesn't require any extra information from the user. For example, if Alice does not want script X to be executed, when her smart contract sees script X, it can throw the error not script <scriptX_hash>. This message can be easily parsed and understood by a machine. In other words, the error messages themselves become a kind of simple programming language. Any pieces with smart contracts that do not follow the standardized formatting/syntax can be automatically dropped. The tx builder can demand extra in fees for this feature. I would personally be willing to pay an additional 1-2 ADA in fees (paid in another token) if I needed finer control over how my piece is used.

Showing scripts within a swap the full transaction will never be advantageous over running scripts in the full sub-transactions

I think this assertion is too strong. You are effectively arguing there is no use case for logical nots with transaction pieces. In other words, you can't make your piece conditional on something else not happening. To say there is no use case for logical nots with transaction pieces seems too likely to be untrue.
Blockchain isn't just meant for distributed use cases, it is also meant to minimize how much you need to trust other people. Consider business partners that are jointly protecting some assets using a multisig. Right now, one of the partners needs to create the entire transaction and send it around to all of the other partners to sign. With transaction pieces, it becomes possible to build up the final transaction like a negotiation. Negotiations use logical nots all the time. Since these are business partners who likely talk directly, it would be trivial to convey the smart contract requirements since the point is just to trustlessly enforce the negotiations. In fact, the smart contract requirements are likely part of the negotiations. While general multisig can be used by business partners, I think it would be better if there was a method that more accurately models what happens in the real world. Transaction pieces with logical nots are exactly that; Alice can trivially make her signature conditional on certain conditions happening and other conditions not happening.

Could you provide an example of the use of this not in a negotiation?

Businesses are not allowed to mix business expenses and personal expenses. Doing so has huge legal consequences. When you are in business with a partner, only one of you needs to mess up to put all parties at risk. Even if you didn't know about your partner's misuse of funds, you will still be held accountable.
In the business multisig example using an unbalanced piece, if I sign off on spending the jointly controlled funds and my partner uses his share of the funds for a personal expense in the same transaction, regulators can easily view this as the business paying a personal expense since that is what it looks like on the blockchain. I would then also be held liable for my partner's misuse of funds.
It would be better for me to include a smart contract in my piece that will fail unless my partner sends his share of the funds to one of his pre-approved personal addresses (or pre-approved business expenses/donations). If the funds went to my partner's personal address and then he spent the funds from this address in a separate transaction, there would be a verifiable trail that the business paid my partner his salary and then he used his income on whatever he wanted. There is zero ambiguity on whether the funds were misused. This is effectively a negotiation where I agree to release the funds as long as my partner does not use his share of the funds for personal expenses in the same transaction.
This eliminates the need for me to have to trust my partner. If I just left my transaction unbalanced (ie, it is missing my partner's share in the outputs), I still have to trust my partner won't use his share for personal expenses in the same transaction. Splitting the transaction into two steps has the same limitation. In a business setting, I need to be able to put constraints on how the extra funds are used. The funds used for a personal expense cannot come from a business UTxO.
Again, I recognize this can be done with a general multisig, but this approach seems more natural and flexible. For example, imagine if I signed the full transaction, but now a change needs to be made for my partner's output. My signature is now invalid since the transaction is completely different; I need to sign the new transaction. If we used pieces instead, only my partner's portion needs to be updated and resigned. My piece is still valid and can already be used with my partner's new portion; he doesn't need to come back to me to approve the change to his output. In other words, the pieces approach makes it easier for businesses to make last minute changes to how funds are spent.

I think you are missing the point of my argument, though. Can you definitively say there isn't a single valid use case for logical nots with transaction pieces? Even if you or I can't come up with a use case, can you definitively say no one else in the world will have a valid use case for it either? I cannot which is why I don't feel comfortable choosing an option that potentially closes off valid use cases. Considering how similar the two approaches are, I would rather accept some slight drawbacks (within reason) to get the extra expressiveness that could potentially create an even more vibrant DeFi economy on Cardano.

It would be better for me to include a smart contract in my piece that will fail unless my partner sends his share of the funds to one of his pre-approved personal addresses (or pre-approved business expenses/donations). ”

Note here that along with the smart contract that checks this, you you have to include a specification (in some kind of language - maybe just use the Plutus contract itself or maybe something else) of the properties of other swaps that your contract should be compatible with . Then, the aggregator (top level Tx builder) will have to check every swap that comes in to see if it meets this specification of another swap(s) by running the Plutus contracts in every swap that comes in(or check them with whatever other language the specification is written in), rather than getting the full data needed for processing your sub-tx in one shot, and they have to do this for every arbitrary combinations of swaps. This compounds the problem that with swaps, there isn't even the possibility of DDoS protection via collateral, and anyone can get the aggregator to run some code that the sender themselves has never tried executing on relevant input.
This scheme also does not reduce communication (since your partner has to send a transaction to you in the case of nested transactions, and the aggregator in the case of swaps). If you yourself are the aggregator (which is likely the cheapest option for dealing with both swaps and nested txs), the two schemes are equivalent. Then, of course, there is the question of fees - they may change depending on other swaps, and that requires either trust or additional communication, such as requiring your partner to commit to paying for more exunits. If you, as the aggregator, are paying for their scripts, you still need their full transaction/swap .

You are right, though, the difference between zones, swaps, and nested txs is like ~10 lines of code in the Agda specification. I will actually maybe make the nested Txs CIP in such a way that you can toggle between your thing being a swap or a full tx.

if you want all sub-txs to be shown to all other sub and top-level txs, or only requiredTxs
and you can set a flag to toggle.

Who toggles this? If it must be toggled at the top-level, then the aggregator can maliciously not toggle it. Also, specifying required transactions by name won't work since the point is to have the logical nots work on any and all transactions.

Who toggles this? If it must be toggled at the top-level, then the aggregator can maliciously not toggle it. Also, specifying required transactions by name won't work since the point is to have the logical nots work on any and all transactions.

it's in the body of every transaction, so that the code will add the units provided the the aggregator if that is what you want. this allows the scripts in your transaction to see all other subTxs, but in case of failure, only top-level tx collateral will be collected

The new README-nested.md is a first draft of Nested Transactions.
It is  based on (hopefully) best of #880 and previous versions Validation zones.

No changes to block structure are required,
Transactions contain sub-transactions
An example of an additional kind of intent this design allows is given, which can be used to implement light client protocols (this is a demo of a potential approach to #779 )
It is possible (but not mandatory) for transactions to see all other transactions in the batch

@rphair @Quantumplation @fallen-icarus @WhatisRT
@lehins since this is heavily inspired by Swaps and VZ criticism, would you like to be a coauthor?

I'm happy to weigh in on the proposal, but I definitely can't commit to being a coauthor 😅

This new design makes it possible to define a script which (via conditioning on transactions fixed by requiredTx), checks that a specific other script (hash) must be run by another transaction in the same batch, or that payments made by other transactions satisfy some property.
This, as requested, can be done in two ways

directly specifying requiredTxs for a given transaction, and also
by allowing your transaction to see all others in the batch and condition on those. This second option requires you to not provide your own ExUnits data, similar to the #880 design, since you cannot locally check this without knowing all other transactions in the batch (then you are back to option 1)

After some discussion with @willjgould and @lehins , we have come up with a way for sub-transactions to constrain the batches they are in - batch observers, see the updated README-nested.md. This is very similar to script observers and both can/will? be implemented together , however

batch observers can be required by any transaction (using requireBatchObservers), but run only by a top-level transaction (it runs all the ones required by itself and its sub-txs)
batch observers get special TxInfo versions that contain otherInfos : List TxInfo , specifying the data of all sub-transactions
the TxInfo for all other script purposes does not contain otherInfos
new script purpose BatchObs Ix

It is essentially impossible to run (calculate exUnits, etc.) batch observer scripts unless you are building the top-level tx, so it probably makes sense for off-chain code to give special instructions to the top-level tx builder in some high-level language about how to build it in a way that will satisfy the script (simpler than Plutus).

Hey everyone.
I didn't have a clear idea on this CIP for a while but recently I'm thinking that it doesn't bring a lot of value especially considering the cost of implementation (impact on the ledger etc...)
Most of what validations zone could achieve could instead be achieved leveraging utxo contention.
We can have multiple transactions spending different utxos of a contract, but the same utxos of a given user.
All these transactions are mutually exclusive and the outcome is indeterministic until one of the transactions makes it to a block.
If someone is worried about contention on the contract, the more utxos the contract can spend (and the user can use in mutually exclusive transactions), the less chance of contention by the contract.
This is effectively moving the load from the ledger to the consensus, that in theory should already be able to handle, without hardfork.

BTW, I see and uderstand how validation zones could turn useful, and I not entirely opposed to it.
Just wanted to let you know of potential alternative possibilities

@michele-nuzzi Signing multiple transactions is a UX nightmare. Also... how much are you willing to waste in min-utxo fractionalizing liquidity across enough utxos to avoid contention. The fact of the matter is that pooling liquidity will give a better UX.
Take for example a musician minting their 100m stream tokens on NEWM. They want to list these tokens for sale. They can put them into a pooled AMM with ~1.3 ada, or they can take your approach and fractionalize it into 1000 chunks of 100k tokens. This costs 1,300 ada to list it.
As you fractionalize further, you don't necessarily avoid utxo contention. It actually increases as you'd have to pull more utxos into a given transaction to perform the swap and even 1 of them conflicting is a failure of the whole transaction.
If you've guessed wrongly and either over-fractionalized or under-fractionalized based on end user demand for the amount of tokens they want to acquire, contention becomes more likely. As the fractions run out as people buy, you can either continue to fractionalize, which leads to contention when people are trying to grab amounts larger than the fraction size and need to take a high number of the fractions to do their swap... contention.  Or, you don't continue to fractionalize and users are left fighting over the remaining fractions... contention.
I do look forward to what your catalyst proposal produces and how you plan to have users signing 2..3...20 duplicate transactions on their ledger device to "solve" the utxo contention issue. As you can tell from my response, I do not believe embracing utxo contention and fractionalizing liquidity is a viable approach.

@AndrewWestberg I think we are basing our perspectives on different assumptions.
There would ideally be a sweet spot to fractionalize liquidity. I don't think it is realistic to assume 1000 orders can be executed in the same block, so over ~30 orders there would be no benefit.
A well designed contract would also make sure that some given utxos can only be spent together to further reduce contention (if we must spend two utxos together is like spending only one).
I would also point out that CIP 103 is currently active, allowing users to sign multiple transactions without impacting UX.

Additionally relying on consensus rather than the ledger allows us more control over the transactions.
We can build many transactions that we directly control and look good enough for us rather than praying and hoping the nodes will pick a favourable utxos for the transaction.

If around 30 orders go into a block, but there are 1000s of users trying to swap, they will need to sign transactions against future state that is un-knowable. You're never going to get away from utxo contention being an extremely poor UX if there's any type of large demand. If I'm not in the first group of 30, there's no way for me to sign a tx(s) and come back and have my swap actually work. The utxos I signed against are long gone in any type of load scenario.
This CIP elegantly solves the problem.

Once again we are basing our statements on different assumptions.
Assuming the 30 orders will change the part of the state that future transactions depend on is the side-effect of the single-threaded mentality that prevents us to fully leverage what the utxo model can offer.
In my opinion, this CIP incentivizes this single-threaded approach that in the long term is counterproductive for the utxo model.

@polinavino Can you update the Rendered Proposal link in the top comment? It is still linked to the first README. Some people are reading that one instead of the latest README-nested, and this is causing confusion among people trying to learn about this CIP.

@polinavino I'd would suggest getting rid of all other versions of README in this PR and only keep the single README-nested.md (renamed to README.md), since other approaches have no chance of being implemented for technical reasons and they only lead to confusion, as @fallen-icarus rightfully pointed out.

@polinavino I have to agree completely with @lehins's suggestion as the proper way to clean up the problem @fallen-icarus pointed out.
Applying updates to a file other than README.md (with editors sometimes having to create & maintain a link here from the top comment, as we did back in July) is both a review and an editorial problem: especially without updates in the top comment about what any other README files are & how they relate to each other.
If needing to keep references to the other implementations, I would recommend perhaps a short-term solution of stripping the non-working files down to differences with the main working file... an d then ultimately including these in the Rationale along with any other alternatives not taken.

i left just the README.md which is the nested transactions one, and renamed the CIP to match


start arcadia

[x] add a cluster
[ ] init kubebb core
[x] add kubebb repo
[x] add kubeagi repo
[ ] deploy arcadia operator

closed as we start arcadia with helm/kubebb

closed as we start arcadia with helm/kubebb


feat: add process bar during dtm upgrade

Signed-off-by: 0zyt<EMAIL_ADDRESS>Pre-Checklist
Note: please complete ALL items in the following checklist.

[*] I have read through the CONTRIBUTING.md documentation.
[*] My code has the necessary comments and documentation (if needed).
[ ] I have added relevant tests

Description
Added a progress bar to the dtm upgrade
Related Issues
#1146
New Behavior (screenshots if needed)

Thank you for your contributions again! 🙌 Just don't forget to remove "todo" if you finish a feature next time. @0zyt

P.S. A small markdown syntax detail:

[x] task done

* [x] task done


TypeScript definitions

Currently, the package does not provide TypeScript definitions. It would be nice if the package provided TypeScript definitions to avoid this kind of error:
Error: Could not find a declaration file for module 'svelte-frappe-charts'. '/node_modules/svelte-frappe-charts/lib/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/svelte-frappe-charts` if it exists or add a new declaration (.d.ts) file containing `declare module 'svelte-frappe-charts';` (ts)

This should be pretty simple to do since the @types/frappe-gantt package is already available.

Made a PR ( #57 ) fingers crossed they review it 🤞🏾

It's been reviewed now, so once the questions/code comments have been addressed and it's rebased/merged with main I am happy to merge and release this!

Any update on this?

Please release types! Easy feature to add and is going to 10x the accessibility of this great library!

Are the types updated?

any updates in this issue ?


exit status 143 after successful verbose installation

I tried installing ruby 1.9.3-p0 and got an error after a successful installation
ubuntu@domU-12-31-39-0B-61-A1:~$ ruby-build 1.9.3-p0 /opt/ruby/1.9.3-p0 -v

....
Installed ruby-1.9.3-p0 to /opt/ruby/1.9.3-p0
/tmp/ruby-build.20120201172315.28186 ~
~
Terminated
ubuntu@domU-12-31-39-0B-61-A1:~$ echo $?
143

This was on Linux, I'm not quite sure how repeatable it is, but I got an error at the end of the installation twice (first time I didn't check the status code, except to see that it indicated an error).
In Mac OS X lion I got 0 as status code.
The Terminated does not show up in the actual log file, so I assume it belongs to the tail command, so I'm assuming that it somehow causes the command to fail, but a smaller test script didn't confirm my suspicion (tail exited normally there)

Third time I tried I didn't get an error, so it seems to be some kind of race condition.

Closing this, I missed issue #116 which is exactly the same


NetCDF attributes like long_name and units lost on .mean()

When reading in a variable from netCDF, the standard attributes like long_name, standard_name, and units are being propagated, but apparently lost when calling .load() .mean() on the DataArray.
Couldn't these CF-Highly Recommended Variable Attributes be kept during this operation?
(What to do with them afterwards, e.g. upon merge, is a different question, unresolved also in the pandas community.)
EDIT: the problem actually occurs when calling .mean() (not .load(), as originally posted).

Hmm. This is definitely a bug -- load should preserve all metadata.

Could you post an example dataset/code for which this occurs? I'm struggling to reproduce this.

Sorry for the confusion, the loss of attributes actually occurs when applying .mean() (rather than .load()).
See this notebook (same in nbviewer) for an example with some opendap-hosted data.

Ah. So this is intentional. .mean() does have an optional parameter that lets you control this -- try .mean(keep_attrs=True).
The basic problem is that it's ambiguous how to handle attributes like units after doing computation. I don't want to inspect attributes and choose some to preserve and others to remove, so we have a choice of either preserving all attributes in an operation or removing all of them.
Obviously, for some aggregations (e.g., sum or var) it doesn't make sense to preserve attributes (which commonly include units). I suppose we could make an exception for aggregations like mean/median/std, but it's also weird to have some aggregations that preserve attributes and others that don't.

That makes sense. Great that there is an option to keep_attrs. Closing this issue.


feat: Added SBUEventHandlers and onPressUserProfile.

Fixes: CLNP-1148

Questions
In relation to ticket, there are additional tasks besides the event handler:

Clicking on the profile within the reaction will change the default behavior to display the user profile. (Default: true)
The interface that displays the user profile should be made available to customers as a public interface.

Will these tasks be handled through a separate PR?

@bang9 thanks for noticing this. I was not aware of 1 and 2. It will be in separate PRs and targeting their release next week's release but not today.


How to load the environment dataset with  ApolloScape ?

We appreciate you go through Apollo documentations and search previous issues before creating an new one. If neither of the sources helped you with your issues, please report the issue using the following form. Please note missing info can delay the response time.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 18.04): 180.4
Apollo installed from (source or binary): source
Apollo version (3.5, 5.0, 5.5, 6.0): 6.0
Output of apollo.sh config if on master branch:

Steps to reproduce the issue:

Please use bullet points and include as much details as possible:
Recently I can run the demo_3.5.record file on  Apollo software. But I want to set up with environment dataset. I found the dataset ApolloScape http://apolloscape.auto/.   how did I operate the  Apollo to load the dataset .
and except that could I run the Apollo platform without demo_3.5.record?
could any expert give me some suggestion?
Thanks.

Supporting materials (screenshots, command lines, code/script snippets):
Currently I could run the demo_3.5.record file. But I want to run the Apollo completely without demo_3.5.record. Is there any suggestion to realize this point?

@luogyu7 It doesn't seem to work at the moment, apollo relies on the record package to run. We will try to fix the offline process, but importing datasets may not be supported yet


AssertionError: batch_normalization_1/keras_learning_phase:0 is disconnected

I trained an Efficientnet B2 model using [https://pypi.org/project/efficientnet/]
I am using
tensorflow==1.14.0
numpy==1.17.0
onnx==1.7.0
Keras==2.2.4
efficientnet==0.0.4
During the conversion, I get multiple warnings
WARN: No corresponding ONNX op matches the tf.op node swish_69/swish_f32 of type swish_f32
The generated ONNX model needs run with the custom op supports.

WARNING: Logging before flag parsing goes to stderr.

W0731 16:03:10.044219<PHONE_NUMBER>14528 parser.py:303] WARN: No corresponding ONNX op matches the tf.op node swish_69/swish_f32 of type swish_f32
The generated ONNX model needs run with the custom op supports.
WARN: No corresponding ONNX op matches the tf.op node drop_connect_16/cond/Merge of type Merge
The generated ONNX model needs run with the custom op supports.

W0731 16:03:10.045672<PHONE_NUMBER>14528 parser.py:303] WARN: No corresponding ONNX op matches the tf.op node drop_connect_16/cond/Merge of type Merge
The generated ONNX model needs run with the custom op supports.
WARN: No corresponding ONNX op matches the tf.op node drop_connect_16/cond/Switch_1 of type Switch
The generated ONNX model needs run with the custom op supports.

W0731 16:03:10.045809<PHONE_NUMBER>14528 parser.py:303] WARN: No corresponding ONNX op matches the tf.op node drop_connect_16/cond/Switch_1 of type Switch
The generated ONNX model needs run with the custom op supports.
WARN: No corresponding ONNX op matches the tf.op node drop_connect_16/cond/Shape/Switch of type Switch

The generated ONNX model needs run with the custom op supports.
W0731 16:03:10.045921<PHONE_NUMBER>14528 parser.py:303] WARN: No corresponding ONNX op matches the tf.op node drop_connect_16/cond/Shape/Switch of type Switch
The generated ONNX model needs run with the custom op supports.

And the conversion fails with the following error.
AssertionError: batch_normalization_1/keras_learning_phase:0 is disconnected, check the parsing log for more details.

The example for efficientNet conversion can be found in our nightly build here. It needs tensorflow >= 2.1.0 and set keras.backend.set_learning_phase(0).

The example for efficientNet conversion can be found in our nightly build here. It needs tensorflow >= 2.1.0 and set keras.backend.set_learning_phase(0).

I tried to convert it using the following dependencies
tensorflow_gpu = 2.3.0
keras=2.4.3
efficientnet= 0.0.4
Code
import keras2onnx
from keras.models import Model, load_model
import efficientnet
model = load_model(model_path, compile=False)
# converting to ONNX
onnx_model = keras2onnx.convert_keras(model, name=model.name)
keras2onnx.save_model(onnx_model, onnx_model_path)

After doing so I get
WARN: No corresponding ONNX op matches the tf.op node model_2/swish_69/IdentityN of type IdentityN                                                                  The generated ONNX model needs run with the custom op supports.                                                                                The ONNX operator number change on the optimization: 982 -> 601

tensorflow 2.3.0 support is ongoing, please use tf 2.2 at this moment.
This IdentityN is recently supported, so please pull keras2onnx from master rather than pypi.

I tried the same steps with these dependencies
tensorflow_gpu = 2.2.0
keras=2.4.3
efficientnet= 0.0.4
But unfortunately, I am still getting this error.
WARN: No corresponding ONNX op matches the tf.op node model_2/swish_69/IdentityN of type IdentityN                                                                  The generated ONNX model needs run with the custom op supports.                                                                                The ONNX operator number change on the optimization: 982 -> 601

See my previous answer, you need pull keras2onnx from master source code:
pip install -U git+https://github.com/onnx/keras-onnx

Thanks for your help.
I followed all the steps and the conversion was successful.
But the issue now is, I wanted to import this model to Snap Lens Studio. But when I import the ONNX model, I get this error
'Transpose' layer type is not supported
I know this issue is not related to this repo.
But if anyone is facing the same issue, as I am. Pls help....

Should we still use TF 2.2 for this?


adds stub to seeds type

Looks like there was a missing type for config.seeds.stub used here: https://github.com/tgriesser/knex/blob/master/src/seed/Seeder.js#L102.

Thanks!

Released in 0.18.0-next2


Fix padding and margin for LineLabels and Tooltips #824

I wanted to make a PR to check with you @imaNNeo that, this PR is going on the right direction. I still need to make more testing, so a draftish PR.
This PR is for #824 and there were also discussion about adding padding/margin for the tooltips as well.

What about these changes? There is no more margin, everything is done by vertical and horizontal offsets. I had to generate mockito files again, so I could write more tests, but I have no idea why it bumped the Mockito version on the comments.
// Mocks generated by Mockito 5.4.4 from annotations

HI, can you please resolve the conflicts?
Then I can review it

There were many conflicts, but hopefully everything is okay now. :)

Resolved conflicts again.

Thanks!
I have an issue with the calculations,
So suppose that we have 40 padding on all the sides, the result is not correct:

Everything seems good to me.
So please resolve those two discussions, and then we can take a look again at the changelog and merge!

Can you please rebase again?
Also, please don't update the CHANGELOG.md, because it is getting updated all the time and there will be conflicts.
Please write your proposed changelog here, I will add it to the file. Thanks!

Changelog:

* **BREAKING**  (by @k0psutin) Remove `margin` from HorizontalLineLabel and VerticalLineLabel, #824
* **BREAKING** (by @k0psutin) Remove `bottomMargin` from ScatterTooltipItem , #824
* **BREAKING**  (by @k0psutin) Remove `tooltipMargin` from HorizontalLineLabel and VerticalLineLabel, #824
* **BREAKING** (by @kopsutin) Add property `tooltipVerticalOffset` to BarTouchTooltipData, LineTouchTooltipData and ScatterTooltipItem to replace `tooltipMargin`, #824
* **IMPROVEMENT** (by @k0psutin) Add `tooltipPadding` to BarTouchTooltipData, LineTouchTooltipData and ScatterTouchTooltipData, #824
* **IMPROVEMENT** (by @k0psutin) Add `verticalOffset` and `horizontalOffset` to HorizontalLineLabel and VerticalLineLabel to replace `margin`, #824
* **BUGFIX**  (by @k0psutin) Fix `padding` to apply padding correctly in HorizontalLineLabel and VerticalLineLabel, #824

/// Migration guide:
/// Old way:
BarTouchTooltipData(
  tooltipMargin: -10,
)

/// New way:
BarTouchTooltipData(
  tooltipVerticalOffset: -10, // same effect as old tooltipMargin
  tooltipPadding: const EdgeInsets.symmetric(horizontal: 16, vertical: 8), // Adds padding to tooltip
)

/// Migration guide:
/// Old way:
ScatterTooltipItem(
  bottomMargin: 10,
)

/// New way:
ScatterTouchTooltipData(
  tooltipVerticalOffset: 10, // same effect as old tooltipMargin
  tooltipPadding: const EdgeInsets.symmetric(horizontal: 16, vertical: 8), // Adds padding to tooltip
)

@imaNNeo Is this feature still relevant? Should I continue updating/merging or should I focus on other features?


Pull request for therve/release-rc3

[Release] Update metadata
[Release] Bumped snmp version to 3.2.1

Closing as https://github.com/DataDog/integrations-core/pull/6690 released snmp for rc3


Removed refresh label from usercard

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable
no changelog entry needed

Description
Ever since #1982 we refresh messages on the usercard automatically, without any need to click the button anymore, so I decided to remove it and it seems that nothing broke.
There's also an extra change of tidying up one QString element without touching it, hope that's okay.

You removed the assignment to UserInfoPopup::refreshConnection_ but you didn't remove it or its usage in the destructor. Is it still required but somehow used elsewhere in the application?

Good catch! I simply removed the function responsible for refreshing new messages and I haven't seen the assignment of UserInfoPopup::refreshConnection_ in there, I assume it can be safely removed as there are no other references to it.

Also I'd consider this change significant enough for a change log update.

 I am still against a changelog entry since this is rather something that should be removed upon merging #1982. and has no longer any practical use what so ever.


Upgrade org.apache.maven.plugins:maven-compiler-plugin 3.8.1 -> 3.9.0

This PR contains the following updates:

Package
Update
Change

org.apache.maven.plugins:maven-compiler-plugin (source)
minor
3.8.1 -> 3.9.0

[ ] If you want to rebase/retry this PR, click this checkbox.

Suggested commit message:
Upgrade maven-compiler-plugin 3.8.1 -> 3.9.0

See https://github.com/apache/maven-compiler-plugin/compare/maven-compiler-plugin-3.8.1...maven-compiler-plugin-3.9.0


More diceware lists from https://ae7.st/g/

https://pthree.org/2017/09/04/a-practical-and-secure-password-and-passphrase-generator/

[ ] Bitcoin lists BIP039
[ ] Elvish and Klingon
[ ] Simpsons
[ ] Trump

[ ] Colors
[ ] Rockyou
[ ] Unofficial EFF FANDOM improved lists


MMM Example Notebook Improvement: Using DelayedSaturatedMMM

This PR improves the MMM documentation regarding the pymc-marketing API. The notebook focusses in the model specification and parameter recovery. We should have a more business-oriented notebook (see Robyn docs!).
Feedback is welcome!
P.S. @lucianopaz While working on this example I realised there is a bug in the step where we transform back the media contributions to the original scale. In https://github.com/pymc-labs/pymc-marketing/pull/119 and https://github.com/pymc-labs/pymc-marketing/pull/122 we rely to much ini the inverse_transform method. Still notice that we just need to multiply back by the scaling factor but we do not want to add the minimum of the target variable. You can test and see how the contribution shares and saturation curves are wrong. I am open for potential solutions but for now I reverted back the change in the DelayedSaturatedMMM and not the base class directly :)

This is awesome!

Thanks! Corrected!

View entire conversation on ReviewNB

Thanks! Corrected!

View entire conversation on ReviewNB

By design: x_1 should resemble a typical paid search channel and x_2 a TV spend time series. Still, no particular reason.

View entire conversation on ReviewNB

Yeah, for now I passed these Fourier modes as control variables since currently we do not have a separate seasonal component. I believe this is part of the next iteration and I will update this notebook accordingly.

View entire conversation on ReviewNB

Thank you @twiecki  for the feedback! I fixed the typos and added more interpretation os the results.

Thank you @twiecki  for the feedback! I fixed the typos and added more interpretation os the results.

Makes sense, maybe add that in for the uninitiated.

View entire conversation on ReviewNB

done!

View entire conversation on ReviewNB

🥳

This closes https://github.com/pymc-labs/pymc-marketing/issues/24


New registers and Remko App support

Added thermal consumption 5321
Added fixed value 1972 and 1974
Added status of additional heater 5051 (for hybrid gas system)
Support parallel use of Remko App
User has 120 s to make changes by Remko App
Custom component sends refresh only for 120 s
Only every 120 s query list is sent
Remko App sends CLIENT2HOST with CLIENT_ID included

Hello @aorzelskiGH
I just installed the main branch. What problems should I see if I don't use this patch? Is the App not working?

You can see with MQTT-Explorer and in the Remko App. Depending on the screen in the app, data is not updated there or data is not updated in home assistant, because it is not transfered any more.

Would you mind merging the open pull requests.

I won't merge all the changes but I'll integrate the "app function" as well as a new binary sensor.


Create ahoyDBusProxy.json

This is a node-red flow creating and registering PVinverter instances. (prepared are 3 instances, named MC1, MC2, MC3) which are fed from an ahoy DTU.  (see ahoydtu.de)  in turn The DTU connects and reads from Hoymiles HM-xx inverters of the given names and propagates the published AC-Power (P_AC)  This is very alpha - but working fine :-)
@freakent: thanks for the great work! Including more devices will work like a charm..

Merged in v0.7.4-beta as a sample, see #62.


Icons missing on Forms example page

Icons are missing on the forms example page:
Dashing Select Menu
Custom Dashing Checkbox
Disabled Custom Dashing Checkbox

This has been resolved.


README: Avoid logging for transient containers

according to paranoid.md. This does make the command line a bit longer but seems to offer a more secure setup for the occasional user who only follows the README. I haven't added any explanations to keep it short.

I think this is fine, thanks!


[fix][sec] Upgrade JacksonXML to 2.13.4

Motivation
Current version of JacksonXML (2.13.3) is vulnerable to CVE-2022-42004
Note that Pulsar is not directly vulnerable since the CVE exists only if DeserializationFeature.UNWRAP_SINGLE_VALUE_ARRAYS is used. And Pulsar doesn't use it.
Modifications

Upgrade to 2.13.4. It's a minor

[x] doc-not-needed

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@92b4708). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #18020   +/-   ##
=========================================
  Coverage          ?   39.09%
  Complexity        ?     6191
=========================================
  Files             ?      607
  Lines             ?    53396
  Branches          ?     5712
=========================================
  Hits              ?    20873
  Misses            ?    29768
  Partials          ?     2755

Flag
Coverage Δ

unittests
39.09% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.


feat: update paste_window options to be either a table of function

closes #183

:tada: This PR is included in version 4.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket: