[pigeon] redirect pigeon resources to ffi

I've cross posted this in the ffi repo:
https://github.com/dart-lang/ffi/issues/58
@gaaclarke
So I want to express what I'm sure will be a controversial opinion.
The nub of the idea is to drop the pigeon project and instead focus all resources onto ffi.
Background:
I'm the author of the Sounds project:
https://pub.dev/packages/sounds
One of the big issues we are grappling with is having to be across four development languages:
Dart
Java
Objective-C
Swift
This is a significant problem for getting resources applied to the project and has the core team bumbling around with languages that they just aren't familiar with.
We have been experimenting with ways to make the project easier to maintain.
The first thing we looked at was converting all of the objective-c to swift as swift is a simpler language and more 'dart' like than objective-c.
This helped some but we still had bits of objective-c left in the code for bridging purposes and we are still not swift experts (or even novices).
Next we had a look at pigeon for a couple of reasons.

we liked that it largely managed channels for us.
we hoped it would take care of some of the bridging code (not so much).
we liked the concept of a federated model (yes not pigeon specific but it helped).

We did an initial implementation with pigeon and the process actually helped us improve our platform api but it did nothing to reduce the no. of languages that we needed to support.
So we are now looking at ffi and dart-native.
https://pub.dev/packages/dart_native
The dart-native project is useful but still very primitive however its clear (to our team at least) that using ffi is a much better path than pigeon.
Once we complete the ffi work we should go close to eliminating all objective-c, swift and java code.
This will make our project much simpler to maintain and should make it easier to get additional contributors.
The biggest stumbling block is that, whilst dart-native, helps we are still having to implement ffi wrappers for large parts of the ios api (and currently all of the java api).
My view is that pigeon is really just a stop gap measure and long term I don't see pigeon being a part of the dart ecosystem.
As such I'm arguing that rather than wasting resources on a stop gap measure those resources would be better placed on completing ffi, improving the documentation and providing a complete set of ffi mappings for the ios and android apis.
I understand that this will be a large task but it is one that could be rolled out progressively and one that the community could easily contribute to by backfilling apis that they need them.
Summary

stop work on pigeon
commence work on providing a full set of dart api wrappers for the android and ios libraries.
improve the ffi documentation with more worked examples.
Encourage the community to contribute api wrappers.

Thanks @bsutton for writing out your thoughts.  Reducing the number of languages was never a goal for Pigeon since many plugins / add-to-app developers want to integrate with the platform libraries.  Only a subset of use-cases could be fully implemented with a host handler written in C/C++.  If you want to do that today I think you are right to consider FFI.  It was never a problem Flutter channels addressed and so by extension Pigeon didn't prioritize addressing it.
If we were to support that use-case in Pigeon we'd have to probably expose the Flutter channels API for C/C++ and create a new code generation target.  It gets a bit tricky on Android since the project needs to be setup correctly to compile and link in a C/C++ library.  I can throw up another issue so we can track that use case, but frankly the backlog for Pigeon is large I'm still working with many clients to figure out how to prioritize them.
Here's the use cases where FFI is the better choice over Pigeon today:

You want synchronous handling of host messages (this plans to be addressed at some point)
You want to call a C/C++ library on android (your use case, for the sake of sharing code)

To be clear, my use case isn't to call a custom c/c++ library but rather to
make calls into the native sdk on each platform.
My post wasn't really about my own use case but rather the wider
communities use case.
We already have a path forward for our project but I see a significant
problem for flutter developers is the requirement to work in multiple
languages.
What I desire is a way to build any dart application/package without having
to write any native code (swift/object-c/java/c/c++).
FFI is the beginning of a way to achieve this.
Whilst I appreciate what you are trying to do with pigeon, my argument is
that it's a distraction from what the end goal should be - build any
flutter app in dart only.
My assumption was that you were part of the dart core team and hence I was
advocating that time on pigeon would be better spent on building on ffi to
provide complete access to the native apis.
On Thu, 12 Nov 2020 at 06:08, gaaclarke<EMAIL_ADDRESS>wrote:

Thanks @bsutton https://github.com/bsutton for writing out your
thoughts. Reducing the number of languages was never a goal for Pigeon
since many plugins / add-to-app developers want to integrate with the
platform libraries. Only a subset of use-cases could be fully implemented
with a host handler written in C/C++. If you want to do that today I think
you are right to consider FFI. It was never a problem Flutter channels
addressed and so by extension Pigeon didn't prioritize addressing it.
If we were to support that use-case in Pigeon we'd have to probably expose
the Flutter channels API for C/C++ and create a new code generation target.
It gets a bit tricky on Android since the project needs to be setup
correctly to compile and link in a C/C++ library. I can throw up another
issue so we can track that use case, but frankly the backlog for Pigeon is
large I'm still working with many clients to figure out how to prioritize
them.
Here's the use cases where FFI is the better choice over Pigeon today:

You want synchronous handling of host messages (this plans to be
addressed at some point)
You want to call a C/C++ library on android (your use case, for the
sake of sharing code)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/70254#issuecomment-725606267,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG32OCZ2XUFB6FQIE4XXO3SPLOMHANCNFSM4TRMG2NQ
.

I see a significant problem for flutter developers is the requirement to work in multiple languages. What I desire is a way to build any dart application/package without having to write any native code (swift/object-c/java/c/c++). FFI is the beginning of a way to achieve this. Whilst I appreciate what you are trying to do with pigeon, my argument is that it's a distraction from what the end goal should be - build any flutter app in dart only.

It's not clear to me from your description how you've come to the conclusion that the languages themselves are the problem. There is a lot of complexity involved in understanding the API structures, SDK idioms, etc. for multiple platforms; language is only a portion of that. Importantly, the language the SDK is designed for is often strongly reflected in the APIs themselves.
As an example, consider this code, which is from an FFI-based Windows implementation of a plugin. This code is not actually much more understandable to a Dart developer with no Win32 experience than the corresponding C code would be (and in some ways is actually more complex, because understanding it now involves knowing both Win32 idioms and FFI details). Language projections into Dart from a bunch of very different SDKs written for very different languages aren't going to solve those problems.
Your fundamental assumption here seems to be that writing platform-specific code against platform-specific SDKs in Dart is inherently superior to writing platform-specific code against platform-specific SDKs in the platform's standard language. Your team may find that to be the case, but teams with different structure/background are likely to have the opposite viewpoint. Which leads into the fact that:

stop work on pigeon

is completely unrelated to:

commence work on providing a full set of dart api wrappers for the android and ios libraries.
improve the ffi documentation with more worked examples.
Encourage the community to contribute api wrappers.

I encourage you to file issues that just provide specific details of things you want improved in FFI, rather than trying to approach this from the standpoint of trying to make project management/resource allocation requests, as doing the latter is just going to distract from evaluation of the merits and priority of the former.

