How to avoid first ms chopped off the sound

Voice recording chops a few milliseconds at the beginning on the sound.
"Active something" is played back as "ctive something" in debug mode, obviously Bing doesn't understand.
utils/timeout.sh 10 rec -V1 -q -r 16000 -c 1 -b 16 -e signed-integer --endian little /tmp/jarvis-record.wav gain 0 silence 1 0.1 3 1 0.5 3 trim 0 5

I did not had time to explore it for now but I have the same issue on the Respeaker, I was thinking it was the platform but if you have the same on macos...

This is related to sow audio levels, which is not always perfect even if you did the auto-adjust level well.
@ybizeul just for the sake of experimentation, please change recorder to Snowboy in:
Menu > Settings > Audio > Recorder > Snowboy
And let me know if you face the same issue.

@alexylem: Is there any other workaround than using Snowboy ?
We cannot on the Respeaker

@ybizeul this is because of sox audio levels.
You min noice perc to start recording seems to be 3. Try to put it at 1% or less in Settings > Audio

I think I found a way to improve this, testing now...

I will do additional tests tonight :

Set noise level to 1%
Switch recorder to Snowboy
Whatever @alexylem comes up with :-)

I'm actually surprised, I thought the recorder what smart enough to maintain a buffer and include a few milliseconds before the level crosses the threshold to account for that.

@ybizeul
It's my formula to calculate thresholds that is not correct, keep sox and try even:

min noice perc to start to 0.1%

I'm adding a new parameter to keep the silence at the beginning, will definitely help bing.
Give me an hour to finish my testing and push the update.

J'ai fait les changements sur la bêta:
Pour le tester dès à présent:

Menu > Settings > General > Branch > beta
Menu > Search for updates
Relancer Jarvis
Refaire l'auto-adjust levels dans Menu > Settings > Audio > Auto-adjust levels
Et dis moi si ca va mieux

Same problem, unless I missed something
------------ Config ------------
jv_branch            beta
jv_version           17.04.28
jv_arch              x86_64
jv_os_name           Mac OS X
jv_os_version        10.12.4
language             fr_FR
play_hw              false
rec_hw               false
speaker              Default
microphone           Default
recorder             sox
trigger_stt          snowboy
command_stt          bing
tts_engine           osx_say
--------------------------------

DEBUG: start_listening hook
utils/timeout.sh 10 rec -V1 -q -r 16000 -c 1 -b 16 -e signed-integer --endian little /tmp/jarvis-record.wav gain 0 silence 1 0.1 2.1% 1 0.5 2.1% pad 0.5 0.5 trim 0 5
DEBUG: speech duration was 15 (10 = 1 sec)
DEBUG: stop_listening hook

Snowboy works much better indeed as a recorder

@ybizeul you are still with min noise perc to start at 2.1%
Try to lower it manually to 0.1% but if after that the sound is still chopped off, stay with snowboy as recorder...

Ok, I thought I didn't need to with the code change.
It's better now, sound recording isn't chopped anymore but it's recording permanently as the room noise is above 0.1%

Ok then try to find the best value.
New formula I use for auto-adjust levels in Settings > Audio should do it for you, but manual finetuning is better.
Do you confirm you don't have the issue with snowboy recorder at all?

Yep, Snowboy recorder doesn't have that problem. It's hard to make bing recognize anything if too far from the mic though but I guess that's another problem, I would need specific omnidirectional mic with noise cancellation, that's for another day :-)

I would be great if sox had an option to include additional time (half a second) before the threshold is crossed

@ybizeul this is what I did, I added half a second before and after the recorded sound. Should be better now.
And yes, for far end recognition, you need an array mic 😄

@alexylem : Thanks you, it is not 100% ok but helps with the respeaker (without mic array for now)

The MicArray module of the ReSpeaker alone would work with any generic device ? (My mac, a Raspberry pi 3, etc)

No idea, you'd better check out with the vendor.

Mine is seen as a USB microphone, so it should work but I never tested it yet. Someone tried it here, but we don't know if it is actually working.


Problems mocking things that return references as generic parameters

Consider fn a(&self) -> &str and fn b(&self) -> Option<&str>.
For a, the MockFn::Output type will be str, and dealing with the reference is handled separately from storing the actual value in unimock. But this trick does not scale for definitions like function b.
Generic types used as return values could be Option, Result, or any user defined type. Unimock must be able to store any kind of "owned" version of these. Those types could be either structs or enums or combinations of those.
Possible fixes (needs investigation):

A trait to convert borrowed types into owned values and back again?
Have some kind of non-generic, fixed "output variants" which could map back to variants of Result, etc. This was the initial idea but probably not scalable.

Fixed in version 0.4.0, with a solution for Option and Result which is perfectly scalable to other types and user-defined types. Perhaps in the future there could be a derive-macro.


BokehDeprecationWarning: 'legend' keyword is deprecated

I am getting a deprecation warning for every scatter plot I make.
You may reproduce the warning by running this code on a notebook (python 3.6):
import pandas as pd
import numpy as np
import pandas_bokeh
pandas_bokeh.output_notebook()
np.random.seed(0)
df=pd.DataFrame(np.random.random((100,3)), columns=['x','y','z'])
df.plot_bokeh.scatter('x', 'y', 'z', colormap='Turbo')

The warning is: BokehDeprecationWarning: 'legend' keyword is deprecated, use explicit 'legend_label', 'legend_field', or 'legend_group' keywords instead

Dear @caph1993 ,
thanks for reporting the issue. I already fixed this and when you upgrade to Pandas-Bokeh 0.5.2 the Deprecation Warning should be fixed.
Really nice plot by the way!
Best Patrik


why no polyfill for localstorage, in tandem with other polyfill?

Sir, this exactly might not be an issue but going through the JavaScript files, I happened to notice that most other files that might create browser issues except that for local_storage_manager.js happened to possess a "polyfill file".
I would really like to know if doing something like creating a new file as
localStorage_polyfill.js
and then starting it with
window.localStorage = window.localStorage || function(){}
would create some unseen error which is why it has been deliberately not presented in the afore mentioned form or can it be used as an alternative to the code that has been defined in the local_storage_manager.js file?
Also in the localStorageSupported function with the following code
LocalStorageManager.prototype.localStorageSupported = function () {   var testKey = "test";   var storage = window.localStorage;   try {     storage.setItem(testKey, "1");     storage.removeItem(testKey);     return true;   } catch (error) {     return false;   } };
checks for the behaviour of the localStorage but doesn't check if localStorage is undefined. Is it because of any particular situation this code has run into where localStorage was defined but was not behaving properly?

Regarding your comment about the checking function, and particularly try { storage.setItem(testKey, "1"); storage.removeItem(testKey); return true; }, it does check if localStorage is defined, as an error will be raised if it is undefined:
In the case where the browser doesn't support localStorage, this will happen:
> var storage = window.localStorage; // storage = undefined
> storage.setItem(testKey, "1"); // Raises "ReferenceError: storage is not defined"

So basically, checking for localStorage support happens implicitly. As for having fallbacks for localStorage, it's a reasonable point, but most browsers (even on mobile) have localStorage support down to the very old versions, so I thought it wouldn't be worth it. Check here: http://caniuse.com/#search=localstorage
Thanks for your comment though!


GH-1272 (DO NOT MERGE) Removal of parent/child context

Initial removal of parent/child context for Binders. This commit contains bare minimum of what's required while still supporting 'the old way'.
Basically implementor of a binder must do the following things:

name your configuration file as the usual boot 'spring.factories` (no more spring.binders)
add name attribute to the @Bean which declares the actual binders (e.g., @Bean('rabbit'))

Codecov Report

Merging #1361 into master will decrease coverage by 0.31%.
The diff coverage is 61.53%.

@@             Coverage Diff              @@
##             master    #1361      +/-   ##
============================================
- Coverage     61.59%   61.27%   -0.32%
+ Complexity      822      818       -4
============================================
  Files           136      136
  Lines          3934     3943       +9
  Branches        550      553       +3
============================================
- Hits           2423     2416       -7
- Misses         1232     1246      +14
- Partials        279      281       +2

Impacted Files
Coverage Δ
Complexity Δ

...loud/stream/config/BinderFactoryConfiguration.java
86.15% <ø> (+1.07%)
16 <0> (-2)
:arrow_down:

...work/cloud/stream/binder/DefaultBinderFactory.java
84.46% <61.53%> (-6.84%)
33 <5> (+3)

...amework/cloud/stream/reflection/GenericsUtils.java
34.88% <0%> (-27.91%)
3% <0%> (-8%)

...gframework/cloud/stream/binder/DefaultBinding.java
33.33% <0%> (+6.66%)
7% <0%> (+3%)
:arrow_up:

Continue to review full report at Codecov.

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

