CIP-0030 | Upgrade to latest format & propose version / extension scheme

This has been a recurring topic regarding extensions of CIP-0030.
Given that this CIP is effectively active (hence the status change in
this commit), we can't simply keep modifying it because it then
becomes hard for DApps to keep track of what is supported by wallet
providers and what isn't.
In this commit, I henceforth propose an extension scheme based off
CIPs. Wallet providers are expected to support the base API given by
CIP-0030 and new extensions or modifications of that API can be
brought in through extension CIPs. Upon initialization, Dapps can
interrogate the wallet about what CIPs extensions it supports and
process or fail accordingly based on whether the wallet provides the
desired functionality.

Rather than throwing an error if one or more of the features is unavailable, could we instead add a field to the returned object that is an array of the features it was able to turn on (or which the user selected to enable, for example)? this makes it the dApps choice on whether this is an error, or just degraded functionality, without having to call enable repeatedly with progressively fewer features.
For example, I may request a wallet with notifications support, but still be able to operate just fine without it.
Or, I may ask to enable a "prompt less signing" extension that allows more rapid "day-trader" like experiences, but the user declines.  The app will still work, and I don't want to binary search through the space of possibilities.
You could use this same mechanism to decide on the version of an extension, much like an HTTP content type negotiation.

@Quantumplation could we instead add a field to the returned object that is an array of the features it was able to turn on

That's a good idea; what about adding that to the error response actually?

@KtorZ well, the idea is, currently enable returns an object that has all the methods we might use to start interacting with the wallet; if we throw an error, we're interrupting the return of that object.
The idea behind my suggestion is to still return the same object from enable; if I absolutely require some feature that isn't in (await cardano.{wallet}.enable()).extensions, then I can treat that as an error and show the user some kind of explanatory dialog.  But, if it was just a nice to have, I can just change the behavior of my application to omit that missing feature.
If, instead, we threw an error that just described "here are the features we could turn on if you wanted, and here are those we couldn't", then I have to call enable again with a restricted set, which is going to (potentially) prompt the user again, etc.

@Quantumplation which is going to (potentially) prompt the user again

This is a valid UX point indeed.

Riffing on this a bit more, maybe a bit more structure would be useful as well.  To be a bit more concrete, here's what I'm suggesting:

enable(extensions) doesn't return an error;
instead, a new field is added to the returned object, called extensions
this field is an object; the keys on this object is the union of extensions the wallet knows about, and the ones that were requested
If a particular extension wasn't requested, but is supported, the value is null; this allows the dApp to know which features it could leverage, if it needed (and, for example, show/hide different flows)
If a particular extension was requested, and enabled, the value here is an object with all methods relevant to the particular extension
If a particular extension was requested and couldn't be enabled for some reason, the value is an error describing why it wasn't enabled (Incompatible, NotSupported, UserDeclined, etc.)

If people don't like the "null" value to discover features (totally get it, I'm iffy on it too), then I'd suggest adding a list of potentially supported extensions to the initial object (the one at window.cardano.{wallet}) instead.

I went for something half-way while you were writing your comment. So, no error but a new endpoint to get the list of extensions actually enabled by the wallet.

@Quantumplation  I'd suggest adding a list of potentially supported extensions to the initial object (the one at window.cardano.{wallet}) instead.

I think that's also easy to do and provide benefits indeed. I am afraid that something more complicated will rapidly be a pain to implement for wallet providers.

It's a good thing to get some structure for extensions to CIP-30. Though the currently suggested string array of extensions to enable limits you from adding additional data in the enable call that might be needed. Taking CIP-0062 as an example it now has its own enable call (that this addition is supposed to replace?) and takes an additional VotingPurpose[] in the enable call.
I would like to extend Extension from being a string array to an object array containing:
{
  "cip": <number>,
  "ver": <number>,
  ...
}

cip is the number of the CIP extension to CIP-0030 to request access for
ver is the version number of the extension that the wallet support
... object can contain any additional fields as specified by the CIP extension. like purpose array for CIP-0062

The same Extension object as above would be returned when calling supportedExtensions(). This would allow for example a wallet that support CIP-0062 extension to return cip, ver, and the supported purposes.
Does this make sense?
I must admit that I was thinking it through as I wrote the reply 😄

@KtorZ Thus, there's in principle no need for version numbers because CIPs do not generally have versions. They have new CIPs instead.

Ok, I can accept the workflow of removing versioning and always requiring a new CIP for extension/changes to existing CIP.
But how would you propose that additional data in enable call should be handled?
Like requesting access to a specific feature within a CIP (that CIP-0062 currently utilizes).

We should then remove apiVersion from CIP-30 as well, as it makes no sense if a CIP, once merged, is final and all changes/extensions should be handled by new CIPs.

@Scitz0

Like requesting access to a specific feature within a CIP (that CIP-0062 currently utilizes).

One way to handle this would be to leave that negotiation to the extension as a separate method;
For example, you call enable("CIP-0062"), and then call .enablePurposes(...), a method provided by the extension;
I'm not super familiar with CIP-0062, so I don't know if this would re-trigger a new user prompt, but if so, that's a slight downside UX-wise.

Internal discussions for how to deal with the proposed workflow have resulted in I'm being ok with the PR in its current state. The only thing would be why Extension is formatted as a string and not just a number representing the CIP number? But I'm ok with it either way.
Just as an FYI, being really more of a CIP-62 thing. I think we will instead of accepting the purpose as an input to enable specific purposes, have CIP-0062 Extension enable call (according to this PR) enable all supported governance purposes for an origin and instead add a getSupportedPurposes() where the wallet can specify the supported purposes. The apiVersion in CIP-62 will also be removed to only allow minor changes, like purpose definitions.
Is this in line with the desired outcome of this PR?

What would be the major difference between the Experimental API and extensions? Isn't the goal anyway that most wallets support a certain extension (if popular/used a lot). If every wallet just adds whatever extensions they like it's going to be a mess for dApp developers anyway. So over time it's desired that most wallets support popular extensions, but then they should be at the base, because it's not an extension anymore then really. If extensions don't see adoption over time then they are likely dropped again, so they are "experimental".

cardano.{walletName}.enable(extensions: Extension[] = []): Promise
I really like this, particularly as the set of possible extensions is large.

I wonder though, from the wallet user's perspective how they might wish to enable a subset of the extensions a dApp requested at initialisation; and maintain a whitelist of the enabled (or not to be enabled) extensions per dApp. Likewise from the dApp's perspective they may make a hard requirement on a subset of the extensions requested at initialisation.
Allowing the dApp to specify a required subset of extensions and giving the wallet user the ability to selectively enable or disable extensions requested at initialisation for different dApps could provide greater flexibility and control for both parties. It could also improve the UX of a wallet, as the wallet user can choose to only enable extensions that they trust and are comfortable with.

@alessandrokonrad: What would be the major difference between the Experimental API and extensions?

These are two orthogonal elements. The experimental API is (purposely) loosely specified. It's a way for wallets to provide specific features that aren't actually specified as CIP extensions. Over time, I wish we would deprecate the experimental API altogether because it creates inconsistencies in the ecosystem. It still bothers me a lot when I see a list of "supported wallets" on a DApp whereas the entire point of CIP-0030 was to remove the need for doing adhoc integration. A DApp should support any wallet that implement CIP-0030.
Yet how did we actually get there?
-> There are actually many divergent implementations of CIP-0030.
Which is why I am proposing to freeze the current API (+ this extension mechanism) and require that all wallet (willing to follow this standard) implement at least the base API and advertise what other features they support through this extension mechanism.
This is truly about features negotiation. So it becomes much more transparent for dapps and wallets alike. Instead of integrating against a wallet, a DApp can integrate against a set of interfaces. Any wallet that provide those interfaces should work.
I didn't remove the experimental API because I think there's still a (narrow) use case for it. If only during development of cutting-edge features not yet fully specified; but I would encourage any wallet providers to document their interfaces as CIPs rather than shoving stuff in the experimental API so we can grow the whole ecosytem.

@teddyjfpender from the wallet user's perspective how they might wish to enable a subset of the extensions a dApp requested at initialisation

@teddyjfpender Allowing the dApp to specify a required subset of extensions and giving the wallet user the ability to selectively enable or disable extensions

I believe this to be out of scope of the current specification. CIP-0030 is a contract between dapps softwares and wallet softwares; users aren't personas of this particular subsystem.
What I mean to say is that, there's nothing in the specification that constraints how wallets may want to handle what extensions they make available. So, if a wallet provider wants to leave the choice to their users through some settings dashboard they're welcomed to do so; this specification doesn't prevent it.
The most naive implementation of this proposal would be for wallets to simply implement and enable all extensions they support every time. Some may want to do something more fine grained.
Note that the requested extensions that the dapp specifies on initialisation is mainly to cope with possibly conflicting extensions and give a hint to the wallet to which one they should enable if they support multiple conflicting extensions.
Imagine two extensions CIP-1234 and CIP-5678. The former provides a way to evaluate a transaction execution units by providing a method 'evaluateTx' in the API that returns some cpu and memory budgets. The other is an extension that performs all the phase-1 validations on a transaction (kind of dry submission) through a method also called 'evaluateTx' (!).
Both extensions are mutually incompatible because they are both bound to a same endpoint with different semantics. This is where a DApp could indicate which one it wants enabled during initialisation. In practice, well obviously do our best to avoid extensions that conflicts like this, unless it is a desired outcome (eg a new version of a particular extension that provides new functionalities but with a non backward compatible interface).

It still bothers me a lot when I see a list of "supported wallets" on a DApp whereas the entire point of CIP-0030 was to remove the need for doing adhoc integration. A DApp should support any wallet that implement CIP-0030.