So firstly I think you may have somewhat mis-understood the objective.
I'm not looking for the typical developer to have to interact with FFI but
rather have a community effort to provide dart wrappers for the platform
sdk's (yes I know this is a large effort hence the community involvement).
Oddly enough my background is actually in win32/C development but these
days I'm a java/dart/javascript developer.
I don't agree that having to understand the idioms of something like win32
requires a deep understanding of C and I certainly wouldn't equate the
complexities of understanding an api with that of understanding a complete
language (or in the flutter cases a minimum of three languages). I've
worked professionally with something like 20 languages so I have some
understanding of the effort to get up to speed with a language compared to
that of an api.
I've been involved with numerous projects that do cross language
development (C->java, C-pascal, java->C, c->ole, java->ole, basic-> C,
dart->java, dart->swift, dart->c) as well as projects that simply use a
different backend language to a front end language.
My involvement in these projects has been both as a project manager and as
a developer.
As a more recent example we are currently porting the Sounds project from
ObjectiveC/swift to ffi.
We have most of the ios platform calls mapped into ffi and the team is
already reporting productivity improvements.
The team is now saying it is easier to maintain the ios code than the
android code (android is still using pigeon at this point). The team has no
real swift/objective-c experience.
Previously it was the other way around (android was easier than ios).
The general process is that you build wrapper classes for each of the
foreign api interfaces and then you can forget about them.
So I would strongly disagree your statement that:
'Language projections into Dart from a bunch of very different SDKs written
for very different languages aren't going to solve those problems.'
The above noted experience of our team also goes against this statement.
(if the statement was correct, moving to ffi should have made the ios
support harder).
I don't see any api as more difficult than another, just because it was
written in a different language. You deal with the type mappings and the
memory management and then you are simply dealing with yet another api.
There are almost no scenarios where developing a project in different
languages is more efficient than developing in a single language. I've
worked cross language many times, on many projects, it's simply expensive.
The exceptions to this revolve around existing code bases and human
resources. The FFI path still allows these teams to develop in their
language of choice.
The two issues (pigeon vs wrappers for ffi) are not unrelated.
Both have the single objective of making calls from dart into platform code.
The path I'm suggesting makes the pigeon project obsolete and will provide
a huge boost to the flutter communities productivity.
I do agree with your statement that requesting a resource re-allocation is
a risky path forward (as you note it can distract from the core premise) on
the other hand we should be able to talk about what is best for the flutter
community in an open manner.
On Thu, 12 Nov 2020 at 09:46, stuartmorgan<EMAIL_ADDRESS>wrote:

I see a significant problem for flutter developers is the requirement to
work in multiple languages. What I desire is a way to build any dart
application/package without having to write any native code
(swift/object-c/java/c/c++). FFI is the beginning of a way to achieve this.
Whilst I appreciate what you are trying to do with pigeon, my argument is
that it's a distraction from what the end goal should be - build any
flutter app in dart only.
It's not clear to me from your description how you've come to the
conclusion that the languages themselves are the problem. There is a lot of
complexity involved in understanding the API structures, SDK idioms, etc.
for multiple platforms; language is only a portion of that. Importantly,
the language the SDK is designed for is often strongly reflected in the
APIs themselves.
As an example, consider this code
https://github.com/flutter/plugins/blob/25957033132ac17094e82bec58e429fac073a483/packages/path_provider/path_provider_windows/lib/src/path_provider_windows_real.dart#L118-L141,
which is from an FFI-based Windows implementation of a plugin. This code is
not actually much more understandable to a Dart developer with no Win32
experience than the corresponding C code would be (and in some ways is
actually more complex, because understanding it now involves knowing
both Win32 idioms and FFI details). Language projections into Dart from
a bunch of very different SDKs written for very different languages aren't
going to solve those problems.
Your fundamental assumption here seems to be that writing
platform-specific code against platform-specific SDKs in Dart is inherently
superior to writing platform-specific code against platform-specific SDKs
in the platform's standard language. Your team may find that to be the
case, but teams with different structure/background are likely to have the
opposite viewpoint. Which leads into the fact that:
stop work on pigeon
is completely unrelated to:
commence work on providing a full set of dart api wrappers for the android
and ios libraries.
improve the ffi documentation with more worked examples.
Encourage the community to contribute api wrappers.
I encourage you to file issues that just provide specific details of
things you want improved in FFI, rather than trying to approach this from
the standpoint of trying to make project management/resource allocation
requests, as doing the latter is just going to distract from evaluation of
the merits and priority of the former.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/70254#issuecomment-725703346,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG32OGMUTGIEXQVIWQJXTLSPMH4PANCNFSM4TRMG2NQ
.

I'm not looking for the typical developer to have to interact with FFI but rather have a community effort to provide dart wrappers for the platform sdk's (yes I know this is a large effort hence the community involvement).

This is essentially equivalent in scope to the entire Flutter plugin ecosystem, and so isn't at all comparable to Pigeon. Given that, I'm even less clear on why you are trying to make this about stopping work on Pigeon.
What, exactly, is your specific, actionable request to the Flutter project here?

I don't agree that having to understand the idioms of something like win32 requires a deep understanding of C

Having watched Flutter developers who have never used a C-like language try to understand the calling semantics of Win32 APIs, we'll have to agree to disagree here.

The general process is that you build wrapper classes for each of the foreign api interfaces and then you can forget about them. So I would strongly disagree your statement that: 'Language projections into Dart from a bunch of very different SDKs written for very different languages aren't going to solve those problems.'

Well, that's not really disagreeing; what you are describing is not a language projection. I thought you meant actual language projections, since you were suggesting it as a replacement for Pigeon.

The two issues (pigeon vs wrappers for ffi) are not unrelated. Both have the single objective of making calls from dart into platform code.

They are not unrelated, but as I mentioned above they have dramatically different scope.

on the other hand we should be able to talk about what is best for the flutter community in an open manner.

Separating highly separable requests does not reduce the openness of discussion. We use the issue tracker to track and prioritize bugs and feature requests, which are inputs to resource allocation. "Stop working on pigeon" is neither, so the issue tracker isn't the right place for that discussion. Given that, I don't see any outcome for this other than being closed as not relevant to the issue tracker if you focus the discussion on that.
If, on the other hand, you can provide concrete feature requests, those can be considered (and prioritized against other efforts, including but not limited to, Pigeon).

So for a moment let's accept your premise that dart developers will have trouble understanding c/windows or objective/ios.
Pigeon does not solve this problem.
With pigeon you require developers to understand pigeon/objective-c/ios libraries.
With ffi you only require the developers to understand ffi/ios libraries.
So how can pigeon be a better solution? Developers must still understand the ios api as well as 'Objective C'.
Of course it's actually worse than that.
With pigeon you actually require developers to understand pigeon/objective-c/java/platform libs. And thats with only two target platforms. How many more languages will be required to deal with all of the target platforms. Javascript,C#,....
With ffi you only require ffi/platform libs.
Once the wrappers are built (either in pigeon or ffi) then you are completely in dart land so it makes no difference after that.
With the cross language projects I've worked we normally assign a single resource to create the wrappers.
After that person comes up to speed with the rules of wrapping an object or function this process is largely boiler plate code.
If the core dart team needs access to a new api the ask the api guy to add a new wrapper.
The dart-native project is actually trying to automate this process and does a moderate job of generating wrappers for ios.
So now we have changed our project from needing skills in dart/java/objective-c/C/JavaScript/C#/platform libs to dart/platform libs with a single resource required to manage the api calls (even on a large project this is usually only a part time job and after the front loading its often only a couple of hours a week). I've been this resource on multiple projects.
You then start to get a compounding effect with the dev team. As everyone is using the same language your teams overall skills set in dart grows much faster as everyone can help everyone else.
You then get to share all of your code. With Sounds there are significant amounts of code that is 'common' across ios and android but has to be written twice. With ffi these will collapse down to a single code base.

equivalent in scope to the entire Flutter plugin ecosystem

There is no intent to replace the flutter ecosystem. Part of the reason for the community involvement is to ensure that we implement wrappers for the pieces we need to fill out the missing bits of flutter (e.g. sounds). My preferred path is actually the creation of automation tools that generate the wrappers. But having a project that exposes commonly used apis would be extremely useful.
I'm not certain what you mean by the term 'language projection'? When I create a wrapper for ffi the aim is to make the api as 'dart' native as possible. For instance a 'C' string should always be converted to a Dart string at the wrapper interface. Users of the wrapper libraries shouldn't have to be concerned with platform specific types (e.g. uint8 or pointers).

dramatically different scope.

This I disagree with. The core objective of both technologies is to call platform apis, everything else is an implementation detail.

which are inputs to resource allocation. "Stop working on pigeon" is neither

