add configuration option(s)

add a mechanism for configuration, options:

config file
config script that can be run on first use?
allow users to put input and output directory wherever on their system
allow users to exempt specific weekdays and specify their own text instead of a recipe (e.g. "Friday is pizza order day")
allow to pick from specific lists on specific weekdays ("Wednesday is soup day")
allow to supply more lists
include option to generate just one week at a time or more weeks at a time (might require checking if there are enough recipes, or repeating recipes if there aren't)

I might (should!) split this list into more issues!

Which data should the config file store? (given the current functionality)

file location: Input and output file
season determination: Is December 31st winter or summer where you live?
determine what days aren't cooking days, e.g. takeout/eating out, joker day, pizza ...
determine soup day (might evolve into days that use specific lists)


Question: Set Page Headers Without Knowing Number of Pages

Is there a way to set a page header on all PDF pages except the first page without knowing how many pages the resulting file will have?

Yes. just set add some html to your page:

Content on all pages

I do that, but I have no idea how many pages will be generated by the PDF itself. Each file will have a different number of pages. I need to skip the first page and set the id to go from pageHeader-2 all the way to pageHeader-n. Is this possible without knowing the number of pages that will be generated?

Content on all pages

Is the default one. You don't need to enumerate everything. That will be used as fallback in case pageHeader-${index} isn't present.

Do you need more? Maybe I misunderstood your problem.

Using pageHeader-${index} works, but I cannot hard code a set number for the index itself because I do not know how many pages will be generated. For example, I can generate one PDF with 5 pages and then another PDF that will have 20 pages. I would need to be able to handle both of those without knowing for sure how many pages will be generated. Currently the only option I can think of is to maybe use some Javascript on the template to generate the markups up to a very large number in order to catch it.

You can use both together. Then all the pages use the default header and page 1 uses the empty one.
It should work like that.

Header of first page

Fallback header for all other pages

Some content

Second page content

Third page content

That does not work. The markup for the header on all other pages displays on the first page as well.

Then that's a bug. That should be handled in here:
https://github.com/marcbachmann/node-html-pdf/blob/master/lib/scripts/pdf_a4_portrait.js#L152-L157

That does handle it, but not in the way I was expecting it to be handled. What happens is that the content of the element gets displayed on the proper page, but the empty element gets display on all of the other pages. I was expecting that the element would be removed or set to display: none on subsequent pages.


Refactor rendering logic into separate methods

This change was prompted by wanting to refactor the code to work towards
having different trait bounds for the functions that need a repository
that supports renders (e.g., rendering into a repository) versus
functions that render into a plain directory.
Rework RenderType so the method that renders into a hardlink doesn't
need to worry about getting a RenderType::Copy value.

@rydrman do you have a use case for hard linking into external directories?

Yes, we leverage this quite extensively. Our storage is read-only for users and the permissions are standardized so we hardlink nearly all of our large deployments

Okay I guess I need to rethink my refactoring. However don't you agree that this is a dangerous feature to support, in general? I think it might be good to gate it behind some kind of opt-in setting or something, so people understand the consequences.

A warning or extra confirmation on the command line maybe since that's really the only place you can invoke it like that...


Windows 1click Installer question

Hi, I bought the one click installer because it seems to me a valuable and powerful tool.  I am not a user who knows how to program, im just copy and follow tutorials to install this thins, so I am sorry if my question sounds stupid. I have installed in my local pc Automatic1111/SD and the one click installer of Oobabooga LLM; this one click installer will not cause aconflict with those other two programs? because I see that lama-cleaner uses something called torch 1.13, while the other two use version 2. Thats my only question; thanks.

Hi, thank you for your support. This one-click installation package is completely independent. Torch will be installed in its own environment and will not affect other programs.


[Android] Modify chiptool crash when skipCommissioningComplete flag enabled

Fix #32686
When in CleanUp Stage, if CommissioneeDevice exists, it must be freed. However, this process must be final. This issue causes a crash because CommissioningStageComplete is called after Release and mDeviceBeingCommissioned is null.
Crash Point :
https://github.com/project-chip/connectedhomeip/blob/824ba6dbd9a7e783353f4c714e7ca0ba03615c64/src/controller/CHIPDeviceController.cpp#L1903

I know this needs to be addressed, but I'm not sure how to do it. Is there a suitable solution?


Update Makefile

A new 'ocs-registry' target has been added to the Makefile. The other
targets have been updated to make the tools and the variables used
consistent.
The README has been update to use the Makefile and the consistent
variables.

/hold
This depends on #19. Hold until it is merged.

@obnoxxx Is this review just for the Makefiles, or is it for #19 too? This PR is based on top of #19. I split it into 2 as these are for different topics.

@kshlm, indeed let me review #19 first. :-)
I think my comment was for the "Update makefile" patch.

#19 has been merged, @kshlm do you want to rebase this?

@obnoxxx A rebase isn't so useful as the CI bot does merge commits any ways. After you give your approval, prow also ensures that it runs the tests once on a merged branch, before actually merging the change into master.

/hold cancel

@obnoxxx A rebase isn't so useful as the CI bot does merge commits any ways.

Well ok. My brain is probably still too much wired to doing rebases. And the merge commit did only work smoothly because you updated this PR as well when you updated #19.... My approach would have been to update 19 first and get it merged, then update this. But it has worked nicely this way, too! :-)
I would just try to avoid having merge commits that do conflict resolution.
I was also expecting two copies of the common patches, but apparently, looking at the current master branch, it has not happened, so all good! :-) (It would probably have happened if you hadn't rebased this on the exact commits that were then merged with #19.)

After you give your approval, prow also ensures that it runs the tests once on a merged branch, before actually merging the change into master.


Delete ignored key from config.json

Since the exercise implementations are all in the exercises directory
we no longer need to ignore any non-exercise directories in the root
of the track.
See https://github.com/exercism/meta/issues/3 for context.

I've created another PR, #8, which normalizes all of the whitespace in the config.json so
that the change in this PR is minimized and easier to see.
If you merge the other PR first, I'll go ahead and rebase this one onto master.
Sorry about the noise!


Fatal error: Uncaught Error: Class 'Symfony\Component\Process\Process'

Hi, I am using your native code from the library. However, it went in error.
Fatal error: Uncaught Error: Class 'Symfony\Component\Process\Process' not found in /opt/lampp/htdocs/vendor/chrome-php/chrome/src/Browser/BrowserProcess.php:123 Stack trace: #0 /opt/lampp/htdocs/vendor/chrome-php/chrome/src/BrowserFactory.php(73): HeadlessChromium\Browser\BrowserProcess->start('chrome', Array) #1 /opt/lampp/htdocs/curl.php(37): HeadlessChromium\BrowserFactory->createBrowser() #2 {main} thrown in /opt/lampp/htdocs/vendor/chrome-php/chrome/src/Browser/BrowserProcess.php on line 123
Here is the code
use HeadlessChromium\BrowserFactory;
require_once($_SERVER["DOCUMENT_ROOT"].'/vendor/autoload.php');

$browserFactory = new BrowserFactory();

// starts headless chrome
$browser = $browserFactory->createBrowser();

try {
    // creates a new page and navigate to an url
    $page = $browser->createPage();
    $page->navigate('https://google.com')->waitForNavigation();

    // get page title
    $pageTitle = $page->evaluate('document.title')->getReturnValue();

    // screenshot - Say "Cheese"! 😄
    $page->screenshot()->saveToFile('/foo/bar.png');

    // pdf
    $page->pdf(['printBackground' => false])->saveToFile('/foo/bar.pdf');
} finally {
    // bye
    $browser->close();
}

Where is the problem anyway?

@flameblue59 I'll fix this issue. You got this one because you'll not pass the path to Chrome.exe to work with this library. Try to pass the next into ```php

This doesn't seem to be an error with the chrome path, but with a missing class.
@flameblue59 did you install the dependencies correctly using composer?

@enricodias actually
php BrowserFactory cannot run browser instance for windows without passing the right path to Chrome.exe. I may assume that $_SERVER["CHROME_PATH"] works well on a Linux environment but with [Windows 10 x64 | OpenServer | PHP 7.4] it not works at all.
P.S.
It is my $_SERVER
Array
(
[HTTP_HOST] => chromium
[HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
[HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
[HTTP_ACCEPT_LANGUAGE] => ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
[HTTP_ACCEPT_ENCODING] => gzip, deflate
[HTTP_CONNECTION] => keep-alive
[HTTP_COOKIE] => notice_behavior=none
[HTTP_UPGRADE_INSECURE_REQUESTS] => 1
[HTTP_CACHE_CONTROL] => max-age=0
[PATH] => c:\openserver\modules\php\PHP_7.4\ext;c:\openserver\modules\php\PHP_7.4\pear;c:\openserver\modules\php\PHP_7.4\pear\bin;c:\openserver\modules\php\PHP_7.4;c:\openserver\modules\wget\bin;c:\openserver\modules\database\MariaDB-10.3\bin;c:\openserver\modules\http\Apache_2.4-PHP_7.0-7.1\bin;c:\openserver\modules\http\Apache_2.4-PHP_7.0-7.1;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\Wbem;C:\WINDOWS\SysWOW64
[SystemRoot] => C:\WINDOWS
[COMSPEC] => C:\WINDOWS\system32\cmd.exe
[PATHEXT] => .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
[WINDIR] => C:\WINDOWS
[SERVER_SIGNATURE] =>
[SERVER_SOFTWARE] => Apache
[SERVER_NAME] => chromium
[SERVER_ADDR] => <IP_ADDRESS>
[SERVER_PORT] => 80
[REMOTE_ADDR] => <IP_ADDRESS>
[DOCUMENT_ROOT] => C:/OpenServer/domains/chromium
[REQUEST_SCHEME] => http
[CONTEXT_PREFIX] =>
[CONTEXT_DOCUMENT_ROOT] => C:/OpenServer/domains/chromium
[SERVER_ADMIN] => [no address given]
[SCRIPT_FILENAME] => C:/OpenServer/domains/chromium/index.php
[REMOTE_PORT] => 55585
[GATEWAY_INTERFACE] => CGI/1.1
[SERVER_PROTOCOL] => HTTP/1.1
[REQUEST_METHOD] => GET
[QUERY_STRING] =>
[REQUEST_URI] => /
[SCRIPT_NAME] => /index.php
[PHP_SELF] => /index.php
[REQUEST_TIME_FLOAT] =><PHONE_NUMBER>.871
[REQUEST_TIME] =><PHONE_NUMBER>
[argv] => Array
(
)
[argc] => 0

)

We might bundle this library with chrome.exe (*as a driver) and deliver it like an earlier had made it by the team of Symfony Panther but it hard to say whether it will need to update Chrome.exe to often.
P.S.
Symphony Panther refused of delivering the browser drivers in a bundle with the library

@ismaxim I know it cannot run without the proper path, I'm just saying that the problem in this issue doesn't seem to be related to the binary path.


Can closing and opening blocks of code show closed "}" like WebStorm.Idea and Webstorm do this very well.

Can closing and opening blocks of code show closed "}" like WebStorm.Idea and Webstorm do this very well.

/needsMoreInfo


[Apple Reminders] Menu Bar Reminders

Extension
https://www.raycast.com/raycast/apple-reminders
Description
The "My Reminders" command is able to filter reminders on a certain list.
The Menu Bar Reminders displays reminders for all lists. This includes "past due" reminders from all lists.
I would like to be able to select which list(s) to display reminders from. The list selection could be made in the settings in the same way the "View" is configured.
Who will benefit from this feature?
Everyone who uses different lists for different purposes. Separate work/personal reminders etc.
Anything else?
No response

Hi @thomaslombart,
I am interested in working on this! Currently, I have a few potential solutions in mind:
Solutions
1. Preferences
One option is to save the name of the list in the command preferences. Then, only display reminders from the selected list. However, this approach is prone to errors due to user input. The preference can only be a textfield, and the list name can change without notice.
2. Shared State
We could utilize the cached state of the my-reminders.tsx command. If I make changes to the list there, it would also reflect in the menu bar. The drawback here is that you can select a list (e.g., today) that is already in the preferences.
3. Cached State
Similar to my-reminders.tsx, we could add a cached state with the list ID. The list can be modified in the command bar using a submenu. The submenu would list all available lists for selection.
Conclusion
Personally, I prefer solution 3. It eliminates the need to access command preferences and prevents the user from entering an incorrect list name. Additionally, it allows for displaying different lists in the command bar and the My Reminders command. What do you think is the best option?

Solution 3 is indeed a great compromise, as you did with the PR.


[stable/spinnaker] Changing email of dwardu89

What this PR does / why we need it: Changing the email of dwardu89, there are no functional changes.

/ok-to-test

/ok-to-test

/assign

/lgtm


Support encryption?

I want to uncompress archive with password.
Is there a way to do it or is there any plan to do it?

Not currently but we are open to accept a PR adding it.

Not currently but we are open to accept a PR adding it.

I'm studying ways to implement it, I just realized that it's not supported :( friends who are rust experts, I found an implementation using libarchive in python, I'll try to implement it, but I'll leave it here in case something wants to implement.
https://github.com/Changaco/python-libarchive-c/pull/109

Thank you, @hivexdev. Please know that I am open to review and help with anything you need. Just let me know how I can be of assistance.

@hivexdev news on your side?

https://github.com/OSSystems/compress-tools-rs/pull/116


Exception with important variables

Is your feature request related to a problem? Please describe.
I always feel sad when I see that my code throws an error simply because the obfuscator renames an important variable in my code.
Describe the solution you'd like
It would be perfect if there was an additional option, like JSON, in the advanced options section to add important variables that should not be renamed.
Additional context
On the website https://obfuscator.io/, the Reserved Strings option works perfectly.

Duplicate of #54, pass a custom renameVariables function.


port to 1.16.5

backport to 1.16.5, please
it's a very popular version
thanks!

I'm sorry, I won't do it


[Trick] Crow Mind Ploy return a true on succecful execution

Crow Mind Ploy is a trick sated to not return anything in its description and name.
However on execution it returns the boolean true.
With some light test there doesn't seem to be any case where it can return false.

Fixed in latest update.


Enable video recording through ARCore & AREngine

Adds support for recording camera through ARCore and AREngine APIs
Fixes all build flavors
Updates Gradle to latest to fix symlink handling
Updates to latest mobile-cv-suite to support building on Mac

TODO: Focal length is still missing

I moved all native access in CameraWorker and AlogrithmicWorker to go through private final Handler mNativeHandler; owned by AlgorithmicActivity. Based on my short tests this seemed to work. Previously both had their own handlers and it seemed to corrupt the jsonl recording due to it being written from two different threads.


Improve search for content under different ink! version

Hey there, at the moment (at least for me), the search bar in the upper right returns results for both documented ink! versions (3 & 4). And it doesn't even highlight the version. I find it quite counter-intuitive (esp. for newbies) accidentally switching to an earlier version of the documentation without even noticing.
IMO, it should either highlight the version next to the results or (preferred) search should be only within the currently active version of the documentation.

Oh boi, thanks for reporting this, I never noticed.
I just fixed it, but I'm not super-happy about it. The plugin that we use is just not that mature.  I've created this follow-up: https://github.com/paritytech/ink-docs/issues/184.


[Feature request] Define multiple abilities for components

It would be beneficial to have the capability to define multiple abilities. In many of our applications, parent components may encompass several actions. For instance, creating a post and updating a post.
<Can
    :ability="[createPost, editPost]"
    :args="[post]"
  >
    <button>Edit</button>
  </Can>

or with multiple args
<Can
    :ability="[createPost, editPost]"
    :args="[[post], [post, another-argument]]"
  >

Hey!
Don't you think it's easier to combine ability within a new ability instead of composing them like this?

While this approach may be somewhat more intricate, it provides the developer with comprehensive information through a single line of code. Additionally, we utilize capabilities somewhat differently than by creating separate abilities, as our backend supplies all user permissions via the API.
Thus, we maintain only one ability to encompass all functionalities.
type PermissionTargets = 'any' | 'all';
export const laravelPermission = defineAbility((user: User, permissions: string, target: PermissionTargets = 'any'): boolean => {
    if (!permissions) {
        return true;
    }

    const _permissions = permissions.split('|');
    if (target === 'any') {
        return _permissions.some(permission => user.permissions?.includes(permission));
    } else if (target === 'all') {
        return _permissions.every(permission => user.permissions?.includes(permission));
    }

    return false;
});

<Can
    :ability="laravelPermission"
    :args="['projects.store']"
>

Now we need to develop custom abilities to determine whether the logged-in user is internal or external. To achieve this, I would prefer:
<Can
    :ability="[laravelPermission, isInternal]"
    :args="['projects.store']"
>

Ok, I see. Do you think you can open a PR for this? I have more free time so it will be faster for me to review your PR!


Rename integration-tests references

Should fix errors while spinning up the notification service during end-to-end-tests on Travis, like here: https://travis-ci.com/github/hpi-schul-cloud/schulcloud-server/jobs/426879819#L2515

solved in https://github.com/hpi-schul-cloud/docker-compose/pull/25


Mobile Web doesn't work on Metamask/Rainbow link

Hey! thanks for this example package. So I noticed that mobile web doesn't seem to work. For example if I go to https://example.walletconnect.org/ on mobile web and login with Metamask or rainbow it does work but I'm not able to get it work on your site https://web3modal-example.vercel.app.

It's working fine for me! using Rainbow 1.5.25(2).

@siddharthsharma94 Strange, it's working for my Metamask mobile when I scan the QR code. I'm on Android though, not sure if that makes a difference. I just updated some of the dependencies, can you give it another shot?

Huh, looks like it works now! I think maybe one of the underlying dependencies may have been the issue. Thanks so much!

I am developing an Dapp on angular .
When I connect to metamask using web3modal, it works fine both in development and production.
When I connect to trustwallet or mobile metamask(browser) and  metamask (mobile) it works fine in development.
connecting to trustwallet or metamask (mobile) fails in production( ie deployed to server), On scanning the QR code , it will show a blank space on trustwallet then return to settings, on metamask(mobile) no action is seen after scanning.
Web3Modal walletconnect works when connecting from localhost:4200 in all wallet using QR code
Web3Modal walletconnect fails when connecting from  an online server -->  http://www.dapptest.com
I really don't know What I am doing wrong. I cannot detect why all wallet connections are fine on localhost, but fail on production (online server).

Hey! i have a same type of problem.
Web3modal working perfectly on desktop - opening all provider options and metamask.
Web3modal doesnt working on mobile corretly - dont see metamask.
I testing this: https://web3modal-example.vercel.app
and many different dapps and have same problem. Maybe somebody know why metamask doesnt injecting?


node4-lts 4.2.4

https://nodejs.org/en/blog/release/v4.2.4/

Thanks for your contribution to Homebrew!  You rock!


[Bug] Typescript does not use the same trigger characters as VS Code

Reproducible in vscode.dev or in VS Code Desktop?

[x] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[ ] Not reproducible in the monaco editor playground

Monaco Editor Playground Code
monaco.editor.create(document.getElementById('container'), {
	value: "type Foo = 'foo' | 'bar';\nconst doSomething = (foo: Foo): void => {\n    // Do something\n}\ndoSomething('')",
	language: 'typescript'
});

Reproduction Steps

Create a type in Monaco that consists of string literals
Create a function which uses that type as a parameter
Attempt to call that function

Actual (Problematic) Behavior
Autocomplete does not appear until you manually bring it up with ctrl + space, both after typing the opening parenthesis and the opening quote.
Expected Behavior
Autocomplete (with options 'foo' and 'bar', in the case of the example) appears as soon as you type a quote in the function parameter.  This is how it VS Code works, both in the desktop and the browser.
Additional Context
This seems to be caused by the different triggers characters in the SuggestAdapter, in Monaco and in VS Code.  It's possible that this is intentional behavior, but I couldn't find it documented anywhere.
This issue was brought up in #2883, but was not marked as a bug there.

I would also like this to be added


reading yml files from directory

Is there a way to read bunch of yaml files from directory instead just a file to apply the rule. I currently have yml files stored in "files" directory and --file option isn't reading all the files.
copper check --rules myrule.cop --file files/*.yml
tried
copper check --rules myrule.cop --dir files/*.yml , but no worky.
ERROR: "copper check" was called with arguments ["--dir", "files/elastic_scc.yml", "files/test-admin.yml"]
Usage: "copper check"

@srjayep currently Copper doesn't support multiple file checks (it does support multiple yamls in a single file separated by --- however).
To run Copper for multiple files in a folder you can try something like this:
for file in /dir/*
do
  copper [option] --file "$file"
done


_tsSimpleAstBrand and import typescript directly

This is a question about the copy of typescript.d.ts inside simple-ast and basically the _tsSimpleAstBrand member:
  /**
    * This brand prevents using nodes not created within this library or not created within the ts namespace object of this library.
    * It's recommended that you only use this library and use its ts named export for all your TypeScript compiler needs.
    * If you want to ignore this and are using the same TypeScript compiler version as ts.versionMajorMinor then assert it to ts.Node.
    * If you don't use this library with this same major & minor version of TypeScript then be warned, you may encounter unexpected behaviour.
    */
  _tsSimpleAstBrand: undefined;

First, I would like to make sure I understand correctly.
Is the idea that in my project I always reference the typescript native types declared on your library, and is not advisable to import typscript's declarations never ? Something like:
import {  ts } from 'ts-simple-ast';
instead of :
import * as ts from 'typescript'
??
I would like to document this better in https://dsherret.github.io/ts-simple-ast/navigation/compiler-nodes so I want to make sure i got it.
Second, my opinion,

Is it really necessary that simple-ast duplicate and export typescript's decls?
Why couldn't just use user's typescript version? (he will be responsible).
once the user enters in the "compiler world" (using compilerX member) then is up to him and he will be responsible of that code and of the typescript version.

Two (bad) experiences:

I wanted to run / compile my simple-ast based code using typescript 3.0 and for the particular thing I wanted to try (new things) it was not possible (only casting to "any" I was able to compile)

some things are in simple-ast ts namespace and other are not and this seems to be arbitrary. for example, SyntaxKind is not in ts, ClassDeclaration and Node are on . If the idea is that users work this way the code will be hard to maintain and understand...

(the last one was just my opinion, I think I want to know the reason you were forced to do this)
thanks

Is the idea that in my project I always reference the typescript native types declared on your library, and is not advisable to import typscript's declarations never ?

Yup. I highly recommend not using an imported version of TypeScript because it will most likely lead to bugs if the versions aren't the same.

Is it really necessary that simple-ast duplicate and export typescript's decls?

Several reasons:

There are very often breaking changes in the compiler API.
Previously when this library referenced Compiler API declarations in its declaration file, that would throw compile errors when the user didn't have something this library referenced (ex. user is using TS 2.5 and this library's declaration file is referencing ts.JSXFragment found in 2.6... well now that's a compile error for the user)
There may be incompatibilities with ts-simple-ast depending on newer features not found in the version of the typescript compiler you are depending on.
Sometimes people may want to use an old version of the compiler to compile their code and if this library didn't support that version then that would be a problem.
Means I only have to support one version of the compiler (way less maintenance)
Allows me to pull out commonly used parts of the compiler API to ts-simple-ast to make it easier to use (more on that later)

Previously this library had a peer dependency on the typescript compiler API and it caused all sorts of problems. Bringing it into this library solved all these situations.

Why couldn't just use user's typescript version? (he will be responsible).

The user is not always responsible ;)

I wanted to run / compile my simple-ast based code using typescript 3.0 and for the particular thing I wanted to try (new things) it was not possible (only casting to "any" I was able to compile)

This is a very rare edge case. I would recommend checking out the library and then updating the library yourself and use that. You'll need to run the createCompilerApiLayer function to regenerate the compiler api declarations after updating (then you can use npm run package—command I just added—to build and create the declaration file for the app). I tried doing it right now and ran into some differences with the latest "@next" version not working the same way as the current version (reinforcing my point on why this library only depends on one version of the compiler).

some things are in simple-ast ts namespace and other are not and this seems to be arbitrary. for example, SyntaxKind is not in ts, ClassDeclaration and Node are on . If the idea is that users work this way the code will be hard to maintain and understand...

When using ts-simple-ast, the library itself is first class and the compiler API is secondary. SyntaxKind is pulled out because it is used often in the library. ClassDeclaration is not because you should be using the wrapped ClassDeclaration that the library exposes. In your case, you're approaching using this library from using the compiler API, but most people approach it from no experience with anything and so it's more geared towards those people.

Thank you very much for the detailed explanation. Glad to know you already walked the path of depending on imported typescript and know the consequences! I have some replies but better leave them till tomorrow. Thanks again, great work! I'm following progress on ts team but seems only recently they have payed more attention to compiler API but still very little for my taste. For example they are just implementing file move refactor while you already have it here. This is exiting! thanks!
P/D in my case is worst than using the compiler API, i'm trying to integrate this with language service plugins - so far so good. But still much to learn. thakns

Updated the documentation. Closing this issue.


Source code for release 1.9.4 is required.

Question?

Regarding release version
I want to get source code for release version 1.9.4 but I cant find it now. I can only see 1.9.6 version source now.

Can I please get either release version 1.9.4 or if you can tell what is the difference in 1.9.4 and 1.9.6 as we are using 1.9.4 app package at our end.
Documentation can be found here: https://opensource.adobe.com/asset-share-commons/. It might answer your question!

Sorry about that - the Git tags for v1.9.2 and v1.9.4 were named incorrectly (or not per convention) and were accidently cleaned up.
Re-added them to the Github releases:
https://github.com/adobe/asset-share-commons/releases
Note that 1.9.6 is the only 1.x release on Maven Central (other 1.x are all on the old repo.adobe.com)


Review the new DVC sharing experiments workflow and unify it with VS Code

With https://github.com/iterative/dvc/issues/9074 and https://github.com/iterative/studio/issues/5050 DVC introduced a way to connect to Studio and a workflow that sends experiments to Studio.
We need to review and unify / make it compatible:

[ ] Token management https://github.com/iterative/dvc/issues/9265
[ ] Sharing experiments. Can we detect that it's already being shared? Show a link?
[ ] Auto-sharing mode - does it contradict or not with existing DVC workflow?
[ ] Do we still need to use our own client implementation or not?

Can we detect that it's already being shared?  Show a link?

We could fetch from the git remote or use dvc exp list to see what's been pushed. Do we need anything specific to Studio?
I'm a bit behind on the Studio efforts to have more shareable links, but I think we can follow it in https://github.com/iterative/studio/issues/5419 and https://github.com/iterative/studio/issues/5150.

Auto-sharing mode - does it contradict or not with existing DVC workflow?

I guess it means this:

I don't think it contradicts. Does it do anything besides add the STUDIO_TOKEN to experiment actions @mattseddon? I think it's needed since there's no other obvious way to enable this behavior when working in the extension.

Do we still need to use our own client implementation or not?

I hope not.

Sharing experiments. Can we detect that it's already being shared? Show a link?

I don't know if we have a good way to detect what experiments have been live shared. For exp refs, we could use dvc exp list to check the git remote. If they exist there, there should be a record in Studio, although it's possible it hasn't been retrieved/parsed yet by Studio.
I would add an item to consolidate and unify the sharing options. Here's what I see today:

Overall, I think we can have a single "Share" action that relies on dvc exp push now and drop the existing different ways to share. This will hopefully make sharing more straightforward.
Now Studio should show any experiments that are pushed to the Git remote via dvc exp push, so we shouldn't need to rely on the live metrics API anymore. dvc exp push will notify Studio if STUDIO_TOKEN is set or if the token is available in studio.token in the DVC config (depends on https://github.com/iterative/dvc/pull/9257; we will likely recommend using dvc config --global studio.token xxx for CLI users).
dvc exp push will push the cache by default. Not sure if we need an option to disable that, but we should at least be aware that it could make pushing slow.

Sharing experiments. Can we detect that it's already being shared? Show a link?

I think DVCLive creates some special signal file with a process pid? Can we utilize it cc @mattseddon @daavoo .
On the "share" actions. I agree, @dberenbaum  we can add item to the list to consolidate this and simplify. We still keep an apply action though, right? So that I can make locally a commit out of an experiment at least. We just don't send these commits, neither we try to do dvc push, etc.

We still keep an apply action though, right? So that I can make locally a commit out of an experiment at least. We just don't send these commits, neither we try to do dvc push, etc.

Agreed, we can keep local actions like "Apply to workspace" and "Create new branch," I just don't think we need to combine them with the sharing action.

I would add an item to consolidate and unify the sharing options. Here's what I see today:

Overall, I think we can have a single "Share" action that relies on dvc exp push now and drop the existing different ways to share. This will hopefully make sharing more straightforward.
Now Studio should show any experiments that are pushed to the Git remote via dvc exp push, so we shouldn't need to rely on the live metrics API anymore. dvc exp push will notify Studio if STUDIO_TOKEN is set or if the token is available in studio.token in the DVC config (depends on iterative/dvc#9257; we will likely recommend using dvc config --global studio.token xxx for CLI users).

I'm happy to drop Commit and Share + Branch and Share and update Share to Studio to use exp push and label it with simply Share. My one question would be "how do we promote Studio as a sharing option"? Currently, with the custom implementation of the Studio client and the command's label, we can do a few things:

Promote Studio as a sharing option.
We can check to see if there is a Studio token set for the extension and redirect to the setup page if there isn't one present.
If we receive a 401 we can notify the user that they need to update their token.

Should we drop this logic altogether and not worry about the edge cases?
How do we show users that sharing to Studio is an option?
It feels like we need an API that we can use at startup to check whether or not the user has a valid token and if not prompt them to add one/update. Otherwise, we can't provide much help to users once they leave the happy path.

dvc exp push will push the cache by default. Not sure if we need an option to disable that, but we should at least be aware that it could make pushing slow.

From testing out with the demo project moving from the old API to using exp push blew the time out to share an experiment from 1s to ~90s, after the initial push this dropped to 14s. It would be good to be able to reduce that time in any way possible.

I'm happy to drop Commit and Share + Branch and Share and update Share to Studio to use exp push and label it with simply Share. My one question would be "how do we promote Studio as a sharing option"? Currently, with the custom implementation of the Studio client and the command's label, we can do a few things:

Sorry, I'm getting confused by all the different ways to share. Do you mean how do we promote live sharing to Studio, or any kind of sharing to Studio?

It feels like we need an API that we can use at startup to check whether or not the user has a valid token and if not prompt them to add one/update.

Not sure I follow all the suggestions, but can we start simpler by checking whether the user has a token at all and assume it's valid if it exists? I think checking the token validity is less of a priority for now.

From testing out with the demo project moving from the old API to using exp push blew the time out to share an experiment from 1s to ~90s, after the initial push this dropped to 14s.

Are you testing with checkpoints?

Sorry, I'm getting confused by all the different ways to share. Do you mean how do we promote live sharing to Studio, or any kind of sharing to Studio?

Any kind of sharing to Studio. How do we highlight this as a collaboration option?
Note: I can see from https://github.com/iterative/dvc.org/pull/4470 that if a user has a token present in their config then they can live share experiments but not sure what the default behaviour is.

Not sure I follow all the suggestions, but can we start simpler by checking whether the user has a token at all and assume it's valid if it exists? I think checking the token validity is less of a priority for now.

I think we need a Studio API that we can check auth details against but this should be fixed/made obsolete by https://github.com/iterative/studio/issues/5158.
A couple of follow-up questions:

Can I use dvc config studio.token to check if a user has a Studio token in their config? (if yes I can use it as an environment variable if "live sharing" is enabled)
When setting the token into a user's config should I set it as --global or --system?

If users have already set this up I think we should still prompt them to add again as this makes it explicit that we are saving it in their DVC config (rather than expending effort migrating the secret).

Are you testing with checkpoints?

In this instance no, checkpoints were dropped on the branch that I was testing with.

Thanks @mattseddon! A couple of not directly related thoughts before responding to your questions/comments.
Looking through the Studio onboarding from VS Code, do we need the "sign in" button? The "get token" button will take them to the same place if not signed in.
To make sharing more useful, can we also include an action to share after selecting multiple experiments (it looks like you can only share one at a time now)?

Any kind of sharing to Studio. How do we highlight this as a collaboration option?

When choosing to share, we could prompt them with something like Connect to Studio to see and manage shared experiments if they aren't connected already (with an option to stop showing the prompt). Open to other ideas here.

Can I use dvc config studio.token to check if a user has a Studio token in their config? (if yes I can use it as an environment variable if "live sharing" is enabled)

Yes and yes.

When setting the token into a user's config should I set it as --local, --global or --system? (my guess is --global)

Yes --global sounds good to me.

If users have already set this up I think we should still prompt them to add again as this makes it explicit that we are saving it in their DVC config (rather than expending effort migrating the secret).

Sounds good.

From testing out with the demo project moving from the old API to using exp push blew the time out to share an experiment from 1s to ~90s, after the initial push this dropped to 14s. It would be good to be able to reduce that time in any way possible.

We probably need an option to share with/without the cache, whether that is two separate sharing actions or whether there's some other way (prompt, settings option, etc.).

Looking through the Studio onboarding from VS Code, do we need the "sign in" button? The "get token" button will take them to the same place if not signed in.

We can do this. I was just trying to give a linear/defined process for the user to follow. We can drop the sign-in button. The user may just have to use some brain power.

To make sharing more useful, can we also include an action to share after selecting multiple experiments (it looks like you can only share one at a time now)?

This is correct. I will enable it through the multi-select context menu. When using exp push with multiple experiments is push parallelised? If not I will push individually and update the progress notification each time an experiment is pushed.

When choosing to share, we could prompt them with something like Connect to Studio to see and manage shared experiments if they aren't connected already (with an option to stop showing the prompt). Open to other ideas here.

Sounds reasonable. I'll add buttons to a toast that let the user:

open the setup page with the studio section focused
sets a config option that means they won't be asked again

We probably need an option to share with/without the cache, whether that is two separate sharing actions or whether there's some other way (prompt, settings option, etc.).

After considering the implications a bit closer I think we should stick with the default, to begin with.
I'll update the description. Please LMK if I have missed anything 🙏🏻.

Drop the sign-in button from Studio setup page

IMO it's simpler with fewer buttons, but Studio won't redirect users to the token if they aren't already logged in, so it could also cause confusion. Up to you what to do.

When using exp push with multiple experiments is push parallelised? If not I will push individually and update the progress notification each time an experiment is pushed.

Yes, at least I think there's some optimization when pushing the cache for multiple experiments, so I would suggest doing it that way. The final output should have the info you want (what was pushed to both git and the cache), but it won't be streamed with each individual experiment, and there's currently no machine-readable output format.

We probably need an option to share with/without the cache, whether that is two separate sharing actions or whether there's some other way (prompt, settings option, etc.).

After considering the implications a bit closer I think we should stick with the default, to begin with.

Okay. Would like to hear more of your thoughts on this since I agree it will be slow and maybe not what people want when they are only interested in things like metrics and plots.

Drop the sign-in button from Studio setup page

IMO it's simpler with fewer buttons, but Studio won't redirect users to the token if they aren't already logged in, so it could also cause confusion. Up to you what to do.

Should be fixed by https://github.com/iterative/studio/issues/5715. Maybe we can wait for that.

After considering the implications a bit closer I think we should stick with the default, to begin with.

Okay. Would like to hear more of your thoughts on this since I agree it will be slow and maybe not what people want when they are only interested in things like metrics and plots.

I was thinking about this from a pessimistic/"what could go wrong" with someone's workflow point of view. If they push the cache by default then at least everything will be re-creatable/shared and there shouldn't be any surprises later on. IIUC this helps to solve the "I forgot the push" issue.

If they push the cache by default then at least everything will be re-creatable/shared and there shouldn't be any surprises later on. IIUC this helps to solve the "I forgot the push" issue.

When choosing to share, we could prompt them with something like Connect to Studio to see and manage shared experiments if they aren't connected already (with an option to stop showing the prompt). Open to other ideas here.

If we are going to have a prompt when sharing, we could include a checkbox for whether to share the cache, which could be checked by default.

If we are going to have a prompt when sharing, we could include a checkbox for whether to share the cache, which could be checked by default.

This would be on the settings page, right? We could start with it in the "Studio" section but I think we would want to move it to the new "Remote" section once we get to it. Maybe we can delay until that is added? Up to you.

This would be on the settings page, right?

I was thinking it could be part of this:

Sounds reasonable. I'll add buttons to a toast that let the user:
1. open the setup page with the studio section focused

2. sets a config option that means they won't be asked again

Maybe we can delay until that is added?

Yup, we can start without it.

Another small item to add: When running a notebook or other no-pipeline workflow, the checbox for sharing new experiments live won't do anything. We could show instructions like "For experiments run outside of this extension, set the DVC_STUDIO_TOKEN environment variable to share experiments live."

[Q] Do we want an "unshare" option for experiments? I.e implement dvc exp remove -g origin <name>

[Q] Do we want an "unshare" option for experiments? I.e implement dvc exp remove -g origin <name>

Good question. IMHO it can wait for a follow up later since it's likely not that commonly needed, it's more natural to do from Studio, and it may be complex/hard to describe.

A couple takeaways from the AH discussion:

@dmpetrov Made a point about distinguishing between all the different options we have in the workflow today. For the dvc exp push action, what do you think about explicitly using "push" instead of "share" for the action name? I think it is more explicit and specific, giving more clarity that it's related to git push/dvc push and separate from "live" sharing.
He also pointed out that in the video I shared, dropping into the terminal doesn't look good, and I think it's a blocker for putting out a video on YT. To get something working well enough for a YT video, we at minimum need an action in the extension that does dvc exp push, so WDYT about prioritizing this first? Ideally it will use the token, but that's not a blocker because reloading the page in Studio will be enough to show the pushed experiments.

@dberenbaum I can rename to push. Most of the work is done. I will make a release early next week (probably your Monday). PR is here: https://github.com/iterative/vscode-dvc/pull/3781
The chain underneath will cover

Token management
Drop custom client implementation
Consolidate share actions into one
When a user is not already connected to Studio prompt with a toast to connect on exp push

Another small item to add: When running a notebook or other no-pipeline workflow, the checbox for sharing new experiments live won't do anything. We could show instructions like "For experiments run outside of this extension, set the DVC_STUDIO_TOKEN environment variable to share experiments live."

I've just realised that this isn't possible. Any attempt made by a user to run an experiment through the extension will be redirected to the "Add a stage" command:
https://user-images.githubusercontent.com/37993418/235397816-3baef59a-fab2-458c-9dda-3a1d44adcff4.mov
I don't think I need to take any further action on this one.

Another small item to add: When running a notebook or other no-pipeline workflow, the checbox for sharing new experiments live won't do anything. We could show instructions like "For experiments run outside of this extension, set the DVC_STUDIO_TOKEN environment variable to share experiments live."

I've just realised that this isn't possible. Any attempt made by a user to run an experiment through the extension will be redirected to the "Add a stage" command:

Sorry for the lack of clarity. I meant here:

However, maybe it's just confusing to mention it. I think it's fine to leave it out for now.

Another small item to add: When running a notebook or other no-pipeline workflow, the checbox for sharing new experiments live won't do anything. We could show instructions like "For experiments run outside of this extension, set the DVC_STUDIO_TOKEN environment variable to share experiments live."

I've just realised that this isn't possible. Any attempt made by a user to run an experiment through the extension will be redirected to the "Add a stage" command:

Sorry for the lack of clarity. I meant here:

However, maybe it's just confusing to mention it. I think it's fine to leave it out for now.

In order to get to this screen the user would have to go through the process of generating/adding a Studio token, do you think they would do this without having a pipeline setup? Even then they would have to run their training script through the terminal and not the extension. If I was in that position I wouldn't expect that checking that box would have any effect on running my training script but not sure whether or not that would apply to users.

The remaining two action items:

[ ] Sharing experiments. Can we detect that it's already being shared? Show a link?
[ ] Drop the sign-in button from Studio setup page

are blocked by https://github.com/iterative/studio/issues/5150 & https://github.com/iterative/studio/issues/5715 respectively.
There may be some follow-up on https://github.com/iterative/vscode-dvc/pull/3781#issuecomment-1529864199 / https://github.com/iterative/vscode-dvc/pull/3781#issuecomment-1530804732 but if needed that should be straightforward enough.

Sharing experiments. Can we detect that it's already being shared? Show a link?

@shcheklein WDYT about making this a separate story/issue? Related to your comment here, it feels like there is more to this. How do we show what has been shared between live Studio metrics, Git refs, and DVC remotes? How do we keep it in sync?

Remaining item is related to https://github.com/iterative/studio/pull/5417 & https://github.com/iterative/studio/issues/5150

Sharing experiments. Can we detect that it's already being shared? Show a link?

Generating a link is now possible after https://github.com/iterative/studio/pull/6149. I don't think that we can detect that an experiment has already been shared without introducing the significant overhead of checking the remote. What I do think we can do is run dvc exp push origin <exp-name> --no-cache when a user requests a shareable link.
One idea that I had is to add a "link" icon into the cell row actions like this:

(positioning up for debate)
On-click the user will have a link copied to their clipboard if they are connected to Studio (this could take a little bit of time because we need to push the experiment). If they are not connected then we can prompt them to connect.
WDYT? Is this good enough to get us unblocked?

We could also call exp list origin with a list of revisions at the same time that we call exp show (with the same watcher trigger). This would avoid having to "generate links" but the call seems fairly expensive. I guess we would only enable the link icon for rows that are shareable, the rest would show the icon as disabled.

Raised https://github.com/iterative/studio/issues/6249 in Studio.

Reviewing the whole thing one more. And I feel lost tbh.

@dberenbaum now save_dvc_exp=True is ignored in VS Code since we use dvc exp run.  Even if "share new experiments" enabled it doesn't send the final result. What was the reason to ignore it? What is the expected way of sending them now in VS Code?
what does the checkbox mean now?

Unblocking this. Let's go back and review one more time this.

@shcheklein behaviour seems related to https://github.com/iterative/dvc/issues/9349. I have seen this mentioned elsewhere but struggling to find the issue.

Not sure I follow your comment overall @shcheklein. Are you lost about the whole experience? Is your confusion only about pushing the final result to the git and dvc remotes, or is there something else?

Are you lost about the whole experience?

Yep, I feel like that. I'm not sure I understand why save_dvc_exp is not working anymore. I'm also not sure I understand what does checkbox do now. Also, yes, what is the expected workflow in VS Code to share the experiments at the end.

In what way is it not working? What were you expecting it to do, and what is happening instead?

I think it was pushing the experiment at the end, no? (so that I can see and create a PR in Studio). Now I see an incomplete experiment in Studio.

If so, it means you will automatically get live updates in studio for any experiments you run.

those that don't have dvclive enabled at all? do I need to use dvc exp run for that? or even from a script that updates the table in the workspace? how do we name it then?

Currently, the workflow is to use the Push action to do this.

okay, I see. So, what is the recommended way to use it - do we want to use and recommend save_dvc_exp in VS Code?

Maybe you are thinking of DVC_EXP_AUTO_PUSH? This was previously used for checkpoints but we discussed bringing it back for this in https://github.com/iterative/dvc/issues/9295.
save_dvc_exp=True does not push anything. It will only make sure each dvclive run saves an experiment locally at the tend (if vs code is running the experiment, it doesn't do anything since it uses dvc exp run to save the experiment). See https://dvc.org/doc/dvclive/live#parameters.
My take - a good and easy step would be to recommend the push action at the end of the experiment in both CLI and and VS Code. Doing it automatically has some hurdles: it will be slow (making the experiment hang at the end) and it will break if there's anything wrong with the git or dvc remote connections (incorrect setup, expired credentials, etc.). Both of these may make the experiment workflow feel broken, so I'd rather suggest users do it themselves.

Okay, let me step back, and think. What really bothers me (no solutions yet, sorry,  just to reflect on why it all doesn't fit into my head when I'm trying that):

I have to know about push overall. It's not common in the other systems. It is also amplified by the combination of: seeing an experiment in Studio already, on top of that having the checkbox and flag, and yes lack of any extra notifications.
combinatorial complexity - dvclive is set or not, save exp is set or not, checkbox is set or not, etc - too many possibilities. I was not able to predict the behavior. I'm not able to start with a default that fits.
warning of exp_save being ignored mislead me - should I drop it from the code since it's ignored? It's ignored so I lack some functionality / need to replace it with something?

Some practical thoughts:

it seems save_exp should become a default. And only if ppl want to disable it they go for it. That would simplify the happy path, docs, etc. And warning can be triggered only when False is set explicitly and it's being ignored (you are getting a different behavior)
push - I have no idea how to improve this besides some messages. It's unfortunately inherently confusing thing in the whole architecture - two (or three) types of experiments, etc. We should be clear at least about their state in UI then. Don't know how to explain this better. Any ideas?
checkbox - we have to put a message around it if this is about VS Code itself pushing any experiments w/o any help from DVClive

Any other ideas on how to simplify this further?

Discussed with @shcheklein. I'm not going to summarize everything here, but the most important action item we agreed on was to think of better ways to make the push action feel smoother, easier, more automatic, etc. In particular, we discussed if pushing in the background can make it feel less intrusive even if it's generally a slow operation. For example, can we check what experiments have not yet been pushed and push them automatically at some regular interval?

Related to this:
https://discord.com/channels/485586884165107732/1129143778805035008/1129344919195111454

I noticed that dvc exp run warned me that the save_dvc_exp=True setting would be ignored.

When I run dvc exp run (via the VS Code extension), there is no data/train/dvclive/dvc.yaml being generated, though, at least not after the validation step and model checkpoints. This means that the VS Code extension doesn't show me any plots to monitor training (for which so far I still use TensorBoard as it's more reliable).

When I run dvc exp run (via the VS Code extension), there is no data/train/dvclive/dvc.yaml being generated, though, at least not after the validation step and model checkpoints. This means that the VS Code extension doesn't show me any plots to monitor training (for which so far I still use TensorBoard as it's more reliable).

That sounds like a bug

@shcheklein to create a separate story / ticket for the async push and exp status in the experiments table.

Overall, action items are:

Make dvc_exp_save default. It's pending a tactical decision on when it should be done on the dvclive
Removing warning that "dvc_exp_save is ignored". Depends tactically on the previous item cc @dberenbaum
Improve UX /copy around checkbox to make it more explicit
Show experiments status in the table (pushed vs not). Can in the upcoming column "Studio link".
Push experiments and their data async to help people sharing the experiments

Show experiments status in the table (pushed vs not). Can in the upcoming column "Studio link".

Discussed with @pmrowla who suggested that it might be faster to call git ls-remote origin 'refs/exps/*' than to use dvc exp list.

Proposed design:
https://github.com/iterative/vscode-dvc/assets/37993418/c1c35cee-48ac-48a3-89c3-20261f6f4fe3
Pushed status can fill the gap taken by the running spinner. When the experiment has not been pushed we will show an upload icon in the style of the plot icon checkbox. If the experiment is uploaded we will show a cloud icon with a tooltip that let's the user know the experiment has been pushed.

Thanks @mattseddon! I like it. A few minor questions:
Can we go back to a spinner or something similar while the push is happening?
Can we coordinate on the iconography with https://github.com/iterative/studio/issues/6870? I think the cloud is a good idea since dvc exp push by default pushes to both the git and dvc remotes, but would be good to make sure we have some consistency.

Note: We are going to struggle to keep what we display in the table synced with the remote data. E.g when (anyone) runs dvc exp remove -g origin <exp-name> we have no event/info to trigger a table update.

Will it sync eventually, like when someone pushes another experiment using the extension?

Thanks @mattseddon for the quick iteration! Should we already introduce a separate column for these states? Where will we put a link to Studio for example?

Can we go back to a spinner or something similar while the push is happening?

Yes, we can do that.

Can we coordinate on the iconography with https://github.com/iterative/studio/issues/6870? I think the cloud is a good idea since dvc exp push by default pushes to both the git and dvc remotes, but would be good to make sure we have some consistency.

Yes, I will keep an eye on that. For native icons choices are limited to these ones. Maybe in Studio, we could show a cloud with a slash through it to signify that it is not uploaded (pushed) yet.

Will it sync eventually, like when someone pushes another experiment using the extension?

Currently, it will sync as soon as there is a change in the workspace. This falls down when dvc exp remove -g origin <exp-name> is run from the terminal (no update is shown in the table).

Thanks @mattseddon for the quick iteration! Should we already introduce a separate column for these states? Where will we put a link to Studio for example?

I considered this and decided that because we are always fighting for space this would be the best option. As there is nothing to show for commits we would be wasting space there as well.
The Studio link can replace the cloud icon for completed experiments (under the correct circumstances). For running experiments get Studio link can appear in the context menu. WDYT?

The Studio link can replace the cloud icon for completed experiments (under the correct circumstances). For running experiments get Studio link can appear in the context menu. WDYT?

Hmm, I don't see how that could happen to be honest.
I would as usual err on the side of being super obvious and look decent vs optimizing things to look good. E.g. if it means three columns with distinct obvious names - I would even go for that. At least initially.

For running experiments get Studio link can appear in the context menu. WDYT?

My take - that would be confusing - when fields change they semantics.

As there is nothing to show for commits we would be wasting space there as well.

They also could show Studio link, GH link, their status (we could check in background data eventually).

Hmm, I don't see how that could happen to be honest.

Link icon:

My take - that's too crowded, also we miss making it explicit (e.g. Studio column name would make the purpose clear).

@dberenbaum @shcheklein is this the correct view/state that we want a shareable link to point to:

I don't think we need it to be selected (checkbox). I think it's better to open plots in this case tbh (since we don't have any other way to highlight the row when it open on the FE, or do we @iterative/studio-frontend ?)
Checkbox enables these actions at the top? (and hides the Plots button, etc). May be it's even fine to keep checkbox selected, but can we then show more actions?
some ideas, Matt, I think it's totally fine as a first iteration! thanks 🙏

I think it's better to open plots in this case tbh

👍🏻
We've recently split the selected elements from active ones. Selected elements correspond to the checkboxes, and activated ones open the plots. Both can be persisted in the URL.

Checkbox enables these actions at the top?

Yes, they do.

May be it's even fine to keep checkbox selected, but can we then show more actions?

Not really, there is not enough real estate in the row. We'll have to squash them aggressively.
If that is acceptable, I'd prefer sticking to the activated rows.

A couple of questions from me:

Should live experiments have plots that are visible in the Studio UI?
Do all views/projects have plots? If not do we know the percentage that doesn't have plots?

Should live experiments have plots that are visible in the Studio UI?

Yes, in most cases.

Do all views/projects have plots? If not do we know the percentage that don't have plots?

No, some projects don't and it's a good point. Means that it's better to show the table. Also show the Plots button (so, no checkbox?).

If that is acceptable, I'd prefer sticking to the activated rows.

what are the activated rows?

what are the activated rows?

Activated row (plot button)

Selected row (checkbox)

Activated AND selected row (plot button AND checkbox)

Okay, I guess let's do checkbox and if there are plots we can do a leap of faith and show them I guess. It's a bit suboptimal tbh. Checkbox are not meant for this use case (they are about making actions on an experiment). We have a way to highlight an experiment (for a second at the moment). I wonder if can / should utilize that instead?

Okay, I guess let's do checkbox and if there are plots we can do a leap of faith and show them I guess. It's a bit suboptimal tbh. Checkbox are not meant for this use case (they are about making actions on an experiment). We have a way to highlight an experiment (for a second at the moment). I wonder if can / should utilize that instead?

Coming back to the original suggestion question quickly:

The reason for using the checkbox here was to apply the show only selected commits filter:

This means we can share a URL of the form:
https://studio.iterative.ai/user/{user_id}/projects/{view_id}?showOnlySelected=1&experimentReferences={exp_ref}&activeExperimentReferences={exp_ref}%3Aprimary
Whoever receives the link will be able to:

Compare the experiment with the baseline.
Easily view plots if they exist.

I suggested this view because even though it is not optimal I felt that it provides value whilst also eliminating edge cases (e.g. no plots).
I should have explained this, to begin with.

Getting closer to finishing this now with https://github.com/iterative/studio/pull/7332 ready for review and a rough prototype done on the extension side.
I have encountered an issue with the proposed links getting bounced if no plots are available for a record. For this reason, I'm going to resort to the following links:
${this.baseUrl}?showOnlySelected=1&experimentReferences=${sha} for completed & pushed experiments
${this.baseUrl}?showOnlySelected=1&liveExperiments=${baselineSha}%3A${name} for live experiments
Copy Studio Link will be available for as a context menu option for all experiments that exist on the user's instance of Studio.
LMK if you have questions regarding any of the above.
🙏🏻

LMK if you have questions regarding any of the above.

I have encountered an issue with the proposed links getting bounced if no plots are available for a record. For this reason, I'm going to resort to the following links:

Thanks for the writeup @mattseddon! Does this mean a link like https://studio.iterative.ai/user/jellebouwman/projects/demo-bank-customer-churn-esgpd8e876?showOnlySelected=1&panels=plots%2C&commits=67521d6d2acc16218e4cf6378b73732b14754140&activeCommits=67521d6d2acc16218e4cf6378b73732b14754140%3Aprimary (note activeCommits) breaks the URL for you?
IMO - we should try to let you trigger the plots for a rev and should fail gracefully (keep the rest of the ProjectURL working) if the rev doesn't have plots. Let me know if that's the case right now, and I can try to work on a fix for you.

Thanks for the writeup @mattseddon! Does this mean a link like https://studio.iterative.ai/user/jellebouwman/projects/demo-bank-customer-churn-esgpd8e876?showOnlySelected=1&panels=plots%2C&commits=67521d6d2acc16218e4cf6378b73732b14754140&activeCommits=67521d6d2acc16218e4cf6378b73732b14754140%3Aprimary (note activeCommits) breaks the URL for you?

If there are no plots for a live experiment then I've seen its link get redirected to the main view page. Here are a couple of examples:

https://studio.iterative.ai/user/mattseddon/projects/vscode-dvc-demo-ynm6t3jxdx?showOnlySelected=1&liveExperiments=37894efde22e96f184ba2531d4a436b74552b731%3Arummy-genu&activeLiveExperiments=37894efde22e96f184ba2531d4a436b74552b731%3Arummy-genu%3Aprimary (works)
https://studio.iterative.ai/user/mattseddon/projects/vscode-dvc-demo-ynm6t3jxdx?showOnlySelected=1&liveExperiments=37894efde22e96f184ba2531d4a436b74552b731%3Apagan-eric&activeLiveExperiments=37894efde22e96f184ba2531d4a436b74552b731%3Apagan-eric%3Aprimary (redirected to https://studio.iterative.ai/user/mattseddon/projects/vscode-dvc-demo-ynm6t3jxdx)

Seems safer to provide a link that doesn't get redirected.

Final demo for this one.
Shareable links are provided for all experiments found on Studio (live or pushed) via the experiments table context menu:
https://github.com/iterative/vscode-dvc/assets/37993418/25f0bc17-06e9-4b00-9af5-90a999e5403d

Thanks, Matt. Looks great.


rkt stop/rm: a pod must be closed after PodFromUUIDString()

ok to test

The test failure was the flake tracked in #3477. I tried to kick off a rebuild.
This change LGTM.

Jenkins is a bit busted here, but this lgtm


[feature request] Use version of pnpm specified in package.json

There's two way to specify pnpm version in package.json:
{
  "packageManager"<EMAIL_ADDRESS>  "engines": {
    "pnpm": ">=6"
  },
}

It should prefer packageManager field because it is more precise (this field does not support semver).

TBH, I would be happy to deprecate the engines.pnpm field but I think it is too strict to only allow exact versions in the packageManager field.

I think engines.pnpm is okay since yarn also supports it IIRC (engines.yarn?)


wsl-terminal terminating right after logging in

When logging in as a user (in arch linux wsl), wsl-terminal immediately closes itself.

can you please try it on the latest wsl-terminal? If this is reproducible please provide the following:

your wsl-terminal configuration file?
your .profile or .bashrc or .zshrc - depending on the shall you're using.

and afterwards I will have a look and try to support :)

closing as no reply was given :)


Re-define Post_Metabox using conventional  WordPress code

Problem

The Post_Metabox is currently defined using the Queulat package.
https://github.com/creativecommons/creativecommons-base/blob/39e72523afed695b4934f5cb131b14182e684345/inc/metaboxes.php#L8
Since we have established a consensus to deprecate the Queulat package, we need to re-create the Post_Metabox using conventional WordPress code.
Task

[ ] Determine what fields are needed for the Post_Metabox
[ ] Determine how the metadata should be processed and stored
[ ] Re-create the Post_Metabox using conventional WordPress code
[ ] determine whether a more class-name meaningful name would be useful (if applicable)

Hi @brylie ! I'd like to work on this issue?


[sozo] World abi isnt included in manifest

Describe the bug
World abi isnt included in the generate manifest <CHAIN_ID>.json  neither in abis
Its must be included

Mentioned in #1664 and will be addressed in #1734. 👍


Event Store Feature Schema

The event store feature schema today is hard-coded as a single SQL file, but with all the v4 changes, we're gonna be introducing a lot of variability for the first time. Let's move the tables and function to Table and Function objects so they can support a migration model.

This wasn't true, not doing anything here.


Laggy video

on Lenovo ideapad 3 ( windows 10 ) video is laggy so much, like you put speed to 0.3 or 0.2.

User no feedback, closed.


NEW MOUNT + SERDE

Update gmt_dos-clients_mount crate to use the mount models with env var
Derive serde for servos components
GmtServoMechanism can now be initialize like so
    let gmt_servos =
        Sys::<GmtServoMechanisms<80, 1>>::from_data_repo_or_else("servos.bin", || {
            GmtServoMechanisms::<80, 1>::new(
                sim_sampling_frequency as f64,
                FEM::from_env().unwrap(),
            )
            .asms_servo(AsmsServo::new().facesheet(Default::default()))
        })?;

where the object is read from file 1st  and if it fails it is build and save for latter use
This is using the Filing interface: cargo doc --all-features -p gmt_dos-actors-clients_interface --no-deps --open

The version of gmt_dos-clients_m1-ctrl (dos-actors/clients/m1-ctrl/Cargo.toml) is 4.0.0. In contrast, the version available in Crates.io (https://crates.io/crates/gmt_dos-clients_m1-ctrl) is 3.1.1. That seems to prevent running the servo examples with the new features.


[feature]: Support for skhd modes

Proposal
Add support for parsing skhd modes, and add an additional optional mode-flag when using the CLI --sheet skhd flag, for example --sheet skhd --mode focus When the parameter is set, only show shortcuts for that mode.
I just found KeyClu when looking for a way to display my own skhd cheat sheets, markdown files I've generated by parsing skhdrc myself. But when I saw that KeyClu supported skhd shortcuts natively that was an even better solution. But I use modes heavily, so unfortunately the current KeyClu-skhd integration doesn't work for me.
Alternatives
No response

Edit: Removed reference to nonexistent CLI parameter --skhd.

Can you share your skhd config so we can see how your utilizing modes? This might help Anze see what can be done. I use skhd and asked Anze to implement the skhd sheet, but I haven't got used to modes yet, so I don't use it. Funny I've been using nvim for about a year now and still have to get used to modes lol.

Hey daniels,
Thank you for your suggestion! Supporting skhd modes is a great idea, and I can see how that would improve usability.
To make sure fully capture your needs, and like gldtn said, could you share a sample of your skhdrc configuration? This will help to understand how to approach adding mode-based support to the CLI.

Hi, and thanks for considering this idea!
Here follows a sample of my skhdrc.
It includes mode definitions (which do not have shortcuts in themselves, but where the comment might be used as some sort of heading for the mode shortcuts. (skhd_mode_change is a script I trigger with the mode name as parameter when the out to that gives me some interface clues as to what mode is active - here I could maybe activate KeyClue to show the sheet cheat - given that it doesn't steel focus from the window I'm operating on ...)
Then there are shortcuts for switching from default into modes and back again, and for switching between modes.
And finally shortcuts in the different modes, where some are defined simultaneously for two modes. I've chosen to show examples where the exact same shortcut is used for different things in different modes, but this could of course vary. The examples all control yabai, which is my main use for both skhdrc in general and especially the modes,
### Mode definitions

# Default - global shortcuts
:: default  : skhd_mode_change default
# Focus - navigate displays, spaces and windows
:: focus  @ : skhd_mode_change focus
# Grid - control windows in float mode
:: grid   @ : skhd_mode_change grid
# Swap - swap windows placements in a space
:: swap   @ : skhd_mode_change swap
# Warp - move windows - focus follows movement
:: warp   @ : skhd_mode_change warp
# Warp no-follow - move windows.
:: warpnf @ : skhd_mode_change warpnf
# Resize - resize windows
:: resize @ : skhd_mode_change resize

### Toggle modes on-off

# Toggle focus mode
default                                 < hyper - space     ; focus
# Toggle default mode
focus, grid, swap, warp, warpnf, resize < hyper - space     ; default
# Leave mode
focus, grid, swap, warp, warpnf, resize < escape            ; default

### Select modes

# Select focus mode
focus, grid, swap, warp, warpnf, resize < f                 ; focus
# Select grid mode
focus, grid, swap, warp, warpnf, resize < g                 ; grid
# Select swap mode
focus, grid, swap, warp, warpnf, resize < s                 ; swap
# Select resize mode
focus, grid, swap, warp, warpnf, resize < r                 ; resize
# Select warp mode
focus, grid, swap, warp, warpnf, resize < w                 ; warp
# Select warpnf mode
focus, grid, swap, warp, warpnf, resize < shift - w         ; warpnf

### Focus mode examples

# Focus left
focus           < h                 : yabai -m window --focus west
# Focus down
focus           < j                 : yabai -m window --focus south
# Focus up
focus           < k                 : yabai -m window --focus north
# Focus right
focus           < l                 : yabai -m window --focus east

### Grid mode examples

# Place left half
grid            < h                 : yabai -m window --grid 1:2:0:0:1:1
# Place bottom half
grid            < j                 : yabai -m window --grid 2:1:0:1:1:1
# Place top half
grid            < k                 : yabai -m window --grid 2:1:0:0:1:1
# Place right half
grid            < l                 : yabai -m window --grid 1:2:1:0:1:1

### Swap mode example

# Swap left
swap            < h                 : yabai -m window --swap west
# Swap down
swap            < j                 : yabai -m window --swap south
# Swap up
swap            < k                 : yabai -m window --swap north
# Swap right
swap            < l                 : yabai -m window --swap east

### Warp examples, duplicated in warpnf (no-follow) mode

# Warp left
warp, warpnf    < h                 : yabai -m window --warp west
# Warp down
warp, warpnf    < j                 : yabai -m window --warp south
# Warp up
warp, warpnf    < k                 : yabai -m window --warp north
# Warp right
warp, warpnf    < l                 : yabai -m window --warp east

I've borrowed from and expanded on some other users configs, not sure if maybe these parts are taken more or less verbatim from one of them:

https://gist.github.com/alyssais/3845e4e9d3cb6b7f080b271270685741
https://gist.github.com/pkazmier/213d9dce6b1ea313eaf0a17b017c2b08
https://gist.github.com/ryan-mooore/016b0d10e3dcc138e429570d0752fbad0

Hey daniels,
Thank you for sharing the sample config! I really appreciate it. I'll take a closer look and explore a solution.


New graph api prototype

Where we use PyTorch API: https://github.com/pytorch/pytorch/blob/main/torch/onnx/_internal/fx/fx_onnx_interpreter.py
The old API: https://github.com/microsoft/onnxscript/blob/main/onnxscript/function_libs/torch_lib/graph_building.py
Related issue and discussion: https://github.com/microsoft/onnx-converters-private/issues/158
The PR uses three component to build the graph: Tensor, Node, Graph.
Tensor:

Add shape and dtype
Add onnx_type
Add to_onnx_value_info()
TODO: Should we make onnx_type an object/class?

Node:

inputs and outputs
operators
attributes
onnx_function(optional)
to_node_proto()

Graph:

inputs and outputs
initializers
nodes
function_store
to_onnx_model()
TODO: load_from_onnx()

TODO:

multiple outputs test
subgraph test
opset_imports
doc_string
Should we keep evaluator? We could use add_node to directly insert node into graph
graph sorting

I do have a very high-level question: what is the goal/intention of this IR? It would be good to have a list of use-cases and scenarios it is intended to support.

I do have a very high-level question: what is the goal/intention of this IR? It would be good to have a list of use-cases and scenarios it is intended to support.

Just answering my question based on my understanding: looks like this is motivated by the needs of the trace-only onnxscript function construction, is that correct? (So, it's a replacement for what's in there for that purpose?

@shubhambhokare1 talked with me on evolving the PR. We think it would be possible to use a feature flag to control which implementation to use, and hide the new logic under the same apis. @shubhambhokare1 will look into doing this and enabling the torchlib tests. Thanks!


Picker not close without select year & month

Hello sir , i am using react-month-picker-input (v 1.1.2) when i select year & month then picker was close using closeOnSelect property but i want to close it without select any year & month how can i do this.
please help me to solve this problem. you can check the link for better
understanding ( https://tinytake.s3.amazonaws.com/pulse/dhp-gmail/attachments/8207704/TinyTake04-07-2018-11-49-11.mp4 )
Thank in advance

@dipeshmali this month picker can be closed by clicking anywhere outside input or calendar, just like other datepicker. Did I answer your question?

No sir you haven't gave answer for this question and i would be very thank full if you could give me solution for this problem.Please help out from this issue.

@slavakisel Actually month picker is not going to close when we click outside input or calendar. May be we need to attach any event or method with it?

@RanaAshish I don't think so. It is being closed without issues both on the examples page and in the other projects where I am using it.


FR: Display whole tree in Tree view

I would like to see the entire tree in the tree view, not just the "down" entries.  Ideally, I would be able to choose how many levels of parents to show.  The current note should be highlighted in bold.

(Could probably merge w #556 )

1 for current note in bold. And let us see this notes “up”, but sorted from up to down, Then it would behave like most file systems

> [parent]
   > [this note]
       > [child]
       > [child]


tf.image.crop_and_resize crash (abort) when given num_boxes=0

Click to expand!
Issue Type
Bug
Source
binary
Tensorflow Version
2.11.0-dev20220916
Custom Code
No
OS Platform and Distribution
Ubuntu 18.04.4 LTS (x86_64)
Mobile device
No response
Python version
3.7.6
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
N/A
GPU model and memory
No response
Current Behaviour?
tf.image.crop_and_resize crash (abort) when given num_boxes=0

Standalone code to reproduce the issue
import numpy as np
import tensorflow as tf
tf.image.crop_and_resize(crop_size=[1,1], box_indices=np.ones((0,1)), boxes=np.ones((0,4)), image=np.ones((2,2,2,2)))

Relevant log output
2022-09-19 20:55:05.906144: F tensorflow/core/framework/tensor_shape.cc:45] Check failed: NDIMS == dims() (1 vs. 2)Asking for tensor of 1 dimensions from a tensor of 2 dimensions
Aborted (core dumped)

@DNXie
I tried to reproduce the issue on Colab using TF v2.10 but Colab crashes. Could you please find the gist here and confirm the issue?
Thank you!

Created a PR #57783 for the fix.

@DNXie
This issue is closed when the PR is merged.
Thank you!


Request Komikges

Source name
Komikges
Source link
www.Komikges.my.id
Source language
Indonesian (ID)
Other details
Nsfw = no
Acknowledgements

[X] I have checked that the extension does not already exist by searching the GitHub repository and verified it does not appear in the code base.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[ ] I have admitted that I am a clown by having checked this box, as I have not read these acknowledgements.
[X] I will fill out all of the requested information in this form.

ngapain req web mati

ngapain req web mati

Terserah org ngab, daripada req web mirror. Lagipula tujuan w req yura, berhubung templatenya webnya sama ya sekalian ae

kasi detail templatenya sama kek yang mana, biar devnya tau


west.yml: ld: soc: move BLE data to RAM DLM in deep sleep mode

Moved BLE data to RAM DLM in deep sleep mode

The following west manifest projects have been modified in this Pull Request:

Name
Old Revision
New Revision
Diff

hal_telink
https://github.com/telink-semi/hal_telink/commit/6c4c9a1e2eab97017eead9e45b2f412417fc4959
https://github.com/telink-semi/hal_telink/pull/64
telink-semi/hal_telink#64/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

hal_telink: af266a4f294283493e5ab45381bffcb490d23196


angularfire2.com: Urgent DNS Migration Required

The angularfire2.com site is non-operational and is displaying an "Urgent DNS Migration Required" message:

Why am I seeing this?
As communicated, Firebase Hosting recently changed its DNS for sites connecting directly through A records. The DNS for this site is currently pointed to deprecated IP addresses. Please contact the site administrator immediately to inform them that action needs to be taken.

Apparently even though I have full permissions for the site, @jeffbcross is still the Registrant. His email is invalid now and has caused the site to go down. However, the site is seriously out of date and should not be used. We'll get this fixed but I don't recommend using it until we get our site plan in place.


Create a new unified storage object for Pods

This pull requests puts in place the basic support to collapse the RESTStorage and Registry objects into a single implementation (backed by generic/etcd).  Demonstrates that extraction on Pods.  The new terminology is "Storage" or "RESTStorage" (adapters are in place for other code that needs typed responses).  The signature of the new store is extremely close to our client signature.
Follow ups will enable setting status on pods ("dumb storage") via a new resource endpoint.
All of the pod test cases (pkg/registry/pod/rest_test.go, pkg/registry/etcd/etcd_test.go) were merged into pkg/registry/pod/etcd/etcd_test.go.  A subsequent refactoring should extract common tests into generic registry and pkg/api/rest/resttest.
The first four commits are part of another pull.

To clarify, we post a Kind and not a Kind.Status to the new end-point?

Yes, that's what it will support

On Feb 9, 2015, at 10:37 AM, Derek Carr<EMAIL_ADDRESS>wrote:
To clarify, we post a Kind and not a Kind.Status to the new end-point?
—
Reply to this email directly or view it on GitHub.

Extracted the common behavior into #4263 as a general cleanup of apiserver to allow sub resource collections to exist

This is now ready for review

@bgrant0607 reassign as necessary - wasn't sure who else has been advocating for this recently.

I've extracted the first four commits into #4419

Please rebase to make this easier to review.

Aww, you're cute lawyerbot
----- Original Message -----

Thanks for your pull request.
It looks like this may be your first contribution to a Google open source
project, in which case you'll need to sign a Contributor License Agreement
(CLA) at https://cla.developers.google.com/.
If you've already signed a CLA, it's possible we don't have your GitHub
username or you're using a different email address.  Check the information
on your CLA or see this help
article on setting the email on your git
commits.
Once you've done that, please reply here to let us know.  If you signed the
CLA as a corporation, please let us know the company's name.

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/4248#issuecomment-74340671

It's rebased.

@lavalamp on the CLA hook issue. Lawyerbot is still teething.
Thanks, @smarterclayton. Will look.

Regarding lawyerbot, red hatters are blocked from google plus by apps domain, so we can't log in to google developers console to confirm CLA (which should be there).

On Feb 13, 2015, at 5:54 PM, Brian Grant<EMAIL_ADDRESS>wrote:
@lavalamp on the CLA hook issue. Lawyerbot is still teething.
Thanks, @smarterclayton. Will look.
—
Reply to this email directly or view it on GitHub.

I've sent out a question about the lawyerbot. Will turn it off if it's just gonna spam everyone from red hat.

LGTM overall. Any changes could be done in follow-up PRs, if you prefer.

I'll do this round, add more comments, then let you know on Monday.

On Feb 13, 2015, at 6:55 PM, Brian Grant<EMAIL_ADDRESS>wrote:
LGTM overall. Any changes could be done in follow-up PRs, if you prefer.
—
Reply to this email directly or view it on GitHub.

SGTM. FYI: Monday is a holiday.

Almost all comments addressed, added TODOs to various places that still need cleanup.  I think this is ready for merge and we can iterate more in subsequent cleanups.
----- Original Message -----

I'll do this round, add more comments, then let you know on Monday.

On Feb 13, 2015, at 6:55 PM, Brian Grant<EMAIL_ADDRESS>wrote:
LGTM overall. Any changes could be done in follow-up PRs, if you prefer.
—
Reply to this email directly or view it on GitHub.

LGTM


MNT: Update pinned versions.

Hi! This is the friendly conda-forge-admin automated user.
I've bumped some of the conda-forge pinned versions, and noticed that it impacts this feedstock.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Thanks!

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi all @conda-forge/core, any idea why curl would be missing from appveyor builds?

Merged, but curl is still missing on appveyor. Will keep an eye on conda-forge/conda-smithy#487 and appveyor/ci#1426


Transaction serialization.

This implements ZcashSerialize, ZcashDeserialize for the Transaction enum, and also correct any data modeling errors introduced in #105 along the way.
The chunks of work here are basically:

Copy a single (Sapling) transaction test vector from the librustzcash source.
Fill in missing ZcashSerialize, ZcashDeserialize impls for transaction components.
Change JoinSplitData to store JoinSplits as (first: JoinSplit, rest: Vec<JoinSplit>) so constructing a JoinSplitData with no JoinSplits is impossible (data modeling correction).
Change ShieldedData similarly, keeping first: Either<SpendDescription, OutputDescription> (data modeling correction).
Hardcode the number of inputs and outputs for JoinSplits as 2, as in the spec (data modeling correction).
Actually implement transaction serialization.

Closes #124.
Follow-on work that needs to be done but isn't included in this PR:

Serialization round-trip property-testing (part of #150).
At least one hardcoded serialization testcase for each transaction version (related to #28 ?).
Proper Debug impls for all Transaction components (probably should be included in #123).
Possible reworking of the ZcashSerialize trait to have an associated error type (no issue yet, I thought of this while working on it).

This is ready for review; I'm happy to include some or all of the "further work" items in this PR or leave them for later ones.


Add PartialEq to StdError

In cosmwasm-plus, I find myself writing similar code in all my tests for error cases on contract calls:
        match err {
            ContractError::Unauthorized {} => {}
            e => panic!("Unexpected error: {}", e),
        }

I realized this should be much simpler and tried:
assert_eq!(ContractError::Unauthorized {}, err);

The compiler then requested I implement PartialEq for ContractError, which I did. But that failed as we embed StdError, which does not implement PartialEq.
Now that we no longer store backtraces inside the errors, such compares should be possible, and makes testing errors easier (which encourages testing more error cases)

Hmmm... I just took a look at StdError and saw:
#[derive(Error, Debug)]
pub enum StdError {
    /// Whenever there is no specific error type available
    #[error("Generic error: {msg}")]
    GenericErr {
        msg: String,
        #[cfg(feature = "backtraces")]
        backtrace: Backtrace,
    },

I guess we do still use backtraces (I stopped using them on 0.11 or so), so standard PartialEq would be impossible to derive (but could be hand coded).
I found derivatives crate with an enhanced version of PartialEq so we can just ignore the backtraces when deriving PartialEq.

Yeah, backtraces are optional and nightly only. Last time I asked you wanted to keep them. But it is simple to implement PartialEq manually, ignoring backtraces.

I did want to keep them as I had used them to track down some nasty bugs a while ago. I thought they were disabled when we left snafu and haven't tried them since then. Nice to see them there, and I just made an issue to expose them better in contract tests: https://github.com/CosmWasm/cosmwasm-plus/issues/178
Happy for a manual implementation for StdError if you don't like the derive fanciness from my #662 (contract changes should be the same though)

Done in #662 and released as part of 0.12.2


Consider move off isparta to latest istanbul

isparta isn't maintained, and it seems that the latest istanbuls might have better support for ES2015+.

FWIW I successfully made the switch to gulp-babel-istanbul on one project after having an isparta issue.

here's a specific example. Pretty easy switch. https://github.com/RoundingWellOS/marionette.toolkit/commit/55993bd656f3921571e198396ac8db739e7d24b3

Nice!

Note that this swaps isparta for https://github.com/jmcriffey/babel-istanbul, another library that is a "temporary fix." Eventually we will want to use just vanilla istanbul.

My approach here will be to test babel-istanbul against istanbul beta on some project of mine. If istanbul beta is up to snuff, I'll use that. Otherwise, I'll switch to babel-istanbul.

Ah jeez, yet another option: https://github.com/dtinth/babel-plugin-coverage
Coverage + transpiled code is in a rough place right now. That last one looks like it might be promising, but I'll have to investigate further...

more: https://github.com/istanbuljs/istanbul-lib-instrument/issues/4

Looks like the babel-plugin-__coverage__ tool is working well for people. I think that'll be what I transition to.

There's also https://github.com/istanbuljs/babel-plugin-istanbul now (based off of ^)

Ha I was literally just posting that @hzoo! Thanks for the link ;)

Ah I might have some answers for that - https://github.com/babel/babel/releases/tag/v6.11.3 Ref https://github.com/istanbuljs/babel-plugin-istanbul/issues/5 - logan made some generator improvements but yeah I would check to confirm

Alright – after some investigating I'm confident that switching to babel-plugin-istanbul is a good move forward.

@jmeas @hzoo let me know if you run into any issues, happy to land patches 👍
@hzoo also, reminds me, I owe you adding babel-plugin-istanbul to babel's own tests!

@bcoe We have it for babylon at least now https://github.com/babel/babylon/blob/master/.babelrc#L6


amd64 for linux missing on the release

Some how I am not able to see the release "packer-plugin-goss_v3.2.9_x5.0_linux_amd64.zip" on the list.

Yeah linux_amd64 is excluded in goreleaser, as recommended in hashicorps scaffolding template (https://github.com/hashicorp/packer-plugin-scaffolding/blob/bf869f2cc3ebfd3b520ddad5fb63f66144810fe0/.goreleaser.yml#L53). I cant really tell you how but it should nevertheless work for linux_amd64 systems as I have used it successfully locally and during CI.. did u give it a try?

until #86 is merged u should be able to use v3.2.8


Fix build & Initial release

Before this PR
Build is broken
After this PR
==COMMIT_MSG==
Initial release
==COMMIT_MSG==
Possible downsides?

Released 0.1.0


All of the pages need an “edit on github” button, similar to the one here: http://localhost:4000/docs/changelog/

Fixed by #159