But isn't that almost unavoidable? When I look at JavaScript builtin functions you also see a list of browsers supporting that builtin or not. Extensions do not solve that problem, they just indicate better what wallets are supported by a certain dApp.
When a dApp relies on a certain feature of an extension and not all wallets support that extension then again you have that list of "supported wallets". I'm not opposed to extensions, I'm just failing to see this. Is the idea to break down bigger compatibility issues into smaller ones?

Which is why I am proposing to freeze the current API (+ this extension mechanism) and require that all wallet (willing to follow this standard) implement at least the base API and advertise what other features they support through this extension mechanism.

When you say freeze, you mean "forever", or under what circumstances can the base API be modified?

@alessandrokonrad But isn't that almost unavoidable? When I look at JavaScript builtin functions you also see a list of browsers supporting that builtin or not. Extensions do not solve that problem

And I am not saying they do!

@alessandrokonrad they just indicate better what wallets are supported by a certain dApp.

Precisely! This is the entire goal here. Have a less ad-hoc mechanism for wallets and dapps to advertise and negotiate what features they support / need. In principle, this could now happen entirely programmatically. When writing your dApp integration, you could simply look for any available wallet, filter out those who don't support your mandatory extensions, and automatically propose them to the user while leaving the others out. As soon as one wallet brings support for a required extension, no work is needed from your dApp -> it automatically supports it.
Of course, there will always be some little details about one wallet implementing something slightly differently than others. But that is something we should resolve at the specification-level. Improve the CIPs so that they lead to unambiguous implementations.

@alessandrokonrad When you say freeze, you mean "forever", or under what circumstances can the base API be modified?

Freeze (mostly) forever yes. Have any changes be brought be new CIPs. But it's very possible that a CIP extension would override an existing method. Say that tomorrow, we change the interface to signTx, this could be written as an extension. And wallets would enable it on-demand from DApps.
There are cases where we might want to make exceptional changes to the base CIP-0030 API; but we will have to be very careful about that to avoid breaking backward-compatibility. This is why I am keen on @Quantumplation's idea (which he proposed on another discussion thread) to have extensions be plain objects with a single key "cip" for now. For example:
{ "cip": 62 }

This allows to possibly introduce later some extra arguments to extensions without breaking all existing interfaces.

i find it a bit confusing to have totally different cip numbers that are basically all variations or extensions of the original one. isn't it time to group them under a main cip number and do extentions/variations on that via a minor naming scheme? like 802.a, 802.n, 802.ac, 802.ax ...? they are all describing wifi specifications/protocols/frequencies etc, but we know they all have to do with network stuff. its just an idea, but maybe we should think about it to group such things.

@gitmachtl that's a good point but kind of orthogonal to CIP-0030. It'd have appreciated the feedback when we reworked CIP-0001 and discussed numbering there as well 😶 ...
There was many debates about how to number CIPs but all-in-all, we concluded that what is really needed is some number that allows to identify CIPs and refer to them easily. We could come up with something more elaborate but every proposal so far had trade-offs we didn't want to introduce. For lack of better proposal, we chose to keep it simple

This is a good proposal IMO.
The only issue I have is that it removes the potential for flexibility in extensions' enable call, which has been highlighted above. Another outcome of this is that extension specific initial API functions will not be possible.
I think it may be useful for some extra prose to be added around guidance for extensions. Questions, I have:

can extensions depend on other extensions? - can extensions have extensions?
should extensions follow a specific format?
can extensions add their own error codes? - can they overwrite error codes?
should extensions have a clear size? - what is too small to be an extension what is too large?
should extensions have a clear focus (i.e. governance) or can they be generic?

Probably ridged boundaries around scope and size are inappropriate, with extensions just being considered against community consensus of the problems they solve.

Another extension to the idea behind this PR could be to make CIP-0030 one of the CIP's to enable; an empty array is assumed to be CIP-0030.
This opens up the possibility of a future CIP-0030 defining a different "base" interface, if we want to make changes to any of those "base" methods.
For example, if we wanted to change the signature of signData or signTxs, or rework how things work entirely (pub-sub streaming communication with the wallet, or something).
I'm more than happy with this proposal without it, just turning it over in my head to see if there's anything we're going to regret not considering 2 years from now 😅

@gitmachtl: extentions/variations on that via a minor naming scheme? like 802.11a, 802.11n, 802.11ac, 802.11ax
@KtorZ: It'd have appreciated the feedback when we reworked CIP-0001 and discussed numbering there as well ...

Just recalling that we did consider this, though it was someone else that brought up the idea last time.  I responded at the time against the idea but what I said was not a comprehensive treatment, nor did it necessarily reflect the opinions of all editors, nor did what I write determine how CIP-0001 was finalised... it was just some specific reasons to "keep [the names] simple" as we might also have been generally & instinctively inclined to do.

https://github.com/cardano-foundation/CIPs/pull/366#issuecomment-1309650355
https://github.com/cardano-foundation/CIPs/pull/366#issuecomment-1310468382

@thaddeusdiamond the problem is, there is no one API; this proposal is about how a dApp and a CIP negotiate features, not (just) a version.
That is, there may be methods that the wallet doesn't want to support; or that it wants to gather user input before enabling.  It's akin to the permissions an app requests from your phone, for example. Some phones don't have a camera, and sometimes the user wants to disallow camera access but allow other features.
This proposal is about allowing dApps and wallets to navigate that process, with little knowledge of each other beyond the shared touch point of a CIP for standardization.
The governance side of things, i.e the discussion, consensus, and adoption of these is provided by the process outlined in CIP-0001; the individual CIPs themselves document the specific extension itself.
You bring up a good point that perhaps it's worth collecting these decisions into a separate format for documentation and ease of use, but I think that's orthogonal to this proposal, i.e. feature negotiation.

CIPs aren't about governance though. We've repeated that countless times -- and even write it quite clearly on CIP-0001 I believe now. Though I understand the confusion.
The CIPs process is a mechanism to reach agreement on technical solutions. CIPs are the technical solutions. Whether a party then wants to implement and support a solution is up to them. That's even more true of the wallet APIs. If tomorrow, a new CIP is accepted, it doesn't automatically create a commitment to every wallet implementors out there. It can't.
CIPs are a catalog of solutions. And the suggestion here is to allow both ends (dapps and wallets) to inform each other about which parts of the catalog they need and support. I'd argue that DApps developers must know about CIPs -- at least to one that are relevant to them. At the moment, this feature negotiation is very cumbersome because everyone has their own subset of features they support. And we end up in situations where each integration requires efforts.
Collecting CIP-0030 related extensions into one website (as well as a compatibility matrix of which wallets support which) sounds like a good idea. It is akin to what https://www.cardano-caniuse.io/ is trying to achieve.

I love cardano-caniuse.io and as a dApp developer use it regularly.  Let me try another analogy.
Multiple web browsers have their own implementations of various CSS features, but they all align to one standard.  The three-phase process is roughly something like:

The Web 3 Consortium puts out a proposal for a new CSS module (e.g., border-radius)
Browsers adopt it experimentally with varying prefixes (sidenote: this is kind of a nightmare for developers but it is what it is, see "Mozilla Equivalent" and "WebKit Equivalent" here).
Aggregators and learning sites like StackOverflow and w3schools.com create simplified tutorials for web developers consumption.

I would argue that dApp developers are equivalent to web devs, who never ever ever read the W3C papers.  Those are the equivalent of CIPs.  Part 2 should be Eternl/Nami/Flint's unique documentation.  Part 3 is cardano-caniuse.com
So my proposed solution would be for each addition to the Wallet API go through it's own CIP, completely detached from any dApp developer's knowledge of the API.
That make sense?

@thaddeusdiamond this is kind of a nightmare for developers but it is what it is

How can you say that, and then not see the value of what we are proposing here 😅 ... ? We don't have to replicate a scheme that is a nightmare for people to use. It doesn't have to be "what it is".

@thaddeusdiamond So my proposed solution would be for each addition to the Wallet API go through it's own CIP

Now I've lost you. This is exactly what is being proposed here. With the addition of a mechanism for wallets to clearly indicates which addition they implement (so that there's no reliance on some external service to tell you empirically whether a wallet supports your needed feature).

@thaddeusdiamond completely detached from any dApp developer's knowledge of the API

I think all is really needed to get you onboard here is a clear API reference on a website that fully documents the API, and the known extensions. Take a step back, and imagine that instead of calling the extensions CIP-0093 and CIP-0123, we call them v2 and v3. And we just have an API reference that lists the features of v1, v2 and v3. So as a developer, you know which one you need for your use case.
There's not much difference here, except that we don't have a pure sequence, but instead, a core foundation (CIP-0030) and composable extensions that can be added as needed.

@gitmachtl yes indeed. That's what I am suggesting with this "website" idea. Something on top of CIPs that is specific to the wallet API and its extensions. And if people want to replace CIP names with fruits or I-don't-know-what, then so be it.

Updated with recent feedback ☝

@KtorZ did that latest force push include some accidental changes to the template / CIP-0001?

@Quantumplation maybe what look like accidental changes are from these 2 already merged commits which affect incidental material?

https://github.com/cardano-foundation/CIPs/pull/450
https://github.com/cardano-foundation/CIPs/pull/452

... as far as I know these commits appearing in the diff for this branch are a consequence of doing a force-push rather than re-basing this branch on the master which already had those commits merged.

Nothing's accidental. Everything's planned. I think Github is just drunk here in showing the diff.

Moved my discussion with @KtorZ into a review to track better.

@KtorZ any issues with using https://www.cardano-caniuse.io maybe it can just be the start ?