This issue is exactly that. 'inputs to resource allocation'.
The problem is that you are taking a periocial view of this issue.
When you look at the ffi/pigeon as single development effort (make it easy to call platform apis) then this feature request is about redirecting resource like every other bug/feature request is.
The feature requests here is to achieve the most optimal path to making platform specific calls.
The fact that this requests covers off two project seems to be part of the difficulty in accepting the point of this issue.
Rather this issue should be viewed as a feature request that is asking the two development team to stop and reflect on what the ultimate goal is and combine their resources.
The discussions here suggest to me that there hasn't been sufficient consideration of where pigeon and ffi will end up and a lack of understanding of what the real goal is.
I will raise a second issue on the ffi project to automate the creation of wrappers and to create a per platform package that exposes commonly used apis.  But my core request in this issue - to cease pigeon development - stands.
Hopefully we can see past the 'sunk costs fallacy' and stop for a moment and look at the bigger picture.
My point here is not to be derogative of the work done with pigeon but to point out that it has become redundant and that there is a better pathway forward.

which are inputs to resource allocation. "Stop working on pigeon" is neither

This issue is exactly that. 'inputs to resource allocation'.

Please don't selectively edit my comments to change their meaning. What I said was "We use the issue tracker to track and prioritize bugs and feature requests, which are inputs to resource allocation. "Stop working on pigeon" is neither". As in, neither a bug report nor a feature request.

But my core request in this issue - to cease pigeon development - stands.

As I've said above, the issue tracker is not the right place for that conversation. If that's the core request here, then closing per my comment above.
If you have concrete suggestions for improving FFI, please file them.

Can you please re-open this issue as closing it at this point in the conversation is poor form.
I didn't selectively edit you comment to changing the meaning. I selected the core piece of text to try and get you to understand that issues are all about resource allocation which is exactly what I'm talking about.
From my perspective you are currently driving a bus over cliff  (yes a little melodramatic) and I'm saying 'hey let's stop the bus' and your saying 'if your not going to help steer the bus over the cliff then your not helping'.

the issue tracker is not the right place for that conversation

If the issue tracker isn't the right place then where is? This is the only forum that I'm aware for long form conversations over this sort of issues. And as I've said before this is all about resource allocation so it is the correct place.
I also note that you haven't responded to any of my points regarding your arguments supporting pigeon.

Can you please re-open this issue as closing it at this point in the conversation is poor form.

I've explained that the conversation you want to have is off-topic for this forum, which is why it's closed.

to try and get you to understand that issues are all about resource allocation which is exactly what I'm talking about.

You can of course use issues however you like in your own projects, but as I've said several times, we don't use the issue tracker as a discussion forum for resource allocation.

If the issue tracker isn't the right place then where is?

The flutter-dev mailing list seems like a reasonable option, or there are various other general discussion forums (e.g., r/FlutterDev, Medium) where you could pitch your viewpoint on how the Flutter community should allocate engineering resources.


Safari and Mozilla error: ...in a lexically nested statement

Hi @ArunMichaelDsouza
I found an error in safari and mozilla related with the 'strict mode' is interpreted for this couple a browsers, they are giving the follow error:

I,ve test it and It's working fine in Chrome, Mozilla and Safari now
Any comments please let me know

Hi @gsalgadotoledo, thanks for catching this bug. The fix has been merged.


 This is reference #230, where self.player.freeze and 180 <= pygame.time.get_ticks() - self.jump_timer: -- this is what I'm thinking should work

Yea, I'll put it to 150 first, if the jumping early bug persists we can increment it up to 180

got it


nixos/xandikos: use systemd socket activation

Description of changes
Xandikos' handling of listening addresses is quite buggy. There were multiple bugs regarding socket activation, which caused it to also listen on unwanted default ports. Additionally the metrics port reuses the listen address.
To avoid all this unexpected behaviour we run Xandikos in a private network namespace and let systemd handle our wanted listening adresses. Optionally the metrics are made accessible in the host's network namespace through xandikos-metrics.service using systemd-socket-proxyd.
Depends on https://github.com/NixOS/nixpkgs/pull/253612.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[x] (Module updates) Added a release notes entry if the change is significant
[x] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Rebased onto https://github.com/NixOS/nixpkgs/pull/253612.


Option Type Registry, plus many other features

Merged in hidden-options and the refactor to pull out the Option class from kbrock and aryeh-looker's branches
Added an option-type registry concept so that trollop could be extensible with user defined types.  This was a pretty significant code change.  Changed Option class to OptionDispatch, removed some constants and methods.  Changed api, but did not break any existing tests to do so.
Added two parser-level settings to Parser.new:

prevent default creation of short-options (as opposed to specifying :short=>:none for all of them
allow inexact match for long-options as long as the match is unambigious.  This is similar to Perl's Getopt::Long.  E.g: options :applesauce and :apricot are minimallly callable with --app and --apr.

All previous tests for trollop 2.1.x still pass, and tests have been added to cover new functionality, including some examples of user-defined registered types.  I regret the quantity of changes here, probably too much for one PR.

Coverage increased (+2.9%) to 96.514% when pulling 4d39d6f5da78f3dbd55e8585c2f06158f48fcca2 on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+2.9%) to 96.514% when pulling 4d39d6f5da78f3dbd55e8585c2f06158f48fcca2 on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+2.9%) to 96.514% when pulling 4d39d6f5da78f3dbd55e8585c2f06158f48fcca2 on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+3.0%) to 96.552% when pulling 2c9115c410254e51774f71f0497c9012bfed962f on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+3.0%) to 96.552% when pulling 2c9115c410254e51774f71f0497c9012bfed962f on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+3.0%) to 96.552% when pulling 2c9115c410254e51774f71f0497c9012bfed962f on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+3.0%) to 96.552% when pulling 2c9115c410254e51774f71f0497c9012bfed962f on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

Coverage increased (+3.0%) to 96.552% when pulling 9cad431b7660ca4812f0556e31d221bebf112111 on nanobowers:registry into 29a8b69fcd909bfb2cc14564dd30b3d99f7897f0 on ManageIQ:master.

@nanobowers this is getting pretty large.
Since there is a largeish base of users and the test suite is not organized in a way that I understand the coverage / holes, I've been hesitant on too many changes.

Do you have an idea how to do this in smaller chunks?
If there are certain PRs that you want merged, please just review / +1 them and we can get them in.

I'm new to this, so thanks for your patience.  I figured that the test suite was pretty comprehensive before embarking on this.  I'll add more tests if someone can provide a little bit of direction.
I'll try to split this into smaller PRs, some of the elements are fairly easy to split out.  The unfortunately, the registry portion is a pretty big change and not easy to do without ripping up a lot of code.  Also, your Option-class change also contained quite a bit of code movement, which i leveraged.
As far as the Travis builds, i am not really sure what's going on with the integration issues.  I am using practically the same versions of rvm, ruby and bundler but not getting any test fails.  They seem to be due to a line wrapping issue, but i'm not totally sure.  From what I can tell, the 1.9.* builds are failing due to a dependency (tins) no longer supporting 1.9.*

Want to note that this may cover PR #7 and Issue #41 to some degree.

already merged your #80, and after merging #66, should cut down on this PR a bunch

Will open a new one once @kbrock gets the option-class PR pulled in.


feat: Negotiate cheques

https://github.com/ethersphere/bee/issues/1819
The pr consists of three main parts:

the priceoracle, polling the current values of the exchange rate and initial deduction at node start and later in every unix timestamp divisible by 300 (meaning every 5 minutes at approximately the same time on all nodes).
the exchange rate and applicable deduction negotiation happening before issuing a cheque to a peer.
converting between the amount of accounting credits attempted to be settled, and the amount of plur sent to cover for this settlement using the exchange rate learned from the price oracle / negotiated in swap protocol

The negotiation process consists of:

