command to wrap comments

In tuareg-mode, tuareg-indent-phrase when invoked from a comment will wrap the comment to the fill-column.  There should be an analogue in reason-mode.

👍
I use this in Vim all the time.

should this be in the reason plugin or up to the editor? In ST and Atom they're handled by their respective general comment/line wrapping plugin. Atom's one (https://atom.io/packages/autoflow) works well with ocaml's (* *) but not with reason's /* */.
If we default to // comment the reflow should just work, without implementing anything from our side.


add_session_string_func

Codecov Report

Merging #225 into develop will increase coverage by 0.17%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #225      +/-   ##
===========================================
+ Coverage     52.8%   52.98%   +0.17%
===========================================
  Files          200      219      +19
  Lines        20806    21727     +921
===========================================
+ Hits         10987    11511     +524
- Misses        8600     8913     +313
- Partials      1219     1303      +84

Impacted Files
Coverage Δ

bfe_modules/mod_header/default_header.go
22.22% <0%> (-6.35%)
:arrow_down:

bfe_modules/mod_static/conf_mod_static.go
50% <0%> (-6.25%)
:arrow_down:

bfe_config/bfe_conf/conf_https_basic.go
47.22% <0%> (-2.28%)
:arrow_down:

bfe_balance/bal_table.go
62.58% <0%> (-1.39%)
:arrow_down:

bfe_websocket/server_conn.go
74.24% <0%> (-0.76%)
:arrow_down:

bfe_spdy/server_conn.go
78.09% <0%> (-0.45%)
:arrow_down:

bfe_basic/condition/parser/scanner.go
30.99% <0%> (-0.24%)
:arrow_down:

bfe_tls/conn.go
64.26% <0%> (-0.15%)
:arrow_down:

bfe_tls/handshake_server.go
61.98% <0%> (-0.12%)
:arrow_down:

bfe_stream/server_conn.go
97.43% <0%> (-0.04%)
:arrow_down:

... and 39 more

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 77ba439...e4b3816. Read the comment docs.


How are errors/panics/exceptions in finish-async blocks handled?

Structured concurrency is finding its way into popular languages and libraries. It's though not one identical concept, it's actually several variants and the world is now searching and evaluating which ones are better and which ones worse.
On of the major differences between structured concurrency implementations is how errors in spawned threads are handled and how they are (if any) passed somewhere else.
Could you shed some light how finish-async blocks behave in case of an unrecoverable error in one spawned thread appears? Feel free to put emphasis on problems described in https://github.com/vorner/vorner.github.io/blob/master/_posts/2018-07-22-dont_panic.md .

Just for the record an example of another major difference between implementations is e.g. support for real os-level threads (i.e. leveraging the power of more than one CPU core).

Thank you for your interesting question, the truth is that I haven’t really thought too much about error-handling yet. This language was written for my undergraduate dissertation so as a result is likely still missing core language features like error handling.


use grafana for inspecting logs

excuse to learn grafana

https://grafana.com/docs/grafana/latest/installation/docker/
https://grafana.com/docs/grafana-cloud/reference/integrations/integration-caddy/


When compressing, zip includes folder named as source

If I use this:
 - name: Zip the app contents
        uses: somaz94/compress-decompress@v1
        with:
          command: compress
          source: wwwroot
          format: zip

The zip file contents include the folder name itself rather than putting the files in the root of the zip. So we see:
wwwroot/
wwwroot/file1
wwwroot/file2
etc.
But this is what we need:
../
file1
file2
This wreaks havoc when you're using the zip in an Azure App Service zip deploy. It should either not include the folder or there should be a parameter that tells it not to.

Ah.. I Understand. I will reflect what you said and revise it. Please wait a moment.

I fixed it.
deploy new release version.. I
https://github.com/somaz94/compress-decompress/releases/tag/v1.0.3
t's Right?

looks good, thanks!


Implementing a ScrollView

I've attempted to implement a scroll view, with minor success, any chance you could help me with completing it!
I've created a scroll_view_styler with view set too true
  def fill_view_port=(bool)
    @view.fillViewport = bool
  end

My stylesheet main_scroll is:
  def main_scroll(st)
     st.fill_view_port = true
     st.layout_width = :match_parent
     st.layout_height = :wrap_content
  end

And in the on_load I've added in the objects
  rmq.append(Potion::ScrollView, :main_scroll)
  rmq.append(Potion::ScrollView).append(Potion::TextView, :some_text)

I've set the :some_text top in the frame to a very large value. So that it appears off the window, to scroll to.
However the result is the scroll bar can be seen, although it won't actually scroll. Any ideas?

So after a bit of experimenting using a Layout instead. I figured out that a Scrollview requires a Relative or Linear view, which will then contain a collection of your objects (TextView/Image etc)
rmq.append(Potion::ScrollView, :main_scroll).append(Potion::RelativeLayout)
You then have to find the ReletiveLayout and append your objects, otherwise you may get an error about only one child view...
rmq.find(Potion::RelativeLayout).append(Potion::TextView, :scroll_style)
Following style will then scroll.
def scroll_style(st)
    st.color = rmq.color('#ffffff')
    st.text = "scroll!\r\n" * 50
    st.background_color = rmq.color('#200163')
    st.text_size = 14
  end

I'll put this into a pull request so you can see the complete code.


Added support for accessing snapshot collection documents via Mongoid::CollectionSnapshot#documents.

Same as #10 cherry-picked without Rubocop.
Ideally we'd like to query collection snapshots as any other, first-class, Mongoid collection. This enables that via a new document keyword that takes a block that will be used to derive a dynamic class connected to the snapshot collection.
class AverageArtistPrice
  document do
    belongs_to :artist, inverse_of: nil
    field :sum, type: Integer
    field :count, type: Integer
  end
end

You can now do:
andy_warhol = Artist.where(name: 'Andy Warhol').first
doc = AverageArtistPrice.latest.documents.where(artist: andy_warhol).first
average_price = doc.sum / doc.count

This is pretty awesome, since we can just use snapshot data as any other data in MongoDB via Mongoid and not via Moped.
All existing features, custom sessions and multi snapshots are supported.
This is on top of some bookkeeping done in #9.

This is all in version 1.1.0. Thanks again!

Thanks @aaw!


CAMEL-10809 Introduce configurator SPI for rest support in camel-core

This removes the SwaggerRestProducerFactory and moves the
responsibility of configuring rest clients to a new SPI
(RestEndpointConfigurer).
The rest endpoint URI has been changed to allow for syntax like:
rest:<component>[:componentSpecific]

Or in case of Swagger:
rest:swagger:getPetById?apiDoc=petstore.json

The SPI is discovered in the META-INF/services/org/apache/camel/rest
properties file with the prefix configurer. so any other components
wishing to configure rest endpoints via this configurer SPI should add
rest file with configurer.class property.
I would like feedback on the following issues:

instead of META-INF/.../rest use different properties file?
design of the RestEndpointConfigurer SPI interface (for instance: is
it sufficient so that it can be used to plug in headers, or
authentication callbacks for rest)
integration with service discovery ({{service:...}})?
properties missing from Swagger specification (notably host, and
port) -- current idea is that that should be provided from
RestConfiguration

I have a bit doubt about the rest swagger stuff I did, and why it was so generic.
The drawback with making this so generic is that

bad tooling support
a bit confusing to use (too generic)
only 1 implementation of api-doc = swagger. Not really seeing that there are many other alternatives out there

I wonder if we have rest-swagger as component instead of rest:swagger: etc. Then it can make it stand out as a component and its just like any other component.
I would like if you can look into that. The rest-swagger may built on top of the generic stuff we have now/you have, but from end users they should use rest-swagger so we have it as a 1st class component and also available from the camel-catalog / documentation / component list et all.

Thanks @davsclaus let's try to go down that route


[meta] Add Microsoft.CodeAnalysis.NetAnalyzers were it was missing

Summary of the Pull Request
What is this about:
Microsoft.CodeAnalysis.NetAnalyzers is now part of each csproj file.
What is included in the PR:
Added Microsoft.CodeAnalysis.NetAnalyzers to the following projects:

How does someone test / validate:
Quality Checklist

[x] Linked issue: #8375
[x] Communication: I've discussed this with core contributors in the issue.
[ ] Tests: Added/updated and all pass
[ ] Installer: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Docs: Added/ updated
[ ] Binaries: Any new files are added to WXS / YML

[ ] No new binaries
[ ] YML for signing for new binaries
[ ] WXS for installer for new binaries

Contributor License Agreement (CLA)
A CLA must be signed. If not, go over here and sign the CLA.

@crutkas : As promised, here's the PR which adds the Microsoft.CodeAnalysis.NetAnalyzers to the remaining csproj files


Include source proto files in jar for extensibility

Environment details

OS: Ubuntu 18.04
Java version: 1.8
google-cloud-java version(s): 1.49.0

Steps to reproduce
Create a project that has a proto import dependency on one of the .proto files.
For example,
google/cloud/dialogflow/v2/webhook.proto
Code snippet
import "google/cloud/dialogflow/v2/webhook.proto";
import "google/api/annotations.proto";
service WikiDialogue {
// Send the response from agent using when a webhookrequest is received.
rpc GetResponseFromAgent (google.cloud.dialogflow.v2.WebhookRequest) returns (google.cloud.dialogflow.v2.WebhookResponse) {
option (google.api.http) = { post: "/v1/wikitalk/talk" };
}
}
This results in a build error because the proto will not be found; it is not included in the jar file.
The fix for this is to modify the pom file to include the proto file in the jar file when it is constructed, e.g.:
To include all the proto files:

src/main/proto

google/cloud/dialogflow/v2/webhook.proto
google/cloud/dialogflow/v2/intent.proto
google/cloud/dialogflow/v2/session.proto
google/cloud/dialogflow/v2/session_entity_type.proto
google/cloud/dialogflow/v2/entity_type.proto
google/cloud/dialogflow/v2/agent.proto
google/cloud/dialogflow/v2/context.proto

This would allow us to import and use the proto files in developing service APIs that build on top of Google APIs.
Thanks!

@pongad, where do the proto jars get generated?

FWIW, the proto files are at: https://github.com/googleapis/googleapis

Sorry I'm late to this. By "proto jars" do you mean the source protos? I don't think we're creating these right now.
To be fair, I don't think it's right to import proto files from JARs, many APIs depend on the same protos and you'll end up in a bit of a mess. If you'd like to import proto files, consider seeing https://github.com/googleapis/googleapis like @sduskis suggested and https://github.com/googleapis/api-common-protos .

This is not resolved. Can we re-open this? Or can you refer me to an appropriate issue location?
I'm looking for an equivalent of a cloud proto library for user in service definitions, like the ones that exist for a subset of services, e.g. proto-google-common-protos. This commons library DOES export protos inside of jar.  This is needed for the maven dependency artifacts.
In thise case, it could be something like:
proto-google-googleapis-protos
Or perhaps more fine-grained to mirror the generated java code:
e.g. google-cloud-dialogflow (java) vs. google-cloud-dialogflow-proto (proto def)
Otherwise, what would you suggest for creating services that interact with the google apis?


legend shadow

@Padanian you did an awesome job adding legend location functionality (#39). Do you think a shadow would be good to have too? We are already drawing a solid frame so it doesn't seem like it would be hard to implement... maybe just a bool to turn it on and off?
Let's make the shadow fall to the lower right so we don't have to go through the trouble of making a shadowLocation object :see_no_evil:
If you think it's over the top we can probably let it go. I just thought it might be a nice touch! It would take a few lines here:
https://github.com/swharden/ScottPlot/blob/dba76dd07a61f910c9d034b8b42474068733670a/src/ScottPlot/Renderer.cs#L167-L172
Some examples:
https://www.google.com/search?q=matplotlib+legend+shadow&tbm=isch

Sure! Not that complicated.  I'll give it a look
----- Messaggio Originale -----
Da: "swharden/ScottPlot"
A:"swharden/ScottPlot"
Cc:"Alessandro Mandelli" , "Mention"
Inviato:Mon, 22 Jul 2019 22:25:59 +0000 (UTC)
Oggetto:[swharden/ScottPlot] legend shadow (#45)
@Padanian [1] do you think this is worth implementing? We are already

drawing a solid frame so it doesn't seem like it would be hard to
implement... maybe just a bool to turn it on and off?
Let's make the shadow fall to the lower right so we don't have to go

through the trouble of making a shadowLocation object 🙈
If you think it's over the top we can probably let it go. I just

thought it might be a nice touch! It would take a few lines here:
https://github.com/swharden/ScottPlot/blob/dba76dd07a61f910c9d034b8b42474068733670a/src/ScottPlot/Renderer.cs#L167-L172
[2]
Some examples:

https://www.google.com/search?q=matplotlib+legend+shadow&tbm=isch [3]
—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [4], or mute the
thread [5]. [ { "@context": "http://schema.org", "@type":
"EmailMessage", "potentialAction": { "@type": "ViewAction", "target":
"https://github.com/swharden/ScottPlot/issues/45?email_source=notificationsu0026email_token=AB3I2BGB2V446OYY4ZMLZN3QAYXW7A5CNFSM4IF5QOKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HAYPOYQ",
"url":
"https://github.com/swharden/ScottPlot/issues/45?email_source=notificationsu0026email_token=AB3I2BGB2V446OYY4ZMLZN3QAYXW7A5CNFSM4IF5QOKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HAYPOYQ",
"name": "View Issue" }, "description": "View this Issue on GitHub",
"publisher": { "@type": "Organization", "name": "GitHub", "url":
"https://github.com" } } ]
Links:
[1] https://github.com/Padanian
[2]
https://github.com/swharden/ScottPlot/blob/dba76dd07a61f910c9d034b8b42474068733670a/src/ScottPlot/Renderer.cs#L167-L172
[3]
https://www.google.com/search?q=matplotlib+legend+shadow&tbm=isch
[4]
https://github.com/swharden/ScottPlot/issues/45?email_source=notifications&email_token=AB3I2BGB2V446OYY4ZMLZN3QAYXW7A5CNFSM4IF5QOKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HAYPOYQ
[5]
https://github.com/notifications/unsubscribe-auth/AB3I2BEYUUABIUI4BCPM6GTQAYXW7ANCNFSM4IF5QOKA

Pull request submitted.

referencing pull https://github.com/swharden/ScottPlot/pull/46 - Thanks @Padanian you work so fast!
I glanced over it and it it looks perfect. I lol'd when I saw you implemented dropShadowDirection - icing on the cake! I'll review and merge in the next day or two. Thanks again!

This shadow looks great! Totally worth it. Should it be on by default?

with shadow
without shadow

Thanks again @Padanian this looks great https://github.com/swharden/ScottPlot/pull/46

Thanks. Your appreciation is valuable to me.
----- Messaggio Originale -----
Da: "swharden/ScottPlot"
A:"swharden/ScottPlot"
Cc:"Alessandro Mandelli" , "Mention"
Inviato:Tue, 23 Jul 2019 21:25:14 +0000 (UTC)
Oggetto:Re: [swharden/ScottPlot] legend shadow (#45)
This shadow looks great! Totally worth it. Should it be on by

default?
	WITH SHADOW
	WITHOUT SHADOW

	 [1]
	 [2]

—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [3], or mute the
thread [4]. [ { "@context": "http://schema.org", "@type":
"EmailMessage", "potentialAction": { "@type": "ViewAction", "target":
"https://github.com/swharden/ScottPlot/issues/45?email_source=notificationsu0026email_token=AB3I2BGDUW4TTMJ3U2OWHPLQA5ZLFA5CNFSM4IF5QOKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UPNYQ#issuecomment-514389730",
"url":
"https://github.com/swharden/ScottPlot/issues/45?email_source=notificationsu0026email_token=AB3I2BGDUW4TTMJ3U2OWHPLQA5ZLFA5CNFSM4IF5QOKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UPNYQ#issuecomment-514389730",
"name": "View Issue" }, "description": "View this Issue on GitHub",
"publisher": { "@type": "Organization", "name": "GitHub", "url":
"https://github.com" } } ]
Links:
[1]
https://user-images.githubusercontent.com/4165489/61748644-c3882c80-ad6e-11e9-9420-03a6d18cadfc.png
[2]
https://user-images.githubusercontent.com/4165489/61748635-bff4a580-ad6e-11e9-8289-412ee65bc057.png
[3]
https://github.com/swharden/ScottPlot/issues/45?email_source=notifications&email_token=AB3I2BGDUW4TTMJ3U2OWHPLQA5ZLFA5CNFSM4IF5QOKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UPNYQ#issuecomment-514389730
[4]
https://github.com/notifications/unsubscribe-auth/AB3I2BHTYNIK765CERADLVDQA5ZLFANCNFSM4IF5QOKA

The setting is there, with a default value, but besides that nothing is done with it:
https://github.com/swharden/ScottPlot/blob/4b48e577ed30436657c76a812c07bfb452471016/src/ScottPlot/Plot/Plot.Legend.cs#L19
I noticed this while setting the background of the legend (semi)transparent. Then you see the shadow rectangle and cannot turn it off:


Error in visualizing/saving NKSR mesh

Hi, getting this error from pycg when trying to visualize/save NKSR mesh.
AttributeError: 'NoneType' object has no attribute 'convert_from_pinhole_camera_parameters'
Installed the full pycg with the command: pip install -U python-pycg[full] -f https://pycg.s3.ap-northeast-1.amazonaws.com/packages/index.html

Hi could you try disabling the visualization (i.e. remove show_3d) and just save the mesh? Maybe you are using a remote server and don't have X11 access.

You are right, saving mesh is working. Thank you for your response and the splendid work.


Added Faculdade CENSUPEG

Site
www.censupeg.com.br
Landing page course with one year or more
https://www.censupeg.com.br/academy/home/course/web-development/127

@marcelocensupeg Thank you for your patience while waiting for a review and processing your request. Pull request merged.


[SPARK-23952] remove type parameter in DataReaderFactory

What changes were proposed in this pull request?
This API change is inspired by the problems we meet when migrating streaming and file-based data sources to the data souce v2 API.
For the streaming side, we need a variant of the DataReader/WriterFactory(see an example). This brings a lot of trouble for scanning/writing optimized data format like InternalRow, ColumnarBatch, etc.
These special scanning/writing interfaces are defined like
interface SupportsScanColumnarBatch {
  List<DataReaderFactory<UnsafeRow>> createUnsafeRowReaderFactories();
}

This can't work with ContinuousDataReaderFactory at all, or we have to do runtime type cast and make the variant extends DataReader/WriterFactory. We have the same problem on the write path too.
For the file-based data source side, we have a problem with code duplication. Let's take ORC data source as an example. To support both unsafe row and columnar batch scan, we need something like
class OrcUnsafeRowDataReader extends DataReader[UnsafeRow] {
  ...
}

class OrcColumnarBatchDataReader extends DataReader[ColumnarBatch] {
  ...
}

class OrcUnsafeRowFactory(...) extends DataReaderFactory[UnsafeRow] {
  def createDataReader ...
}

class OrcColumnarBatchFactory(...) extends DataReaderFactory[ColumnarBatch] {
  def createDataReader ...
}

class OrcDataSourceReader extends DataSourceReader {
  def createUnsafeRowFactories = ... // logic to prepare the parameters and create factories

  def createColumnarBatchFactories = ... // logic to prepare the parameters and create factories
}

You can see that we have duplicated logic for preparing parameters and defining the factory. After this change, we can simplify the code to
class OrcReaderFactory(...) extends DataReaderFactory {
  def createUnsafeRowReader ...

  def createColumnarBatchReader ...
}

class OrcDataSourceReader extends DataSourceReader {
  def createReadFactories = ... // logic to prepare the parameters and create factories
}

The proposed change is: remove the type parameter and embed the special scanning/writing format to the factory. e.g.
interface DataReaderFactory {
  DataFormat dataFormat;

  default DataReader<Row> createRowDataReader() {
    throw new IllegalStateException(
      "createRowDataReader must be implemented if the data format is ROW.");
  }

  default DataReader<UnsafeRow> createUnsafeRowDataReader() {
    throw new IllegalStateException(
      "createUnsafeRowDataReader must be implemented if the data format is UNSAFE_ROW.");
  }

  default DataReader<ColumnarBatch> createColumnarBatchDataReader() {
    throw new IllegalStateException(
      "createColumnarBatchDataReader must be implemented if the data format is COLUMNAR_BATCH.");
  }
}

A potential benefit after this change: now it's up to the factory to decide which data format to use(UnsafeRow, ColumnarBatch, etc.). Which means, it's possible to allow different data partitions to be scanned with different formats. Some hybrid storage may keep realtime data in row format, and history data in columnar format, and it can fit the new API well.
TODO:
apply this change to the write path(next PR)
How was this patch tested?
existing tests

cc @rxin @jose-torres @rdblue @gengliangwang

Test build #89133 has started for PR 21029 at commit d44105d.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2162/
Test FAILed.

Test build #89133 has finished for PR 21029 at commit d44105d.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89133/
Test FAILed.

+1
From the PR #20933, we can see that there is a lot of common code between DataReaderFactory[ColumnarBatch] and DataReaderFactory[UnsafeRow], if we use the current method factory pattern.
This change makes data source implementation easier, and we don't need to do runtime type cast.

Test build #89400 has started for PR 21029 at commit dac302f.

Test build #89400 has finished for PR 21029 at commit dac302f.

This patch fails RAT tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89400/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2347/
Test PASSed.

Test build #89401 has started for PR 21029 at commit 556eef2.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2348/
Test PASSed.

Test build #89430 has started for PR 21029 at commit 36031f2.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2372/
Test PASSed.

Merged build finished. Test PASSed.

Test build #89430 has finished for PR 21029 at commit 36031f2.

This patch fails to generate documentation.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89430/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2377/
Test PASSed.

Test build #89436 has finished for PR 21029 at commit b5c3b39.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89436/
Test PASSed.

Test build #89458 has started for PR 21029 at commit c5071b4.

Test build #89461 has started for PR 21029 at commit 1ae4b6d.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2396/
Test PASSed.

Test build #89461 has finished for PR 21029 at commit 1ae4b6d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89461/
Test FAILed.

Test build #89482 has started for PR 21029 at commit 18e391a.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2414/
Test FAILed.

Test build #89482 has finished for PR 21029 at commit 18e391a.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89482/
Test FAILed.

retest this please

Test build #89490 has started for PR 21029 at commit 18e391a.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2423/
Test PASSed.

Merged build finished. Test PASSed.

Test build #89490 has finished for PR 21029 at commit 18e391a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89490/
Test FAILed.

Merged build finished. Test FAILed.

retest this please

Test build #89505 has started for PR 21029 at commit 18e391a.

Test build #89505 has finished for PR 21029 at commit 18e391a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89505/
Test PASSed.


Bump required version of setuptools to 57.5.0

It shouldn't introduce any breaking changes from the currently supported 57.4.x.

@edgarrmondragon, thank you for your suggestion. We have bumped setuptools to the latest version 60.3.1, tested it and released it.

Thank you @RuslanBergenov!


RTC Question.

Maybe this is a silly question, but how do I test RTC? Can I use RTC with Minimig core? If not, what is the use case?
Cheers,
Ranko

To test and configure RTC you can use "DATE & TIME" menu entry by F12 key.
RTC is supported at least in Minimig, ZX Spectrum Next, MSX cores, possibly in others.

Works! Thank you Eugene.


[Question] Gatus Metrics for Prometheus

Describe the feature request
Hi!
I have been reading through your documentation https://github.com/TwiN/gatus#metrics and checked out your example https://github.com/TwiN/gatus/tree/master/.examples/docker-compose-grafana-prometheus
Thank you for taking the time to make these, it saves me a lot of time and get a better understanding of your metrics.
I am wondering if there is a method to show just the 'latest' state in grafana using these metrics.
I have tried using gatus_results_code_total and gatus_results_total but they both return all occurences of a fail/succeeded request or status code with the number of times it has happened.
Would it be an option to add a metric that just returns the statuscode as the value? Or is there another way to achieve this?
Why do you personally want this feature to be implemented?
It would be nice to have all my alerting go through grafana an currently the 'latest state' alerting goes through gatus still
How long have you been using this project?
1 year
Additional information
If desired and not possible yet I could help out with the initial PR :)

Ah nevermind!
After checking your screenshot I noticed you have 6 charts but only wrote down 5 below it!
The one i was missing was successrate.
https://github.com/TwiN/gatus/tree/master/.examples/docker-compose-grafana-prometheus
So i added the following query, and interpeted it as 0 = all retries failed (not 200)
sum(rate(gatus_results_total{success="true"}[120s])) by (key) / sum(rate(gatus_results_total{}[120s])) by (key)


Promise rejection with await not throwing UnhandledPromiseRejectionWarning

Prerequisites

[x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
[x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[ ] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[ ] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend avoiding the use of globally installed Mocha.

Description
const someFn = async () => {
  throw new Error(`I'm an error!`)
}

describe('someFn', () => {
  it('should result in UnhandledPromiseRejection', async () => {
    await someFn()
  })
})

In the above code, if try/catch is not used in the test I would expect an UnhandledPromiseRejection to be logged in the console, but instead, the error is. Trying to understand why. Maybe this is a duplicate of #2640 ? Couldn't quite tell.
Expected behavior: expect an UnhandledPromiseRejection to be logged in the console
Actual behavior: error is logged, without UnhandledPromiseRejection
Versions

The output of mocha --version and node node_modules/.bin/mocha --version: 4.1.0
The output of node --version: 10.0.0
The version and architecture of your operating system: OS X 10.10.5
The code transpiler being used: none

It's not unhandled because the Promise returned by your test is then caught and eaten by Mocha.  It's considered a test failure.


Automatically implement from using default

Via an attribute ?

The idea would be to do
struct FooV0 {
    name: String,
}

#[derive(Deserialize)]
#[versioning(from_default, previous_version = "FooV0")]
struct FooV1 {
    name: String,
    age: u8,
}

and get the Deserialize impl generated as well as a
impl From<FooV0> for FooV1 {
    fn from(value: FooV0) -> Self {
       /* insert all fields from value */
        ..Default::default()
    }
}

unfortunately
impl From<FooV0> for FooV1 {
    fn from(value: FooV0) -> Self {
        ..value,
        ..Default::default()
    }
}

Isn't valid rust.

Would probably only be available for structs 🤔

don't think its possible, at least with my current knowledge
Best i could get was to generate
impl From<FooV2> for Foo {
    fn from(value: FooV2) -> Self {
        Self {
            name: value.name,
            age: value.age,
            place_holder: value.place_holder,
            ..Default::default()
        }
    }
}

but this is generated from the fields of Foo, not FooV2, so I assign place_holder which doesn't exist on FooV2 => error.
Try is here : https://github.com/vic1707/serde-versioning/commit/0c5e5c27e73ee3742ccebeac1e2a662818918296

https://docs.rs/serde-reflection/latest/serde_reflection/
Might help ?


Update how-to-enable-nested-virtualization-template-vm-using-script.md

added workaround to avoid a known issue using Server Manager, WAC or PowerShell Add-WindowsFeature to enable Hyper-V on a nested virtual machine

#assign-reviewer: @EMaher

Dear @ntrogh thank you for your concern and attention.
Intentionally added this to the User guidance  to prevent known limitations of the instructions below.
It can be checked if the PowerShell script does handle it, albeit this is added to avoid the error that Hyper-V will not install on nested virtualization.
Do you have any questions or improvements on the content and wording?

@Karl-WE
I agree with @ntrogh .  These changes should NOT be added to the official docs.  All the docs say is "go run this script over there". Adding this warning to the docs will cause unnecessary confusion.
I think a better way to proceed would be to update the script itself on GitHub.  File being executed is https://github.com/Azure/LabServices/blob/main/ClassTypes/PowerShell/HyperV/SetupForNestedVirtualization.ps1.
Looking at the code we are already calling Enable-WindowsOptionalFeature for Win10 and Install-WindowsFeature only on server OSes and only after we check the feature is available.   Please log a GitHub issue with changes you would like to see and I'll take care of it ASAP.  (Or you can submit PR directly to Azure/LabService repo and I can review.  Whatever is easiest for you.)
Thanks,
Elizabeth

Kindly request to add Hyper-V role via Server Manager in a nested virtualized machine.
You will receive an error because the underlying Add-WindowsFeature will terminate because of a prerequisite check.
Unfortunately this guidance here
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization
does not mention how to install the Hyper-V role, just how to satisfy the requirements on the VM.
Using Server Manager or Add-WindowsFeature won't work to install the Hyper-V role in the nested VM. That's what I received from the Windows Server team.

In contrary it's crucial to understand that no matter Windows Server or Windows Client OS, in both cases only Add-WindowsOptionalFeature will deliver the expected results in a nested virtualized machine.
Do you have any questions on this? I am trying to find a cite but this might take a while.

Here's the trusted source. Mind that this has not changed and is not release related.
This behaviour is by design and affecting Windows Server 2012 or later including derivats as Azure Stack HCI.
https://techcommunity.microsoft.com/t5/windows-server-insiders/b25110-enabling-nested-virtualization-will-only-be-visible-in/m-p/3403652/highlight/true#M2571

Dear @ntrogh @EMaher have you had time to consider the additional reference and implications on this PR? Thank you very much in advance!

Yes,  I've created at GH issue to track changing the script and adding explanation of using one cmdlet over the other.  See https://github.com/Azure/LabServices/issues/25.

Thank you very much for your initiative and appreciation.
Would you be fine to accept a middle way?
Removing my PR and update it with an infobox that enabling might fail and refer to the alternative (Script)
I am not sure about the Syntax to create this box, but could update my PR with your help.

@Karl-WE Apologies for the delay (back from holidays). I've gone through the UI steps for enabling nested virtualization and was successful. Isn't the issue you refer to already tackled because in Azure Lab Services we require that you use the specific nested virtualization VM sizes (see important message at top of article)?
@EMaher can you confirm?

Maybe they have changed something in the code (blocker mentioned by Andrei in the linked post).

@Karl-WE We'll be updating the PowerShell script in our other repo. As for the UI-based instructions, I suggest we keep them as-is. Thanks a lot for bringing this to our attention! Very much appreciated 🙏.
cc @EMaher

Thank you both for your time and revealing that the blocker that existed in the Server Manager based commandlet, have been resolved. I appreciate your cooperation.
This PR can be closed.


voice issue

I can see video only i can't listen voice.

project is out of date. I do not have time maintain it.


filter out duplicate messages 2

ref: #6490
#6491 failed due The keyword 'const' is reserved (174:6) !!??
Changed to var

You don't need to open a new pull request. Just git push to the old one.

I don't develop on Github so I don't know about git push :(

Addons need to run as-is on IE9, so that indeed means no const. But the includes method is also not available there, so you'd have to indexOf instead and compare the result to -1.
Updating the branch that the PR refers to updates the PR, so indeed, there's not need to open new ones to add or change patches.

Thanks @marijnh for the explanation. Updated the code to use indexOf

Thanks. Merged!

@marijnh I was thinking, is arrow function supported or should it be changed to normal function?
e.g.
anns = anns.filter(item => message.indexOf(item.message) > -1 ? false : message.push(item.message));

Should it be changed to?
anns = anns.filter(function(item) {return message.indexOf(item.message) > -1 ? false : message.push(item.message);});

Yes, it should. I've done so in 4f37b1e9


adjustable delay before getting next song

User should be able to adjust the delay for when the system retrieves the next song from the server.

Hard coded delay has been configured. If issues are reported with delay time, then adjustable delay can be implemented.


[Bug]: User Settings Region Lookup does not preselect current setting (like Language Lookup does) Fixes #351

[Bug]: User Settings Region Lookup does not preselect current setting (like Language Lookup does) #351
Fixes #351
Internal work item: AB#494608

That looks like a "no brainer" to me. Approved. I will run the CI pipeline now and then we're ready to merge!


Generate names for destructuring closure params

This PR generates parameter names for destructured patterns, as shown below.
#let foo((x, y, _, ..z)) = [ #x #y #z ]
#foo((1, 2, 3, 4, 5, 6))

Seems like we just work around the problem by stringifying the entire pattern, but it is totally fine currently since we haven't done anything with binding names in patterns. I would like to test whether it works well with textDocument/signatureHelp before merging.

🚀


Object detection 2D: GemLearner

This PR concerns the GemLearner, a multimodal 2d object detection learner. Note that this learner requires the DetrLearner from #107 as a baseline. Therefore I suggest that #107 should be reviewed first before reviewing this PR.

Please let us know when this PR is ready for review.


[Bug]: User interface views need sender returned in new "process_message_before_send" hook

Describe the bug
User interfaces for chat-like experience need to know what the sender is in the new "process_message_before_send" hook (PR #1783). Having the recipient is good but not enough. This is a very simple fix -- just pass "self" as the sender in ConversableAgent._process_message_before_send().
Steps to reproduce
No response
Expected Behavior
No response
Screenshots and logs
No response
Additional Information
No response

Thanks. Adding sender in the hook is good. Would you like to make a PR?

Thanks. Adding sender in the hook is good. Would you like to make a PR?

@sonichi I would like to open the PR against this issue. Thanks!


test: find and replace "localhost" with "<IP_ADDRESS>" in *.test.ts files

I kept it as simple as possible to make this easier to review because
it will be a huge diff even with this simplified approach (e.g.
I did not do a full text search all kinds of files, just the ones
that match *.test.ts)
Reasoning: "localhost" can default to ::1 in IPv6 environments
but that is often broken in NodeJS >=18 (or maybe it's something
else that is broken but nevertheless this is the fix) so it's
prudent to explicitly hardcode the IPv4 localhost which is
"<IP_ADDRESS>"
[skip ci]
Signed-off-by: Peter Somogyvari<EMAIL_ADDRESS>
Pull Request Requirements

[x] Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
[x] Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
[x] Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

[x] Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
[x] Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

@petermetz I've already updated localhost references to explicit <IP_ADDRESS> in my node upgrade PR here - #2879, is it urgent or can we just wait for my PR to get merged?

@outSH Oh no, I'm so sorry for the front-running, I just forgot that we had talked about this already and you said you'll send a PR! Closing! :-)


feat: add -all flag to generate docs for all types

If -all flag is present, the tool will generate documentation file with multiple sections for each type with environment variables tags.

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


only write to s3 if data has changed

Updated requirement - it is not necessary to retain all downloads indefinitely - only write download to s3 if something has happened.
A file structure something like this should work:
/MVRD/surrey/<layer>.gdb.zip
/MVRD/surrey/<layer>_changes/<layer>.gdb.zip
/MVRD/surrey/<layer>_changes/change_report.xlsx
/MVRD/surrey/<layer>_changes/change_report.gdb.zip

within the changes folder:

save spatial diffs - additions, deletions, 3 types of modifications (geometry change only, attribute change only, attribute and geometry change)
for attribute changes, generate a diff
summarize changes in csv/xls/etc with filename like <layer>_change_summary, having keys:

record_count_old
record_count_new
record_count_difference
record_count_difference_pct
n_unchanged
n_deletions
n_additions
n_modified
n_modified_spatial_only
n_modified_spatial_attributes
n_modified_attributes_only


Prevent vertical scroll when interacting with custom view

After some experimental test, i found the following code will prevent vertical scroll when touching the Croller.
 @Override     public boolean dispatchTouchEvent(MotionEvent event) {         if (getParent() != null && event.getAction() == MotionEvent.ACTION_DOWN) {             getParent().requestDisallowInterceptTouchEvent(true);         }         return super.dispatchTouchEvent(event);     }

Thanks for the input, I have updated the code to pass all touch events outside the progress circle to the parent and whenever the touch events are within the progress circle, the parent is not allowed to intercept the touch events as per your code. Cheers!


a problem about video_player in  IOS

Hello, after I packaged in Flutter Web, there was no problem in Android terminal, but the video could not be played when I accessed it in the browser of iOS terminal, so I could not get the video.I use Chewie and Video_Player.

// 视频部分
class VideoLook extends StatefulWidget {
final String url;
final List mediaEntityList;
VideoLook({this.url,this.mediaEntityList});
@override
_VideoLookState createState() => _VideoLookState();
}
class _VideoLookState extends State {
VideoPlayerController _controller;
@override
void initState() {
super.initState();
// 在初始化完成后必须更新界面
_controller = VideoPlayerController.network("${widget.url}",videoPlayerOptions: VideoPlayerOptions(mixWithOthers: true));
_controller.initialize()..whenComplete(() {
setState(() {});
});
}
@override
void dispose() {
_controller.dispose();
super.dispose();
}
@override
Widget build(BuildContext context) {
return Row(
mainAxisAlignment: MainAxisAlignment.start,
children: [
Container(
color: Colors.black87,
alignment: Alignment.centerLeft,
width: 150.0,
constraints: BoxConstraints(
maxHeight: 240
),
child: Stack(
alignment: Alignment.centerLeft,
children: [
ClipRRect(
borderRadius: BorderRadius.circular(6),
child: VideoPlayer(_controller)
),
Positioned(
left: 0,
right: 0,
top: 0,
bottom: 0,
child: InkWell(
child: Container(
child: Icon(Iconfont.pause,color: Colors.white,size: 46,)
),
onTap: () async{
MediaPickerViewer.pushToViewer(context, previewAssets: widget.mediaEntityList,themeData: AssetPicker.themeData(Colours.high_color),currentIndex: 0);
},
)
),
],
),
)
],
) ;
}
}

IOS在web端无法播放

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


pygls > 1.0.x breaks version checks

pygls 1.1  seems to have removed the __version__ attribute from the top-level module, which breaks the validation code.

Checking versions for python 3.7+ is annoying due to the lack of importlib.metadata in python 3.7.
If you switch this to python 3.8+ you can use importlib.metadata instead. For python 3.7+ you could use importlib_metadata from spacy.compat. You'd have to refactor the version checking code a bit to import spacy first/separately.

So a "quick fix" would be to install pygls>=1.0.0,<1.1.0.
But as Python 3.7 and 3.8 have reached their EOL is supporting them in this extension still an issue?
If not do you accept pull requests in this repo?


Clean URL links on proposal comments

Referencing #851 ( #858 ) where clean URL links to proposals were fixed, this also needs to be applied to proposal comments.
Right now they still point to the the long URL.
For example, the share URL for the below comment:

It currently points to the long URL:
https://near.social/devhub.near/widget/app?page=proposal&id=146&accountId=gagdiez.near&blockHeight=123000964
Originally posted by @ori-near in https://github.com/NEAR-DevHub/neardevhub-bos/issues/858#issuecomment-2218290061

@ori-near See a preview in the Pull Request: https://github.com/NEAR-DevHub/neardevhub-bos/pull/868


chore(build): bump toolchain to 2022-06-09

What's changed and what's your intention?
As title
Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Refer to a related PR or issue link (optional)
close https://github.com/singularity-data/risingwave/issues/3105

Need to rebuild CI image before merging

This PR also upgrades sqllogictest to v0.5


Collecting rewritten Fortran modules

Attempting to gather up and connect all Fortran modules rewritten to Python.
For now, only for spherical geometry.
Used PRs: https://github.com/wolvespack/alcor/pull/42, https://github.com/wolvespack/alcor/pull/17, https://github.com/wolvespack/alcor/pull/20, https://github.com/wolvespack/alcor/pull/21, https://github.com/wolvespack/alcor/pull/22, https://github.com/wolvespack/alcor/pull/23, https://github.com/wolvespack/alcor/pull/24

That was a bad idea. We will merge everything here: https://github.com/wolvespack/alcor/pull/12


No Content Page for "Contribute" and "Learn"

Bug Report
Issue Summary
There is no content page for "Contribute" and "Learn"
A summary of the issue.
Expected Behavior
There should have a Page with content for "Contribute" and "Learn" respectively
Observed Behavior
There is no content page for "Contribute" and "Learn"
Steps to Reproduce

Goto https://elevate-lab.github.io/elevate-lab-website/index.html
Click on "Contribute" and "Learn"

Screenshots (if any)

can i add a page with content learn?

Hi, I would like to work on this issue.

Closing due to inactivity.


Typo in specification of 'range' node?

The spec says:

range: remap incoming values from one range of float/color/vector values to another, optionally applying a gamma correction "in the middle". Input values below inlow or above outhigh are extrapolated unless doclamp is true.

I think it should say that input values below outlow are extrapolated.

@pablode Agreed that we should use one convention consistently here, and I believe another way of stating this would be:

Input values below inlow or above inhigh are extrapolated unless doclamp is true.

CC'ing @dbsmythe for his thoughts as well.

I think the intended wording should be "Input values below inlow or above inhigh are extrapolated unless doclamp is true."  E.g. if an input value is between inlow and inhigh, no clamping will take place, while if it's less than inlow or greater than inhigh, then the remapped output would be less than outlow or greater than outhigh, but the doclamp would clamp the output to stay within the outlow..outhigh range.  I will update the spec to say that; I'm pretty sure the nodegraph implementation is correct but we should verify.

@pablode @dbsmythe Here's the latest language proposed for the MaterialX 1.39 specification, and feel free to suggest any additional improvements here:
range: remap incoming values from one range of float/color/vector values to another, optionally applying a gamma correction "in the middle".  Input values below inlow or above inhigh are extrapolated unless doclamp is true, in which case the output values will be clamped to the outlow..outhigh range.
- in (float or colorN or vectorN): the input value or nodename
- inlow (same type as in or float): low value for input range.  Default is 0.0 in all channels.
- inhigh (same type as in or float): high value for input range.  Default is 1.0 in all channels.
- gamma (same type as in or float): inverse exponent applied to input value after first transforming from inlow..inhigh to 0..1; gamma values greater than 1.0 make midtones brighter.  Default is 1.0 in all channels.
- outlow (same type as in or float): low value for output range.  Default is 0.0 in all channels.
- outhigh (same type as in or float): high value for output range.  Default is 1.0 in all channels.
- doclamp (boolean): If true, the output is clamped to the range outlow..outhigh.  Default is false.

@pablode @dbsmythe Now that the 1.39 specification is maintained directly in the MaterialX repository, I'll close out this original issue, since improvements can be proposed directly to the text.


”Terebești”, ”Aliza”, ”Gelu”, ”Pișcari” are listed in the drop-down menu

Description:
When user writes ”Terebești”, ”Aliza”, ”Gelu”, ”Pișcari” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Terebești"

Expected results
The location appears in the drop-down menu as "Sat Terebești, SATU MARE (Terebești)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Gelu"

Expected results
The location appears in the drop-down menu as "Sat Gelu, SATU MARE (Terebești)".

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Write in the search bar "Pișcari"

Expected results
The location appears in the drop-down menu as "Sat Pișcari, SATU MARE (Terebești)".


Slurm Autorequeue Doesn't Work for Job Arrays

Bug description
It looks like the slurm auto-requeue doesn't work right when a job is part of a job array. I started noticing weird bugs where my jobs would ask to requeue at "weird" times or they would "fail to requeue" but then mysteriously restart or they wouldn't requeue at all. The common thread is that I was using job arrays to manage a batch of related experiments automatically.
It looks like when this happens you need to make sure you tell scontrol to requeue the specific array job which can be found with the environment variables SLURM_ARRAY_JOB_ID and SLURM_ARRAY_TASK_ID so you would do something like scontrol requeue $SLURM_ARRAY_JOB_ID_$SLURM_ARRAY_TASK_ID. What lightning was doing was requeueing the entire job which was trying to get both of the jobs in the array back on the queue and causing weird issues.
Fixing this seems to be really simple, just detect if those array variables are set and make a different call to scontrol. I will PR this ASAP because it's suddenly become mission critical for me (long story), what is your deadline for getting a feature into 1.8?
ref
https://github.com/facebookincubator/submitit/blob/main/submitit/slurm/slurm.py#L187
https://github.com/facebookincubator/submitit/blob/4cf1462d7216f9dcc530daeb703ce07c37cf9d72/submitit/slurm/slurm.py#L192
https://github.com/facebookincubator/submitit/blob/4cf1462d7216f9dcc530daeb703ce07c37cf9d72/submitit/core/job_environment.py#L82
https://github.com/Lightning-AI/lightning/blob/master/src/pytorch_lightning/trainer/connectors/signal_connector.py#L82
How to reproduce the bug
* Try to run an array job using lightning and with autorequeue enabled
* Wait a while, if you're unlucky weird stuff will happen

Error messages and logs
No response
Environment

#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow):
#- PyTorch Lightning Version (e.g., 1.5.0): 1.8.0.dev0 (built myself from master)
#- Lightning App Version (e.g., 0.5.2):
#- PyTorch Version (e.g., 1.10): 1.12.1+cu116
#- Python version (e.g., 3.9): 3.8.10
#- OS (e.g., Linux): Linux
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(`conda`, `pip`, source):
#- Running environment of LightningApp (e.g. local, cloud):

More info
No response

Additional ref: https://slurm.schedmd.com/job_array.html#scontrol

Hey @Queuecumber. Great catch !
Would you be interested to make a contribution with a fix ?

I will PR this ASAP because it's suddenly become mission critical for me (long story), what is your deadline for getting a feature into 1.8?

I will try to do this tomorrow depending on my availability, if it doesn't happen tomorrow it would have to be on Tuesday

I'll try to get to this tomorrow but if it doesn't happen then it will have to be Tuesday

I found time to do it tonight, will test on a real cluster some time this weekend, please take a look when you can


how to change cell value of dynamic column

i added custom column to ag-grid like this
 this.columnDefs.push( {headerName: "Action Status", cellStyle:{"text-align":"center"}});
how to change a cell value of this column in runtime ?
i tried this solution but not work
this.gridOptions.api.forEachNodeAfterFilterAndSort(function (rowNode:RowNode) {
   rowNode.columnController.originalColumns[1].colDef.headerCellTemplate="test"

});

      this.gridOptions.api.softRefreshView();
        this.gridOptions.api.refreshView();

the answer
first put the field name like this
 this.columnDefs.push(
            {headerName: "Action Status",field:"actionStatus", cellStyle:{"text-align":"center"} })

-set new value like this
this.gridOptions.api.forEachNodeAfterFilterAndSort(function (rowNode:RowNode) {

            rowNode.setDataValue("actionStatus","the new value") ... ... ...


[Feature] alloy_rpc_types::eth::log::Log and Log have similar names, but are actually distinct types

Component
contract, network, json-rpc
Describe the feature you would like
Hello,
When we get logs from TransactionReceipt It gives us a log that has the type:
alloy_rpc_types::eth::log::Log
But when we want to decode the log using an abi, it asks for a alloy_primitives::Log instead

Example code to illustrate this problem
use std::env;

use alloy_primitives::{address, b256, utils::format_ether, Address, B256};
use alloy_provider::{Provider, ProviderBuilder};
use alloy_sol_types::{sol, SolEvent};
use eyre::Result;
use IERC20::Transfer;

const WETH: Address = address!("C02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2");

// Transfer topic:
// https://etherscan.io/tx/0xd183a55586addbce7a6c1e3849d495a8dca5a0c8d5f96e876d25dc50bd97c27a#eventlog
const TRANSFER_TOPIC: B256 =
    b256!("ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef");

sol!(
    #[sol(rpc)]
    IERC20,
    "src/abi/IERC20.json"
);

// We know that at least one WETH transfer hapenned at this block:
// https://etherscan.io/tx/0xd183a55586addbce7a6c1e3849d495a8dca5a0c8d5f96e876d25dc50bd97c27a
const BLOCK: u64 = 19633475;

#[tokio::main]
async fn main() -> Result<()> {
    let http_rpc = env::var("HTTP_RPC")?.parse()?;
    let provider = ProviderBuilder::new().on_http(http_rpc)?;
    let receipts = provider
        .get_block_receipts(BLOCK.into())
        .await?
        .expect(&format!("Block {BLOCK} should already exists"));

    for receipt in receipts {
        for log in receipt.inner.logs() {
            if log.address() == WETH {
                if log.topics()[0] == TRANSFER_TOPIC {
                    // here got error: `alloy_rpc_types::eth::log::Log` and `Log` have similar names, but are actually distinct types
                    let transfer = Transfer::decode_log(log, true)?;
                    println!(
                        "{:?} has transfered {} ETH at transaction {:?} to {:?}",
                        transfer.data.src,
                        format_ether(transfer.data.wad),
                        receipt.transaction_hash,
                        transfer.data.dst
                    );
                }
            }
        }
    }

    Ok(())
}

The current workaround is to manually convert:
let log_primitive = Log::new(
    log.address(),
    log.topics().to_vec(),
    log.data().data.clone(),
)
.unwrap();

But that is not very user friendly
#50 should have given a cleaner workaround but I was not able to use it in the latest branch.
I also have a question about this:
I think there is a good reason behind it, but why are there two different Log that exists:
alloy_rpc_types::eth::log::Log and alloy_primitives::Log?
Additional context
I placed my issue in features because I think that adding an easy way to convert from the two different log instance could be helpful

you should be able to do let transfer = Transfer::decode_log(log.as_ref(), true)?;
I agree the naming can be confusing,
perhaps we should consider renaming the rpc log type LogReceipt or something?

is there a reason that you're not usinglog.log_decode<Transfer>() to manage decoding?

@mattsse I would prefer RpcLog and RpcReceipt to differentiate

Thanks, I didn't found these methods for converting a log, they are way better. I will write an example for these if I have time.
Also why can't RPC directly use the alloy_primitives::Log?

Also why can't RPC directly use the alloy_primitives::Log?

Because the RPC Log contains a lot of metadata not found in the consensus Log


why it's not working in laravel 7.0  version

It gives a lots of issues
Problem 1
- mongodb/mongodb 1.6.0 requires ext-mongodb ^1.7 -> the requested PHP extension mongodb is missing from your system.
- mongodb/mongodb 1.6.0 requires ext-mongodb ^1.7 -> the requested PHP extension mongodb is missing from your system.
- mongodb/mongodb 1.6.0 requires ext-mongodb ^1.7 -> the requested PHP extension mongodb is missing from your system.
- Installation request for mongodb/mongodb (locked at 1.6.0, required as ^1.6) -> satisfiable by mongodb/mongodb[1.6.0].
To enable extensions, verify that they are enabled in your .ini files:
- C:\xampp\php\php.ini
You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.
Installation failed, reverting ./composer.json to its original content.
PS C:\xampp\htdocs\example> pecl install mongodb
^CTerminate batch job (Y/N)? y
PS C:\xampp\htdocs\example> composer require jenssegers/mongodb:dev-develop
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- mongodb/mongodb 1.6.0 requires ext-mongodb ^1.7 -> the requested PHP extension mongodb is missing from your system.
- mongodb/mongodb 1.6.0 requires ext-mongodb ^1.7 -> the requested PHP extension mongodb is missing from your system.
- mongodb/mongodb 1.6.0 requires ext-mongodb ^1.7 -> the requested PHP extension mongodb is missing from your system.
- Installation request for mongodb/mongodb (locked at 1.6.0, required as ^1.6) -> satisfiable by mongodb/mongodb[1.6.0].
To enable extensions, verify that they are enabled in your .ini files:
- C:\xampp\php\php.ini
You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.
Installation failed, reverting ./composer.json to its original content.

See https://github.com/jenssegers/laravel-mongodb/issues/1974

Check extension php -m

Check extension php -m
It's showing this

PS C:\xampp\htdocs\example> php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
SimpleXML
SPL
standard
tokenizer
wddx
xml
xmlreader
xmlwriter
zip
zlib
[Zend Modules]

@shailesh5152 install mongodb extension

@shailesh5152 install mongodb extension

I installed it
C:\Users\hp>php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mongodb
mysqli
but I am also facing same problem after entering this below command
composer require jenssegers/mongodb
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Conclusion: don't install jenssegers/mongodb v3.6.3
- Conclusion: don't install jenssegers/mongodb v3.6.2
- Conclusion: don't install jenssegers/mongodb v3.6.1
- Conclusion: remove laravel/framework v7.4.0
- Installation request for jenssegers/mongodb ^3.6 -> satisfiable by jenssegers/mongodb[v3.6.0, v3.6.1, v3.6.2, v3.6.3].
- Conclusion: don't install laravel/framework v7.4.0

See your composer.json, please

Show your composer.json, please

{
"name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
"framework",
"laravel"
],
"license": "MIT",
"require": {
"php": "^7.2.5",
"fideloper/proxy": "^4.2",
"fruitcake/laravel-cors": "^1.0",
"guzzlehttp/guzzle": "^6.3",
"laravel/framework": "^7.0",
"laravel/tinker": "^2.0",
"mongodb/mongodb": "^1.6"
},
"require-dev": {
"facade/ignition": "^2.0",
"fzaninotto/faker": "^1.9.1",
"laravel/ui": "^2.0",
"mockery/mockery": "^1.3.1",
"nunomaduro/collision": "^4.1",
"phpunit/phpunit": "^8.5"
},
"config": {
"optimize-autoloader": true,
"preferred-install": "dist",
"sort-packages": true
},
"extra": {
"laravel": {
"dont-discover": []
}
},
"autoload": {
"psr-4": {
"App\": "app/"
},
"classmap": [
"database/seeds",
"database/factories"
]
},
"autoload-dev": {
"psr-4": {
"Tests\": "tests/"
}
},
"minimum-stability": "dev",
"prefer-stable": true,
"scripts": {
"post-autoload-dump": [
"Illuminate\Foundation\ComposerScripts::postAutoloadDump",
"@php artisan package:discover --ansi"
],
"post-root-package-install": [
"@php -r "file_exists('.env') || copy('.env.example', '.env');""
],
"post-create-project-cmd": [
"@php artisan key:generate --ansi"
]
}
}

I'm getting the same issue although it looks like the package needs Laravel 5.8 to 6.8:

jenssegers/mongodb v3.6.0 requires illuminate/events ^5.8|^6.0 -> satisfiable by illuminate/events[5.8.x-dev, 6.x-dev, v5.8.0, v5.8.11, v5.8.12, v5.8.14, v5.8.15, v5.8.17, v5.8.18, v5.8.19, v5.8.2, v5.8.20, v5.8.22, v5.8.24, v5.8.27, v5.8.28, v5.8.29, v5.8.3, v5.8.30, v5.8.31, v5.8.32, v5.8.33, v5.8.34, v5.8.35, v5.8.36, v5.8.4, v5.8.8, v5.8.9, v6.0.0, v6.0.1, v6.0.2, v6.0.3, v6.0.4, v6.1.0, v6.10.0, v6.11.0, v6.12.0, v6.13.0, v6.13.1, v6.14.0, v6.15.0, v6.15.1, v6.16.0, v6.17.0, v6.17.1, v6.18.0, v6.18.1, v6.18.2, v6.18.3, v6.2.0, v6.3.0, v6.4.1, v6.5.0, v6.5.1, v6.5.2, v6.6.0, v6.6.1, v6.6.2, v6.7.0, v6.8.0].

Does anyone have a fork with Laravel 7 compatibility added that's ready to use right now and works with the 3.6 branch?

@vesper8 , we have using of 7 laravel in development branch, but we don't test on bugs and not implement new features

@Smolevich Any estimation when 4.0 will be released? Is it a week away? a month? more? Thanks

I'm having the same issue and this is as fur as I can get at the moment. There's no support for Laravel 7 apparently at the moment

@Smolevich Any estimation when 4.0 will be released? Is it a week away? a month? more? Thanks

We don't discuss about time new release

@Prince-254 you can use it with Laravel 7 if you change it to "jenssegers/mongodb": "dev-develop", in your composer.json
I've done this and haven't run into any issues yet.
On a side note, I've decided to abandon using MongoDB in my project alongside MySQL. It seemed like a good idea at the time but now that Mysql 5.7 / 8 has excellent support and performance dealing with and querying JSON fields, Laravel has built-in JSON field support inside Eloquent.. and Mysql now supports GeoSpatial queries.. it's no longer worth the extra overhead and complexity of supporting MongoDB both from a Laravel point of view and from a server deployment point of view. I ported my code to a pure MySQL solution in the last two days and it was surprisingly painless and simple. I thank the developers of this excellent package over the years, it's just no longer for me going forward.

you can use  "jenssegers/mongodb": "^4" in  Laravel 7


Python3.5 not working

Hi,sorry i am new to programming
I installed successfully pysnmp using pip install (4.4.12) but when using python2.7 i am able to import pysnmp.hlapi but not when using python 3.5 ...
Do you have some recommendation ?

Ok so i need pip3 to make it work with python version 3
Thanks!


renable some disabled pyright checks

Title says it all, pyright does not seem to create issues with those checks enabled

Never mind it does generate errors


Updates to Readme to clarify update flow

Issue #, if available:
Description of changes:
Made a couple small tweaks.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/retest-required

/override eks-distro-base-tooling-presubmits-golang-1-20-al-2

/override eks-distro-base-tooling-presubmits-golang-1-20-al-2022

/approve

/lgtm


Update doc url certified images

Added the correct document URL in the certified_image.go for the certifiedImages check.

/ok-to-test

HI @aksaswadkar It looks like you raised two pr's with overlapping info I assume you will close the other pr? Can you also search for red_hat_software_certification in the entire project and update all links to 8.68? Thanks!

Hi @acornett21 I closed the other PR and sure, I will find and update the URL to the latest version.

Hi @acornett21 Updated the URLs to 8.69, please review.


Timesheet - 22/05/2021 - Dmitry Mugtasimov

Task 1
Working on https://github.com/thenewboston-developers/Website/issues/1752
Proof of Work

See https://docs.google.com/document/d/1_6OCmqL0OK5UiWJROe-EbRYAQa9s-iuIIQOdv_Vd5Bs/edit# comments

Time Spent
1 hours

Task 2
Work on task: https://github.com/thenewboston-developers/thenewboston-node/issues/130
Proof of Work

https://github.com/thenewboston-developers/thenewboston-node/pull/137
https://github.com/thenewboston-developers/thenewboston-node/pull/138
https://github.com/thenewboston-developers/thenewboston-node/pull/139
https://github.com/thenewboston-developers/thenewboston-node/pull/141
https://github.com/thenewboston-developers/thenewboston-node/pull/141
https://github.com/thenewboston-developers/thenewboston-node/pull/142

Time Spent
X hours

Total Time Spent
X hours
Account Number
757d598308bf1e2943bd1a9fc34ae7b8951ca864d64228b59e62614b27ddefc4

@dmugtasimov, any update on this timesheet?


new generic sample for image preview column type

Q
A

Bug fix?
no

New sample?
yes

What's in this Pull Request?
New generic sample for image preview column type

@joaoferreira this is a great sample and our first for the Image field type! I've made some modifications as listed below. Please let me know if you have any concerns with any of them.

Renamed sample to image-lightbox (this matches the fieldtype naming convention)
Changed the initial display to use the same thumbnail image used when formatting is not applied. This prevents distortion and accounts for other things like transparency and keeps the initial view the same as the out of the box display.
Added the filename as a tooltip to the hover card image
Changed the hover card image to use the same thumbnail that the out of the box links to for the same reasons as above
Linked to your Twitter profile
Added the tracking image to the README

Thank you very much!

@joaoferreira just realized this PR had 2 samples in it. I'll go ahead and look at the YouTube one as well. Always happy to have more!
In the future, however, please separate these into separate PRs as that's easier to manage. Thanks!

@thechriskent I'm totally ok with your changes thanks for improving it. 👍
About the second formatting, next time I'll make sure I do them separately.


problem on getting total mesh

How can i get the absolute coordinate of mesh? I try to visualize the object and hand mesh, each single looks well, but when i put them together, the results looks like

which is incorrect because in my original video, hand and object are about same size, how can i find correct coordinate to record the mesh

what's the name of files that you opened?

By the way, since the hand is too small, I add a bias to the hand such that you can see it clearly. Without the bias, we can't separate hand and object anymore.

Those are the canonical shapes, not the posed shapes. You can visualize with visualize_ckpt.py here https://github.com/zc-alexfan/hold/blob/master/docs/usage.md

Thank you very much, I find mesh from the visualize_ckpt.py is correct.


custom validator and prompt

I made a small example how to implement a custom validator and a custom prompt.
I'm not sure if this is the right way to do it, but the example works as I anticipated.
One option is to merge as is, or rename it to validator_prompt (is it kind of covers both), or alternatively split them in two (as they are kind of independent).
Let me know what you think is best way forward.

Would you mind fixing the lints from cargo clippy --examples?

Will do...

I think this should do.

Sorry for letting you hang out to dry on this one. Decided to split them up into two as there was no direct interaction. Thanks for the examples, this should really help newcomers and implementers while experimenting!


GitLab Builds needs fixing

It looks like the way we are using the commit status api is causing weird behavior on GitLab.
Lots of different builds for the same civet target with different statuses (passed, pending, running), many reporting retried. For a single civet job, many of these get reported.
It would be nice to not have all these. This also seems to indicate that we are no longer using the API correctly.

Looks like #201 seemed to fix this as well, or the latest version of GitLab doesn't have this problem.


chore: backport upcoming changes to simp in Counterexamples + Archive

Please see https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/Help.20with.20.60nightly-testing.60/near/423522417

bors p=10


Remove third-party plugins from tests

The third party apps djangocms-link and djangocms-text-ckeditor require django-cms to be installed. This is intentional and good practice.
However the test-suite for django-cms requires to install djangocms-link and djangocms-text-ckeditor. This adds a circular dependency, which is bad practice and prevents modularity.
Therefore, these tests should either become part of the apps djangocms-link and djangocms-text-ckeditor, or, if that's not possible we should add some mock plugins to emulate their behavior in the django-cms test-suite.
For details look at cms/tests/test_page.py:
...
from djangocms_link.cms_plugins import LinkPlugin
from djangocms_text_ckeditor.cms_plugins import TextPlugin
from djangocms_text_ckeditor.models import Text
...

Hello @jrief,
I agree, this is not good practice and makes maintaining the tests harder as the plugin dependencies can break the cms tests.
Historically these plugins were embedded in the core of the cms, as a result all these tests were built around this assumption.
We started the process of decoupling the ckeditor tests on 3.4.x.
The plan is to move over all ckeditor specific tests to djangocms-text-ckeditor and then replace all tests that make use of the Link plugin, to use a much simpler version of this plugin,  maintained in test_utils.
I personally would love to get a contribution towards this :)

@jrief would be awesome if you could help us there with this as our focus is currently on other topics :/

@czpython @FinalAngel
ah ok, so it's a legacy issue.
I'd really like to contribute more to django-cms, but currently I'm far too involved into django-SHOP, which itself is kind of a CMS plugin.

Hello. Is this issue still relevant ??


winget upgrade --all broken, if an application does not provide a version

Brief description of your issue

winget upgrade --all broken, if an application does not provide a version
Steps to reproduce
winget install AngusJohnson.ResourceHacker

winget upgrade --all
Expected behavior
As the uninstall entry does not provide DisplayVersion,
winget should ignore Resource Hacker and proceed with other packages.
https://docs.microsoft.com/en-us/windows/package-manager/winget/upgrade#upgrade---all
Some applications do not provide a version. They are always latest. Because the Windows Package Manager cannot identify if there is a newer version of the app, an upgrade will not be possible.

Actual behavior
winget reinstalls Resource Hacker and stops then

PS C:\WINDOWS\system32> winget upgrade
Name               ID                          Version Verfügbar   Quelle
-------------------------------------------------------------------------
MusicBrainz Picard MusicBrainz.Picard          2.6.3   2.6.30000.0 winget
Resource Hacker    AngusJohnson.ResourceHacker Unknown 5.1.8       winget
LibreOffice        LibreOffice.LibreOffice     <IP_ADDRESS> <IP_ADDRESS>     winget
PS C:\WINDOWS\system32> winget upgrade --all
Gefunden Resource Hacker [AngusJohnson.ResourceHacker]
Diese Anwendung wird von ihrem Besitzer an Sie lizenziert.
Microsoft ist nicht verantwortlich und erteilt keine Lizenzen für Pakete von Drittanbietern.
Downloading http://www.angusj.com/resourcehacker/reshacker_setup.exe
  ██████████████████████████████  3.98 MB / 3.98 MB
Der Installer-Hash wurde erfolgreich überprüft
Paketinstallation wird gestartet...
Erfolgreich installiert

Environment
[winget --info]
Windows Package Manager v1.0.11692
Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten.

Windows: Windows.Desktop v10.0.19043.1165
Paket: Microsoft.DesktopAppInstaller v1.12.11692.0

Any other software?

This looks like a duplicate of #752 or #1192.

There are some bug reports whose cause is a missing DisplayVersion value in the ARP entries. If I may make some suggestions:

Add a check to the validation pipeline and reject the manifest, if the DisplayVersion value does not match the PackageVersion winget-pkgs#25357
let winget upgrade ignore packages that do not report a version.
let winget check the ARP entries after successfull installation and add a missing DisplayVersion.
#1279 had a similar proposal, but this case could be automatically handled.

@rhemberger these are all good suggestions. We're looking to expand the validation pipeline behavior to help with these as well as enhancing the client.
Rather than just "reject" a manifest, we're hoping to add suggestions back to the PR author for the first item so the correct value can be included. In some cases there is a "marketing" version and a "package" version so the v1.1 schema will help here (it's in progress). Manifests will be able to have a display version and an Apps and Features version. This should also help the third point.
We may consider excluding packages that do not report a version from winget upgrade -all. At least we could inform the user they could winget upgrade <package> for those specific packages if they want to try an upgrade without knowing the consequences.
I don't believe we want to enable PreInstall / PostInstall commands, but there may be a set of behaviors we would be willing to build into the client to accomplish the same objective behaviors. I also don't think we want to add missing DisplayVersion values as this could have unintended consequences with future upgrades or functionality. This is more likely a case where the Independent Software Vendor (ISV)/Publisher should be engaged to improve their install experience for their customers.
I will go ahead and leave this Issue open since it's articulating the specific scenario for a missing version. It's linked to a couple of the other Issues related to this class of problem.
One of the key problems we're trying to solve is being able to work with any existing software installed on a system. That means we will still need to be able to upgrade packages when the installed version isn't reported, and the latest version also doesn't report it's version. If this continues to be a problem, we may enhance the manifest with additional metadata so the client can behave in a consistent manner, and the user can be informed.
The version "latest" is used in some of these cases in the community repository. Our current work with the experimental store source has led us to experiment with "unknown" rather than latest. This should help set a better expectation in the event a user attempts to "upgrade" when in fact the available version might be older so the actual result is a "downgrade".

Thank you for your explanations. But I got three errors on winget upgrade now and it doesn't look like this will be fixed anytime soon. I apologize for not having searched the open issues more thoroughly beforehand. No need to let this issue open.
Winget  is still very new in the world of software, and it's best to allow the developers time to decide how they would like their product experience to be for their customers. (#https://github.com/microsoft/winget-pkgs/issues/16003#issuecomment-872653235, #https://github.com/microsoft/winget-pkgs/issues/25357#issuecomment-902174964).

You're welcome. Thanks for contributing! Customer feedback is the best way we know if we're focusing on the important issues. This product has been able to help many publishers learn a bit more about how customers perceive their products and experiences. It will take time for all of us working together to make experiences on Windows better.


errors: ensure the 1.13 method to access the cause is called Cause() not Unwrap()

The rationale in https://go.googlesource.com/proposal/+/master/design/go2draft-error-values-overview.md mentions this:

Unwrap. It is unclear if Unwrap is the right name for the method returning the next error in the error chain. Dave Cheney’s github.com/pkg/errors has popularized Cause for the method name, but it also uses Cause for the function that returns the last error in the chain. At least a few people we talked to did not at first understand the subtle semantic difference between method and function. An early draft of our design used Next, but all our explanations referred to wrapping and unwrapping, so we changed the method name to match.

In summary the rationale was "some people were confused so we're going to change the name".
However this choice creates a more serious technical problem.
Suppose a program upgrades to use Go 1.13 but has some dependency library that relies on github.com/pkg/errors (or another Cause()-compatible error library). Now consider what happens if our program makes some API call through its dependency, and that encounters an error from the standard library -- for example io.EOF or context.DeadlineExceeded. And then the intermediate library dependency wraps the error using the facilities in github.com/pkg/errors which only provides Cause().
How is the program now meant to identify the ultimate cause of its error?
The proposal with Is() and Unwrap() will be unable to "peek through" the wrappers created by the existing library code. This is defective design.
Solution: By changing the design in Go 1.13 to instead make the causer access method remain Cause(), the new 1.13 error package would become/remain drop-in compatible with existing library error wrapper code.

CC @jba @neild

It is not a goal of the proposal to be compatible with existing error packages. Indeed, that is impossible, since they contradict each other. The goal is to establish a common set of names and behaviors, and the hope is that existing packages like pkg/errors will adopt them.

How is the program now meant to identify the ultimate cause of its error?

Couldn't you continue to use Cause? Leaving aside the fact that you should never wrap io.EOF, you could write
if pkgerrors.Cause(err) == io.EOF || xerrors.Is(err, io.EOF) { ... }

It is not a goal of the proposal to be compatible with existing error packages.

why? 2) can you also explain why in the proposal itself

Indeed, that is impossible, since they contradict each other.

why/how?

Couldn't you continue to use Cause? Leaving aside the fact that you should never wrap io.EOF, you could write
if pkgerrors.Cause(err) == io.EOF || xerrors.Is(err, io.EOF) { ... }

No that will fail if an error is wrapped both by xerrors and pkgerrors.

why/how?

There exist error implementations where the Cause method returns the root of the chain, as well as ones where Cause returns the next step in the chain. There is no way to reconcile these two definitions.

There exist error implementations where the Cause method returns the root of the chain, as well as ones where Cause returns the next step in the chain. There is no way to reconcile these two definitions.

Can you provide examples. This is not my understanding. If you look at the doc of the related packages you will see the following used consistently:

the package-level function accesses the root cause
the causer interface method Cause() accesses the next step

What is the evidence you've found that some libraries do it differently? Are you going to report this evidence in the proposal?

What is the evidence you've found that some libraries do it differently? Are you going to report this evidence in the proposal?

One package where the Cause method returns the root of the chain is gopkg.in/errgo.v2/errors, which is cited in the draft design for error inspection.

I went and looked at the package you linked, and I am afraid the source code contradicts your statements:

the Cause() method does exactly what I said and only accesses one level up -- which is what the top level issue in this thread is requesting for Go 1.13. See the code here:
https://github.com/go-errgo/errgo/blob/v2.1.0/errors/struct.go#L48

the Cause() package-level function accesses just 1 level deep (instead of the root cause) and I would agree it is better to provide Is() like you did, but this point is irrelevant for the issue at hand.

So at this point I still  see no evidence of library code in the ecosystem where the Cause() method is contradicting the proposal.
I would kindly request that you either provide some evidence or instead reconsider the Go 2/1.13 proposal for the method as requested at the top of this thread.

I went and looked at the package you linked, and I am afraid the source code contradicts your statements:

You are mistaken:
https://play.golang.org/p/1rR97pPojOd

It looks to me like the errgo Cause function goes one level:
func Cause(err error) error {
	if err, ok := err.(Causer); ok {
		if cause := err.Cause(); cause != nil {
			return cause
		}
	}
	return err
}

while the pkg/errors one follows the chain:
func Cause(err error) error {
	type causer interface {
		Cause() error
	}

	for err != nil {
		cause, ok := err.(causer)
		if !ok {
			break
		}
		err = cause.Cause()
	}
	return err
}

No that will fail if an error is wrapped both by xerrors and pkgerrors.

You could instead write your own function, looking for both Cause and Unwrap methods.

You are mistaken:
play.golang.org/p/1rR97pPojOd

Thank you for the example, although I believe it is disingenuous: this exemplifies specifically the feature of that package that hides the cause. The goal of that Note API is to provide control for the code that constructs the error on the ability for other downstream code to query that code. That use case / requirement would exist also for users of xerrors and arguably an xerror-compatible implementation could provide the same feature that prevents a cause from being visible via Unwrap().
So far it does not seem you have provided evidence that in the common case (even a common case for gopkg.in/errgo.v2/errors) the established ecosystem is incompatible with the Go 1.13 proposal, and it does not seem that the conversation so far has provided a reason to keep the current design that outweighs the inconvenience that I have outlined initially.

No that will fail if an error is wrapped both by xerrors and pkgerrors.
You could instead write your own function, looking for both Cause and Unwrap methods.

Yes I am aware I could do this. However, if I and other people find ourselves required to do this often (as I am arguing since the beginning of the thread), this would be strong evidence that the proposed definition of Go's error API is defective. Now (before 1.13 is released) would be an adequate time to study this risk and perhaps make adjustments before the Go user community finds themselves inconvenienced by the defect.

As a matter of practicality, golang.org/x/xerrors uses Unwrap(), and there are people using that package now.  Which means that whether we end up choosing Unwrap() or Cause() or something else, everyone else is going to have to add backward compatibility,
If we choose Unwrap(), then github.com/pkg/errors and everyone else will have to add support for Unwrap().
If we choose Cause(), then golang.org/x/xerrors and everyone else will have to add support for Cause().
And ditto for any other API that is out there.
I understand that the error values proposal isn't final yet, but I think it would be impractical to change it drastically without a strong reason since people are using it already (including me).  Similarly, there was no guarantee that github.com/pkg/errors provided any kind of standard API across the Go ecosystem and their users should have understood that they were committing to an API only implemented by github.com/pkg/errors and any explicitly cooperating packages.
The point of this part of the error values proposal, as I see it, was to commit to a standard API across the Go ecosystem.  That it is not the github.com/pkg/errors API is perhaps unfortunate, but at this point in time being noncommittal about the API will cause more harm than benefit.
Addressing @knz's concern directly,

Suppose a program upgrades to use Go 1.13 but has some dependency library that relies on github.com/pkg/errors (or another Cause()-compatible error library). Now consider what happens if our program makes some API call through its dependency, and that encounters an error from the standard library -- for example io.EOF or context.DeadlineExceeded. And then the intermediate library dependency wraps the error using the facilities in github.com/pkg/errors which only provides Cause().
How is the program now meant to identify the ultimate cause of its error?

If your program previously used Cause style functions to check errors, it will keep working.
If you switched your program to use Unwrap style functions on a library that doesn't support it, well, don't do that.
If the library adds support for Unwrap style errors (which is trivial), then you are free to to switch to using Unwrap style functions or keep using Cause style functions.

The error values proposal doesn't change the fact that every package needs to document an explicit contract about how a user will go about unwrapping or checking errors, or the backward compatibility implications thereof.  All it does is adds a standard contract that hopefully all packages can agree upon going forward.

As a matter of practicality, golang.org/x/xerrors uses Unwrap(), and there are people using that package now. Which means that whether we end up choosing Unwrap() or Cause() or something else, everyone else is going to have to add backward compatibility

I am really glad that you recognize that some people are going to be inconvenienced.
It would be interesting here, for the sake of clarity and methodology, to estimate the size of the user populations. AFAIK xerrors has been around for less time than the alternatives using Cause().
There is a utility argument to be made about the amount of inconvenience. A solution that causes less inconvenience in aggregate seems (to me) to be the better solution. I am sure that the fact that you happen to be invested in the initial development of xerrors will not bias you against looking at the utility aspect as a whole.

I would expect third party packages like github.com/pkg/errors to change their Cause function to support both their own Cause method and Unwrap. That seems like the way to migrate from github.com/pkg/errors to xerrors to Go1.14.

You realize that you could change the go 1.14/xerror code to use Cause instead and take the cost of the change for yourself, instead of pushing it to the community right?
So far the discussion has been pretty clear:

there's no real good reason to keep Unwrap over Cause other than choosing who to inconvenience the most

in terms of number of people inconvenienced you are choosing the maximum amount of inconvenience because... I guess it makes someone's life easier, consequences be dammed?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

@knz please be respectful.

Was this issue a reason for revert at 3e2c522d5c712fa2b1d18a101272abefc7dcb074?

No.

Our final decision is to stay with Unwrap.