I am not sure I am following the objective here.
How will we support different boot properties for each binder (via the environment property: https://docs.spring.io/spring-cloud-stream/docs/Elmhurst.RELEASE/reference/htmlsingle/index.html#multiple-systems) ?

Polished and squashed.
Merged upstream.


How to use your code?

Hey guys, how do I use appannie? I tried pip installing to no avail. Should I fork the entire repo and build a project with all your code in it?

This library is currently not maintained, so forking the library would be advisable.
Alternatively you could install it like this:
pip install git+git://github.com/webhue/appannie.git

If you are going this route feel free to submit any fixes you find while using it.


Command line tool for Concerto

Is your feature request related to a problem? Please describe.
It would be useful to offer a command line interface (CLI) for concerto. This could be used to test whether a JSON document validate against a model, for generating other schema languages (XML Schema, JSONSchema, etc) from a model, or to resolve external models (See #66).
Describe the solution you'd like
The CLI could be called concerto followed by a command and options:

concerto validate for validation
concerto generate for generating other scheme languages
concerto get for resolving models

I would really like a concerto validate !

I would really like a concerto validate !

Added in PR #94


feat : use --no-cache-dir flag to pip in dockerfiles to save space

using the "--no-cache-dir" flag in pip install, make sure downloaded packages by pip don't cache on the system. This is a best practice that makes sure to fetch from a repo instead of using a local cached one. Further, in the case of Docker Containers, by restricting caching, we can reduce image size. In terms of stats, it depends upon the number of python packages multiplied by their respective size. e.g for heavy packages with a lot of dependencies it reduces a lot by don't cache pip packages.
Further, more detailed information can be found at
https://medium.com/sciforce/strategies-of-docker-images-optimization-2ca9cc5719b6
Signed-off-by: Pratik Raj<EMAIL_ADDRESS>
[x] I agree to contribute to the project under Apache 2 License.
[x] To the best of my knowledge, the proposed patch is not based on a code under GPL or other license that is incompatible with FlexMeasures

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 65.032%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
6480

Relevant Lines:
9358

💛  - Coveralls

Thanks for your PR, @Rajpratik71!

I also ran tests within that image and they passed - so this seems good to me :)
On another note, I read the article and also tried saving space on apt-get install. With --no-install-recommends, I saved another 300 MB (removing and purging afterwards only saved ~40 MB I think). That image also tested well.
If you want, you can add that to this PR to complete the reduction :)
Finally, I'd like to mention this in documentation/changelog.rst under "Infrastructure / Support", like this:
* Reduce size of Docker image (from 2GB o 1.4GB) [see `PR #512 <http://www.github.com/FlexMeasures/flexmeasures/pull/512>`_]

If you could add that line I'd appreciate it. Otherwise, I'll do it later.

Thanks for your PR, @Rajpratik71!

I also ran tests within that image and they passed - so this seems good to me :)
On another note, I read the article and also tried saving space on apt-get install. With --no-install-recommends, I saved another 300 MB (removing and purging afterwards only saved ~40 MB I think). That image also tested well.
If you want, you can add that to this PR to complete the reduction :)
Finally, I'd like to mention this in documentation/changelog.rst under "Infrastructure / Support", like this:
* Reduce size of Docker image (from 2GB o 1.4GB) [see `PR #512 <http://www.github.com/FlexMeasures/flexmeasures/pull/512>`_]

If you could add that line I'd appreciate it. Otherwise, I'll do it later.

Sure @nhoening , I will add.

Thanks. I'll test the combined Docker image but I don't expect issues


[Question][Help] Reverse Proxy a google website

I'm trying to Reverse Proxy www.google.com. Every time I recive a "Location: www.google.com ". I keep reciving the "Location:" header even if I change the "Location:" header to back to my website.

You can probably fix your specific issue by looking at http://docs.mitmproxy.org/en/stable/features/reverseproxy.html#host-header, but see the warning at http://docs.mitmproxy.org/en/stable/modes.html#reverse-proxy - you can't really "mirror" google by just specifying -R.
Cheers,
Max


Feature Request: LCOV or Istanbul format code coverage

It would be nice if the format of the code coverage report returned form the new page.coverage API was in a format that existing tools could use such as nyc.
I came across v8-to-istanbul which converts the v8 format to istanbul but the new coverage API isn't returning the raw v8 format so I can't really leverage it.

@shannon @JoelEinbinder I just spent a weekend hacking with some awesome developers at HackIllinois. @vkoves and @rjaltman helped pull together a library that outputs puppeteers' test coverage output in a format consumable by Istanbul:
https://github.com/istanbuljs/puppeteer-to-istanbul
this allows you to run a variety of detailed reports against your puppeteer coverage output \o/
would you accept an update to the documentation, outlining how to collect HTML coverage, etc., through puppeteer with Istanbul?

@bcoe this looks great!

would you accept an update to the documentation, outlining how to collect HTML coverage, etc., through puppeteer with Istanbul?

It will be very nice to have a reference here:
https://github.com/GoogleChrome/puppeteer/blob/master/examples/README.md

@aslushnikov 👍 I will draft up an example application and update that README.
I think it might also be worth providing a link here:
https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#class-coverage


net/mail: Address.String() and ParseAddress() don't match RFC 5322

I have noticed that Address.String() and ParseAddress() functions don't match RFC 5322, especially regarding quoted-strings, and some other special cases.
Most simple way to find out if Address.String() and ParseAddress() do their job, is to look if a parsed and formatted mail address can be parsed again, which isn't the case: https://play.golang.org/p/Kl0FDI-BxO
package main

import "fmt"
import "net/mail"