the peer willing to issue a cheque begins opening a stream sending empty headers
the accepting peer returns it's current known exchange rate, and the applicable deduction in headers

the applicable deduction is the current known deduction, or 0 if the peer attempting to settle has already sent a cheque with negotiated deduction previously

the peer compares the received exchange rate and deduction headers to his version of known truth, if both match, issues a cheque, otherwise cancels the cheque issuing and restrains from further attempts to send cheques to this peer for 10 seconds, to limit rate of errors in negative scenarios
if the deduction was negotiated non zero, both peers save the other as already having a deduction sent to / received from, so that in the future they are able to agree on zero deduction based on this registry.

Negative scenarios can be:

if there was an update of the oracle exchange rate or deduction between polling point A and A+1, any node started after the the point of update but before A+1 can be ahead of the network in his version of the truth until A+1.
if there was an update of the rate or deduction, near the polling point when one of the peers might be ahead by getting or using the new version of truth sooner / faster

The conversion logic between accounting credits and plur:
Cheque value is ( accounting amount * exchange rate ) + deduction
Thereby received/sent cheque is calculated as changing the balance with ( cheque amount - deduction ) / exchange rate

This change is

Reviewed 7 of 7 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @metacertain)

pkg/settlement/swap/swapprotocol/swapprotocol.go, line 208 at r1 (raw file):

	checkPeer := false

	if checkPeer {

always false

it is a work in progress, yet to introduce the component for registering whether a peer already had an initial deduction

pkg/settlement/swap/priceoracle/priceoracle.go, line 45 at r2 (raw file):
Previously, acud (acud) wrote…
I think there's a v0_2_0

that's a different price oracle, for this one there is only one version.

  BEEKEEPER_BRANCH: "thresholds"

needed?

yes, this reduces thresholds by the magnitude of the newly introduced exchange rates
the beekeeper PR containing this should be merged at the same time as this to avoid breaks

failedSettlementInterval = int64(10)

ten what? s/m/d/m/y?
EDIT: seconds.

seconds indeed, added comment

pkg/accounting/accounting.go, line 333 at r2 (raw file):

				// add settled amount to shadow reserve before sending it
				balance.shadowReservedBalance.Add(balance.shadowReservedBalance, paymentAmount)
				go a.payFunction(context.Background(), peer, paymentAmount)

there is no goroutine tracking here for shutdown, which means that payments made during shutdown might be lost

still to be fixed

acc.Release(peer1Addr, 1)

is this needed at the end of the test?

we always do it consistently, not strictly needed

  err = s.addressbook.AddDeductionFor(peer)

is this operation made under a peer lock? there might be a data race hiding here

no need for lock in this case. this adds an empty struct to the specified address-index
if it is overwritten by another empty struct, wouldn't cause a problem
this is to remember deduction happened once towards a specific peer.
only one payment is ongoing at a time so no other payment is attempted without this saved yet

exchangeRate := big.NewInt(100)

can we have a short comment explaining the arithmetics and why the error should be returned?

added comment to test

ErrWrongComment

:)

Nit, but since the only error that can be returned from ParseDeductionHeader is ErrNoDeductionHeader, and since the calling contexts always fall back to deduction value 0, then maybe it is not needed to return the error and just return a 0 from ParseDeductionHeader. However having it explicit as it is might be a nice option too, since it makes things a bit clearer in the calling contexts

this should be fine the way it is, than?

// Deposit starts depositing erc20 token into the chequebook. This returns once the transactions has been broadcast.

wrong comment, missing comments on other methods in the interface

changed comment