No issue in using it. Rather, about keeping it up to date. In the end, it provides an idea but doesn't necessarily reflect reality. Embedding the version negotiation in the API itself solves this problem as wallet and DApp can dynamically figure out where they stand.
I'd imagine cardano-caniuse to still be useful to (a) provide an overview of the extensions available and what wallet implement them and (b) still indicate information about experimental apis of wallets.


Minor update to README

Blockquote was looking weird before the change.

Sorry, this was supposed to go to the develop branch.


[BUG] vulnerable library tough-cookie & semver detected

Hi,
We are using elasticdump as an internal tool to selectively dump data from our active elastic search to a backup elastic search cluster. But recently our scans on internal tools have reported 2 vulnerabilities on tough cookie v2.5.0 (dependency of request:2.88.2 ) & semver v5.7.1 which is a peer
Tough-cookie:
The latest version of elasticdump "6.103.1" is still using "request:2.88.2" which has been deprecated for some time now.
This has a peer dependency on tough-cookie:2.5.0 which is vulnerable. Here's the link to the vulnerability in NVD  https://nvd.nist.gov/vuln/detail/CVE-2023-26136
As request itself is deprecated and so tough cookie upgrade is not possible, so are there any plans to move to a newer library like axios, etc?
Semver:
Semver v5.7.1 is reported as a vulnerability. Here's the link to the vulnerability in NVD  https://nvd.nist.gov/vuln/detail/CVE-2022-25883. Its fixed with version >7.5.2 which is also available in npm.  Can the next build we can update the semver to a safe version.

I've moved to using @cypress/request. There are a few features axios doesn't support.

These are security advisories. As it stands none of these issues can be exploited.

Thanks @ferronrsmith


Bump 0.1.29

@rhatdan @mtrmac @nlewo PTAL

I will tag https://github.com/projectatomic/skopeo/pull/486/commits/7add6fc80b0f33406217e7c3361cb711c814f028 as v0.1.29

ACK, please merge whenever it works for you.

@runcom I will build packages, but could you create a release doc describing what has changed.

@runcom @mtrmac cool, thanks!

@runcom lets get a blog published on Monday with the new features. Most are from containers/image
Here is what I put in the skopeo.spec