func main() {
	a, _ := mail.ParseAddress(`"<EMAIL_ADDRESS>	fmt.Println(`"<EMAIL_ADDRESS>	fmt.Println(a)
	_, err := mail.ParseAddress(a.String())
	fmt.Println(err)

	fmt.Println()

	a, _ = mail.ParseAddress(`"hello<EMAIL_ADDRESS>	fmt.Println(`"hello<EMAIL_ADDRESS>	fmt.Println(a)
	_, err = mail.ParseAddress(a.String())
	fmt.Println(err)

}

"<EMAIL_ADDRESS>< @test.com>
mail: invalid string

"hello<EMAIL_ADDRESS><hello<EMAIL_ADDRESS>mail: unclosed angle-addr

I fixed this problem, and wrote tests for other special cases: https://go-review.googlesource.com/#/c/8724/
I created this patch request a month ago, but hadn't got any answer unfortunately...

Sorry, this did slip through the cracks on assigning a reviewer. But you did mail this prior to the Go 1.5 freeze.
I sent out some initial comments, but I'll let @dsymonds handle finishing the review, since it's his code I believe.

Ok, thank you!


[3.6.0] "Gui control clip their contents" is not mentioned in General Settings

Need to add this property, and also since at that double check that the General Settings page reflect 3.6.0 overall.

just to keep track of changes, about "Gui control clip their contents", you added right now here
https://github.com/adventuregamestudio/ags-manual/wiki/GeneralSettings/_compare/f16525b^...f16525b

I'm running through the list of options now, looks like few backward options have changed their place in the table, and few others may benefit from adding more details to them.

Okay, I guess i'm done.
https://github.com/adventuregamestudio/ags-manual/wiki/GeneralSettings/_compare/eb972118f97fc078e7242e23ebb44effc1b5cebe...5da3eef63e4ed451989eda5ceac9dc8cbcb5f6c2


bedtools merge output interval different by 1 in each direction

I have number of files in delimited format: chromosome start end . I would like to merge overlapping intervals between files, keeping option min distance between intervals to be merged. I cat all files , sorted and applied bedtools merge with option -d. All good, but the problem I have is that when interval is of length 1, the output from bedtools merge outputs it as +1 -1 interval. For example:
my input: chr 421 421
my output" chr 420 422

I get the same problem.
bedtools v2.25.0

cat test.bed
chr12	25398284	25398284
chr12	25398285	25398285

bedtools merge -i test.bed
chr12	25398283	25398286

This is probably because BED is a zero-based half open interval (first base of chromosome = 0, end coordinate is not included in the interval):
chr 421 421 ==> is a region of length 0, starts at base 422 (421 + 1) in the chromosome and ends before base 422
so your regions all have a length of 0 basepares.
If you have BED regions which have a length of at least 1 basepare, it works fine.
$ printf 'chr1\t421\t422\nchr1\t422\t423\n'
chr1	421	422
chr1	422	423

$ printf 'chr1\t421\t422\nchr1\t422\t423\n' | ./bedtools2-git/bin/bedtools merge -i -
chr1	421	423

@mfoll

Indeed:

BED starts are zero-based and BED ends are one-based.
http://bedtools.readthedocs.io/en/latest/content/overview.html#bed-starts-are-zero-based-and-bed-ends-are-one-based


Modify partition_values field type in Add/Remove actions.

Description
Modify partition_values to type HashMap<String, Option> according to the delta spec.
Related Issue(s)

closes #348

Documentation
Detailed discussion here: https://groups.google.com/g/delta-users/c/ZzzrtNRqRyk

Thank you @zijie0 ! Looks good from a quick glance, I will take a closer look later today.

@houqp I'm not sure whether I need to add some write tests. I tried locally changed following test: https://github.com/delta-io/delta-rs/blob/main/rust/tests/write_exploration.rs#L422 with empty string value:
// test data set #2 - updates
let json_rows = vec![
    json!({ "id": "D", "value": 148, "modified": "" }),
    json!({ "id": "E", "value": 150, "modified": "" }),
    json!({ "id": "F", "value": 152, "modified": "" }),
];

The generated files seems to be the same with "native" delta.

@houqp I'm not sure whether I need to add some write tests.

@zijie0 it would be great if you could help write some write tests to cover the cases of both empty strings and actual null values. So perhaps something like below:
    json!({ "id": "D", "value": 148, "modified": "" }),
    json!({ "id": "E", "value": 150, "modified": null }),

The rest looks good to me, thank you @zijie0 for discovering this big can of worms :)

It is weird, cargo clippy passed on my local machine. Could you help me on this build failure? @houqp

Sorry, forgot to rebase on main branch...

Thank you @zijie0 !


Code cleanup

Alrighty, I went ahead and made sure swiftlint did its job on the code, so everything is lookin' nice and snazzy now. Everything in the booklet seems to load fine, except for the buttons are not yet tappable. The state hasn't changed, as this was the case before, so I think everything is in its right place for this PR.

Also, as a way to test this pull request, I would appreciate it if someone could:

freshly clone this repo
cd into the iOS folder
run carthage update --platform iOS
run the rainbow.xcodeproj file and run the app

The app should load out of the box.


Microphone input does not work in Safari

Describe the bug
Microphone input does not work when using Safari since the 62b5ce6 commit. Granting microphone permission does not activate on the browser's microphone symbol either. Repeatedly muting and unmuting shows these console logs: "[Warning] 2020-10-01 – "21:10:05.106Z" – "|" – "WARN" – "in" – "[LocalAudioTrack #3: e7157454-ad7e-4aad-ab18-83eab8f46af9]:" – "Got a silent audio MediaStreamTrack. Stopping all MediaStreamTracks and calling getUserMedia again. This is retry #2." (2.d54d144d.chunk.js, line 2)"
To Reproduce

Deploy commit 62b5ce6 and enter a room.
Microphone input is not detected. Repeatedly mute and unmute to see the other console log.

Expected behavior
Microphone input is detected and transmitted.
Environment (please complete the following information):

OS: macOS 10.15.4
Browser: Safari Version 13.1 (156<IP_ADDRESS>.8)
App Version: commit 62b5ce6
Node.js version: v12.18.0

Additional context
This bug seems related to https://github.com/twilio/twilio-video.js/blob/master/COMMON_ISSUES.md#mobile-safari-participants-on-ios-1301-sometimes-fail-to-send-audio but I'm not sure what broke after the latest change.

Thanks for the question @nalinbhardwaj!
Unfortunately, I couldn't reproduce this issue. I don't have the same version of Safari installed as you - I'm running Safari version 14.0 on macOS 10.15.7.
What audio device is the app trying to use? I'm wondering if you are seeing the Got a silent audio MediaStreamTrack warning because your audio input device is actually producing a silent stream. Does your audio input device work on other websites/programs?
Also, in the video app, can you select a different audio device to use by going to Settings > Audio and Video Settings?

@timmydoza  I can only reproduce this behaviour in Safari 13.1 (updating to 14 resolved it for me too). And yeah, audio input works just fine in other apps (in fact, I was deploying a previous commit of the react app at the same time and it was working for that as well). I'm using the default MacBook Pro Microphone. Trying another audio device from Settings did not fix this either.

I'm wondering if it has something to do with this: https://github.com/versatica/mediasoup-client/issues/101#issuecomment-567559926
If you enable "WebRTC Unified Plan" in the developer menu of Safari 13.1, does the audio work again? Let me know how that works out for you!
In the meantime I'll close this issue. The problem seems to be with that specific version of Safari, and not with this app.
Thanks!


modified Links

👷 Deploy Preview for waterfrontiers processing.

Name
Link

🔨 Latest commit
468da75fea995d94de5427940eff75f59ffd33bd

🔍 Latest deploy log
https://app.netlify.com/sites/waterfrontiers/deploys/653905a748e31100080d71c9


Add library to serde ecosystem

Serde has a list of serde formats specifying the main library supporting each of those. Let's ask to be added to the list for avro.

https://github.com/serde-rs/serde/pull/1260 has been merged 👍


Removing mentions about Rector CI

Leave this great idea for later

Just like Packagist, this might come in the future


Update after_install.sh to remove Docker network for previous deployment

Docker networks can build up and prevent the creation of additional containers. Let's update our deploy script, which stops and removes the previous Solr container, to also remove the associated Docker network.
https://github.com/Metro-Records/la-metro-councilmatic/blob/8848bfb42e26881a8c525aca393d14e828aea49e/scripts/app_start.sh#L66-L73

@hancush It looks like the change isn't working.

I think what's going on is that the we're trying to remove the network named for the current deployment before the network has been created.
What about running docker system prune --force to remove the unused networks from the previous deployment(s)?

Done and deployed.


[PE1-1247] Add S3 origin config

Description

Motivation and Context

How has this been tested?

Checklist

[ ] I have implemented automated tests for the changes.
[ ] I have updated the documentation accordingly.

wrong branch name, closing


Index page responds with HTTP 500 error while running in docker.

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
When running a bit boilerplate admin panel demo in docker, it launches into the swagger UI fine, though when you try to navigate to the index page it responds with an HTTP 500 error.
Expected Behavior
For the index page to respond with a HTTP 200 code returning the home page, like it does when not running in docker.
Steps To Reproduce
Create a bit boilerplate admin panel demo
Run the project in docker
It should launch into the swagger UI displaying the page
Navigate to the home page by removing /swagger/index.html from the path
The page should respond with an HTTP 500 error
Exceptions (if any)
HTTP 500
.NET Version
8.0.202
Anything else?
Windows 11 Pro Build 22631
SDK version 8.0.202
Visual Studio version 17.9.5
Docker version 20.10.22, build 3a2c30b
If you need any other information just let me know, more than happy to help. Very cool project I would like to learn if I can get it running in docker.

Are you using SQLite or SQL Server for your database? It's possible having trouble connecting.

SQL server (mssqllocaldb), any idea why it would have trouble connecting in docker but not when running it normally? Also do you think switching to SQLite would resolve the issue?

You've to do something for the Sql server dependency in docker.
The other choice would be sqlite.

I'm closing this issue since there has been no activity in a long time.


Add async support

This PR adds future and AsyncRead/AsyncWrite support for this crate

Pull Request Test Coverage Report for Build 183093757

13 of 19 (68.42%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+18.2%) to 63.83%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/error.rs
0
1
0.0%

src/asynchronous.rs
13
18
72.22%

Totals

Change from base Build 181855124:
18.2%

Covered Lines:
60

Relevant Lines:
94

💛  - Coveralls

@alesharik thanks for working on this.
Please take a look as there are few tests no CI not passing, it seems to be clippy warnings. Also, please squash both commits.
There is a lot of duplicated work among both code blocks. Do you foresee any way to reduce it?

@alesharik thanks for working on this.
Please take a look as there are few tests no CI not passing, it seems to be clippy warnings. Also, please squash both commits.
There is a lot of duplicated work among both code blocks. Do you foresee any way to reduce it?

I am closing this in favor of #27 PR. Please take a look at it @alesharik and provide feedback if possible.

Pull Request Test Coverage Report for Build 183098378
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

12 of 18 (66.67%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+18.2%) to 63.83%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/error.rs
0
1
0.0%

src/asynchronous.rs
12
17
70.59%

Totals

Change from base Build 181855124:
18.2%

Covered Lines:
60

Relevant Lines:
94

💛  - Coveralls

Pull Request Test Coverage Report for Build 183098378
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

12 of 18 (66.67%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+18.2%) to 63.83%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/error.rs
0
1
0.0%

src/asynchronous.rs
12
17
70.59%

Totals

Change from base Build 181855124:
18.2%

Covered Lines:
60

Relevant Lines:
94

💛  - Coveralls


Stone cli prove-bootloader doesnt work

If we run
stone-cli prove-bootloader --cairo_programs ./examples/cairo0/bitwise_output.json --layout starknet --parameter_file ./tests/configs/bootloader_cpu_air_params.json --output bootloader_proof.json --fact_topologies_output fact_topologies.json

I am getting this output
Bootloader program output:
382450030162484995497251732956824096484321811411123989415157331925872358847
-1105634678291810840495795743566225907562315655840952488182375710141777272881
1
3
603813996395768983940956317134610857891217643068814355807758856063588214192
0
Running prover for bootloader...
Error: Failed to run stone prover: prover run failed

ps: i solve the cairo-proof-parser with a new updated package

Could you try making the error more expressive by changing the error.rs code to the following and sharing the output?
    #[error("prover run failed: {0}")]
    CommandError(std::process::Output),

Hey @mellowcroc , idk what happened but suddenly it worked for me . But do you plan to merge the cairo-proof-parser pr or are you finding some better alternatives.?
Also running the prover in m3 chip takes about 8mins and on M1 about 30 mins , doing something like CPU_AIR_PROVER=<absolute path to binary>

But do you plan to merge the cairo-proof-parser pr or are you finding some better alternatives.?

There's a PR now that uses a different lib and adds additional functionalities (https://github.com/zksecurity/stone-cli/pull/13). It will be merged soon, but feel free to work on that branch.

Also running the prover in m3 chip takes about 8mins and on M1 about 30 mins , doing something like CPU_AIR_PROVER=

What sure what you mean here, do you mean it's too slow?

@mellowcroc Yes it takes about 30 mins on m1


Adds walkergriggs.com

This PR is:

[x] Adding a new domain
[ ] Updating existing domain size
[ ] Changing domain name
[ ] Removing existing domain from list
[ ] Website code changes (512kb.club site)
[ ] Other not listed

[x] I used the uncompressed size of the site
[x] I have included a link to the Cloudflare report
[x] This site is not an ultra minimal site
[x] The following information is filled identical to the data file

I confirm that I have read the FAQ section, particularly the two red items around minimal pages and inappropriate content and I attest that this site is neither of these things.

[x] Check to confirm

- domain: walkergriggs.com
  url: https://walkergriggs.com/
  size: 43.28
  last_checked: 2024-07-02

Cloudflare Report:
https://radar.cloudflare.com/scan/447a8f31-4095-4e63-870c-731cb85a5b6f/summary

Thanks


Add VS Code related debug files to examples

This should be done alongside electro-smith/DaisyWiki#13

 Add VS Code Files to DaisyExamples Repo

added to all existing examples.


Update README

Add an introduction paragraph with maven dependency library usage example.
Document the release process - how to bump the version and triger a release/deployment.

The dependency example seems like a bad idea in a README file - one would have to update the version xml tag for every release.

Add a short motivation section in which you:

briefly explain the purpose of this library
list alternatives

Add a short motivation section in which you:

briefly explain the purpose of this library
list alternatives


Add MSRV (Minimal Supported Rust Version)

Currently this package does not have a mentioned MSRV, neither in the README, rust-toolchain file or Cargo.toml.
Why? because upgrading to 0.7 has lead to the following error for rust versions below 1.74(.1):
error[E0446]: private type `ServiceState` in public interface
  --> /home/hasezoey/.local/cargo/registry/src/index.crates.io-6f17d22bba15001f/souvlaki-0.7.0/src/platform/mpris/dbus/interfaces.rs:19:1
   |
19 | / pub fn register_methods<F>(
20 | |     state: &Arc<Mutex<ServiceState>>,
21 | |     event_handler: &Arc<Mutex<F>>,
22 | |     friendly_name: String,
...  |
25 | | where
26 | |     F: Fn(MediaControlEvent) + Send + 'static,
   | |______________________________________________^ can't leak private type
   |
  ::: /home/hasezoey/.local/cargo/registry/src/index.crates.io-6f17d22bba15001f/souvlaki-0.7.0/src/platform/mpris/dbus/mod.rs:54:1
   |
54 |   struct ServiceState {
   |   ------------------- `ServiceState` declared as private

For more information about this error, try `rustc --explain E0446`.

suggestions:

[ ] add field package.rust-version to Cargo.toml
[ ] mention in README
[ ] add ci test to verify it will build on the msrv

Given that the MSRV is so recent, there's also no reason not to raise the edition to 2021. Not that it makes any difference, really

Thank you. This is completely necessary and I apologize for any trouble the lack of it caused. I can set the MSRV to 1.74 but I feel like the error about leaking a private type should have an easy solution that lowers the MSRV again since we're not using any particularly cutting-edge features. I'll try something out.

In the end I managed to get the MSRV down to 1.67. I'll keep the edition 2018 for now. Thanks!

That's great, thank you!

It's not that good of a solution but after all in 0.8 the dbus backend won't be supported anymore.

just to confirm some wording, this only means that the dbus(crate) backend wont be supported anymore, but dbus as a whole will still be supported (via zbus), right?

Exactly.


fix(deps): update terraform github.com/terraform-ibm-modules/terraform-ibm-watsonx-saas-da to v1.7.15

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-watsonx-saas-da
module
patch
v1.7.14 -> v1.7.15

Release Notes

terraform-ibm-modules/terraform-ibm-watsonx-saas-da (github.com/terraform-ibm-modules/terraform-ibm-watsonx-saas-da)
v1.7.15
Compare Source
Bug Fixes

deps: update terraform terraform-ibm-modules/cos/ibm to v8.15.5 (#225) (e269cb5)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

:tada: This PR is included in version 2.6.4 :tada:
The release is available on:

GitHub release
v2.6.4

Your semantic-release bot :package::rocket:


infra: logs cleanup

This may be already on your radar, but I've noticed a few frictions when it comes to accessing logs:

logs are long and take a while to load (and failures tent to be summarized at the end)
not all bots use the same log format (different flags for test.py)
logs from browser tests are noisy

Overall, it would be nice if we could make changes to make it easier to extract errors from the build bot results. Some ideas that can help here:

unify on a single format for calling test.py on all configurations
remove unnecessary text in the buildbot format from test.py, for example we no longer need the progress indicators (since luci doesn't support these):

!@@@STEP_CLEAR@@@
!@@@STEP_TEXT@ 99% +16656 -1 @@@

create a separate log file containing only failures, ensure that every step contains a link to it, and educate team members about it
review logs from browser tests and see what can be done to reduce the output to just logging the failure message (currently we include debug messages from the test_controller.js and a dump of the DOM, both of which are not valuable when inspecting failures of langauge and corelib tests)

Most of these issues have been resolved by storing test logs in a logs.json file, and uploading them to cloud storage.
The logs viewer, which is linked to from the results feed, shows logs for individual failing tests.
Testing has been extensively changed since this issue was created, and test logs are no longer sent to stdout for test steps. Test.py is called using recipes and options are taken from test_matrix.json.  Closing the issue as completed and/or obsolete.


Support resolving multi-language content from external sources

Bug/issue #, if applicable: rdar://82968120
Summary
This adds support for resolving multi-language content from external sources via OutOfProcessReferenceResolver. The variant information is an additive change so this is backwards compatible with existing resolvers, which continue to return single language content.
Dependencies
n/a
Testing
Set up Swift-DocC with an external reference resolver for a given identifier. For example, the bash script at "bin/test-data-external-resolver".

Note: the example resolver above uses "swift" and "objc" as language identifiers to make it more convenient to test with other Swift and Objective-C content.

Run DocC with an external reference resolver and experimental multi-language support enabled using

DOCC_LINK_RESOLVER_EXECUTABLE=/path/to/external-resolver \
  swift run docc preview path/to/documentation/catalog   \
  --enable-experimental-objective-c-support

For example, you can use the test catalog at Tests/SwiftDocCTests/Test Bundles/MixedLanguageFramework.docc to test this since it has multi-language symbol information.

Add a few absolute documentation links, using the external resolver's identifier, to task groups in the DocC catalog's content, for example <doc://com.test.bundle/first-test> and <doc://com.test.bundle/second-test>.

For example, you can add this documentation extension file for the Bar symbol:
# ``MixedLanguageFramework/Bar``

Some example content with an external reference to <doc://com.test.bundle/first-test> in it.

## Topics

### External references

- <doc://com.test.bundle/first-test>
- <doc://com.test.bundle/second-test>

The external references should resolve

Navigate to a page with external references

The external references should display their resolved information.

Note: with the example resolver, all symbols and all references were resolved to the same information.

Toggle between the different languages.

The external references should update to display their variant information.

Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[x] Added tests
[x] Ran the ./bin/test script and it succeeded
[x] Updated documentation if necessary

That test resolver script may be useful to have in the repo. If you prefer I can add it to the test resources.

@swift-ci please test

That test resolver script may be useful to have in the repo. If you prefer I can add it to the test resources.

This looks really great! I'd love to have it in the repo. Maybe /bin is a better place for it? But happy either way. Thanks for putting it together!

@swift-ci please test

@swift-ci please test

@swift-ci please test


_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 36s
Maven dependency ordering for branch

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
hadolint
0m  1s
There were no new hadolint issues.

+1 :green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

_ Other Tests _

+0 :ok:
asflicense
0m  0s
ASF License check generated no output?

11m  3s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1578/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1578

Optional Tests
dupname asflicense hadolint shellcheck shelldocs

uname
Linux ff22669b4ef2 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 023c6fe56b

Max. process+thread count
45 (vs. ulimit of 12500)

modules
C:  U:

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1578/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) shellcheck=0.4.6 hadolint=1.17.5-0-g443423c

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.


(WIP) Backend API restructure: pagination, refactoring, and plans for Gitlab & BitBucket

Summary
This is a design proposal for our backend API - a goal of the 2.0 release. It is also an update on the immediate plans for implementing pagination for the GitLab API. This is an architecturally complex feature, and the current code needs significant refactoring to support more pagination paradigms, such as the links used by the GitLab API or the JSON wrapper used by BitBucket. Developing this feature should therefore be done with thought towards our future API. I've had extensive discussions with other maintainers and contributors about improvements we want out of this process - these have been a major influence on the design I'm proposing, so I encourage continuing that process with further critique of the suggestions here. While I've written things in an imperative style ("the best way to do this is foo", "we should do bar"), that's just for the sake of brevity. This is all currently in flux, so now is the ideal time to bring up as many concerns as you can think of.
The immediate goals are listed at the end - the proposed design is not intended to be implemented top-to-bottom all at once. It is important to consider, though, since the entire entry-listing process already requires refactoring to support pagination.
Reasons for restructuring
The current pagination code is heavily coupled to a few assumptions which prevent using most REST APIs idiomatically. These include the following:
TODO: link to the code assuming these conditions

Any given page can be loaded immediately, given an integer index as the only argument.
The page contents are static and new pages can simply be appended to an existing list.
The user simply loads one page after another from the beginning to the end (which invalidates any use of the earlier requirement of being able to load any arbitrary page by its index).

The reducer that manages store.entries.pages maintains a single Immutable.js List of ids for each collection, which is simply concatenated to as new pages are loaded. It's the minimum possible implementation for the infinite-scroll pagination used by the Algolia integration. However, it is incompatible with the way most third-party APIs implement pagination, as well as preventing us from loading arbitrary pages and having their order make sense.
Usually, APIs return - either in the JSON body or in headers - a set of links which allow for navigation to given pages relative to the current one. In GitLab, for instance, you can navigate to the next, previous, first, or last page via links in specific headers, but the docs specifically warn against trying to construct URLs based on indexes. BitBucket, on the other hand, uses a wrapper with pagination information around the values returned by its API, and only provides previous and next (and previous isn't guaranteed).
Additionally, pages can change between requests as entries are added or removed, and resolving arbitrary changes in pagination (the sources of which may be well outside the current page) on top of sorting things.
Finally, there are significant improvements we've already discussed which can be leveraged to make dealing with pagination easier.
Current backend API

Expand...
Init and auth lifecycle

Expand...
The CMS starts its lifecycle by rendering the App component, which dispatches loadConfig when it mounts:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/components/App/App.js#L60-L62
When the config finishes loading in loadConfig, it dispatches authenticateUser:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/actions/config.js#L102-L105
authenticateUser dispatches authenticating (AUTH_REQUEST), then calls backend.currentUser:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/actions/auth.js#L46-L51
backend.currentUser checks this.user and this.authStore for existing user information, then passes that to this.implementation.restoreUser and resets the authStore user to that, returning null if there is no user info:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/backends/backend.js#L95-L107
When the App component is rendering and the user is null, it renders the return value of this.authenticating():
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/components/App/App.js#L121-L123
this.authenticating gets auth (originally from the redux store) as a prop and creates a backend with currentBackend:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/components/App/App.js#L68-L70
currentBackend returns a function that takes a config and returns a memoized backend with resolveBackend, which constructs and returns a backend based on the config:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/backends/backend.js#L358-L367
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/backends/backend.js#L343-L356
Next, App.authenticating renders backend.authComponent():
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/components/App/App.js#L76-L89
It is passed the following props:

onLogin: bound version of the App.handleLogin(credentials) method

error: the last auth error (during init this should be null)

isFetching: whether the authentication is fetching (during init this is null)

base_url: backend.base_url from the config.yml.

siteId: backend.site_domain from the config.yml.

(The names of the siteId and base_url props should be made consistent - they will be a public face of our backend API. We may want to rethink how we handle backend configuration as well.)
The component returned from backend.authComponent calls its onLogin prop with a credentials argument (e.g., the GitHub backend). This is passed to App.handleLogin, which dispatches loginUser with the same argument:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/components/App/App.js#L64-L66
loginUser dispatches an authenticating (AUTH_REQUEST), then calls backend.authenticate:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/actions/auth.js#L66-L72
backend.authenticate calls this.implementation.authenticate to get a user, adds a backendName property, caches it, and finally resolves to it:
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/backends/backend.js#L113-L119
In current implementations, this sets properties on the backend instance itself (this.token, for instance) and initializes the backend API object (these are not technically public interfaces, but they are patterns used by all current backends). (e.g., GitHub backend.authenticate).
Next, loginUser dispatches authenticate (AUTH_SUCCESS), or, on error, dispatches a notification action and then an authError (AUTH_FAILURE):
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/actions/auth.js#L72-L84
The AUTH_SUCCESS action is received by the auth reducer, which resets the stored auth information in Redux to Map({ user }).
https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/reducers/auth.js#L4-L19

Methods

Expand...
The methods a backend implementation is required to have are a mixed bag of synchronous, asynchronous, and some which are called with a Promise.resolve wrapper, so a synchronous return works despite the fact that the rest of the code sees that operation as asynchronous.
TODO: expand on these methods
Authentication

sync authComponent()
Returns a component which presents an interface to login to the CMS. This is usually either a login form or a button to trigger a login popup.

async authenticate(credentials)
Calls the backend with the credentials returned from the authComponent. Returns a user object which is stored in Redux (see auth lifecycles above).

sync getToken()
This is used solely to pass a token to integrations, and is called synchronously.

sync/async logout()

sync/async restoreUser(storedUser)

Published entries

async entriesByFiles(collection, extension)
This only receives the extension argument because of the dynamic dispatch used for this and entriesByFolder.

async entriesByFolder(collection, extension)
Note that the existing pagination API is not currently exposed to backends (this would be the most commonly paginated endpoint), as it's only used by an integration.

async getEntry(collection, slug, path)
The path argument to this strikes me as odd - shouldn't the backend be responsible for resolving a collection/slug pair to a path? This seems to couple the API needlessly to a filesystem-based backend, or at least require other backends to emulate being based on a filesystem.

async persistEntry(entryObj, options)
TODO: figure out the arguments to this function
TODO: figure out if the collection object is consistent across calls

Media library

async persistMedia(file, options)

async getMedia()

async deleteMedia(path)

Editorial workflow

async unpublishedEntries()

async unpublishedEntry(collection, slug)

async updateUnpublishedEntryStatus(collection, slug, newStatus)

async publishUnpublishedEntry(collection, slug)

async deleteUnpublishedEntry(collection, slug)

No clear category

async deleteFile(path, commitMessage)
This method couples the backend interface not only to fs-like storage, but also to GitHub's particular implementation of this API method. This call should be reworked to be in terms of a collection and entry (or just a collection in the case of a single-file collection, if we end up implementing those). It is also confusingly similar to deleteUnpublishedEntry.

Redux store design

Expand...
const store = {
  collections: {
    [collectionName]: {
      // collection data
    },
    // ...
  },
  entries: {
    entities: {
      [collectionName].[postID]: {
        // entry data
      }
    },
    pages: {
      [collectionName]: {
        isFetching: false, // is the page currently being fetched
        ids: [
          // list of post ids - this is concatenated to every time a
          // new page is loaded, regardless of what page it is. This
          // thus ends up being just a full list of the posts in
          // whatever order they were loaded.
        ],
      }
    }
  },
}

New backend design

Expand...
Goals

Statelessness.
Should not tie backends to a specific storage implementation.
Pagination support should not significantly complicate development of non-paginated backends.

Backends as stateless functions

Expand...
Instead of storing auth, token, and configuration information in the state of an object, we can pass the required state into the backend when calling it, along with functions that allow the backend to store the state it needs. This state can then be handled by the core code however we want - this would allow us to more easily debug and test backend functions, including the eventual possibility of a backend-agnostic test suite we can provide to assist backend authors. All of that is much harder to do reliably if our API requires the backends to store state themselves.
We can do this by passing a context object as an argument containing the value state and the asynchronous function setState. setState triggers a Redux action which stores a new backend state in the primary Redux store. This allows us to control backend state by changing the arguments we pass in - a huge benefit for both testing backends and using them in unanticipated ways.
Is there a use-case for changing state to an async function getState?
Additionally, this would make creating a backend as simple as exporting functions and a capabilities object (perhaps some other metadata) from a JS module. The imported object could be passed directly to CMS.registerBackend.

Backend state storage

Expand...
Since backends will be implemented by arbitrary third parties, we can't allow the core code to depend on any part of the redux structure that's specific to a given backend. However, we also want to move to a stateless backend API which allows state to be stored in the Redux store, which allows us to leverage Redux state tracking. We also don't want to store functions in the Redux store, since they can't be serialized - this rules out hiding state with closures, as well as using a Symbol for a unique backend key.
I believe the best way to do this is to create a separate tree in the redux store specifically for backends. It should be considered a bug for any of the core code to rely on the data within this structure directly - if there is any way to enforce that, we should do so. It should be solely for the purposes of storing backend state, which should be considered opaque to the core CMS application. This allows us to store data in Redux without coupling the core code to a specific backend storage layout.
One important restriction on what backends should set as state is that it should remain serializable, to preserve the benefits of being able to serialize our entire Redux store.
Credential elision with stateless backends
One notable concern with saving Redux state is that we don't want to risk exposing a user's credentials. While we don't currently serialize the Redux store at all, we should keep in mind that we'll need some sort of credential elision if we decide to add an export of the Redux state for things like bug reports.
Allowing backends to use Redux actions/reducers
While I think it would be a mistake to require the use of Redux for backend state, I think it would be useful to allow backends to use the actions/reducers pattern for managing their own state.
An easy way to implement this would be to create a default set of action and reducer that simply implement the ability to set the new backend state completely. Backends that wish to override the default backend reducer could simply export their own reducer, which will be used if it exists. This would make Redux part of the public API, albeit a small one.

Redux structure
const store = {
  // TODO
}

Configuration
TODO
Init and auth
TODO
Functions
TODO: determine function signatures - these will be mostly the same with the addition of the context argument and a few refactors.
Capabilities

Expand...
API
A capabilities API for backends would allow them to declare what featureset they support. For instance, GitLab's pagination capabilities might look like the following:
{
  pagination: ["next", "previous", "first", "last"];
};

Since the plan is to use capabilities only for pagination to begin with, GitHub's capabilities would start out as simply an empty object.
The UI would receive the current capabilities as a prop, and could change UI based on what actions are available.
Pagination
Initially, capabilities will be implemented to handle pagination.

Get page size
Get number of pages
Go to next page
Go to previous page
Go to first page
Go to last page
Seek to page number

None of these capabilities can be assumed - BitBucket, for instance, only guarantees that the actual values and the link to the next page will exist.
Search

Ties into integration conversation - could a search integration be modeled as a wrapper for any other backend that adds a search backend and the search capability?
Should search and relations widget functionality be the same capability or distinct ones? (example use case: an API with search-by-document but no ability to narrow by field)

Media library

Do getting and setting media need to be represented distinctly? (example use case: a Git host that doesn't serve image mimetypes correctly)
Should there be two APIs specifically for media (the backend media API and the integrations media API?)

Pagination

Expand...
Features impacted by pagination
I summarized this for @talves in Gitter as follows:

If you think of all the entries of a collection as an array, then you can think of almost all the CMS features as being functions that could be passed to either entries.map(...) or entries.reduce(...). The ones that are essentially entries.map(...) functions (like editing a post, or displaying the metadata for a post) are really simple, and won't be affected by pagination. The ones that are essentially entries.reduce(...) functions (like the relations widget, search, collection sorting, tag list generation, etc.), unless they're supported by a specific backend API (like a search API, for instance), are all affected by pagination, because they all fundamentally require checking every single entry in order to return a result. We either have to find a workaround (like a specific backend API, or the Algolia integration) or we have to load every entry in the CMS itself. The only reason any of those features work right now is because nobody we know of except Smashing has enough entries in a collection for all this to matter.

The impact of this is that backends will need some way of communicating their capabilities to the core code, since feature support differences between backends can be small and fine-grained. The "crash on unsupported features" approach we use for backends without editorial workflow support won't work for more subtle differences like "which pagination links are available".
API
The core application will represent pagination state as an opaque cursor. The cursor is simple a value used to pass pagination context to the backend, but the core code should never look into or examine the cursor's contents. Cursors should be serializable, so they can be stored in Redux.
The cursor lifecycle will look something like the following:

When a paginated backend endpoint is called, the backend creates and returns a new cursor alongside the results.

The core code stores the cursor object as part of the current view state.

When the UI is rendered, it is passed function props that allow it to perform backend pagination. These should close around the cursor and pass it to the action creator so that the UI itself never has direct access to the cursor. It is also passed the static backend capabilities.

The UI decides which actions to show based on the backend's capabilities.

When the user performs a pagination action, the UI calls the corresponding function prop to create and dispatch that action (the cursor is passed along by calling the function prop, which closed over it earlier).

The action creator calls backend.cursor.<ACTION>(cursor) with the cursor, and receives the results and a new cursor.

TODO: how do we handle the count, size, and index?
Page Caching

What do we currently cache?
We currently treat pagination as if it is a static, lazy list of entries. That is, we don't require fetching all pages up-front, but we don't ever invalidate the pagination of the current request.

Should we cache?
Since we're leveraging Git-based APIs, I believe that we should cache collection contents as much as possible. Git helps us here by providing SHAs which can be used to tell when the folder underlying a collection has changed.

Where should caching be done, architecturally?
Since the CMS could conceivably used with APIs that either cannot or do not provide immutable keys to data, we will want different caching strategies for different backends. Caching should therefore be done in the backends themselves, and be transparent to the core code.
Caching goes quite a ways past pagination - backends are also responsible for caching auth information, entry contents, etc. Doing page caching in the backend fits our current architecture best.

When can page data be safely cached?
When it refers to an immutable collection with a unique identity. For instance, if a Git-based API provides SHAs of folders, we can safely cache the pages of that folder, since if the folder changes its SHA will also change. This can be leveraged to reduce bandwidth usage even further if the API supports HEAD requests to get the SHA of an directory or file without the body.
For instance, a page-cache system for a paginated folder using such an API could work like this:

When initially requesting the first loaded page, store the SHA of the currently paginated folder.
On loading any page, store
On pagination, make a HEAD request to the currently paginated folder, and retrieve the SHA.

UI

Infinite scrolling
Infinite scrolling should not be specified as a capability of its own, since it is simply an implementation of various other pagination capabilities (next/previous being the minimum required for 2-way infinite scrolling).

Standard page navigation
It may be simpler to drop infinite scrolling entirely in favor of explicit paging. It's extremely easy to drop features dynamically with standard paging - you just show a different set of buttons to go to other pages.

Semantic changes

Expand...
These changes are goals for the new API, but can't be implemented as a simple wrapper without changes to the core code:

Backends should be able to trigger display of the authentication dialog.

If we pursue composable backends, we'll want to support multiple backends by allowing the default backend to be overridden for specific collections.

Composable backends can implement several features which are currently implemented separately:

Integrations - the current integrations system could be replaced by composing backends, overriding the desired functionality in a much clearer and more direct way.
Media library - if we support multiple backends, the media library could be implemented as a collection which

Ideally, we'll remove ~"files"~ and ~"folder"~ collections in favor of single-entry and multiple-entry collections, leaving concerns such as paths to be handled by backend-specific configuration.

Examples
TODO

Integrations
The integrations API is also in need of refactoring or elimination (of the API, not the functionality it's implementing). The writeup on that is now located here: https://github.com/netlify/netlify-cms/issues/1171
Immediate Goals
All this long-term API design has a short-term purpose: it directly impacts how we'll want to implement pagination for the GitLab API.

Expand...
Capabilities API for GitLab/BitBucket pagination
For purposes of GitLab and BitBucket support, the capabilities API will only be used for pagination to begin with. Other backends will be modified to return an empty object for capabilities. The capabilities will be passed into the collections pages to allow pagination support, but a comprehensive capabilities system is beyond the scope of the immediate pagination changes.
Cursor implementation
Since the current pagination implementation cannot be neatly refactored to work with the paginated GitLab or Bitbucket APIs, the cursor API will be implemented immediately. Existing backends should need minimal or no changes in order to use the cursor API - they'll simply export no pagination capabilities, return any value whatsoever for the cursor (since it won't actually be used), and continue returning all entries when requesting the
BitBucket
BitBucket will also be updated to use the new capabilities API for pagination. Merging may require some cleanup of the auth code as well, to implement BitBucket's refresh token, but a new auth workflow won't be implemented until this is merged.
New API methods
These will not be implemented by the GitLab or BitBucket backends for now. See the longer-term migration strategy below for more details.

Longer-term migration strategy
Once we've got pagination working and GitLab/BitBucket support merged into master, we'll want to start the work of moving to the new, stateless API (assuming we've decided to move forward with this).

Expand...
The best way to migrate to this backend API would be to build an object which wraps a backend written to support the new, stateless API, and implements the stateful lifecycle expected by the current API. The object wrapper will likely be quite simple, as it's just providing the state management without any of the redux details. Once this is done, we'll want to develop a generic backend test suite that can be run on any backend (perhaps with some backend-specific setup code for reproducible tests). This will allow several things:

We don't have to change any existing backends until we've proven the new API can work.
We're not locking in the shape of the new API.
If we decide to change what this API looks like, existing backends using it will continue to work.
As we develop new backends against this API, we'll refine the test suite we're using and it will become more robust, allowing us to port more heavily-used backends with greater confidence.

This won't immediately provide the benefits of the stateless backend structure, such as more robust Redux playback, but we've lived without that so far. It's important to prove that the new design is both robust and usable before we try to move heavily-used, battle-hardened code like the GitHub backend to it.
TODO: expand

I've detailed the existing backend methods in this Gist: https://gist.github.com/tech4him1/9972cf4465e88e7f4e8cc29e6019e8c6.

Re @lafiosca's efforts: I'm not going to be fully comfortable with using Netlify CMS until it uploads to bog-standard object storage, so to me, this is important.
Has anyone gotten any further than this?

@snoopdouglas I apologize that my spare time for this effort has been reappropriated. I have not been keeping up with the current state of netlify-cms, but anyone else should feel welcome to pick up the torch and run with it as I will not likely get back to it.

Closing this as stale


dotnet ef

Install dotnet ef 3.1.0 using dotnet tool install -g dotnet-ef
Run dotnet-ef
Recieve error message:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '3.1.0' was not found.
  - The following frameworks were found:
      2.0.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.8 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.11 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.12 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.13 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.2.8 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      3.0.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      3.0.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      3.1.0-preview3.19553.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=win10-x64

I have a .NET Core 3.1.0 preview SDK installed. Obviously the release version is not available yet.
Further technical details
EF Core version: 3.1.0
Database provider: N/A
Target framework: N/A
Operating system: Windows 10 (1809)
IDE: Visual Studio 2019 16.3.9

Tried dotnet tool install -g dotnet-ef --version 3.1.0-preview3.19553.2 as per my SDK version
warning NU1603: restore depends on dotnet-ef (>= 3.1.0-preview3.19553.2) but dotnet-ef 3.1.0-preview3.19553.2 was not found. An approximate best match of dotnet-ef 3.1.0-preview3.19554.8 was resolved.

Working now, but as someone who hasn't used EF Core before, this wasn't obvious!

You got caught in the middle of us publishing 3.0 - it should be out now.


Update AcknowListViewController initializers

Add initializer with array of Acknow
Rename parameter for initializer with plist path
Remove initializer with multiple plist paths

@KieranHarper Hello Kieran; just to give you a heads-up, I’ve decided to remove the initializer with the array of paths from the next update (v2.0). If you still need this functionality, it should be very easy to add it as an Extension in your app, for instance. Cheers.


windows 7 works!

just the live repair cd for now but its still windows 7

Indeed, let's close this in favour of the existing thread: https://github.com/copy/v86/issues/404

you know the live repair cd is windows xp right?


Await.result blocks forever in before/after using AsyncFlatSpec

scalatest version: 3.1.2
before {
  Await.result(Future{1}, Duration.Inf)
}

Will block forever using AsyncFlatSpec.

yes you shouldn't Await in your tests, as that blocks the (only) thread in the execution context and therefore hangs the test.

@johnduffell what if I need to run blocking operation before each async test?

@reugn You could change the ExecutionContext. The default ExecutionContext is single-threaded. Info on that is here:

@bvenners thanks, that worked.


Unexpected input range behavior

Description

See the demo, I was expecting both input ranges to had initially the same value.
Live Demo

https://stackblitz.com/edit/lit-element-range?file=index.js
Browsers Affected

[x] Chrome
[x] Firefox
[ ] Edge
[ ] Safari 11
[ ] Safari 10
[ ] IE 11

Versions

lit-element: v0.5.2
webcomponents: v2.0.2

@Link2Twenty I'm getting the same results using $= instead of = (on Chrome 66)

What are you expecting steps to do, do you know it's invalid syntax?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range
Do you mean to do step?

@Link2Twenty you are right, my mistake, I mean step. I updated the example, and added a version with $=, but as you can see, the error is still there

This is not lit-html related. If you do the same in raw javascript, you get the same issue (at least in Chrome): https://jsfiddle.net/shihn/4bux526p/8/
The declared node vs node created by javascript. I think the defaultValue is set in the constructor and not reset when the range values change.
The best solution would be the set the initial value yourself.

@pshihn Right, I guess lit-html is generating the element like in your example, since there is an expression on the template. And probably if there isn't an expression, lit-html uses innerHTML, maybe like this:
https://jsfiddle.net/4bux526p/24/
I'll set the initial value myself, but I still think that the behavior is bit confusing.

As noted, this is just how the input element works. I'd recommend setting the input's value property. It's more clear and it avoids this issue.


Post fit selection from asp path

continuing PR #87

@tinatorabi  -- I've changed the interface to a format how I see myself using it. Sorry this resulted in a few changes from your version.
Basically the rationale is that I just want a mechanism to very quickly select from a path in different ways. The warmstart you implemented is actually a really nice idea - my rationale for removing it again was that a user would expect that one can continue the solution process, e.g. extending the length of the path. So I'd rather keep my simpler selection mechanism for now and come back to your idea if it is needed.
Would you be willing to take a brief look and see if you see any problems?

looks good. :) I agree, I think I have to make some changes to BPDual in the ASP package to allow warm-starting with a pre-computed tracer to extend the path, but it is definitely doable. I'll create a PR there.

ok I'll merge and register and we can add proper warmstarts later


Changes from parent branch + attempt to fix issue 171 that affects fotonotes

Issue: https://console.firebase.google.com/u/1/project/fotonotes-apps/crashlytics/app/ios:com.fotobabble.fotonote.ios/issues/68a1b39b3062656522c8c23074acccae?time=last-seven-days&sessionEventKey=bdec1dcb671d4664b4249810afb14d5a_1542075841603520250

Oh boy! Wrong PR. 😅 I apologize.

Re-opening. Maybe you guys can approve this one. Sorry to bother y'all. Thank you!


Solved #1921 . All the functions and exports in all the doc file and made to new standard

Every file that has exports and functions are converted to the new standard .

Hi @psjishnu, thank you for contributing to the standardization efforts! Can you tell me which work batch/batches (from the #1921) is this PR covering?

I have standardized all the functions in the docs

@Simek  I have standardized all the functions in the docs

@Simek I just changed every  file with old standards

@psjishnu Ah, I'm sorry, but since it's stated in the issues that you should post the comment with selected batch/batches before you start you work I had to ask you to discard the files that are a part of other accepted PR or from work batches taken by others.
It's not stated in the issue explicitly, but it would be nice to avoid the inline exports for the classes too (Class Component version of examples). Other PRs contains such changes.

OK sir , I will open PR in required manner

@psjishnu Quick question, just to be sure: Are you going to post modified PR for all of the remaining batches or should I unassign you from some of them?

@Simek  I have opened another PR excluding files tat have changes which are a part of another PRs


Support command line switches

It looks like the application does not support queries like the web site does:
http://devdocs.io/#q=language search

Being able to communicate with the application would be very useful.

Extending on the topic, wouldn't it be better to register a custom protocol? It would allow to use queries knowing that the result will always open inside the application.


Tooltip for 'Next' or 'Previous' is not shown even when the pointer is still on the arrow button

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to web chrome
Go to any chat
Send multiple image attachments
Open the first attachment and hover over the right arrow and see that 'Next' displays on the tooltip
Now without releasing the mouse, click again on the arrow and see that the pointer still shows 'hand pointer' but the tooltip is not being displayed. It will work when you shift and release your mouse and hover over the button again.

Expected Result:
The tooltip should be shown when clicking next since the pointer is still a 'hand' pointer
Actual Result:
The tooltip doesn't display when clicking on the right arrow button even when the pointer is still on the button
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: v1.2.99-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43996225/231292621-3f49f9d9-10f8-4069-a41e-5aa9f59610a5.mp4
https://user-images.githubusercontent.com/43996225/231292637-0689182d-c832-418a-b5f5-ae997a0a66ac.mp4
Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1681229369724739
View all open jobs on GitHub

I can repro this, and my first thought was that tooltips generally go away on clicks, but I compared it to Slack - interestingly enough, Slack's tooltips always show "Next":
https://user-images.githubusercontent.com/30815269/231344025-19ec0e5f-42da-40b2-838e-bc0bcabcf7b2.mp4

Triggered auto assignment to @NicMendonca (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Hi @NicMendonca - I'm OOO starting tomorrow so had to reassign. At the moment, I can reproduce this issue, but I wanted to check if this is something we want to implement - https://expensify.slack.com/archives/C01SKUP7QR0/p1681271382760309
Once you get consensus in that thread, you can add the External label, or close it (if we don't want to implement). Thanks!

This sounds like a feature request and it should go through a Problem/Solution post in #expensify-open-source


Some tips on generics

/// A simple generics enum example that represents a gift box. The gift box could contain any type
/// of gift or could be empty. `#[derive(Debug)]` macro is used to simplify the path to `println!`.
#[derive(Debug)]
enum GiftBox<T> {
    Gifts(T),
    Empty
}

So to clarify this declaration. When you say a gift box could contain "any" type, that is true depending on what you mean by any. Generics associate another type (T here) with a type (GiftBox) to create a combined type. In this case you have to choose 1 specific T value each time you have a variable that stores a GiftBox (not entirely true, Ill comment on generic functions later). Something which might help clarify is the most common/well known example of generics are lists (aka vector in rust). Rust has:
struct Vec<T> {...}
but the T value is only "any" type at the moment of declaration. The moment you create a vector, you have to decide what it is a vector of, so that the memory for it can be layed out. In the same way, GiftBox needs to decide what it is a GiftBox "of" the moment it is layed out in memory. You cannot create an "empty box, which you can decide what you want it to be a box of later", as the compiler wouldnt know how to lay out the memory.
/// In this example an empty gift box is declared and no gift box is declared with gifts. This is
/// doomed to compilation failure because the compiler does not know what type the gifts could be.

The reason for the compilation failure is because it needs to know how to lay out the memory. You might be surprised to find that you wont actually need to have the T value be left undetermined.
fn main() {
    // Declare an empty gift box called `empty_box`.
    let empty_box = GiftBox::Empty;

    // Attempt to `println!` to see what the gift box contains. However, this will not compile! An
    // error will be displayed stating "cannot infer type for type parameter `T` declared on the
    // enum `GiftBox`".
    println!("The gift box contains: {:?}", empty_box);
}

When you declare the empty box, if you dont plan on putting anything in the box, then you can just associate the empty type with the GiftBox by adding the type annotation to the empty box.  let empty_box: GiftBox<()> = GiftBox::Empty; That tells the compiler "ah, so for the empty_box variable, the T associated with giftbox in that instance is the empty type". If you wanted to assign a gift value to that variable, you would then only be allowed to put in an empty type instance empty_box = GiftBox::Gifts(())/. This would not compile: empty_box = GiftBox::Gifts(true) because the empty_box type doesnt have a T of boolean
/// If the purpose of the `GiftBox<T>` enum is to allow any sort of type to be within
/// `GiftBox::Gifts`, how do we best accomplish this?
///
/// - Do we have to always hint to the type of `T` if we only declare `GiftBox::Empty`?
/// - Do we have to be explicit on the types that `T` can be?
/// - Is this where turbofish is supposed to be used?!
fn what_do() {
    todo!("Need to figure out how to make this a fully functional generic!");
}

If you would like to accept a GiftBox, but this particular function does not care what kind of gift is in the gift box, then you can make the function itself generic. Example:
fn open_gift_or_panic<T>(gift: GiftBox<T>) -> T {
     return match gift {
        GiftBox::Gifts(the_gift) => the_gift,
        GiftBox::Empty => panic!("I thought I was going to get a gift! D: "),
    }
}

Here the  on the function lets the function work for any T because the code works regardless of what the type in the gift is, it only needs to return the type which is whatever type was in the gift box.

Do we have to always hint to the type of T if we only declare GiftBox::Empty?
Yes (sorta). The compiler must always know what T is for every variable. If the value is a concrete instance of GiftBox (as in your empty_box example) then it must know the T, or in the case of the generic function, it passes the responsibility of figuring out what the T is on to the caller of the function.

Do we have to be explicit on the types that T can be?
You can choose if you want to constrain what types are allowed to be for T. For example, lets say we had a function where we wanted to make a comparison between the gift and a number. In that case the function would only work for types T which can be compared with a number. Notice the type constraint : PartialOrd<u8> (meaning can be compared with) in the generic declaration.

fn open_big_gifts_or_panic<T: PartialOrd<u8>>(gift: GiftBox<T>) -> T {
     return match gift {
        GiftBox::Gifts(the_gift) =>
             if (the_gift > 10) { the_gift } else { panic!("I only open big gifts.") },
        GiftBox::Empty => panic!("I thought I was going to get a gift! D: "),
    }
}

Type constraints like this can also be added to the enum itself so that the giftbox can only hold types which meet certain crtieria (aka implements certain traits).

Is this where turbofish is supposed to be used?!
Normally, most generics in Rust the compiler can "figure out". So for example, in the code I suggested above let empty_box: GiftBox<()> = GiftBox::Empty; we add a type annotation onto empty_box which lets the compiler know "hmm, I see () where the T goes for this isntance, so when it says GiftBox::Empty, that must be a GiftBox<()> empty value" even though you never had to put the () directly on the GiftBox::Empty. Turbofish is a way to tell it explicitly what T to use if it cant just "figure it out". So if we dont want to add the type annotation onto empty_box, we can alternatively tell it what T to use with let empty_box = GiftBox::<()>::Empty (where the "::<()>" I added is the turbofish). That just tells it what T to use at the call site.

(From the readme) How does Option accomplish this?
Option works just like your GiftBox does actually. They are basically identical. Option also must have a specified T associated with every instance, but as talked about above the compiler is usually able to "figure it out" so that you dont have to type the T out.

Note: Fair warning here, I wrote this while I was in a meeting so didnt actually compile any of my stuff. Hopefully I remembered the syntax all right.

Thank you @707090 for such an excellent response with this issue! I've made significant changes to main.rs as a result. There were some major additions in terms of functions, new types, and much better documentation with examples. Your issue was of significant assistance.
May I have your thoughts on pull request 3 prior to merging it into the main branch?

Merged the Library Conversion branch. Upcoming issues related to lack of trait usage still relevant. Therefore, keeping issue open.


build: use github.com/google/uuid for Go UUID generation

Recent updates of the github.com/pborman/uuid library have become thin wrappers
around the Google version, and in fact they're both maintained at least in part
by the same person. Instead of updating the wrapper, which would require us to
also depend on the underlying library, just use the Google one directly.
This required a small change to the call site for uuid.New(), since the type
has changed slightly. However, otherwise this is a fairly straightforward update.

Assuming the CI is happy after the rebase, is there anything further you'd like me to do before this is merged?

Was just waiting for buildbot, I think.


Can I use XYPlot?

Can we use XYplot in the form of a supermerger to see the difference due to merge weights?

I don't see why not, have you tried yet?

You can try something like this
https://github.com/hnmr293/ComfyUI-nodes-hnmr
or
https://civitai.com/models/31126/imagesgrid-comfy-plugin-xy-plot

thankyou!
出来そうですね！
しかしComfyUIを最新にしたら以下のTracebackが出てmehノードが読み込めなくなってしまった。
Traceback (most recent call last):
File "C:\Product\ComfyUI\nodes.py", line 1693, in load_custom_node
module_spec.loader.exec_module(module)
File "", line 883, in exec_module
File "", line 241, in call_with_frames_removed
File "C:\Product\ComfyUI\custom_nodes\comfy_meh_init.py", line 1, in
from .meh import NODE_CLASS_MAPPINGS
File "C:\Product\ComfyUI\custom_nodes\comfy_meh\meh.py", line 7, in
from comfy.sd import CLIP, VAE, ModelPatcher, calculate_parameters, load_model_weights
ImportError: cannot import name 'calculate_parameters' from 'comfy.sd' (C:\Product\ComfyUI\comfy\sd.py)
Cannot import C:\Product\ComfyUI\custom_nodes\comfy_meh module for custom nodes: cannot import name 'calculate_parameters' from 'comfy.sd' (C:\Product\ComfyUI\comfy\sd.py)

thankyou! It looks like I can do it! But when I brought ComfyUI up to date, I get the following Traceback and can't load the meh node.
Traceback (most recent call last): File "C:\Product\ComfyUI\nodes.py", line 1693, in load_custom_node module_spec.loader.exec_module(module) File "", line 883, in exec_module File "", line 241, in call_with_frames_removed File "C:\Product\ComfyUI\custom_nodes\comfy_meh__init_.py", line 1, in from .meh import NODE_CLASS_MAPPINGS File "C:\Product\ComfyUI\custom_nodes\comfy_meh\meh.py", line 7, in from comfy.sd import CLIP, VAE, ModelPatcher, calculate_parameters, load_model_weights ImportError: cannot import name 'calculate_parameters' from 'comfy.sd' (C:\Product\ComfyUI\comfy\sd.py)
Cannot import C:\Product\ComfyUI\custom_nodes\comfy_meh module for custom nodes: cannot import name 'calculate_parameters' from 'comfy.sd' (C:\Product\ComfyUI\comfy\sd.py)

update comfy_meh

Thank you @alexbofa !

Thank you for your response!
I have just updated ComfyUI to the latest version, but the ModelPatcher seems to have been moved after the above action, and the same error is occurring again.
It seems that it is now independent as modelpatcher.py instead of in sd.py.
Traceback (most recent call last):
File "C:\Product\ComfyUI\nodes.py", line 1694, in load_custom_node
module_spec.loader.exec_module(module)
File "", line 883, in exec_module
File "", line 241, in call_with_frames_removed
File "C:\Product\ComfyUI\custom_nodes\comfy_meh_init.py", line 1, in
from .meh import NODE_CLASS_MAPPINGS
File "C:\Product\ComfyUI\custom_nodes\comfy_meh\meh.py", line 7, in
from comfy.sd import CLIP, VAE, ModelPatcher, load_model_weights
ImportError: cannot import name 'ModelPatcher' from 'comfy.sd' (C:\Product\ComfyUI\comfy\sd.py)
Cannot import C:\Product\ComfyUI\custom_nodes\comfy_meh module for custom nodes: cannot import name 'ModelPatcher' from 'comfy.sd' (C:\Product\ComfyUI\comfy\sd.py)


Duplicated parent references

https://github.com/Azure/azure-rest-api-specs/blob/49fc16354df7211f8392c56884a3437138317d1f/specification/timeseriesinsights/resource-manager/readme.md
  - !<!ObjectSchema> &ref_104
    type: object
    apiVersions:
    - !<!ApiVersion>
      version: 2018-08-15-preview
    children: !<!Relations>
      all:
      - !<!ObjectSchema> &ref_105
        type: object
        apiVersions:
        - !<!ApiVersion>
          version: 2018-08-15-preview
        parents: !<!Relations>
          all:
          - *ref_104
          - !<!ObjectSchema> &ref_108
            ...
          - *ref_104
          - *ref_108

@pakrym  -- can you test out the last build in #263 and see if this is good for you?
https://github.com/Azure/autorest.modelerfour/pull/263#issuecomment-611058930
The Quality-Pre-Checker does a better job of finding the parent names

Do we know how many existing swaggers adding these checks would break? I know the network management one stopped working because of the property override error.
Other than that the fix seems to works.


[RFC] Execution hints

RFC#37 introduces a SetAssetClaimer instruction.
This idea of instructing the XCVM to change some implementation-specific behavior is useful.
In order to generalize this mechanism, this RFC introduces a new instruction SetExecutionHints
and makes the SetAssetClaimer be just one of many possible execution hints.

Do you have some examples of other potential hints that we may have?

@xlc Thinking of the leftover fees in https://github.com/paritytech/xcm-format/pull/53, we could have a LeftoverFeesDestination hint to send all leftover fees to that location

Closing in favor of https://github.com/polkadot-fellows/RFCs/pull/107


Merkle storage multiple backends

Other than the current clippy warnings about cloning arrays instead of using *key it looks ok to me, but a few things remaining:

I don't get the difference between StorageBackend and KeyValueStoreWithSchema, they are similar, why do we need both?
Only the RocksDB backend returns stats when asked.
Some write_batch functionality from RocksDB was used in the old version, but has now been replaced by a custom implementation (that is compatible with all backends I assume). Can this be an issue? (here)
Are the other stores being tested? I see that the KVBACKEND can be used to control what backend is used in the tests, but that is not being used right now, right?

I'm ok if the first two are addressed later, but I'm a bit worried about the last two.

Some write_batch functionality from RocksDB was used in the old version, but has now been replaced by a custom implementation (that is compatible with all backends I assume). Can this be an issue?

just checked and docs says that write_batch is atomic write - ill try update StorageBackend` interface to make use of that

Are the other stores being tested? I see that the KVBACKEND can be used to control what backend is used in the tests, but that is not being used right now, right? i can try to integrate that into our github pipline somehow

Update on the tests: I'm adding a macro to expand to calls to all same tests but with each of the different backends. @mat13mn has tested them locally using the env var, but we still want them on CI.


Can i custom Password Reset in \App?

I want to change the way Password Reset work. But i can't overwrite Illuminate\Auth\Passwords\DatabaseTokenRepository and more. How to do it?

Please ask on the forums.


Post-Order Tree Traversal in cpp

Have you read the Contributing Guidelines on Pull Requests?
YES
Description
Post-Order Tree Traversal
Issue no-#125
Checklist

[x] I've read the contribution guidelines.
[x]  I've checked the issue list before deciding what to submit.
[x]  I've edited the README.md and link to my code.

Related Issues or Pull Requests
(Write your answer here.)

kindly review this PR @Kajol-Kumari @SKAUL05 @siddharth25pandey @iamrajiv @HarshCasper

Kindly Merge this PR

@yashaswibiyahut Resolve the conflict error


ineffective nocursor argument

vncdotool version 1.0.0
python  version 3.10
The VNC server is an old binary. I believe it came from Real VNC.
I'm passing the output screenshot of vncdotool to OpenCV to confirm on-screen UI elements. I would like the screenshot to exclude the cursor so that it does not interfere with template matching. Despite using the nocursor argument, my screenshots still contain the cursor... Am I missing something?
    vnc_client = api.connect(host, password=None)
    vnc_client.timeout = 10
    vnc_client.nocursor = True  # Appears to be ineffective. Want to remove the cursor from screenshots to prevent occlusion.
    vnc_client.captureScreen('screenshot.png')  # Resulting screenshot contains the cursor.

nocursor onyl works when client-side rendering is negotiated with the server: In that case the cursor shape and position are sent to the client, which is then supposed to merge the cursor shape into the screen before displaying it to the user.
Without the extension the server will handle that and will instead sent the screen with the cursor already merged in, which the client cannot undo.
Please check if your server does the merging — in which case this issue would be invalid — or the client is supposed to do it. Sadly there is no easy way in vncdotool to see, if PSEUDO_CURSOR = -239 is negotiated: If you're experienced with pdb you can add a break _handleDecodePsuedoCursor or you might want to use wireshark to see, if you an updateRectangle with that encoding is received by the client — or use another VNC client, which is more verbose.

I just want to add that before closing this issue it might be worth it to add some of @pmhahn's explanation in the documentation. At first I looked at the nocursor and pseudocursor options in https://vncdotool.readthedocs.io/en/latest/modules.html?highlight=cursor#vncdotool.client.VNCDoToolClient.cursor (since my initial guess for nocursor from just looking at the source code had no effect as above) but there are no docstrings explaining the meaning of either of these, even a single short sentence might be quite helpful. Then also adding the above detail could be very helpful so that other users don't have to look up the issues on Github to figure this out.


Switch to Vite

To do:  Implement build command

Also add comment in release notes

Try the instructions documented here and adapt to Vite in order to keep the staging environment on GitHub Pages functional.


main method with handcrafted client does not exit

The following class starts and runs everything fine but won't exit:
public class Test {
    public static void main(String[] args) {
        GraphHopperWeb graphHopperWeb = new GraphHopperWeb().setKey(KEY);// even without setKey the issue is reproducable
        GHResponse resp = graphHopperWeb.route(new GHRequest(48.180739, 3.80127, 52.509535, 13.271484));
        if (resp.hasErrors())
            throw new RuntimeException(resp.getErrors().toString());
        System.out.println(resp.getBest().getTime());
    }
}

A workaround is to run
graphHopperWeb.getDownloader().connectionPool().evictAll();

The following does not help:
graphHopperWeb.getDownloader().dispatcher().executorService().shutdown();

Also a shutdown hook does not help!?
Runtime.getRuntime().addShutdownHook(new Thread(() -> graphHopperWeb.getDownloader().connectionPool().evictAll()));

Update: the shutdown hook is called if I do System.exit but then I do not need the workaround anymore.
Found a couple of issues with HTTP/2 like https://github.com/square/okhttp/issues/2575

Ok, this is a problem only when running the class via IntelliJ and can be fixed via either calling System.exit(-1) or connectionPool().evictAll();
An assembled jar does the exit properly without any workaround. So there is nothing to fix IMO.


Consider a different structure where the calculator isn't embedded in the dinero structs

Currently each dinero as a calculator instance stored in it. This has the benefit of being able to make calculations from Dineros without needing to use the calculator, however, this then creates 2 more problems:

There is added overhead to create and store the calculator for every Dinero
Unmarshalling directly into a Dinero struct leaves the calculator nil and requires an UnmarshalJSON method to manually inject the calculator.

It could be better to have the core dinero API (allocate, transformScale etc) come from the calculator and drop the dot notation from the dinero structs.

The best i could come up with is keeping the current structure and looking up the calculator based on the type if it is nil in a calculation. Still not perfect but better DX. Open to ideas for a later version