var (
priceOracleABI = transaction.ParseABIUnchecked(priceoracleabi.PriceOracleABIv0_1_0)

I think there's a v0_2_0

thats the other ABI for postage stamps, v0_1_0 is good

  	timeUntilNextPoll := time.Duration(s.timeDivisor-ts%s.timeDivisor) * time.Second

why not use a const?

added comment explaining logic

func (s *service) GetPrice(ctx context.Context) (*big.Int, *big.Int, error) {

since this wrapping method does not provide any further functionality, it can be removed and instead the unexported one can be exported

done

priceOracleABI = transaction.ParseABIUnchecked(priceoracleabi.PriceOracleABIv0_1_0)

here too, v2?

v1 is ok

func TestInit(t *testing.T) {

it would be good to document these tests also with a godoc style comment and also inline comments within the tests as they are not self describing and I find them hard to review

added comments

Is this a breaking change due to the new protocol streams?  In other words, if I update to the current master, can I still participate in the 0.6.2 swarm?


Converted the project to a gradle project

Changed this project to be built and run from Gradle.
I realize this may be overkill for a project with a single jar file, but I thought it would help the development of this task, especially if anyone wants to add any additional functionality.

Thanks for the gradle script ;-)


Ability to integrate interdomain inducing point methods with GPflow

Some GPflow users are interested in interdomain inducing points. At the moment it is a little fiddly to integrate their code with the main code base. We should think about making it easier without disrupting the main code base.

I've pushed the branch inter-domain. It has as working implementation of the inter domain GP, which is demonstrated in the notebook. A few unittests may fail since it's not easy to generally find Kzx and Kzz for kernels.Prod.
I'll take a look if I can adjust the unittests appropriately soon.

Ok all unittests run. The thing that still needs to be checked is whether gp_predict, gaussian_gp_predict and gaussian_gp_predict_whitened are only used by inducing point methods. If this is the case, then everything's ready to go. I've searched through the usages of these functions and currently I can't find any usages other than in SVGP. Though I don't know what your plans for the future are.
If this is not the case (or perhaps in the future) then things are more complicated, since Kzx and Kzz need to be used when inducing variables are considered, and K should just be used in other cases. This may require adding a switching parameter or something.

Superseded by #530


Update dApp connect/onboarding flow

User Story
As Chris I want to see which reward I would pay if a monitoring service submits my balance proof so that I am able to trust the system.
Split from #1352
User flow

Select Hub (do not show mint & deposit any more)
Open Channel (rename to "Set deposit")
Monitor Channel (new screen)
3a. Show available SVT tokens (move #1371 to this new screen)
3b. Mint & Deposit button
3c. Show the monitoring reward in SVT
3d. Show the exchange rate (preset but adjustable) -> related SDK feature #1369
3e. Show the monitoring reward in the channel token = exchange rate * monitoring reward
3f. Explain the monitoring reward briefly
3g. Button should be called "Open Channel" -> not sure if we should call the screen the same

Acceptance criteria

Just display the value, how many RDN if the monitoring reward is used. This is not interactive so showing the value is about being transparent about it.
There is a default for each token we use separated by net
There is an explanation of how the user can calculate the value

Tasks

[ ] Design [Pre-iteration]

@andrevmatos Proposal:

Modal, if we receive a transfer before signing the message for the MS
Add it to the transfer history

Please assign the "Ready" label after the design has been done, thanks :)

Sure thing!

@taleldayekh I have written down the user flow (see above). Let me know, if you have got questions.

The way I understood this is that we want to be transparent about the amount of SVT/RDN a user might have to spend if a balance proof is sent.
Since this is not interactive (at the moment) I suggest we just add this information on the UDC screen. A user would then see how many SVT/RDN tokens they have and in relation to that also how many of those tokens they need to pay in case a balance proof is sent?
@kelsos @andrevmatos @christianbrb @weilbith

The original idea was to put it in the token connection flow (see user flow). There it would be more educative / explaining for the user.

Alright, let me sit down and continue thinking about this one. I think the issue is a lot bigger than the title suggests.

The token connection flow outlined in the description above would require:

3 new screen designs (Select Hub, Set Deposit and Monitor Channel)
The current implemented connect flow can not be re-used except the Open Channel screen because the other screens have elements that either needs to be removed or added.

I would like to rename this issue to "Update connect/onboarding flow"? Displaying the monitoring reward is only a minor detail in the scope of this issue.

There are also some unknowns/question marks regarding step 3d and step 3e. @andrevmatos could you please leave some comments on those two steps. :)

We are pulling this one out from the current iteration after discussions. It's a good idea to look over and re-work the connect flow as outlined in the issue so that it becomes more pedagogical for a user, but for now it is too big and not urgent for mainnet.
We should however add details about the balance proof amount in the newly introduced UDC screen. That information should be added regardless of this issue.

3. 3d. Show the exchange rate (preset but adjustable) -> related SDK feature #1369
3e. Show the monitoring reward in the channel token = exchange rate * monitoring reward

I'm not sure about this. The exchange rates shouldn't be set by the user, they should be either fetched automatically (#1513) or fallback to some of the stated default behaviors.
Also, the SVT/RDN is our "common currency" to show prices on, and reward is already a config param (defaulting to 5 tokens) on this currency, not sure it'd be worth it to show on the transfer token. We can/could do it for tokens we do have exchange rates, but there may be tokens without it (see fallbacks at the linked issue), but I'm not sure it's useful, because it'd be shown at channel opening time's exchange rate, while the reward could be paid far in the future, when the rate may have changed, so the amount paid by the user in monitoring reward value would have changed in transfer tokens, but is constant in service tokens (5 RDN, unless explictly changed)

This is a messed up issue ;) Closing.


add legend ordering for new scenarios in trajectory_alignment.js

closes #53

closes #52 (hopefully)

[x] needs @MonikaFu's review for the colors and functionality

[x] needs @jdhoffa's review for the scenarios and proper ordering

@cjyetman thanks! I will give it a look tomorrow morning!

@cjyetman I run the code and looked into the report generated and the problem seems still not to be resolved. I looked into the .js just to make sure that I am using the code from this PR and I am using the same version but the plots don't render correctly. For example, for ISF there are no scenarios

And for WEO2023 we see a black area while there should only be colourful scenario areas.

@cjyetman I run the code and looked into the report generated and the problem seems still not to be resolved. I looked into the .js just to make sure that I am using the code from this PR and I am using the same version but the plots don't render correctly. For example, for ISF there are no scenarios

And for WEO2023 we see a black area while there should only be colourful scenario areas.

@cjyetman just jumping in here, I could be wrong, but I believe this is because we need to re-run data-prep to pick up the changes in scenario name in pacta.scenario.preparation? At least for the case of WEO?
ISF I'm not sure what the issue is

I did advise @MonikaFu that the WEO NZE scenario needs to be temporarily, manually adjusted to WEO_NZE instead of WEO_NZE_2050 in the workflow.transition.monitor project configs to work with the current data.prep outputs that we have. That appears to be the problem in these plots because NZE is missing. I also don't know if the explicitly defined "worse" is actually necessary, I just tried to follow the previous pattern. My expectation was that "worse" defined the color of the area beyond the worse scenario, but I don't really know how this works.
With ISF2023, I also don't know if it really needs "worse". Also no idea why it's not picking up "1.5°C".
If this doesn't work, we can close this ticket and I guess @MonikaFu will have to figure it out.

I have adjusted the parameter as advised but still see this issue. If I look into the parameters used in the code I see select_scenario = "WEO2023_NZE" which is what we want with current data.prep outputs right?
You always need "worse" as far as I remember in the way the colour assignment works in this plot. But would need to dive deeper to recall.
Yes, I guess since it seems this PR does not manage to solve the issues with adding new scenarios I probably need to take over.

Then is the intention to close this PR?

Then is the intention to close this PR?

I'm working within this PR as the changes @cjyetman made are needed but there is more that needs to change for the scenarios to be picked up.

@MonikaFu is this ready for review? or was the review request a mistake?

@MonikaFu is this ready for review? or was the review request a mistake?

it was kind of a mistake. I did not want it to have the 'approved' status so I re-requested a review but I only realised after that it will ask you for a review of course. It is not ready for review that is why I put it into 'draft' mode.

@jdhoffa I believe this is solved now. The 'WEO2023' source still does not work properly because the plot expects a scenario called 'NZE_2050' but in the current version of the data it is 'NZE'. From what I understand this is going to be fixed and the proper name should be 'NZE_2050' so I am not going to change it.

@cjyetman maybe you would like to have a look at it as well?

Seems to function as expected, minus the NZE_2050 situation. But... is "worse" supposed to appear black? and is there something wrong with the order of "worse"?

also, not sure if this is related, but I get 2 JavaScript errors that prevent the trajectory plots from displaying until I change one of the selectors...

Seems to function as expected, minus the NZE_2050 situation. But... is "worse" supposed to appear black? and is there something wrong with the order of "worse"?
also, not sure if this is related, but I get 2 JavaScript errors that prevent the trajectory plots from displaying until I change one of the selectors...

Is this an artifact of the NZE_2050 issue (and a mismatch between expected and actual scenarios?)
Does "worse" still appear black if you try a different scenario?

Worse should not appear at all but it appears because of the mismatch between expected and actual scenario names. No idea about the

@cjyetman makes sense. Then I will leave it open and marked as 'blocked' on ADO until we get a new version of data.prep.

Depends on:
https://dev.azure.com/RMI-PACTA/2DegreesInvesting/_workitems/edit/10505

For what it's worth, I jumped through all of the hoops (I think), and with @MonikaFu's additions, this appears to work as expected! 👍🏻

@cjyetman does it mean that you tested with the right data? And it works? Can we merge?

@cjyetman does it mean that you tested with the right data? And it works? Can we merge?

Yeah, I manufactured an inputs dataset that has the expected scenario name. There were still a few problems (like the JS errors mentioned above), but I believe those are separate issues. I think this PR is safe, but I leave it up to you to decide if/when to merge.


Doc fixes

I'm not satisfied with how I explain the secondary magic being unset, please come with your ideas :)

image swaps state enumeration looks good.

I'm not satisfied with how I explain the secondary magic being unset, please come with your ideas :)

What is the reason - I don't catch?

I couldn't find a better place to put it, but I would like to have it written somewhere in the general description of the update procedure.
The way it is currently would suffice for the docs to be consistent though, so I guess it is OK :)

Should the unset concept be explained?

@utzig could you have a look?

@utzig could you have a look?

It's on my list :rofl:


chore: Bump xmldom to 0.8.0

Switching from package xmldom to @xmldom/xmldom, which resolves the security issue present in latest xmldom version 0.6.0:
https://github.com/xmldom/xmldom/security/advisories/GHSA-5fg8-2547-mr8q
The reason is that the maintainers were forced to switch to a scoped package since 0.7.0:
https://github.com/xmldom/xmldom/issues/271
No matter what version of node I used to try and run the normal npm install, I always received a warning about either old package lock file format or newer lock file version format.
So to avoid to many unrelated changes, I disabled the postinstall step locally and installed the root level using node v12 and the mbTest folder using node v16.

When running the npm run test on the root level using node v12, there is a single failing test, but running them with node v16 works.So let's see what happens on CircleCI.
When running cb mbTest && npm run test (using node 16) The first listed test fails. When adding MB_AIRPLANE_MODE=true there are quite a bunch of tests failing... not sure if this is really related to the xmldom update.

I'm happy to fix any regression we introduced, I just need help to understand how exactly the xmldom upgrade influences the failing test(s).
I'm one of the xmldom maintainers. Don't hesitate to ask me questions.

Changes in xmldom since 0.6.0
## [0.8.0](https://github.com/xmldom/xmldom/compare/0.7.5...0.8.0)
Fixed

Normalize all line endings according to XML specs 1.0 and 1.1
BREAKING CHANGE: Certain combination of line break characters are normalized to a single \n before parsing takes place and will no longer be preserved.

#303 / #307
#49, #97, #324 / #314