Updated containers/image
docker-archive generates docker legacy compatible images
Do not create $DiffID subdirectories for layers with no configs
Ensure the layer IDs in legacy docker/tarfile metadata are unique
docker-archive: repeated layers are symlinked in the tar file
sysregistries: remove all trailing slashes
Improve docker/* error messages
Fix failure to make auth directory
Create a new slice in Schema1.UpdateLayerInfos
Drop unused storageImageDestination.{image,systemContext}
Load a *storage.Image only once in storageImageSource
Support gzip for docker-archive files
Remove .tar extension from blob and config file names
ostree, src: support copy of compressed layers
ostree: re-pull layer if it misses uncompressed_digest|uncompressed_size
image: fix docker schema v1 -> OCI conversion
Add /etc/containers/certs.d as default certs directory

@rhatdan +1


Allow metadata upload when dor_object is in a "registered" state

modsulator currently does not support spreadsheet upload when an object is in a "registered" state. Tommy pointed to the piece of code where in_accession is defined - and it seems that there are numerical state definitions that are included for the broad category of "in accessioning".
@LynnMcRae - this is in keeping with your understanding of the desired functionality, correct?

Fixed by sul-dlss/argo#510


⚠ GLDDNS Server (ns2.glddns.com) has degraded performance

In f10f478, GLDDNS Server (ns2.glddns.com) (ns2.glddns.com) experienced degraded performance:

HTTP code: 200
Response time: 701 ms

Resolved: GLDDNS Server (ns2.glddns.com) performance has improved in e183ec3 after 8 minutes.


Ad not appearing on mobile phone app

Noticed this has been happening for the last few days. Posting ad will only show on desktop/web browser and not in the smartphone app. This has happened to me in the past for short periods of time and I just assumed there might be some replication delays on Kijiji end and it would eventually show up on the app but not sure anymore. Maybe some API to upload to app needs to be updated? Just a guess :P
Thanks again

Could you clarify what you mean by not showing on the app? Does the ad not appear in the ad list from you "My Kijiji" profile page?

The ads appear to be showing under "My Kijiji"
They do not appear when searching using keywords
Also noticed the postal code is not resolving to the city in the ad and I think that is why this is happening
For example...Ad should says Toronto, ON M3M1A1 instead of just M3M1A1
As mentioned, this happened in the past for max 1 day at a time (few times) and noticed the issue was resolved when postal code look-up/resolution is working correctly.
Tried with different phones and kijiji accounts, same thing...
Thx for ur reply

Editing the ad (no changes) and saving the ad on the mobile application seems to fix the postal issue and makes ad appear using keywords

And it seems to have resolved itself again! Not sure why its happening but im guessing its something to do with kijiji back-end since no changes were made to the app

Tried to edit ad using web browser and noticed the Location section looks like its missing stuff...is this normal?

I can confirm the same thing with regard to the location for new ads posted by kijiji-manager vs older ones. I'll have to look into what changed on the Kijiji side for ad locations.

Thanks for confirming. I noticed the mobile application is no longer asking for a region (like Toronto, Peel, etc) and seems like it is just basing it off postal code and showing the city it is in. If you look at ads on the mobile app, they no longer show regions like it did in the past. Now it shows the city for the postal put into the ad such as Brampton instead of Mississauga/Peel Region or East York instead of York Region. I think this change is what is causing this issue.  Thanks again!

Hey @rybodiddly
Tried with your application too (looks awesome wow!!) and experiencing the same region/postal issues thing

Fix submitted in Pull Request 29

@thanksforkijijimanager I just uploaded the patch 1hr ago. If you use my version, it is also fixed now.

Downloaded your version 20 mins ago and still having the issue, maybe I need to update my XML?
Which line/section should I be updating and reduce postal to first 3 characters or what do I input now?

@thanksforkijijimanager yes, the xml files need to be recreated or edited so they contain longitude and latitude coordinates.
Example of Address section of xml:
<ad:ad-address>
     <types:zip-code>YOUR_POSTAL_CODE</types:zip-code>
     <types:longitude>-65.1234</types:longitude>
     <types:latitude>40.3456</types:latitude>
</ad:ad-address>

PR #29 merged in to master.


Small fixes here and there

Commit messages explain the gist.

Thanks for the proof read. Much needed :)
One question - is the file vscode/ltex.hiddenFalsePositives.en-US.txt required?

It's not critical for development but you will have to ignore these warning once again.
If you wish to purge these changes you could add them to your local settings.
But that's assuming you even use vs code 😅. So no, the entire .vscode directory does not affect the project.


[Scenario] Musamji (무삼지)

What kind of mission do you want to add (mark with an X, e.g. [X] Descent)?

[X] Mansions of Madness
[ ] Descent

What expansions does the scenario require?

[ ] Conversion Kit (CK)
[ ] First Edition (MoM1E) - Also Recurring Nightmares
[ ] Fatal Alchemy (FA) - Also Suppressed Memories
[ ] Call of the Wild (CotW) - Also Suppressed Memories
[ ] Beyond the Threshold (BtT)
[ ] Streets of Arkham (SoA)
[ ] Sunctum of Twilight (SoT)
[ ] Horrific Journeys (HJ)
[ ] Path of the Serpent (PotS)

Another Korean scenario. It uses only the base game. Available just in Korean.
Please enter the GitHub Url to your scenario here
https://github.com/vidimus/Corea/tree/main/Musamji

@antontimmermans , would you mind to add this scenario to the statistics, please?

Thanks, @antontimmermans


jM

Kind of issue

[ ] Feature
[ ] Bug
[ ] Design
[ ] Other, namely:

Description

Closing this issue since it's empty.
If you want to make a request, please open a new issue with a relevant title and the description of the issue you wish to have addressed.


[WIP] Resolve various checkpointing issues

What was wrong?
Fixes #1114
Fixes #1115
Fixes #1117
How was it fixed?
Catch and continue if peer is cancelled while we ask it for the checkpoint header.
Added some logs that helped identify the problem.
To-Do

[ ] Clean up commit history

[x] Add entry to the release notes all fixes to unreleased code

Cute Animal Picture

@cburgdorf only the last two commits are relevant for review, the others are in another PR

I'll take a look at the test failure in the morning.

I'll take a look at the test failure in the morning.

Apparently, beam_to_block=1 fails, all blocks coming after the first one are working fine.


pull request for e2e test at 12/05/2016 11:26:00

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


New traversal proposal.

This is my proposal for a new generic traversal supposed to be used as replacement for our current Traversal class to build up our DSL steps.
This proposal offers three advantages when compared to the current state:

DSL steps only need to be defined once to be usable on single elements as well on collections/traversals of elements and it does so without wrapping single elements in some kind of single element collections.
It is equally fast or faster when using C2 JIT (the default one on JVM 8 and 11) and it is much faster when using Graal JIT (can be enable in JVM 11 via flags or by using GraalVM). In fact for the performance tests i made so far the new DSL with Graal JIT runs as fast as using no traversal wrapper at all.
DSL step definitions can be used for lazy iterations via Iterator as well as non lazy iterations via Iterable just buy including a different implicit PipeOps iterator.

Before i go into some of the details i dont want to spare you the drawbacks:

People writing DSL steps will be exposed to more complex generic programming than it is currently the case. E.g. higher kinded generic type parameters are used. I have come up with a strict schema for the DSL steps in order to keep complexity low.
We wont be able to swap in the new traversal without some stylistic changes in the usage pattern of steps which take implicit parameters: E.g. repeat(...)(_.emit) would need to become repeat(..., _.emit). With scala 3 we would not need to make that change.

I will now provide an example of the new DSL step definitions for the referencingIdentifiers step on LOCAL nodes:
// Implicit function which wraps a single LOCAL node into a LocalTraversalNew.
// This is quite analog to the current DSL and goes into some language package object.
// FT[_] will be explained futher below.
implicit def toLocalTraversalNew1[I <: nodes.Local, FT[_]](trav: I): LocalTraversalNew[I, Trav1, FT] = {
  new LocalTraversalNew(trav: Trav1[I])
}

// Implicit function which wraps an input traversal(IT) of LOCAL nodes into a LocalTraversalNew.
// This is quite analog to the current DSL and goes into some language package object.
// FT[_] will be explained futher below.
implicit def toLocalTraversalNew2[I <: nodes.Local, IT[_], FT[_]](trav: IT[I]): LocalTraversalNew[I, IT, FT] = {
  new LocalTraversalNew(trav)
}

// Extension class which works on any input traversal(IT) of LOCAL nodes.
class LocalTraversalNew[I <: nodes.Local, IT[_], FT[_]](val pipe: IT[I]) extends AnyVal {
  // Extension method takes implicit traversal operation ops1 which provides the basic traversal operations
  // like map and flatMap for the input traversal type (IT). Some of the basic traversal operations like flatMap
  // have an output traversal type which is different from IT. We call it flatMap traversal(FT).
  // The seconds traversal operation ops2 is than required to again provide the basic traversal operations
  // for the result of flatMap.
  def referencingIdentifiers(implicit ops1: TravOps[IT, FT], ops2: TravOps[FT, FT]) = {
    pipe
      .flatMap(_._refIn.asScala)
      .filter(_.label == NodeTypes.IDENTIFIER)
      .cast[Identifier]
  }
}

Keep in mind this PR is just a proposal so it contains some stuff off less importance.
The new traversal core definitions are under semanticcpg/src/main/scala/io/shiftleft/semanticcpg/langv2/ and
MethodTraversal.scala, AstNodeTraversal.scala and LocalTraversal.scala contain some example step implementations.
Please ignore semanticcpg/src/main/scala/io/shiftleft/semanticcpg/language/MySteps.scala and
semanticcpg/src/main/scala/io/shiftleft/semanticcpg/language/PipeOps.scala. They contain my first attempt for a new traversal but that approach while easier for the step writer turned out to be too slow.

From your description, the advantages clearly outweight the disadvantages. The one thing I ask myself when seeing the example code is whether we can find any ways of making the complexity less visible to the language writer. @mpollmeier what are your thoughts?

Just discussed this in detail with markus, and he's looking into a few additional points (e.g. support for PathAwareTraversal and .repeat()(_.until) with type application). We'll let it sink in over the weekend.
Additional benefit that's not in the description yet: the end user (not the language designer) doesn't need to learn about Traversal - she can just continue to use Iterator or whatever collection they have at hand.
Additional downside: when the language designer adds a non-trivial step (like in LocalTraversalNew.referencingIdentifiers), she only has the methods that we defined in AnyTraversal at hand. Currently, with Traversal, we have all collection methods, including things like zipWithIndex, partition etc. We'd need to make sure we cover enough ground here.
We also discussed and agreed that it makes sense to bring this in before upgrading to Scala 3, mostly because changing the Scala version and traversal impl wold mean a hard cut for all existing Scala 2 users.
It'll be crucial to document this really really well, especially those additional generic terms like InputTraversal(IT) / FlatMapTraversal(IT) and TravNOps.
Overall I'm positive for this PR. The complexity certainly goes up, but the benefits seem to outweigh the downsides.


Request with 401 returns as Failure even when validate statusCode treats 401 as acceptable

As per subject above, I am treating 401 as a success (long story short, I'm looking at the statusCode to decide if I need to renew my bearer token).
Previously:
Alamofire.request(MYRESOURCE).validate(statusCode: MYACCEPTABLESTATUSCODE).responseJSON{ (request, response, responseObject, error) -> Void in
When HTTP 401 is encountered, error is nil. From there, I proceed to check the statusCode and what to do next.
Currently:
Alamofire.request(MYRESOURCE).validate(statusCode: MYACCEPTABLESTATUSCODE).responseJSON { (request, response, result) -> Void in
When HTTP 401 is encountered, result is a failure. I would expect it to be a success, to mimic the previous scenario where error is nil.

Did a bit more research, found this: http://stackoverflow.com/q/32656703/351810
Taking cues from there, I tried
Alamofire.request(MYRESOURCE).responseJSON{ (request, response, result) -> Void in
and
Alamofire.request(MYRESOURCE).validate(statusCode: 200...409).responseJSON{ (request, response, result) -> Void in
Got .Failure for both instances when the server returns 401.

It appears that result was set to failure set by the responseSerializer as the response I received not valid JSON (HTTP 401).

Thanks for all the info. I'd say everything is working exactly as expected based on the info provided. If you need a successful 401, don't validate, and use the response or responseData serializer.


added DrawerListener for drawer open and close events to the scaffold

I needed a way to know when the Drawer was opening or closing.  Since there was no hook for that yet through the Scaffold I put one in.

I signed it!

Why do you need to know if the drawer is open?

Well, I am working on implementing a design that calls for an element to be spanning both the AppBar and Body of the Material scaffold.

The only way to get this to work that I could think of was to use a Stack.
 return new Stack(         children: <Widget>[           new Scaffold(             drawerListener: this,             appBar: new AppBar(),             drawer: new GardenDrawer(context, user),             body: new _LandingBody(),           ),           !hideLogo ? new Row(             children: <Widget>[               new Container(                 child: new Image.asset(                   'images/logo_shadow.png',                   width: 100.0,                   height: 100.0,                   fit: BoxFit.scaleDown),                   margin: new EdgeInsets.fromLTRB(0.0, 40.0, 0.0, 0.0)               )             ],             crossAxisAlignment: CrossAxisAlignment.end,             mainAxisAlignment: MainAxisAlignment.center,           ) : new Container(),         ]     );
The problem is that Since the Drawer is part of the Scaffold the Image appears on top of the drawer when the drawer opens.  I needed a hook into the events of the drawer in order to hide/show that image.  I know that is hacky and maybe I should implement my own scaffold but this seemed to me to be the quickest way to get this prototype up and running.  I decided to submit the pull request because I thought there might be other unforeseen reasons why a developer might want to execute arbitrary code when the drawer opens/closes.

Easiest way to do what you describe is to put the AppBar in a Column with crossAxisAlignment set to stretch, then put the body in an Expanded in that column below it. Then, put that Column in a Stack, and use the Stack to position the image on top of the AppBar. Or, use a CustomMultiChildLayout to lay out the appbar, body, and flower image, using the "body" slot of the Scaffold to do this. Then you don't need to remove the image when the drawer opens.

I'm going to close this PR based on my last comment, but please don't hesitate to file a bug or contact me if that wasn't sufficient. I'm not against the idea in this PR, just avoiding adding code that isn't strictly necessary. If it turns out it's necessary after all, we should definitely consider adding it.


Frontend: search on custom properties

Are there any plans to make custom properties searchable?
We would like to be able to find entities based their custom properties.
It may be useful to search both for the key of the custom property and a combination of key and value
One idea would be to add search-ability in the existing search box.
Example search on a high level:

Give me all entities that has a customProperties field named "fruit" with value "banana"

Some examples of custom property key-values are:
'owner_system_uid=foo-system'
'reload_interval=daily'
'compressionType=gzip'
A naive search text could be: "customproperty.fruit=banana"
However, it's a bit verbose, so maybe just 'fruit=banana'. Optionally a filter on the search page 'is_custom_property', to narrow it down to only custom-properties.
A possible useful option to avoid indexing uninteresting fields is to have a property on each custom property which can be set upon ingestion whether that property should be searchable or not.

Hi @RickardCardell!
We are now managing feature requests through our new portal to improve visibility & prioritize work into our public roadmap. If this request is still relevant, please create a new issue so we can gauge current interest from the Community & prioritize work accordingly.
We'll close out this issue in the meantime. Feel free to reach out to me on DataHub Slack with any questions!


Feature: Add measurement evaluation to CLI tool

Is your feature request related to a problem? Please describe.
we use an external tool calculate this https://github.com/virtee/sev-snp-measure
Describe the feature you are requesting, as well as the possible use case(s) for it.
move this to cocos cli
Indicate the importance of this feature to you.
Must-have
Anything else?
No response

resolved by #245


Bug: TransactionPaymentApi_query_info panic for V3 or higher multiloc version when using with polkadotXcm.limitedReserveTransferAssets

Description
TransactionPaymentApi_query_info panic for V3 or higher multi-location version when using with polkadotXcm.limitedReserveTransferAssets if account has 0 balance of transferred asset.
Expected Behavior
Should return correct estimation as for V1/V2 multi-location
Actual Behavior
Throw panic, with no paymentInfo details
Steps to Reproduce

Try for example transfer from kilt to hydration with Alice (or another empty acc):

0x010104530803010100c91f03000101004554480026f5c2370e563e9f4dda435f03a63d7c109d8d0400000000000000000304000000000b00407a10f35a0000000000

can we fix this?


chore: fixed minor spelling error

Did that fix it?

Actually I just remembered I can squash into a single commit, so will add the correct commit message there.

Thanks for fix @WrathZA  :+1:


Feature Request: Critical Rolls

Allow a critical success/failure to generate a critical roll (3d6) to obtain a number for the tables.  Also, allow extension of critical success by the "7 on effective skill 20, 8 on effective skill 25" etc. (or really allow the progression to be set as desired).

Closing, as this seems a duplicate of https://github.com/crnormand/gurps/issues/993


feat: cli_set_process_title

[2019-08-08 18:44:14 $64069.0]  WARNING swReactorProcess_start: The onStart event with SWOOLE_BASE is deprecated


Make bitcoind rpc passed by command-line arg / env variable

See discussion in https://github.com/fedimint/fedimint/pull/1202#issuecomment-1373993690

Completed by #1289


try-runtime: execute a range of past blocks

An extension to the existing execute-block that, instead of re-executing one block, it executes a range of past blocks, as long as they are one continuous range.
Should be tested with the new testing infra added in https://github.com/paritytech/substrate/pull/13794.

Hey, I would really like to work on this issue but my experience in try-runtime is absolutely zero. This looks like you want a new fn in the impl frame_try_runtime::TryRuntime<Block> for Runtime Block that takes a range of blocks as an argument instead of the single block as execute_block does. Is that correct? So it would be a simple wrapper function using the already existing execute_block fn I'll just try to figure out a correct way to implement that function so it is available via the cli. Regarding the continous range, does it mean the new fn should check for the user that every block is in the correct order so a failure would be detectable before the actual execution?

This would probably require https://github.com/paritytech/substrate/issues/14150 (I did multiple runtime run (hacky change of onruntime upgrade in https://github.com/cheme/substrate/tree/try-runtime-mig and got add to patch with a memory-db that do not remove content in order to get some data).
(actually this branch could be use to simulate running multiple block on_init (which I needed to get input for state-trie-migration)

actually this is not directly related to the issue (I was thinking multiple block execution, but here it is pas block), I am removing my comment thus.

Moved to https://github.com/paritytech/try-runtime-cli/issues/11


Update documentation

Images courtesy of @cloudRoutine.

Why settings dialog is so huge? There is lots of empty space left on pages.

I don't know. I updated the screenshots to use smaller windows.


fix(overlay): Fixed broken components when blurring the tab

Explanation of the error:
A component opens the dropdown when a input got focus and closes the dropdown when blurred. The close works by adding a css class to animate the element and a listener removes mod-open class when the animation is done. When you focus the input and the dd is opened and then switch the tab, chrome and ff will trigger a blur event, the animation is started but actually chrome and ff are not rendering anything. When you then focus the original tab again, the input will be focused and the dropdown is opened and finally chrome renders the close animation^^ At this point the dropdown thinks it's open but it isn't and it's broken.
Solution
before starting the animation add another listener for window blurring to immediately call the callback like the animation would be done.

👍


Save WorkoutRouteHarmonized

I try to save a workout route harmonized but I git error
I try to save like this:
try {
      final canWrite = await HealthKitReporter.isAuthorizedToWrite(
        SeriesType.workoutRoute.identifier,
      );
      if (canWrite) {
        final now = DateTime.now();
        const duration = 60;
        final minuteAgo = now.add(Duration(seconds: -duration));
        final harmonized = WorkoutRouteHarmonized(
          10,
          [
            WorkoutRouteBatch([
              WorkoutRouteLocation(
                43.584231,
                -84.787381,
                281.000,
                10.0,
                null,
                null,
                20.0,
                2.0,
                null,
                minuteAgo.microsecondsSinceEpoch,
                10.0,
              ),
              WorkoutRouteLocation(
                43.582840,
                -84.787370,
                281.000,
                10.0,
                null,
                null,
                20.0,
                2.0,
                null,
                now.millisecondsSinceEpoch,
                10.0,
              ),
            ], true),
          ],
          null,
        );

        final workout = WorkoutRoute(
          'testWorkoutUUID',
          'bicycle',
          minuteAgo.millisecondsSinceEpoch,
          now.millisecondsSinceEpoch,
          device,
          sourceRevision,
          harmonized,
        );
        print('try to save: ${workout.map}');
        final saved = await HealthKitReporter.save(workout);
        print('workoutSaved: $saved');
      } else {
        print('error canWrite workout: $canWrite');
      }
    } catch (e) {
      print(e);
    }

Error
flutter: isRequested auth: true
flutter: try to save: {uuid: testWorkoutUUID, identifier: bicycle, startTimestamp:<PHONE_NUMBER>915, endTimestamp:<PHONE_NUMBER>915, device: {name: FlutterTracker, manufacturer: kvs, model: T-800, hardwareVersion: 3, firmwareVersion: 3.0, softwareVersion: 1.1.1, localIdentifier: kvs.sample.app, udiDeviceIdentifier: 444-888-555}, sourceRevision: {source: {name: myApp, bundleIdentifier: com.kvs.health_kit_reporter_example}, version: 5, productType: fit, systemVersion: 4, operatingSystem: {majorVersion: 1, minorVersion: 2, patchVersion: 3}}, harmonized: {count: 10, routes: [{locations: [{latitude: 43.584231, longitude: -84.787381, altitude: 281.0, course: 10.0, courseAccuracy: null, floor: null, horizontalAccuracy: 20.0, speed: 2.0, speedAccuracy: null, timestamp:<PHONE_NUMBER>915182, verticalAccuracy: 10.0}, {latitude: 43.58284, longitude: -84.78737, altitude: 281.0, course: 10.0, courseAccuracy: null, floor: null, horizontalAccuracy: 20.0, speed: 2.0, speedAccuracy: null, timestamp:<PHONE_NUMBER>915, verticalAccuracy: 10.0}], done: true}], metadata: null}}
Unsupported value: HealthKitReporter.HealthKitError.invalidValue("Invalid arguments: [:]") of type __SwiftNativeNSError
*** Assertion failure in -[FlutterStandardWriter writeValue:], FlutterStandardCodec.mm:338
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Unsupported value for standard codec'
*** First throw call stack:
(0x180f5370c 0x19868ef04 0x1826f4b00 0x103ded08c 0x103ded7ec 0x103dea7dc 0x10119ead8 0x1011b1e20 0x1011b0868 0x1011a5fbc 0x1011b0910 0x103dea744 0x103923c78 0x103cb1b3c 0x103bd9148 0x103bdceac 0x180f67c58 0x180ef14e8 0x180eec0a0 0x180ecbd94 0x180edec30 0x1a18f9988 0x1836d9c50 0x1834733d0 0x100d170dc 0x1010343d0)
libc++abi: terminating with uncaught exception of type NSException
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00000001bb6a1bbc libsystem_kernel.dylib`__pthread_kill + 8
libsystem_kernel.dylib`__pthread_kill:
->  0x1bb6a1bbc <+8>:  b.lo   0x1bb6a1bd8               ; <+36>
    0x1bb6a1bc0 <+12>: stp    x29, x30, [sp, #-0x10]!
    0x1bb6a1bc4 <+16>: mov    x29, sp
    0x1bb6a1bc8 <+20>: bl     0x1bb69d60c               ; cerror_nocancel
Target 0: (Runner) stopped.

Thanks.

@bazrafkan
Hi, currently there is a lack to save workout routes. It will be a separate method in new versions, because on the native side it should be implemented using HKWorkoutRouteBuilder. Please refer to https://developer.apple.com/documentation/healthkit/workouts_and_activity_rings/creating_a_workout_route


removing buckets does not remove the data

Deleting the bucket after points were written to it won't remove the points.

Jeff just completed the work related to deleting the data when buckets are deleted.


Linux VS Windows versions

Hi,
i was wondering if the two versions are the same and in sync .
and what about future developement for the two branches .
thanks

Hello. Current linux branch is a bit ahead of windows branch. We will update the windows branch soon.

so it's always recommended to use the linux version ?

so it's always recommended to use the linux version ?

Yes.

Ok Thanks for the quick response .
and for sharing this amazing piece of work <3


getting error at AddDefaultIdentity

[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b3668fea-5d71-a4fc-96d1-74b53906bf25
Version Independent ID: 980a23e7-56e4-da94-a139-cab85135c5f7
Content: Role-based authorization in ASP.NET Core
Content Source: aspnetcore/security/authorization/roles.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

The error message tells you everything you're missing.


cucumber-expressions: unable to differentiate between float and int for steb disambiguation

In the original cucumber (non @cucumber/cucumber), I could associate multiple step-definitions with the same gherkin statement and the correct step definition would be called based on type inference. for example, I could have:
  Scenario Outline: set a param on a device
    When I set <parameter> to <value>

  Examples:
  | parameter | value |
  | "age"     | 32    |
  | "weight"  | 180.0 |

I could have in my step_defintions
When('I set {string} to {int}', function (intParam, val) {...}

and
When('I set {string} to {float}', function (stringParam, val) {...}

and cucumber was able to find these by type inference. It worked well and allowed for a lot of code reuse.
However, when I do the same thing with @cucumber/cucumber, I get ambiguity failures because of the function overloading. This means I now need to have multiple gherkin statements where before I only needed one.
I would propose an option to infer type. I believe cucumber-ruby has a "--guess" option.
edit
It seems like there is simply an issue with cucumber differentiating between ints and floats in the .feature.

I think this will be an issue across cucumber-expressions implementations and I'm not sure there is really a solution.
(Please reopen if I'm wrong)


Apply MVVM pattern

Currently I have issue applying BackgrounWorker class to in ViewModel class for the Server project.

Fixed


Bad Indent Issue

Getting this error code:

<EMAIL_ADDRESS>start
ts-node --transpile-only src/index.ts

/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/composer.js:69
this.errors.push(new errors.YAMLParseError(pos, code, message));
^
YAMLParseError: All mapping items must start at the same column at line 41, column 1:
# If the date input is invalid or in the past, the app will automatically u…
startDate: ['05/31/2024']

^
at Composer.onError (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/composer.js:69:34)
at Object.resolveBlockMap (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/resolve-block-map.js:34:21)
at resolveCollection (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-collection.js:13:27)
at Object.composeCollection (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-collection.js:47:16)
at composeNode (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-node.js:31:38)
at Object.resolveBlockMap (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/resolve-block-map.js:81:19)
at resolveCollection (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-collection.js:13:27)
at Object.composeCollection (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-collection.js:47:16)
at Object.composeNode (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-node.js:31:38)
at Object.composeDoc (/workspaces/texas-dps-scheduler/node_modules/yaml/dist/compose/compose-doc.js:33:23) {

code: 'BAD_INDENT',
pos: [ 1803, 1804 ],
linePos: [ { line: 41, col: 1 }, { line: 41, col: 2 } ]
}

delete the config.yml file then copy it again


Docker image does not seem to work on linux/amd64

$ docker run -it --rm shayonj/pg_easy_replicate:latest pg_easy_replicate
WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v4) and no specific platform was requested
exec /usr/local/bundle/bin/pg_easy_replicate: exec format error

Seems like it's trying to run an arm version.
Version:
Docker version 24.0.2, build cb74dfcd85
I'm on latest Arch Linux on an intel i7 machine.

only arm version is published on dockerhub. Can you add at least  linux/amd64 ?

I will take a look at this soon and get the build pipeline going for other platforms

Docker image support for linux/amd64 and linux/arm64 is now out starting 0.1.3. https://hub.docker.com/repository/docker/shayonj/pg_easy_replicate/general
Thanks for report!


Version 1.1.0 bumps minimum compiler version

Version 1.1.0 bumps the minimum compiler version because of the use of associated constants. This is not a semver-compatible change and should be reverted.

There is no consensus on whether bumping the MSRV is a semver incompatible change or not.

My CI started failing overnight because of this release even though I employ lockfiles everywhere.

What does "employing lockfiles everywhere" mean? If your versions are locked, then you wouldn't pick up a new version with a higher compiler version requirement.

Yeah, I suppose that's quite puzzling. I've narrowed it down to an optional dependency that only gets activated through a particular feature. This dependency is not in the lockfile.

Possibly https://github.com/rust-lang/cargo/issues/3629

Yeh the 1.1.0 release didn't bump the minimum compiler version. The additional build.rs specifically exists to avoid bumping the minimum compiler version.

That might not be working correctly then:
02:00:25   --> /home/jenkins/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-1.1.0/src/heap_lazy.rs:17:5
02:00:25    |
02:00:25 17 |     pub const INIT: Self = Lazy(0 as *const T, ONCE_INIT);
02:00:25    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
02:00:25    |
02:00:25    = help: add #![feature(associated_consts)] to the crate attributes to enable
02:00:25
02:00:25 error: aborting due to previous error(s)
02:00:25
02:00:25 error: Could not compile `lazy_static`.

@jethrogb Oh are you compiling lazy_static on a compiler before 1.21.0? While we didn't bump our documented minimum supported version from 1.21.0 we might've bumped our technically supported minimum version by actually using a feature that stabilized close to 1.21.0?

I'm on 1.18

I'm on 1.18

we didn't bump our documented minimum supported version from 1.21.0

Documented where exactly?

Documented where exactly?

It's documented as the explicit version we test in Travis through our .travis.yml, but you could reasonably argue that totally doesn't count as documentation. It's clearly not discoverable...
Maybe we should adopt the approach some other crates take and stick a badge in the readme with our minimum version?

Digging a little deeper here...

Rust 1.21 was added to the CI config on Dec 8, 2017.
lazy-static 1.0.0 was released on Nov 29, 2017.
From testing, it looks like lazy_static 1.0.2's actual minimum Rust version is Rust 1.6.0.
From testing, it looks like lazy_static 1.1.0's actual minimum Rust version is Rust 1.20.0. (The documented minimum Rust version is Rust 1.21.0.) The version increase appears to have been caused by the use of associated constants.

There are no rigid policies on how to handle all of this, but it is a bit of a mess. This also means regex's documented minimum version is technically wrong because it is less than lazy_static's documented minimum version (a dependency of regex). I don't really know what to do about it. I'm not sure it's worth this amount of fuss at this point, at least until we get some sort of LTS release that core crates can rally around.

Hm it is a bit of a mess... I think we've made a few assumptions that lead to this specific case:

I assumed that because we test 1.21.0 explicitly in CI that it's our minimum version and bumping up to 1.21.0 is ok and expected
Others have assumed that because their library that depends on lazy_static happens to compile on a given version that lazy_static supports that version

Some sort of LTS release would nicely cut through those assumptions in the future. It seems like our efforts right now across the ecosystem to manage minimum versions are a bit too ad-hoc to scale.

It seems like our efforts right now across the ecosystem to manage minimum versions are a bit too ad-hoc to scale.

I agree. I watch the repos of (almost?) every dependency I use, including this one, and specifically look out for this and I still missed it. :-(


Open Link to Blog Entrys in "normal" BlogEntryViewer

If a blog entry contains a link to another blog entry, the new blog entry should be opened in the integrated viewer instead of a WebView.

Done!


Port #300 and #326 (image optimisation and cleanup of unused images) from Gridcoin-Site

Also ports extra optimisation from<PHONE_NUMBER>9d504c1e1c6500fc02e90cf5d5a863
Also accidentally ports e20ef1f899444cebfb0b0380135866f4134d128d cuz it got caught in a cherry-pick
I cannot locally test the guide pages so I'd imagine that it does not look right straight out of the gate. Please help test it.

This really needs to be squashed.  It's extremely hard to review when these commits are all overwriting one another.


nz_upload 移动端android上传图片

Reproduction link
https://stackblitz.com/edit/ng-zorro-antd-start-4l4uta?file=src/app/app.component.html
Steps to reproduce
使用android手机的时候 不像ios那样有拍照上传的功能 只有文件上传
What is expected?
'capture','camera' 添加这个属性能够在android上面可以看到拍照上传的功能
What is actually happening?
'capture','camera' 添加这个属性能够在android上面可以看到拍照上传的功能

Environment
Info

ng-zorro-antd
9.1.2

Browser
android 内置浏览器

Hi, antd is not totally compatible with mobile device. If Upload not work as expect, please try to use input instead.

This issue has been closed due to inactivity.
Please file a new issue or discussion if you are encountering a similar or related problem.


Shows esp8266 core outdated, even though I have 2.4.2 installed

According to the prerequisites for the library, esp8266 v2.4.0 or above must be installed. Recommended versions are 2.4.2 or 2.5.0.
I have 2.4.2 version installed. But compiling the code gives the error:
Arduino: 1.8.6 (Windows 10), Board: "NodeMCU 1.0 (ESP-12E Module), 80 MHz, Flash, 4M (1M SPIFFS), v2 Lower Memory, Disabled, None, Only Sketch, 115200"

Multiple libraries were found for "SD.h"
In file included from C:\Users\nikhil\Desktop\CODES\CODES\CODES.ino:13:0:

 Used: C:\Users\nikhil\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.2\libraries\SD
C:\Users\nikhil\Documents\Arduino\libraries\Firebase_ESP8266_Client\src/FirebaseESP8266.h:58:2: error: #error Your ESP8266 Arduino Core SDK is outdated, please update. From Arduino IDE go to Boards Manager and search 'esp8266' then select version 2.4.0 or above.

 Not used: D:\Arduino\libraries\SD
 #error Your ESP8266 Arduino Core SDK is outdated, please update. From Arduino IDE go to Boards Manager and search 'esp8266' then select version 2.4.0 or above.

  ^

exit status 1
Error compiling for board NodeMCU 1.0 (ESP-12E Module).

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

What is it that I am doing wrong?
Any help appreciated.

How about SD library at D:\Arduino\libraries\SD?
ESP8266 Arduino core lib has SD library too.
You need to remove or delete another SD library at SD library at D:\Arduino\libraries\SD

@mobizt Thanks for the quick response.
Tried that already, still get the following error
Arduino: 1.8.6 (Windows 10), Board: "NodeMCU 1.0 (ESP-12E Module), 80 MHz, Flash, 4M (1M SPIFFS), v2 Lower Memory, Disabled, None, Only Sketch, 115200"

In file included from C:\Users\nikhil\Desktop\CODES\CODES\CODES.ino:13:0:

C:\Users\nikhil\Documents\Arduino\libraries\Firebase_ESP8266_Client\src/FirebaseESP8266.h:58:2: error: #error Your ESP8266 Arduino Core SDK is outdated, please update. From Arduino IDE go to Boards Manager and search 'esp8266' then select version 2.4.0 or above.

 #error Your ESP8266 Arduino Core SDK is outdated, please update. From Arduino IDE go to Boards Manager and search 'esp8266' then select version 2.4.0 or above.

  ^

exit status 1
Error compiling for board NodeMCU 1.0 (ESP-12E Module).

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

You need to install ESP8266 Arduino Core SDK from Boards Manager.
Your core version may not released git version.
These are released git version that this library supported and also available in Boards Manager
2.5.0, 2.5.0-beta3, 2.5.0-beta2, 2.5.0-beta1, 2.4.2, 2.4.1, 2.4.0, 2.4.0-rc2, 2.4.0-rc1

I already have version 2.4.2, installed through the Boards Manager

I just fixed the issue and update.
Please delete the current version from library folder.
Down load the new one of v 1.0.5.
I don't change the version number due to I'm working on the new version.

@mobizt I just did that and it works perfectly. Thanks!


Feature update, refactoring, tests addition, Nuget package v1.0.5

Implicit wait manipulation removal.
Retry logic for failure to initialize web driver instance.
Shadow DOM HTML - Additional .CORE/.NET tests for zero implicit wait.
docker-compose.yml - Max node sessions update.
Increased parallel test run count.
Is (shadow root/nested shadow root) present, check logic update.
Nuget package creation - v1.0.5.

Codecov Report

Merging #20 (e594c1b) into main (de5b3aa) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #20   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines          108        96   -12
  Branches        10        10
=========================================
- Hits           108        96   -12

Impacted Files
Coverage Δ

ShadowRoot.Digger/ShadowRootAssist.cs
100.00% <100.00%> (ø)

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 de5b3aa...e594c1b. Read the comment docs.


[fix] tower: "buffer full; poll_ready must be called first"

When using AsyncInterceptor for tonic client through tower service, example:
let client_interceptor = ClientInterceptor::new().await?;
let auth_channel = tower::ServiceBuilder::new()
    .layer(async_interceptor(client_interceptor))
    .service(channel);
let client = ServiceClient::new(auth_channel.clone());

let response = client.get_user(Request::new(...)).await?;

it will face this error:
thread 'tokio-runtime-worker' panicked at 'buffer full; poll_ready must be called first',
.../tower-0.4.13/src/buffer/service.rs:146:14

This fix use the same solution mentioned in here https://github.com/hyperium/tonic/pull/624#issue-873757689

@nguquen  Thanks for the PR, I appreciate you tracking down the issue and fixing it. I vaguely remember seeing this issue when I first wrote this utility, but I can't remember why I didn't end up using mem::replace. Maybe because the tests passed and my use case worked without it.
Anyway, I'll merge this and publish a new version.

@nguquen v0.11.1 has been published to Cargo


dev: implementing a custom method to allow to rescan the utxos

See https://github.com/ElementsProject/lightning/issues/7172

Fixed in https://github.com/coffee-tools/folgore/pull/77


include/spirv_cross/sampler.hpp has wrong type for wrap_t

Hi, the file include/spirv_cross/sampler.hpp has a sampler wrap_t defined with the format type, which errors on recent versions of Clang.
https://github.com/KhronosGroup/SPIRV-Cross/blob/7d42fd7f7b8bd92a57a6a7745f9841a1128f58f7/include/spirv_cross/sampler.hpp#L88
When I change it to the following, the compile error goes away
spirv_cross_wrap wrap_t;

Fixed on master.


Consider a codecs sub-module that holds all codecs.

This will make the initial interaction with the project a bit easier to grok.

Does this mean that the codecs module will have additional sub-modules within for ilp, btp and ildcp? as codecs.ilp, codecs.btp and codecs.ildcp?

@sappenin Thoughts on this?

Does this mean that the codecs module will have additional sub-modules within for ilp, btp and ildcp? as codecs.ilp, codecs.btp and codecs.ildcp?

Yes, although I expect the maven module naming convention will be something like ‘codecs-btp’, ‘codecs-ilp’, etc. I think it makes sense to keep these as independent modules so we can publish individual jars for them in case someone wants to only include one particular codec maybe...


Document symlinking existing version of ruby to versions/ directory

In README, you are mentioning

Alternatively to the install command, you can download and compile Ruby manually as a subdirectory of ~/.rbenv/versions/. An entry in that directory can also be a symlink to a Ruby version installed elsewhere on the filesystem. rbenv doesn't care; it will simply treat any entry in the versions/ directory as a separate Ruby version.

Would it be possible to actually document what exactly to symlink there, or possibly create a tool for that? The motivation is, obviously, to use multiple versions of ruby already installed on system with tools like ruby-switch (debian) or eselect ruby (gentoo).

@hkmaly Sorry, but I believe that the current documentation is sufficient documentation. Example: you can either compile a Ruby version into ~/.rbenv/versions/1.2.3 or ~/.rbenv/versions/1.2.3 can be a symlink pointing to a location on your system where the corresponding Ruby version is installed.


Added self.deviceName in BLESession and other small changes

When logging the device it may be more useful to have the name print rather than "<bluepy.btle.Peripheral object at 0x************>"
The shorter device name will be used if the long name is not defined
Passing the device variable itself into Peripheral() will give the addr, addrType and the iface to the Peripheral()
and if a device doesn't have a long name defined it will use the short one in params['name']
Fixed some spelling mistakes

sorry for the messy commit history, I am still figuring things out with GitHub

Hi @ErrorJan , thank you for this work! I took a look in your changes. There have good intent. I like them, and picked up with some minor changes. They are all in the master branch now.
To make my merge task easier, it is the better your branch has only commits to be merged. It might be rather difficult to control git branches. If you are ok for me to cherry-pick your changes as I did, such pull requests with dirty branch is fine and welcomed.
Also, I added CONTRIBUTION.md to share what will help me to merge changes. It might be some more help.
Thank you again for the good changes!


Settings schema Error! with logseq-awesome-links

Info:

OS: Windows
Logseq ver: 0.10
Plugin ver: v1.15.16

Description:
After an upgrade of logseq to version 0.10 the plugin Awesome Links stopped working properly.
When clicking the settings icon I get the following error: Settings schema Error!
To Reproduce:

Go to settings
Go to plugin settings

Expected behavior:
It should show all the plugins installed and let you configure them.
Screenshots

The following may or may not be related to the above-mentioned issue but in general, the overall functionality of the plugin stopped working in general with the following observations:

The icons and colours that are configured in the properties for each page do not show up in the references.
When I try to uninstall or disable the plugin, I cannot do so [have to resort to physically deleting the folder on the hard drive].

I figured out the problem and consequently fixed it, here are the steps that I followed to resolve the issue:

Go to: C:\Users<username>.logseq\settings\logseq-awesome-links.json
Observe that the file contains a collection of NULL values as seen in the screenshot below
Replace the content of the file with {}
Re-load logseq: the file will be rebuilt to contain proper settings
All functionality will be restored afterwards


ru toc for Extender

Sorry, this project is old and abandoned, therefore I'm not accepting any pull requests.


Upgrade ANP dependency to v0.1.1

Signed-off-by: xuezhaojun<EMAIL_ADDRESS>Fixes: https://issues.redhat.com/browse/ACM-2840

/assign @skeeey

/lgtm


⚠ ClamAV has degraded performance

In e1282ee, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 209 ms

Resolved: ClamAV performance has improved in 4552c16.


运行报错

精彩的工作，感谢作者的分享。
1. A100(80g)*16 + HLLM/reproduce/HLLM-Books-neg512.sh进行训练，并对脚本做了部分修改（epoch=1, num_negatives=32），worker节点爆显存错误，具体错误如下：
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 16.46 GiB. GPU 0 has a total capacty of 79.17 GiB of which 11.75 GiB is free. Including non-PyTorch memory, this process has 67.41 GiB memory in use. Of the allocated memory 59.52 GiB is allocated by PyTorch, and 6.98 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
2. A100(80g)*16 + HLLM/reproduce/HLLM-Books-neg512.sh进行训练，并对脚本做了部分修改（epoch=1, num_negatives=1），worker节点爆Lightning相关错误，具体错误如下：
Traceback (most recent call last):
File "/home/work/code/HLLM/code/run.py", line 139, in
run_loop(local_rank=local_rank, config_file=config_file, extra_args=extra_args)
File "/home/work/code/HLLM/code/run.py", line 110, in run_loop
best_valid_score, best_valid_result = trainer.fit(
File "/home/work/code/HLLM/code/REC/trainer/trainer.py", line 329, in fit
self.lite.launch()
File "/home/work/miniconda3/envs/img/lib/python3.10/site-packages/lightning/fabric/fabric.py", line 843, in launch
return self._wrap_and_launch(function, self, *args, **kwargs)
File "/home/work/miniconda3/envs/img/lib/python3.10/site-packages/lightning/fabric/fabric.py", line 928, in _wrap_and_launch
return launcher.launch(to_run, *args, **kwargs)
File "/home/work/miniconda3/envs/img/lib/python3.10/site-packages/lightning/fabric/strategies/launchers/subprocess_script.py", line 101, in launch
self.cluster_environment.validate_settings(num_devices=self.num_processes, num_nodes=self.num_nodes)
File "/home/work/miniconda3/envs/img/lib/python3.10/site-packages/lightning/fabric/plugins/environments/torchelastic.py", line 90, in validate_settings
raise ValueError(
ValueError: You set devices=8 and num_nodes=16 in Lightning, but the product (8 * 16) does not match the world size (16).

self.lite = L.Fabric(accelerator='gpu', devices=world_size, strategy=strategy, precision=precision, num_nodes=nnodes)
set param devices=world_size to match your num_nodes


Sending FormData from NodeJS

I am attempting to send data from a NestJS application to SpeechSuper and having a rather difficult time of it. So far I have not made a successful request to the SpeechSuper API and I have run out of ideas to try.
When I attempt to submit a multipart/form-data request with Axios, regardless of whether I serialize the data manually or simply pass a FormData object, I get a serialization error that appears to be related to the FormData class itself because it occurs even if I do not add anything to the native or form-data-provided FormData object.
However, when I try to use the form-data package's submit method as in the SpeechSuper NodeJS sample, the method does not accept a target URL (only a protocol) and keeps trying to post the data to localhost. In other words the sample given does not appear to work.
How is sending a request from Node supposed to work if the API requires FormData? Is a websocket connection a potential workaround?
Environment info:

Node v18.19.1
form-data 4.0.0
axios 1.7.2

Issue resolved with Qiusi via email. Apparently related to network configuration.


init and launch: implement profiles

lxc init ubuntu u9 -p ab -p cd
should result in proviles ab and cd both being applied to u9.
Signed-off-by: Serge Hallyn<EMAIL_ADDRESS>

So this branch now hardcodes "default" into the client. While not a big deal, is there really no easy way simply not to pass "profiles" over the REST call if no profile was specified by the user?

There's an easy way, I was just concerned that it would end up harder to read/review/maintain.
I've tried to address that by renaming the emptyprofiles variable, and am pushing the result.


Forcing JSON withouth *.json

Hello there,
even if I run the risk that it has been asked in the past, but how do i force JSON as content type without adding ".json" to the url?
I'm trying to develop a plugin, where I need to set up an API. Is it possible to use some method/value in the Page object?
Regards,
Michael

I had a PR related to this that ultimately died. I'm now working on fixing the arbitrary error code issue and then I'm going to try issuing my PR again. I agree that Grav should be fully capable of understanding and responding to the Accept header, but currently I can't get the core to issue the appropriate 406 Not Acceptable code.

Hi @Perlkonig,
uuhhhh seems like I asked for a complex topic.  Is there a way to force the content type inside the coding?
I mean yeah it would be nice if Grav would react on the Accept attribute of the header, but isn't there any other way?

I had forgotten about that. We need to add that to the Headers / Frontmatter page, methinks.

Definitely should add it... if someone wants to add it as a PR on learn, that would help! :)

I will do my best.

Sorry. It's already there. Somehow I missed it.
So, @mgollmer, if indeed you want your page to always return JSON, just add template_format: json in your frontmatter and Grav will automatically apply the appropriate *.json.twig template.

UHHHH!!! Cool!
Thanks @rhukster! I must have scrolled over it. Just saw template, but not templateFormate. Thank you very much!


Making Phyloseq Object with No Tree File?

I am trying to exclude the tree file for an analysis that is going to use merge_phyloseq and the tree files just mess everything up.
When I try to leave out the tree file, I get an error. Is there a way to exclude the tree file?

I found a solution for my exploratory analysis - probably only works for my data so I would be interested ot hear overall if there is a way to just exclude trees for the future!


docs issue: clarify initializable parameter

The docs give all indication that initializable is a boolean but there's a comment that says
        readonly:
          required: true
          # This can't be updated once the object is created.
          mutable: false
          # But we do allow this to be set at creation time.
          # If omitted, `initializable` defaults to the value
          # of `mutable.
          initializable: true
          schema:
            type: string

what does a value of mutable mean for this parameter? What's the interaction with the mutable parameter? Clarification appreciated.

what does a value of mutable mean for this parameter? What's the interaction with the mutable parameter? Clarification appreciated.

Thank you, good catch!
In this case, what the comment is trying to say is that if you don't specify initializable, we'll use whatever value you specified for mutable. So if mutable: true, then initializable defaults to true. If mutable: false, then initializable defaults to false.


fix: fix jenkins k8s plugin version error

Fix issue https://issues.jenkins.io/browse/JENKINS-70639?jql=project %3D JENKINS AND component %3D kubernetes-client-api-plugin

@purelind: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

debug/prow-call-jenkins
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-jenkins

Full PR test history.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@purelind: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

debug/prow-call-jenkins
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-jenkins

debug/prow-call-nested-jenkins-job
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-nested-jenkins-job

Full PR test history.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/lgtm

@purelind: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

debug/prow-call-nested-jenkins-job
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-nested-jenkins-job

debug/prow-call-jenkins
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-jenkins

Full PR test history.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@purelind: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

debug/prow-call-jenkins
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-jenkins

debug/prow-call-nested-jenkins-job
b34824a835f6f97a7a92695a08e3a716a8d4ec54
link
true
/test prow-call-nested-jenkins-job

Full PR test history.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Missing using Xpand.XAF.Modules.Reactive.Services;

using Xpand.XAF.Modules.Reactive.Services; was missing from two files causing a failure to build in Xpand.ExpressApp.ExcelImporter.Win

I do not understand how can a build fails? since it is already published.

When I open the AllModules in Visual Studio and attempt to build, there are build errors. When the using statements are added, the build errors go away.

did u attempt to build.ps1 first?

Yes, the failure happened with build.ps1 first, then I opened in Visual Studio to find the problem.

what I meant before is that Azure builds use the Build.ps1 and the AllModules.sln and they do not fail. Anyway thanks for the PR I will check it

Look at the log at this page. It is failing.
https://dev.azure.com/eXpandDevOps/eXpandFramework/_build/results?buildId=4801

Line 654 through 660 of the build log failure is what my change fixes.

There is another failure on line 670 which I am attempting to find a fix for as well, but it is unrelated to this.

yes i see now thnks

the build u are working though it fails, so it means that is under works. New packages are introduces so the usings are complain. The plan is to integrate paket b4 release https://fsprojects.github.io/Paket/

Sounds great. So for now the lab will not build, is that correct? I was trying to verify the Dashboard defect that still doesn't work. Instead of asking you, I was trying to be helpful and fix it myself. ;)

thanks for the help feel free to fix anything it makes sense, I can let the build pass if u need it once u verify that it does work on your side.

There was a missing dependency in the Xpand.ExpressApp.ExcelImporter.Web and XVideoRental.Module.Win csproj file for Extensions. Once I added this back, I get a clean build.ps1
There is still an issue with the Executing VSIX part of build.ps1 though.....
Executing VSIX
MSBuild auto-detection: using msbuild version '16.2.37902.0' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin'.
InvokeScript :
SerializedRemoteException      :
SerializedRemoteInvocationInfo :
ErrorRecord                    : D:\NewGithub\eXpand.lab\Xpand.Plugins\Xpand.VSIX\Xpand.VSIX.csproj(278,11): error MSB4226: The imported project "C:\Program Files
(x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VisualStudio\v16.0\VSSDK\Microsoft.VsSDK.targets" was not found. Also,
tried to find "VSSDK\Microsoft.VsSDK.targets" in the fallback search path(s) for $(VSToolsPath) - "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v16.0" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual
Studio\2019\BuildTools\MSBuild\Current\bin\msbuild.exe.Config". Confirm that the path in the  declaration is correct, and that
the file exists on disk in one of the search paths.
WasThrownFromThrowStatement    : True

I was missing some components in Visual Studio for the VSIX items. I can now confirm that this PR gives a clean build.ps1


how to use externs or interop for go code?

if i want to use standart go libs with this grympy code - how i can do this?

Hi, 6ump.
You can import from '__go__' to get stuff from Golang libs.
Please take a look on the math.py implementation, that uses from '__go__/math' import: https://github.com/grumpyhome/grumpy/blob/7370a936adc980d998f769efc56db0d820cce053/grumpy-runtime-src/lib/math.py#L15

Hi, 6ump.
You can import from '__go__' to get stuff from Golang libs.
Please take a look on the math.py implementation, that uses from '__go__/math' import: https://github.com/grumpyhome/grumpy/blob/7370a936adc980d998f769efc56db0d820cce053/grumpy-runtime-src/lib/math.py#L15

from 'go/math' import Pi
print Pi

this output

grumpy run test.py
3.14159265359

but this

 import "__go__/encoding/hex"
 print hex.Dump('foobar')

output error
grumpy run test.py
/tmp/tmp8Y9Chn__pycache__/gopath/src/python/main/module.go:4:2: cannot find package "python/go/encoding/hex" in any of:
/usr/lib/go/src/python/go/encoding/hex (from $GOROOT)
/tmp/tmp8Y9Chn__pycache__/gopath/src/python/go/encoding/hex (from $GOPATH)
/home/user/.local/lib/python2.7/site-packages/grumpy_runtime/data/gopath/src/python/go/encoding/hex

Can you post the output of grumpy -v debug run test.py instead?

grumpy -v debug fail.py                                                                                :(
info: GOPATH: /home/user/.local/lib/python2.7/site-packages/grumpy_runtime/data/gopath
info: __main__ pycache folder: /tmp/tmphOSzQ___pycache__
debug: Should transpile '__main__'
debug: Dependencies file regenerated
info: `go run` GOPATH=/tmp/tmphOSzQ___pycache__/gopath:/home/user/.local/lib/python2.7/site-packages/grumpy_runtime/data/gopath
debug: Starting subprocess: `go run /tmp/tmphOSzQ___pycache__/gopath/src/__python__/main.go`
/tmp/tmphOSzQ___pycache__/gopath/src/__python__/__main__/module.go:4:2: cannot find package "__python__/__go__/encoding/hex" in any of:
	/usr/lib/go/src/__python__/__go__/encoding/hex (from $GOROOT)
	/tmp/tmphOSzQ___pycache__/gopath/src/__python__/__go__/encoding/hex (from $GOPATH)
	/home/user/.local/lib/python2.7/site-packages/grumpy_runtime/data/gopath/src/__python__/__go__/encoding/hex

i found one folder with python/go
and here is this files
/home/user/.local/lib/python2.7/site-packages/grumpy_runtime/data/gopath/pkg/linux_amd64/python/go
.
./math
./math/rand.a
./io
./io/ioutil.a
./reflect.a
./grumpy.a
./time.a
./math.a
./syscall.a
./unicode.a
./os.a
./runtime.a
./path
./path/filepath.a
./sync.a


AWS Device Farm integration

Is any plan for creating an example how to integrate with AWS Device Farm? Currently i trying to do that but without any success.

Hi @azetor .
No, right now it seems to be out of selenide-appium scope.
But feel free to share your result if you succeed.

Hi @azetor .
No, right now it seems to be out of selenide-appium scope.
But feel free to share your result if you succeed.