XMLSerializer: Preserve whitespace character references #284 / #310
BREAKING CHANGE: If you relied on the not spec compliant preservation of literal \t, \n or \r in attribute values.
To preserve those you will have to create XML that instead contains the correct numerical (or hexadecimal) equivalent (e.g. 	,
,
).
Drop deprecated exports DOMImplementation and XMLSerializer from lib/dom-parser.js #53 / #309
BREAKING CHANGE: Use the one provided by the main package export.
dom: Remove all links as part of removeChild #343 / #355

Chore

ci: Restore latest tested node version to 16.x #325
ci: Split test and lint steps into jobs #111 / #304
Pinned and updated devDependencies

Thank you @marrus-sh, @victorandree, @mdierolf, @tsabbay, @fatihpense for your contributions
0.7.5
Commits
Fixes:

Preserve default namespace when serializing #319 / #321
Thank you @lupestro

0.7.4
Commits
Fixes:

Restore ability to parse __prototype__ attributes #315
Thank you @dsimsonOMF

0.7.3
Commits
Fixes:

Add doctype when parsing from string #277 / #301
Correct typo in error message #294
Thank you @rrthomas

Refactor:

Improve exports & require statements, new main package entry #233

Docs:

Fix Stryker badge #298
Fix link to help-wanted issues #299

Chore:

Execute stryker:dry-run on branches #302
Fix stryker config #300
Split test and lint scripts #297
Switch to stryker dashboard owned by org #292

0.7.2
Commits
Fixes:

Types: Add index.d.ts to packaged files #288
Thank you @forty

0.7.1
Commits
Fixes:

Types: Copy types from DefinitelyTyped #283
Thank you @kachkaev

Chore:

package.json: remove author, maintainers, etc. #279

0.7.0
Commits
Due to #271 this version was published as

unscoped xmldom package to github (git tags 0.7.0 and 0.7.0+unscoped)
scoped @xmldom/xmldom package to npm (git tag 0.7.0+scoped)
For more details look at #278

Fixes:

Security: Misinterpretation of malicious XML input CVE-2021-32796
Implement Document.getElementsByClassName as specified #213, thank you @ChALkeR
Inherit namespace prefix from parent when required #268
Handle whitespace in closing tags #267
Update DOMImplementation according to recent specs #210
BREAKING CHANGE: Only if you "passed features to be marked as available as a constructor arguments" and expected it to "magically work".
No longer serializes any namespaces with an empty URI #244
(related to #168 released in 0.6.0)
BREAKING CHANGE: Only if you rely on "unsetting" a namespace prefix by setting it to an empty string
Set localName as part of Document.createElement #229, thank you @rrthomas

CI

We are now additionally running tests against node v16
Stryker tests on the master branch now run against node v14

Docs

Describe relations with and between specs: #211, #247

Thanks! Sorry for a slow response, been busy but should free up shortly and will respond.

First, thank you so much for creating a PR like this. It's pretty amazing that you not only updated your package but made an attempt at updating the ecosystem around it.
The failing test is causing me some head-scratching so I'll describe it here in case you have an idea based on a deeper understanding of the change. The cause appears to be an assumption in another npm package (xpath), which sets a case sensitivity flag based on an check that I'm struggling to wrap my brain around (doc.implementation.hasFeature("HTML", "2.0")). The test that's failing in mountebank has nothing to do with HTML; it uses a simple document of "value". Here's a simplified view of the xpath code, including their comment. This code sets caseInsensitive to false before the xmldom change and true after:
  // backward compatibility - no reliable way to detect whether the DOM is HTML, but
  // this library has been using this method up until now, so we will continue to use it
  // ONLY when using an XPathExpression
  this.context.caseInsensitive = XPathExpression.detectHtmlDom(n);

    XPathExpression.detectHtmlDom = function (n) {
        if (!n) { return false; }

        var doc = XPathExpression.getOwnerDocument(n);

        try {
            return doc.implementation.hasFeature("HTML", "2.0");
        } catch (e) {
            return true;
        }
    }

Any thing strike you as obvious about the change that would flip that feature between versions?

After a bit more research, I suspect it's a legacy check in xpath, but I don't understand the issue well enough to make a PR there, so I ended up patching xmldom. Works as far as I can tell, but LMK if you think there's something wrong with this code:
    if (doc && doc.implementation) {
        // Monkey patch due to some legacy case sensitivity check in xpath
        // Couldn't find a way to patch xpath due to closures so patched the dom instead
        const originalHasFeature = doc.implementation.hasFeature;
        doc.implementation.hasFeature = (feature, version) => {
            if (feature === 'HTML' && version === '2.0') {
                return false;
            }
            else {
                return originalHasFeature.apply(doc.implementation, [feature, version]);
            }
        };
    }

And, thanks again for all your effort!

Yes, before 0.7.0 DOMImplementation.hasFeature had a very strange implementation where the "enabled features could be passed as constructor arguments". Since 0.7.0 it always returns true which is what the specs suggest.
I'm very close to finish a change that will allow HTML detection again starting from 0.9.0.
I will let you know when it's available, so you can stop patching xmldom :)

O and https://github.com/goto100/xpath/issues/27#issuecomment-1041378729 suggests there is an isHtml option you can set to true to avoid the detection. Maybe that also works for you test?

I will let you know when it's available, so you can stop patching xmldom :)

Sorry that was an offer I have to take back. I have to many things to keep track of already. Feel free subscribe to the related issue or PR or to watch the xmldom releases, so I don't have to remember to notify you :handshake:

Not a problem, thanks again for your help,
On Thu, Feb 24, 2022 at 1:14 PM Christian Bewernitz <
@.***> wrote:

I will let you know when it's available, so you can stop patching xmldom :)
Sorry that was an offer I have to take back. I have to many things to keep
track of already. Feel free subscribe to the related issue
https://github.com/xmldom/xmldom/issues/203 or PR
https://github.com/xmldom/xmldom/pull/338 or to watch the xmldom
releases https://github.com/xmldom/xmldom/releases, so I don't have to
remember to notify you 🤝
—
Reply to this email directly, view it on GitHub
https://github.com/bbyars/mountebank/pull/660#issuecomment-1050177691,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAARFP4UVSRJ3HM3WGIKU2DU4Z7TFANCNFSM5KYBC7EA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you modified the open/close state.Message
ID: @.***>


PACKAGE: mod-settings - Theme and Night Mode split

Get Night mode detected on Desktop

See main rpeo as we got it working there.

The Word "Theme" in the Settings page to be changed to be called "Auto Night mode"

Theme Support

Make 2 BASIC themes. These are just to test the architecture.
-there is package on dart pub that manages this i think.
make the setting simialr to above.

@winwisely99 Two basic themes, and by that u mean dark and light, or other than that?


README is out of sync with current contentful-importer

The contentful-importer.rb appears to have been modified significantly since the README in this repo was last updated. It would be great to have the instructions here updated to match (or perhaps just removed and make reference to the authoritative instructions on the other repo).

Done 👍


Where to download the 'sugarbeet', 'weed' dataset ?

Dear author:
thanks for your great yolo example.
I wonder where to download the toy dataset: sugarbeet', 'weed'. I google it and can not find the download link? thank you.

Thank you for your positive appreciation. There is no public dataset because I built it myself. I just added the test and training set to the repository.

yes, it helps. Thank you.


Mouse Move on Dot Spatial in Asp.Net

Hi All,
I want to know how I can trap the mouse events and get coordinates i.e. Lat, Lon on mouse move using webmap_mapclick
b/c I have been trying to do this:
Private Sub WebMap1_MapClick(Sender As Object, e As DotSpatial.WebControls.MapClickEventArgs) Handles WebMap1.MapClick
If e.button = 1 Then
lblCoordinates.Text = e.x
End If
lblCoordinates.Text = e.x
End Sub
but it shows nothing and no event is fired when i run it with bookmarks
I also want to know how I can place markers on mouse click event

Try _MouseOver event.
~AGP

Its in ASP.NET and there is no mouseOver event given with WebMap


error when trying to flash deploy-sd.img using belena and rasp pi imger on mac and pc

i've redownloaded the zip file a couple times.  i also used various programs to extract the files (keka, unzip, winrar, 7zip) and have the same issue.  also tried different sd cards.
error message is checksum does not match for range [0,2684354550]; " BUNCH OF GARBAGE"

I had success with raspberry pi imager


Add babel-cli and babel-presets into docs

I think it is worth mention these dependecies in quick start, because I need those to run npm run start.
I'm totally new to this (node, react) so I don't know if these babels related are default or should be manually installed.
I did followed the step that uses create-proton-app.

https://github.com/kusti8/proton-native/blob/d2f293d65ae3aaa442af65fc4aed720e6b97b887/docs/manual_install.md
needs to be updated. Previously, the babel stuff wasn't needed.

Since they should be devDependencies, the command should be
npm install --save-dev babel-cli babel-preset-env babel-preset-stage-0 babel-preset-react

Also, I don't think babel-preset-stage-0 would be strictly needed (it depend on the kind of syntax you'll want use in your package, but proton-native should not impose that)

Yeah so create-proton-app should install it automatically soon, @albe-rosado hasn't gotten back to me yet. But this should be added to the manual install section.


Import/Export feature for backup/reinstallations of app.

:warning: Is your feature request related to a problem? Please describe

No built in ability to export/backup my appdata without root.
If I were to uninstall or switch phones/devices, all my to don't lists would disappear.
:bulb: Describe the solution you'd like

Adding a feature to backup/restore app data to a file I can store for backup.
:bar_chart: Describe alternatives you've considered

Unable to root my phone at the moment, I can't backup any intended way.
:page_facing_up: Additional context

:raising_hand: Do you want to develop this feature yourself?

[ ] Yes
[x] No

can i work on to this issue>?

can i work on to this issue>?

Yes, that would be awesome. 👍

The feature is live with v3.0.0 thanks to @theftzoku.


New React Docs Translation Progress

Maintainer List

@galnir
@galtalmor
@itayyehezkel

For New Translators
To translate a page:

Check that no one else has claimed your page in the checklist and comments below.
Comment below with the name of the page you would like to translate. Please take only one page at a time.
Clone this repo, translate your page, and submit a pull request!

Before contributing, read the glossary and style guide (once they exist) to understand how to translate various technical and React-specific terms.
Please be prompt with your translations! If you find that you can't commit anymore, let the maintainers know so they can assign the page to someone else.
For Maintainers
When someone volunteers, edit this issue with the username of the volunteer, and with the PR. Ex:

[ ] Quick Start (@tesseralis) #12345

When PRs are merged, make sure to mark that page as completed!
Main Content
To do before releasing as an "official" translation. Please translate these pages first.
Note that each section has an index page, which needs to be translated too.
Learn React

[ ] Quick Start

[ ] Tutorial: Tic Tac Toe
[ ] Thinking in React

[ ] Installation

[ ] Start a New React Project
[ ] Add React to an Existing Project
[x] Editor Setup @galnir #278
[x] React Developer Tools @galnir #279

[ ] Describing the UI

[ ] Your First Component
[ ] Importing and Exporting Components
[ ] Writing Markup with JSX
[ ] JavaScript in JSX with Curly Braces
[ ] Passing Props to a Component
[ ] Conditional Rendering
[ ] Rendering Lists
[ ] Keeping Components Pure

[ ] Adding Interactivity

[ ] Responding to Events
[ ] State: A Component's Memory
[ ] Render and Commit
[ ] State as a Snapshot
[ ] Queueing a Series of State Updates
[ ] Updating Objects in State
[ ] Updating Arrays in State

[ ] Managing State

[ ] Reacting to Input with State
[ ] Choosing the State Structure
[ ] Sharing State Between Components
[ ] Preserving and Resetting State
[ ] Extracting State Logic into a Reducer
[ ] Passing Data Deeply with Context
[ ] Scaling Up with Reducer and Context

[ ] Escape Hatches

[ ] Referencing Values with Refs
[ ] Manipulating the DOM with Refs
[ ] Synchronizing with Effects
[ ] You Might Not Need an Effect
[ ] Lifecycle of Reactive Effects
[ ] Separating Events from Effects
[ ] Removing Effect Dependencies
[ ] Reusing Logic with Custom Hooks

API Reference

[ ] react: Hooks

[ ] useCallback
[ ] useContext
[ ] useDebugValue
[ ] useDeferredValue
[ ] useEffect
[ ] useId
[ ] useImperativeHandle
[ ] useInsertionEffect
[ ] useLayoutEffect
[ ] useMemo
[ ] useReducer
[ ] useRef
[ ] useState
[ ] useSyncExternalStore
[ ] useTransition

[ ] react: Components

[ ] <Fragment> (<>)
[ ] <Profiler>
[ ] <StrictMode>
[ ] <Suspense>

[ ] react: APIs

[ ] createContext
[ ] forwardRef
[ ] lazy
[ ] memo
[ ] startTransition

[ ] react-dom: Components

[ ] Common (e.g. <div>)
[ ] <input>
[ ] <option>
[ ] <progress>
[ ] <select>
[ ] <textarea>

[ ] react-dom: APIs

[ ] createPortal
[ ] flushSync
[ ] findDOMNode
[ ] hydrate
[ ] render
[ ] unmountComponentAtNode

[ ] react-dom/client: Client APIs

[ ] createRoot
[ ] hydrateRoot

[ ] react-dom/server: Server APIs

[ ] renderToNodeStream
[ ] renderToPipeableStream
[ ] renderToReadableStream
[ ] renderToStaticMarkup
[ ] renderToStaticNodeStream
[ ] renderToString

Navigation and UI
We suggest to leave most of the UI translation until the end. We plan to do some invasive changes to the website folder layout and components, so postponing this until your translation is almost complete would make it easier to merge the changes from our side later. It might make sense to translate the homepage above the fold early, but leave the rest for later. As individual pages get translated, you can change the page titles in the corresponding sidebar files. Finally, when you're translating the navigation, make sure to test both desktop and mobile layouts.

[ ] Homepage (currently in HomeContent.js)
[ ] Sidebars (currently in src/sidebar*.json)
[ ] Top-level navigation (currently in TopNav.tsx)

When You're Ready...
After everything above is translated, add your language to deployedLanguages in Seo.tsx of the original reactjs/react.dev repository.
Secondary Content
These API pages should ideally be translated too, but they're less urgent and can be done after the others:

[ ] Legacy React APIs

[ ] Children
[ ] cloneElement
[ ] Component
[ ] createElement
[ ] createFactory
[ ] createRef
[ ] isValidElement
[ ] PureComponent

Optional Content
These aren't the main translation targets, but if you'd like to do them, feel free to expand the list to include their subpages:

[ ] Community
[ ] Blog
[ ] Warnings

I can translate ״Escape Hatches״

The React team recommended to hold on with that section because they keep rewriting some of the pages. Is there anything else you'd like to translate?

I have no problem translating something else as well, whatever is needed

I have no problem translating something else as well, whatever is needed

Okay so I'm assigning "Your First Component" to you. This is the page, and this is the file

i can help with translation, you can assign me to whatever is needed...

i can help with translation, you can assign me to whatever is needed...

Awesome, I'm assigning "Importing and Exporting Components" to you.
page
file

I can help with translation,
Assign me to whatever is needed .

I can help with translation,
Assign me to whatever is needed .

Thanks! "Writing Markup with JSX" is yours
page
file

I can translate:
"Reusing Logic with Custom Hooks"
And other pages if needed.

Can you first translate "JavaScript in JSX with Curly Braces"?
page
file

היי ניר,
אני פעם ראשונה תורם קודם ואשמח לעזרה.
עשיתי FORK לפרויקט וניסיתי להבין לאן אני מתרגם את הדף שביקשתם ולא הבנתי לאן.
אשמח לכיוון\עזרה בנושא.
תודה מראש ניר וערב נהדר!
בתאריך יום ו׳, 30 בספט׳ 2022 ב-13:22 מאת Nir @.***
>:

I can help with translation,
Assign me to whatever is needed .
Thanks! "Writing Markup with JSX" is yours
page https://beta.reactjs.org/learn/writing-markup-with-jsx
file
https://github.com/reactjs/he.reactjs.org/blob/main/beta/src/pages/learn/writing-markup-with-jsx.md
—
Reply to this email directly, view it on GitHub
https://github.com/reactjs/he.reactjs.org/issues/280#issuecomment-1263390698,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVCJUDMMFMEVE2VGQEAYH53WA25NPANCNFSM552TWBBA
.
You are receiving this because you were mentioned.Message ID: <reactjs/he.
@.***>

היי ניר, אני פעם ראשונה תורם קודם ואשמח לעזרה. עשיתי FORK לפרויקט וניסיתי להבין לאן אני מתרגם את הדף שביקשתם ולא הבנתי לאן. אשמח לכיוון\עזרה בנושא. תודה מראש ניר וערב נהדר! בתאריך יום ו׳, 30 בספט׳ 2022 ב-13:22 מאת Nir @.*** >:
…

Fork the project, then you have 2 options:

Open the fork repo on your browser, create a new branch for your contribution, go to the file of the page you want to translate, hit 'edit' on the top right bar. Now you can translate on the web browser. You can also open a word document and translate there, then copy to the browser.
Clone the repo to your PC, create a new branch using Git on your terminal and then translate the file in your code editor

אם עדיין לא מובן תעדכן אותי

בתאריך יום ג׳, 11 באוק׳ 2022 ב-15:00 מאת Nir @.***>:

היי ניר, אני פעם ראשונה תורם קודם ואשמח לעזרה. עשיתי FORK לפרויקט וניסיתי
להבין לאן אני מתרגם את הדף שביקשתם ולא הבנתי לאן. אשמח לכיוון\עזרה בנושא.
תודה מראש ניר וערב נהדר! בתאריך יום ו׳, 30 בספט׳ 2022 ב-13:22 מאת Nir
@.*** >:
… <#m_-1239378473831299196_>
Fork the project, then you have 2 options:

Open the fork repo on your browser, create a new branch for your
contribution, go to the file of the page you want to translate, hit 'edit'
on the top right bar. Now you can translate on the web browser. You can
also open a word document and translate there, then copy to the browser.
Clone the repo to your PC, create a new branch using Git on your
terminal and then translate the file in your code editor

אם עדיין לא מובן תעדכן אותי

המון תודה ניר, אעדכן 🙏🏻

—
Reply to this email directly, view it on GitHub
https://github.com/reactjs/he.reactjs.org/issues/280#issuecomment-1274571245,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVCJUDJFJPAS7HYZSSHAHK3WCVJHLANCNFSM552TWBBA
.
You are receiving this because you were mentioned.Message ID: <reactjs/he.
@.***>

Hi folks,
Just a heads-up that we've done our best to bring main and legacy branches up-to-date with upstream. This brings you to the latest visual design and sets up all the redirects. We don't anticipate more changes necessary on legacy. For main, there's a few things you need to be aware of:

Keep in mind translating UI is best done closer to the end. We plan to make non-trivial code changes to the repo over the next few months. So it's best to focus on the content rather than on UI components.
The homepage is untranslated so ideally it would be good if you could do a pass at that. For now, unfortunately it requires messing with the code file.
A few rewritten pages (from Installation) are currently untranslated.

Thank you so much for your cooperation!

I've updated the translation page checklist.

@galnir @galtalmor @itayyehezkel @bentlusty
Can you please confirm whether you'd be able to steer and maintain this translation? I want to get the list in https://github.com/reactjs/translations.react.dev/blob/main/langs/he.json updated to match the currently active list. Thank you!

Yep, still active

I'm also active

Me too :)

Hello,
I would be happy to contribute to useLayoutEffect section.

Hi, I'd like to start with useCallback, anyone else working on this?

Hi :)
I will be delighted to contribute to the useContext section.

@gaearon Who is responsible for managing this project? We are eager to drive its progress. Additionally, Hebrew is an RTL language, so we are curious if there is RTL support available in other projects (i.e Arabic, Hebrew, Persian, Urdu, Kashmiri, Pashto, Uighur, Sorani Kurdish, Punjabi, and Sindhi)

Do we support dir="rtl" attribute to make the documentation readable?

I'm still here just didn't have the time to review your PRs. I'll see if I can find how we supported RTL in the old version of the docs

It is mentioned in the thread description that there's still work being done in the main project on the UI and the recommendation was We suggest to leave most of the UI translation until the end.. To me this means we should focus on translating first and only once most content is translated start focusing on the UI and RTL improvements.

Hi, I would like to help with the translation.
You can assign me to whatever is needed.

@Sa-ar please choose any of the unassigned pages (ones that do not have a user name in parenthesis next to them), go ahead and start translating and submit an MR once ready. Thanks!

Hi @galtalmor,
Would it be possible to reassign my name from the useLayoutEffect implementation? The repository appears to be relatively inactive (I'm waiting with PR for almost 4 months ).
Thank you for your understanding :)

Hi,
@galtalmor
@itayyehezkel
@galnir
Is it still relevant to offer a translation?
I can see that a lot of the pages are still available
but no activity for a long time.


Diagnostic quickfix menu shows no "Ask Cody to fix" option

In Cody in VS Code v0.15.1698592121, there is no Cody fix option here in the menu, only explain. Copilot shows a fix option.

@umpox I think that this issue only happens when there are other coding assistants with similar Code Actions. As I don't have the Co-pilot installed, the Ask Cody To Fix Options works fine.

I couldn't find a clear reason this could happen, but I did notice that the previous code actions were implicitly tied to other logic in VS Code (FixupViewProvider). I have refactored this so that code actions are registered independently: https://github.com/sourcegraph/cody/pull/1724
Haven't been able to replicate this so will close the issue. Happy to reopen if we can reproduce still!


How to get value of CascadeFrom in custom LookUp

Hello,
I'm making an CasaceFrom, but i dont have direct relation between the tabels, the relation is in third table cause it can be n to n.
Its like this:
public class Account
{
	public int Id {get; set;}
}

public class Application
{
	public int Id {get; set;}
}

public class AccountApplication
{
	public int Id {get; set;}
	public int AccountId  {get; set;}
	public int ApplicationId {get; set;}
}

I'm consuming this tables and need to make an CascadeFrom get all Application in same Account.
I have tryed the normal LookupEditor and got no success and tryed to make an custom LookupScript but the value in CascadeFrom don't come.
Any idea/example how to do this ?

Segue esse exemplo
https://volkanceylan.gitbooks.io/serenity-guide/content/howto/how_to_setup_cascaded_editors.html

Já segui... dessa forma não funciona, pq no meu caso o vinculo ano está dentro na própria tabela.

Acho que faltou você informar o AutoComplete = true
[LookupEditor(typeof(AplicativosRow), CascadeFrom = "ContaId" , CascadeField = "ContaId", AutoComplete = true)]

Mesma coisa....
Preciso fazer um Cascade que faça um inner join com a terceira tabela se nao nunca ira retornar algo.
@alexdaywid

The problem was not Resolved @volkanceylan , why did u close it?

I had the same problem. Once the fields associated with the two tables are inconsistent, the data cannot be loaded. @volkanceylan .....And, @PedroHFranco Have you solved the problem?

I got it @PedroHFranco