Adding Ability to Add Caption / Text to Photos.

Is your feature request related to a problem? Please describe.
My app requires adding a caption to a photo when uploading.  Or Adding a caption to each photo when selecting/uploading multiple photos.
Also my users won't need to have Filters or Crops, so I use this library mostly just for the multiple selection and taking photos.
Describe the solution you'd like

Adding another state like Filter, Crop and Caption would be the solution.
I forked the repo and made the changes I need to have , however since it is a major change it needs a lot of detailed improvements.
It'd be nice to see this changes in the next version.
Things I have changed:

Added caption to Photo Media Item

public class YPMediaPhoto {

    public var image: UIImage { return modifiedImage ?? originalImage }
    public let originalImage: UIImage
    public var modifiedImage: UIImage?
    public let fromCamera: Bool
    public let exifMeta : [String : Any]?
    public var asset: PHAsset?
    public var caption:String?

    init(image: UIImage, exifMeta : [String : Any]? = nil, fromCamera: Bool = false, asset: PHAsset? = nil, caption:String? = nil) {
        self.originalImage = image
        self.modifiedImage = nil
        self.fromCamera = fromCamera
        self.exifMeta = exifMeta
        self.asset = asset
        self.caption = caption
    }
}

Added showsCaption flag to Config files YPConfigLibrary section

    public var showsCaption: Bool = false

For multiple selections, filter and caption doesnt work at the same time so usage becomes like this
config.filters = []
config.library.showsCaption  = true

or for single photos if you want to both use Filters and Caption you can just use
config.library.showsCaption  = true

TODOs:

Didnt translate localized changes
Caption view's font and sizes are hardcoded, will make this configurable
For multiple selection Filters and Caption doesn't work at the same time, so user needs to disable either one in configuration file. This part was a bit more complicated because if user wants to edit the photos we need to know if they want to just edit the filter or caption or both?

I will make a merge request from my fork and can work on this future if others also needs a feature like this.

@ugenlik
First of all thank you for taking the time and energy to try and improve the library, this is much appreciated. At the same time, I wish we had discussed this before you issued the pull request.
This is my fault actually for taking a long time to reply 🙏
Our app also needs a caption before sending to the server. However I believe this kind of functionality belongs on the "app side" of things and not the library side. There are so many different ways to handle captions, for example some catch hashtags or mentions etc, I think this would be kind of utopic to try and do a generic way that would match all app use cases that need a caption.
To be honest I am not sure we are willing to support this use case on the library side.
The preffered way, in my opinion, is to have the ImagePicker final callback feed into a new UI where the captions are added, keeping the features separated. @NikKovIos I'd love your point of view on this :)

Hi @ugenlik
Do you mind me asking how did you get the caption view controller to appear after choosing the filter ? This is something I am currently working on a project and a caption needs to be included as well.
Thanks mate

@ugenlik Anyway you can sure your version of the caption code mate?

Totally agree with @s4cha. In my app the caption also use the custom UI. Image picker library should pick image and pass on. Cropping, filters is already side functions, but they are complex and the library allows to disable them. UI for caption always different and not needed there.
However folks who need this feature can copy code manually from MR https://github.com/Yummypets/YPImagePicker/pull/266


Removing dependency from go/vt/health and go/vt/mysqlctl to topo.

@enisoc @aaijazi @yaoshengzhe

LGTM


Update of annotations field in volumeClaimTemplate is not reflected in annotations field in existing PersistentVolumeClaims

Describe the bug
We use MOCO with pvc-autoresizer. This is because we want to automatically resize the volumes created by MOCO in response to lack of free space by setting the annotations defined by pvc-autoresizer in MySQLCluster's volumeClaimTemplate. These annotations allow us to configure the resizing behavior, such as thresholds. Our team has adopted a change in resizing policy, so we updated the annotations of MySQLCluster's volumeClaimTemplate to apply the new policy. We expected that the updated annotations of the volumeClaimTemplate to be reflected in the annotations of the already created PersistentVolumeClaims, but unexpectedly the annotations of PersistentVolumeClaim remained unchanged.
Environments

Version: MOCO v0.16.1, pvc-autoresizer v0.8.1
OS: Flatcar Container Linux (stable)

To Reproduce
Steps to reproduce the behavior:

Configure annotations of volumeClaimTemplate as the follows and deploy MySQLCluster

resize.topolvm.io/increase: 5Gi
resize.topolvm.io/storage_limit: 100Gi
resize.topolvm.io/threshold: 5Gi

Update annotations of volumeClaimTemplate as the follows.

resize.topolvm.io/increase: 5Gi
resize.topolvm.io/storage_limit: 200Gi
resize.topolvm.io/threshold: 5Gi

Check kubectl describe pvc mysql-data-moco-...

Expected behavior
The updated annotations of the volumeClaimTemplate to be reflected in the annotations of the already created PersistentVolumeClaims.

It's by design. Please update the metadata by any operation.
The metadata of PVCs may be updated by someone other than moco, like admission webhooks.
Because of the possibility of malfunction, MOCO will not change labels and annotations of existing PVCs.
https://github.com/cybozu-go/moco/blob/v0.16.1/docs/change-pvc-template.md

When re-creating a StatefulSet, moco-controller does not support any operation other than volume expansion as described below. It only re-creates the StatefulSet. Therefore, changes to the label and annotation assigned to the PVC must be done by the user. This is because there is a concern that if someone other than the moco-controller is editing the PVC's metadata, there may be side effects.

I recognized this issue as a feature request.
Deleting the labels and annotations from existing PVCs is difficult because MOCO cannot judge that someone created the extra metadata.
But I don't see a problem with updating the value of labels and annotations if the key of the existing PVCs and the volumeClaimTemplate are the same.

https://github.com/cybozu-go/moco/pull/613
https://github.com/cybozu-go/moco/pull/644

This feature is available in v0.20.0 of MOCO.
https://github.com/cybozu-go/moco/blob/v0.20.0/CHANGELOG.md#0200---2023-12-19


Don't require dependencies to be linked

This should improve pull requests with lots of conflicting formulae in the same PR. Additionally, it’ll test that this linkage check isn’t required any longer.

CI failing on Linux, will fix it later.


Decentralized Private Computation

Project Abstract
This Project based in ZEXE and ZEXE paper.
In order to  implement ideal_ledger,plain_dpc,delegable_dpc Pallet.
Grant level

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $30,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied and aptly renamed (project_name.md).
[x] I have read the application guidelines.
[x] Payment details have been provided (bank details via email or Polkadot (USDC & USDT) or BTC address in the application).
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
[x] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @aric0x02:matrix.org (change the homeserver if you use a different one)

recheck

I have read and hereby sign the Contributor License Agreement.

recheck

our goal:
phase 1'goal :We will implement DPC prototype  substate local devement node.It includes ideal_ledger ,plain_dpc,delegable_dpc pallets.
phase 2 (2024 Q2)'goal :We will implement DPC privacy-preserving application parachain/chain testnet.
It includes private user-defined asset ,private DEXs,private stablecoins pallets.
phase 3(2025 Q2)'goal :We will implement DPC general-purpose privacy-preserving smart contract application parachain/chain.
It include private smart contract application examples.
We are new learner regarding zero-knowledge applications and cryptography.
the integration into Polkadot/Substrate:
phase 1 prototype stage:
The merkle tree of transactions and commitments will store on the storage of substrate palletideal_ledger.
plain_dpc  transaction proof verify will implement in on-chain function verify  in substate palletplain_dpc pallet.
delegable_dpc  transaction proof verify  will implement in on-chain function verify   in substate pallet delegable_dpc pallet.
phase 2 :
We will support polkadot address.
We will implement private user-defined asset substrate pallet.
We will implement private DEX substrate pallet.
We will implement private stablecoin substrate pallet.
phase 3 :
The another version of the offline proof computation execute' part of plain_dpcanddelegable_dpc` will be using off-chain worker.
Due to the needs of the collaborative team, we are now focusing on ZEXE. We are also very interested in zero-knowledge. We will also continue to implement the Move language ecological tools including the Move virtual machine, which is also an area of great interest to us.

Thanks for your review.
ZEXE 's  verify code  like smart contract executed on  chain or node validator(any machine and any one ).
ZEXE is more like privacy BTC blockchain  that support rich privacy-preserving applications ,without compromising privacy (of data or functions)  or relying on unnecessary re-executions.It is very different from TEE.
We will update the application with more details and use cases  ASAP.


Help maintaining Cookiecutter?

It's been 5 months without any update. Is there any way we can help with the repo maintenance?
There's this issue from 2014, #190, asking for maintainers, maybe is a good starting point to define some commiter criteria?

just faced this project several days ago, when was working on ansible roles templates in molecule project. I agree that this project needs more maintainers and will be glad to join a team.

Maybe @audreyr, @pydanny, @michaeljoseph, @pfmoore, and @hackebrot will share their thoughts about it.

Sorry, I no longer work on this project.

I use this project in https://github.com/ansible/molecule and I would like to revive it or we will be forced to move away from it or even fork it (which I hate).

Let's see if some of the maintainers have something to say. If not we can consider forking it.

Myself and @hackebrot have permission from our respective companies (Mozilla and BriteCore) to dedicate paid time to work on this project. I had hoped to start work back on it in June, but a series of family emergencies blocked me from participating.
I plan to begin working on Cookiecutter in July.

@pydanny, what about my help and help of @ssbarnea. As I see it we have an interest in this project too, so it is a good chance to expand developers team. Why not?

@insspb @ssbarnea I'm willing to entertain the idea!
Next week when I have bandwidth to do open source, we can discuss plans for triaging issues and PRs, your help would be invaluable there and that would give us an opportunity to work together. 😄
Also, considering how frequently this tool is installed across many systems, we need to check your credentials before granting merge access. I'm not sure how to do that, although having someone from RedHat confirm you work there would probably do that.

@pydanny Glad to hear that. There are multiple ways to verify, starting with email, freenode openstack channels (especially #openstack-infra #tripleo are another way). FYI, I am always online on #irc because is needed for my daily work, nicks zbr or ssbarnea (both are registered).
Regarding maintenance, usually I assume that no change would merge without at least two core reviews. On few less mainstream projects I used one-core but only for trivial/minor changes.

Big <3 for keeping the dream alive on this project :rocket:

@pydanny, @ssbarnea
To contact me main methods are email, slack, and Skype. I can be on Freenode on request.
I agree about pr merging after 2 core reviews, except PRs related to docs, typos, etc. No need to waste a lot of time on such things, it is more useful to update them frequently.

@pydanny Maybe we should make a meeting? How to catch you?

This week is intense at work. I'm meeting with my boss tomorrow to get me time to at least talk to people.

Hi @pydanny. Will you able to talk this week?

Yes I will. How about 9PM UTC on July 1?
@insspb @ssbarnea Is there a slack channel you hang out in? Or we could do Gitter. @hackebrot You want in on this discussion? I' thinking topics of discussion will include, but are not :

Moving this project to a GitHub org (a little more complicated than it seems)
Triaging issues and PRs
Revising the change management process
Should we plan for Cookiecutter 2 (drops Python 2.x support)?

@pydanny We with @ssbarnea from different occupations and not from the same organization, so we do not do anything together now, except writing in this thread and discussing this problem.
9 PM UTC is midnight in my TZ, better to make meeting several hours earlier, if possible.
I can join any slack/gitter/skype(preferred)/irc channel

I am in UK so at 9PM is 10PM.,... i am usually outside the home-office but I will setup a reminder that time. Skype

Clearly an github org is better than individual. Unless someone knows another one, I propose https://github.com/pycontribs -- transfer can be done without loosing any ticket and even having users automatically redirected. At least two, preferably 3 people should be marked as repo owners, so we give project some maintenance-redundancy.
Triaging would be what I would focus on (no plans to do any new features myself, at least for now)
I vote for 2x cores requirement
I would not support dropping 2.7 support, at least not until next year.
N/A

@pydanny @ssbarnea So where we will meet? We with @ssbarnea already found each other in Skype, @pydanny can you join Skype?

Alright, Audrey gave me ownership of the Cookiecutter GitHub org that she owned and approval to move Cookiecutter there. That was very nice of her and I've already made that happen.
However, considering how @audreyr has been whitewashed from projects over the years, I'm going to insist she get oodles of permanent credit for the project in the README and other places. When I mentioned this to her, her response was to insist that @hackebrot also get tons of permanent credit.
Now that we're moved over, let's have our discussion in Skype. My account name there should be pydanny. I'll get on and see what happens.

@pydanny added your skype. Check it out.

As a result. We have had a meeting and make some near future plan of project maintenance.
Now we are begging issues and PRs clean up as the first step.

@insspb, @ssbarnea, and @luzfcb have been made Triagers for Cookiecutter.
@luzfcb is a long time contributor to various Cookiecutter projects, in fact based on his skills we hired him at my company.

Apparently this did not help much in what really counts making a release. The last tag and release on https://pypi.org/project/cookiecutter/#history is more than two years old.
Someone need to make this release, even if the tag it as a pre-release one.

Agree. We cannot do releases or modify documentation, so all other work has almost no sense.

@insspb Let me check your rights and ensure you have permission to make necessary changes.

@ssbarnea
After some time I see no other options as change release sequence.
Next alpha release will be today/tomorrow, when I will deal with strange appveyour behavior.
This will include only current master in state as it is, and maybe some doc changes. I will not include any PRs that are not reviewed by several commiters, if it is not doc/test related (all not reviewed).
Then I will switch this project to new/old development model, that should introduce some breathe here.
More details in issue #1256


add trophies from shnatsel's blog post

https://medium.com/@shnatsel/auditing-popular-rust-crates-how-a-one-line-unsafe-has-nearly-ruined-everything-fab2d837ebb1

Should be covered by #38 and #39. I was adding my trophies here as I went along ;)
This issue can be closed.


Refactor Log::Formatter

This replaces the Log::Formatter with a module with two basic implementations:

ProcFormatter: used to allow formatting with a proc, just like it's right now
StaticFormatter inspired in the date/time formatters with the addition of a macro to generate subclasses

Log::Formatter.new { |entry, io| } returns a ProcFormatter and it can be used when the StaticFormatter is not enough.
The macro Log.formatter can be used to generate StaticFormatter subclasses from string patterns, like this:
Log.formatter MyFormatter, "[#{timestamp}] #{severity}: #{message}"

That will create a MyFormatter that will format entries like this:
[2020-04-30T23:33:09.363434000Z]    INFO: Message goes here!

Also, I replaced the default formatter of the IOBackend with one that generates less output by default. We could add other built-in formatters with common patterns.

I'm not sure about this. I didn't have time yet to actually work with the new Log framework to get some experience on whether such an extension is even necessary. It also doesn't seem super important to do and it's not even a substantial change. As far as I can see, it's not even breaking (at least it doesn't need to be).
In any case I would appreciate to discuss the general use cases and API design in a dedicated issue first, before returning to this PR.

@straight-shoota it’s ok not to have experience with every aspect of the language. I’ve been working on this project since the very first lines of code and I also don’t know every corner.
I don’t think I have to open a RFC for every small detail we want to change. This change is actually not big but I do believe it needed some rework to make it easier to use. Formatting the output of a logger is quite an essential part of it.
Please, give it a chance if you want to participate in the changes of this small component. And take this PR as a proposal for the design.

I'm not opposing this, I'm just saying it's hard to see whether this is necessary. I wasn't suggesting that I personally need to know about everythings that's going on, but that the Log framework is very new and so far has only been adapted by a few useres as far as I am aware. So it might be a good idea to see what experiences are made with the current API and whether we actually need to change the way the formatter works.
For example, I'm not sure why you would need so much configurability. IMO the defaults should be good enough for at least 80% so that typical applications don't need to bother about defining custom formats. There might be some use cases where you want specific behaviour, but I'd expect that to be handled in a few libraries that provide logging extensions.

I don’t like the current default output format of the logger so I wanted it to change. But if I just change the format the (infinite) discussion would start ardound what should or shouldn’t be on the output. So at least I wanted to provide an easy way to set a custom output that at the same time lowers the risk of less efficient implementations that affect the performance while logging.
I don’t know any log framework that doesn’t provide a way to customize the output format. And the current one (just a proc) was something Brian and I decided to put just to get it done on the first iteration.
The proposed api is not even complete in terms of flexibility. More methods should be added to the static formatter to avoid having to fall back so easily to the proc. But this is actually what I’d like to be exercised and get feedback so we can fine tune the api.

I like this.
I do have some concerns whether using the struct metaclass instead of a struct value would be limiting. But since the Log::Formatter is a module I guess we are fine for this limitation to apply only in the built-in formatters.
I know @carlhoerberg cares about overriding the progname in some scenarios within the same app. Since this PR is moving progname from the backend to the formatter there would be a need for new formatters for him. Or maybe with the split of context and local data, that can be used instead of progname.
So, 👍 on my end.

Since this PR is moving progname from the backend to the formatter

Actually is being moved to a class variable, so it's the same for all formatters. Changing the progname sounds weird to me, and probably a context value fits better for that case.

It's not highlighted in the discussion here, but this appears to add backtraces to exception logging. Regardless of this PRs movement, this is :+1: from me; currently I've been having to add Log.error { ex.inspect_with_backtrace } in a lot of places to retain our quality of logging.

I don’t like the current default output format of the logger so I wanted it to change.

Changing the current default is great. We must improve that. And I'm sure we can design a default that just fits for most typical applications.

But if I just change the format the (infinite) discussion would start ardound what should or shouldn’t be on the output.

I don't agree on that. A) I expect we can agree on a reasonable default formatter. B) Giving too much options on a feature that (usually) doesn't need such options is a wrong development.
IMO this PR is a premature answer to a problem that doesn't exist yet.
Let's work on the default to be great and see how it works for actual users.
I doubt there's gonna be much need for customized formatters. And for the rare cases there is, alias Log::Formatter = Entry, IO -> is good enough to roll your own.
If it turns out that custom formatters are needed all over the place and people want a better tools for that, I'm all in for adding this. But as long as there's no indication this is actually useful, I'm strictly against adding mor complexity without reason.

@straight-shoota the problem exists. I can speak for myself, but many times I wanted to customize the output of a logging format. Of course it's not something I do all the time, but when I wanted the logging frameworks had some mechanism to do so. And I don't know any logging framework not supporting something for that. Ruby's Logger is extremely simple, and in my opinion too much. On the other extreme of the spectrum, log4j has many different kind of Layout. But I don't pretend go that far. Only provide the adequate and extensible interface.
I think you're overreacting about the complexity of my PR. In any case, we could remove the macro. I think it's neat but @asterite also expressed privately that he wasn't so sure about it.
All I did was replace the formatter requirement from a proc to a module, so it's now possible use static functions, that favors inlining and dispatches faster. Also it's more convenient to create stateful or configurable formatters than passing a closured proc.
I don't think we're moving away too much from this proposal. It matches what in general we think Crystal should provide as the basis for the standard library.

Maybe I think a bit to strong about this. But the fact is not a single real use case has been presented so far. And I'm sure we can't be conrete about this until we have improved the default formatter to a reasonable standard. Only then it's possible to see what use cases it fits and what need extra customization. And for that I'd like to hear about experiences from users.
So I'm not saying we should cut the feature completely. But IMO a necessary step before adding enhanced customization options is to provide a sensible default. We're lacking that currently. I understand that this PR adds that, but I'd prefer to work on that first and separate because it doesn't need a new API.

I'm fine with this PR as long as:

Log::Formatter, all its subtypes and methods are properly documented.
An example in Log::Formatter is shown defining a subclass of it and using the available methods
At the very end, include a section mentioning the macro way, and what it expands to.

That is, the macro way should be demystified, and it shouldn't be presented as the main option.

Thank you @waj, this is sorely needed.   The default logger is way too noisy.  4 of my projects already have custom formatters and each is different depending on need.

Maybe I think a bit to strong about this. But the fact is not a single real use case has been presented so far.

Here's one use case (or several depending on how you see it):
  INFO [ 0.0015 0.0001 #1074926c0]  -- b_pool: ObjectB ↓ checkout 0.00007 -- {"oid" => "107491a80", "qsize" => 30}
  INFO [ 0.0016 0.0001 #1074926c0]  -- example.a: doing x -- {"x" => 0, "size" => 0 }
  INFO [ 0.0017 0.0001 #1074926c0]  -- example.b -- {"z" => 0, "name" => "..." }
  INFO [ 0.0020 0.0030 #107492cc0]  -- a_pool: ObjectB ↑ checkin  0.00000 -- {"oid" => "10748a300", "qsize" => 74}
          ^       ^                                     ^ Different color shades depending on in or out
          |       | Relative time between log calls or between calls per fiber depending on formatter.
          | Relative time since program start.

Colors are missing making the example harder to see.

Both times have grey/white/bright/yellow/red colors depending on the threshold.
When qsize drops below a threshold it's colored yellow or red.
Relative time is more useful than absolute for short program runs like specs and benchmarks.
The output above represents 2 different formatters.  One tracks relative time between log calls and the other between log calls per fiber.

Almost every log framework has a formatter/layout.  There's an obvious need if everyone is doing it.
Please don't let your strong opinion of not using hinder those of us who rely on it daily.

Thanks @didactic-drunk! It helps to look at this use case.
I'm still not convinced it demonstrates a clear argument for a highly-customizable formatter as proposed in this PR. Maybe a adding another default formatter suited for this use case would be a better idea.
IMO it's always better to try to use standardized log formats as much as possible, because that greatly improves usability. I see little point in having a different log format for every program, just because it a slightly different use case than the others. That's can easily cause sysadmin's nightmares.
Also note that using a custom formatter is already possible and will stay that way. It's only about the interface we're exposing for customizing a formatter. Note that the libraries you linked all expose a very thight interface with only a singl format method (or similarly named). Nothing like StaticFormatter with essentially a custom DSL for formatting log messages.
Logs4cplus is a bit different as it uses a formatter string, similar to sprintf or strftime. That would actually be more useful because it allows configuration at runtime, so the annoyed sysadmin can configure the logging output to be in a standardized format, even if the author intended some fancy special logging format.

For specs and benchmarks I sometimes replace timestamp without touching the remaining log format.
@waj provided exactly what I'm looking for.  The ability to override each log value without recreating an entire log format.
Or to change the format and n values without recreating everything else.  I planned my own PR with exactly these features which I discussed with @Blacksmoke16 privately last week.

(Incomplete) Reusable component case:
module ColorSeverity
  def severity(...)
    case ...
    end
  end
end

module ColorTimestamp
  def timestamp
    ...
  end
end

class MyFormat
  include ColorSeverity
  include ColorTimeStamp

  timestamp_colors [{0.001, :gray}, {0.005, :white}, {0.01, ;yellow}, {0.05, :red}]

  def format(...)
    ...
  end
end

class SpecFormat < MyFormat
  include RelativeTime
end

class BenchFormat < MyFormat
  include FiberRelativeTime
end

@straight-shoota I don't think it's fair to block this PR given that everyone else think this is a good change.
Maybe we can merge this and iterate on the default format later on, even after 1.0? Why does the default format needs to be perfect before 1.0?

I have no intention of blocking this. Just wanted to make my objections clear. If you want to merge it, go ahead.

Maybe we can merge this and iterate on the default format later on, even after 1.0? Why does the default format needs to be perfect before 1.0?

If we find a good default format (or a couple ones to choose from) we likely won't need  StaticFormatter at all. So I'd rather ask why we need that at all before 1.0. We can perfectly enhance the formatter API after 1.0 without breaking changes by keeping the Log#formatter=((Entry, IO) ->) overload.
Good defaults should always come before more customization features.
This seems like making two step at once without doing the basic one properly.

I have no intention of blocking thi

Because you requested changed, this can't be merged. We have to dismiss your review, but that's a bit rude.

I have no intention of blocking this. Just wanted to make my objections clear. If you want to merge it, go ahead.

But that's what you just did. I heard every objection as always, but you think this is overdesigned and I don't. You think extensibility is not required and I do. But it's just opinions vs opinions.
The code in this PR is the simplest thing to introduce some flexibility and even reducing overhead.
I know I can dismiss the review, but that's not how I'd like things to work here.

@straight-shoota I think that before and after this PR Log#formatter : Log::Formatter holds.
The same goes for Log::Formatter.new proc (where proc : (Entry, IO) ->)
I think there is a leak of abstraction if you expect Log#formatter=((Entry, IO) ->).
The StaticFormatter is a implementation details that allows simpler definition of formatters, but that is not changing the above interface.

Sorry, I wasn't considering that the review type would block merging. I've revoked it.


Reduce number of classes

Classes like PostmanInfo are just single level collections of strings.  These could probably be handled as properties on the PostmanCollection object with the Javascript info object created by a custom Gson serializer.

Solved with inner classes and serializers


Not clear that Xamarin.Forms builds on Xamarin.iOS/Android

Myself, as well as other Internet people, were a bit confused about how Xamarin.Forms apps run on iOS/Android. That is, are Xamarin.Forms apps special in how they run, or do they "follow the rules" of Xamarin.iOS and Xamarin.Android on their respective platforms?
I talked to the Xamarin.Forms team and indeed it "follows the rules" of Xamarin.iOS/Android. Specifically, on iOS the project is compiled to native iOS code and then packaged up for delivery (that is, AOT), and on Android the MSIL is packaged up along with the Mono runtime and packaged up for delivery and then JIT'ted on the device (at least by default).
I suggest adding a sentence or two to the Xamarin.Forms section of this doc to make the connection between Xamarin.Forms and Xamarin.iOS/Android.
cc @PureWeen

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

ID: 95f1bfc6-27ee-d6b0-6823-bf44d37ae207
Version Independent ID: 278e483a-9b38-451c-8b79-5c36da9190fe
Content: What is Xamarin? - Xamarin
Content Source: docs/get-started/what-is-xamarin.md
Product: xamarin
Technology: xamarin-crossplatform
GitHub Login: @profexorgeek
Microsoft Alias: jusjohns

Separate from this, but in the same doc, I wonder if we should nix the stuff around Mono, just not calling it out by name now.
We're becoming "one .net" for .net 5/6, and emphasizing how we aren't that today, instead are this different but compatible mono thing, but will be in the future, just seems like extra complexity for the user to understand and not really necessary for a conceptual understanding of Xamarin, especially on an intro page. We don't need to convince users to trust mono. Textually it looks like it would work to remove the Mono references, but keep the text that talks about what the execution environment does.
I can submit a PR if desired for that.

Personally I agree about not mentioning Mono (except maybe in some super technical doc). Some people might have some bad taste of Mono from some long-ago experience or some ancient Internet posting that is no longer correct or relevant. Some problems I'm sure do still exist, though (it's not perfect). But it's just .NET as far as a customer is concerned. If there's a problem with .NET on Android, it's a problem for .NET, not specifically Mono.

I've updated the text (clarified that Xamarin.Forms builds Xamarin.iOS and Xamarin.Android apps, and removed mentions of Mono) in a PR that will go live later today.

Thank you @davidbritch !


"Frătăuții Vechi" and "Măneuți" villages are listed in the drop-down menu.

Description:
The villages are listed in the drop-down menu alongside its corresponding county and commune, according to the law
Preconditions:
The website (https://peviitor-ro.github.io/ui.orase/) is up and runing. After every step delete the text you typed from the search bar.

Step 1
Write in the search bar "Frătăuții Vechi".

Expected results
The location is listed in the drop-down menu as "Sat Frătăuții Vechi SUCEAVA (Frătăuții Vechi)".

Step 2
Write in the search bar "Măneuți".

Expected results
The location is listed in the drop-down menu as "Sat Măneuți SUCEAVA (Frătăuții Vechi)".


[Tests-Only]Adjust expected failures for remaining closed issues

Description:
Some of the expected failures are linked with some closed issues. So this PR adjusts the file such that the failing tests are linked with correct issues.
Related Issue:

https://github.com/owncloud/ocis/issues/2078

@jasson99 is this ready?

@jasson99 other PRs have just been merged. Please rebase this so we can be sure that CI passes.

@jasson99 please  make sure to apply the same/similar changes in owncloud/ocis so that all the expected-failures files have up-to-date links.


[Bug]running the default test report address conflict error

Describe the bug
dperf build was finishied without error. I run the default test report conflict then exit.
# root user
./build/dperf -c test/http/server-cps.conf
Error: client and server address conflict

server-cps.conf

the contents of server-cps.conf file

mode        server
cpu         0
duration    10m
port        0000:1b:00.0    <IP_ADDRESS>   <IP_ADDRESS>
client      <IP_ADDRESS>       254
client      <IP_ADDRESS>       254
server      <IP_ADDRESS>      1
listen      80              1

client-cps.conf

the contents of client-cps.conf

cat test/http/client-cps.conf
mode        client
cpu         0
duration    60s
cps         10k
port        0000:1b:00.0    <IP_ADDRESS>   <IP_ADDRESS>
client      <IP_ADDRESS>     2
server      <IP_ADDRESS>      1
listen      80              1

** enviroment**

dperf version

./build/dperf -v
1.7.0

DPDK version

RTE_SDK=dpdk-stable-19.11
RTE_TARGET=arm64-armv8a-linuxapp-gcc

Network card
lspci info

lspci -s 01:00.0 -k
01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
	Subsystem: Intel Corporation Ethernet Server Adapter X520-1
	Kernel driver in use: igb_uio
	Kernel modules: ixgbe

memory info

cat /proc/meminfo | grep -i hugepage
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:       4
HugePages_Free:        4
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:     524288 kB

DPDK hugepage memory

cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
1024
cat /sys/kernel/mm/hugepages/hugepages-524288kB/nr_hugepages
4

Operation System

Kylin V10 030 (RHEL8 like)

client      <IP_ADDRESS>       254
server      <IP_ADDRESS>      1

The server IP(241.27) is in the client IP range(241.1-241.254)

fixed


set_disable_ssl_verification not applying

Hi,
I have configured the set_disable_ssl_verification to True but it's not applying, and this error is of certificate not found is persistent
{SSLError(MaxRetryError("HTTPSConnectionPool(host='iam.cloud.ibm.com', port=443): Max retries exceeded with url: /identity/token (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)')))"))}
I'm applying the disable ssl verification following this documentation https://github.com/IBM/ibm-cloud-sdk-common/blob/main/README.md#programmatically-1.
Thank you,

Thanks for the feedback, I'll look into it. Could you attach the full trace back of the error? It would help a lot.

@nrocaalh we just merged the linked PR which should fix the issue so I am closing this, but feel free to re-open it if needed.

Hi,
Sorry for the delayed response.
I have been doing some tests and it's still don't working from me.
Here I'm attaching the code where I create the connection and I disable the ssl verification.
BASE_URL_REGION=https://eu-de.iaas.cloud.ibm.com/v1
connector_cloud = VpcV1(authenticator=authenticator)
connector_cloud.set_service_url(BASE_URL_REGION)
print("SET DISABLE SSL VERIFICATION")
connector_cloud.set_disable_ssl_verification(True)

Here's the output when I try to do the connection:
<bound method BaseService.set_disable_ssl_verification of <ibm_vpc.vpc_v1.VpcV1 object at 0x00000183428AD8E0>>
2
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): iam.cloud.ibm.com:443
send: b'CONNECT iam.cloud.ibm.com:443 HTTP/1.0\r\n'
send: b'\r\n'
{SSLError(MaxRetryError("HTTPSConnectionPool(host='iam.cloud.ibm.com', port=443): Max retries exceeded with url: /identity/token (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)')))"))}

Also I updated the versión to ibm-cloud-sdk-core==3.19.1 .
Please, let me know if I can help you with more information.
Thanks for your help,

@nrocaalh Did you also disable SSL verification in the IAM authenticator?   That has a similar boolean property to disable ssl verification during the interactions with the IAM identity server.  Please give that a try and report back.

Hi,
I added this option to the IAMAuthenticator and it's working now.
authenticator = IAMAuthenticator(api_key,disable_ssl_verification=True)
Thanks for the help :)


detect and generate architecture information in package.tools.msbuild package

Is your feature request related to a problem? Please describe.
package.tools.msbuild simply apply command arguments and execute build comment. But this package does not check architecture of package, so caller must detect architecture of package manually, like this:
        table.insert(configs, "/p:Platform=" .. (package:is_arch("x64") and "x64" or "Win32"))

It is inconvenient to detect arm64, x86 or x64 with this style of detection, thus many ci in xmake-repo fails on winarm because of incorrect platform setting.
Describe the solution you'd like
Remove manual detection of architecture and mode.
         local configs = {path.join("source", "allinone", "allinone.sln"), "/p:SkipUWP=True", "/p:_IsNativeEnvironment=true"}
-        table.insert(configs, "/p:Configuration=" .. (package:debug() and "Debug" or "Release"))
-        table.insert(configs, "/p:Platform=" .. (package:is_arch("x64") and "x64" or "Win32"))
         import("package.tools.msbuild").build(package, configs)

and insert such codes in package.tools.msbuild:
        if(package:is_arch("x86")) then
            table.insert(configs, "/p:Platform=Win32")
        elseif(package:is_arch("x64")) then
            table.insert(configs, "/p:Platform=x64")
        elseif(package:is_arch("arm64")) then
            table.insert(configs, "/p:Platform=arm64")
        end

Describe alternatives you've considered
No response
Additional context
No response

you can open a pr.


Apnea tags show up as 0 seconds in viewer

I think they are stored in seconds instead of ms and then they get divided by 1000 and end up rounding to zero. However, it also seems like the original computed duration is somehow off, so I need to check that the duration of the apneas is getting computed properly. The file I am currently looking at (J:\Amanda\TestInputFiles\ConvertedUsing1_1_7\UAB\FilesForAmandaZimmet_May29_2020\RNICU_3347-1-1527705568_v1_20180530.hdf5) has an apnea duration of 76 (units?), but in the viewer it looks like it should be around 25 seconds long.

The error was actaully that for a single apnea event, the duration column was calculated as the end index-start index +1 instead of as an actual duration. I think this error only occurred when there was a single apnea event. I have altered the code and will increment the apnea algorithm version number.

Fixed problem here https://github.com/amedwards/NICUHDF5Viewer/commit/fa95b751f70845df700c8673ac71bfadb117991a
and updated apnea version numbers here https://github.com/amedwards/NICUHDF5Viewer/commit/46c7fbf4d1cf2c0023021ee01f296844d6ee0f0e


Slow networking inside containers.

Any idea why the docker container networking is slow. IE. Running Speedtest from CLI on host I’m getting 900+ Mbps. Using the Speedtest container I’m getting less than 100 Mbps.

The speedtest CLI checks between your server and a nearby host on the Internet while the speedtest container tests the speed between your browser and the server.
So, for example, my server is in Paris and I am in the United States.  The CLI is going to test my Internet speed (ie, verify that the ISP is truly delivering what I'm paying for) while the speedtest container is meant to test the user experience (in my case, streaming a large amount of data from Paris to the US).
But, this may not be your situation nor may it be the question you intended to ask so let me know if that answers it or just makes things worse 😄


Fix regression on default value for find_unused_parameters

What does this PR do?
Fixes #14089
The change was unintentionally introduced in #13405, #13744. Tests have been added that fail on master.
Does your PR introduce any breaking changes? If yes, please list them.
No
Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
I made sure I had fun coding 🙃
cc @borda @tchaton @rohitgr7 @justusschock @kaushikb11 @awaelchli @akihironitta

@awaelchli This was merged with Windows job failures. Can you fix them?

Yes, I didn't notice.
The logic is correct. The test just needs to be skipped on Windows.


add option to specify server port at runtime

Add the option to specify browser-sync server port at runtime with the following npm-standard syntax:
npm start -- --port={PORT}
Change leverages functionality already present in browser-sync, so all we are doing here is parsing the args to see if a port argument exists and passing it to browser-sync instead of the default port.

Sweet! Thanks @djeglin


feat(CX-2818): Remove support for floating label in LineChart

Description

Following product decision to remove support for floating label and revert to static label on the Median Sale Price chart, this PR mostly removes all the logic, Components, scaling etc that was previously necessary to support a floating label on scroll.

https://user-images.githubusercontent.com/18648835/188136094-49ae366b-71de-45c3-a3a2-27d9c4102a4b.mp4

This PR resolves CX-2818
QA Testing

Acceptance Criteria

Setup Instructions

PR Checklist

[x] I tested my changes on iOS / Android.
[x] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.
[ ] I added an app state migration.
[ ] I hid my changes behind a feature flag.
[ ] I have prefixed changes that need to be tested during a release QA with [NEEDS EXTERNAL QA] on the changelog.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Remove support for floating label in LineGraph - kizito

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

Niiiice


Unable to run node

There is no error in the process of compiling the code, but an error is reported when running the node, as shown below:

In source code root path, run this:
./bazel-bin/node  --node_id=node0 --service_port=50050 --config=./config/node0.yaml

I‘ll correct it on the developer documentation.

thanks，but I have this problem again：

Generate test data first, run this:
 cd test/primihub/script
sudo bash ./gen_logistic_data.sh

But when I run this command, there will be a connection refused error, is it a network problem?

In source code root path, run this:
cp ./data/* /tmp/

This method does not work either, and my virtual machine network should be fine.
run ping www.baidu.comis allowed

At the same time, after I start the node with the data in /data, I don't know how to complete an MPC calculation, can you guide me?

run default task
./bazel-bin/cli

运行默认任务之后，得到了这样的结果，是我的参数设置有问题嘛？

1.https://docs.primihub.com/docs/advance-usage/start-nodes 启动点的项目目前有正确运行吗？本机有没有4001端口？
2../bazel-bin/cli 运行后有没有正常退出，像这样的输出
# ./bazel-bin/cli --server="<IP_ADDRESS>:9051" Could not create logging file: No such file or directory COULD NOT CREATE A LOGGINGFILE 20220621-173349.75816!I20220621 17:33:49.151315 75816 cli.cc:172] SDK SubmitTask to: <IP_ADDRESS>:50050 I20220621 17:33:49.153991 75816 cli.cc:130]  SubmitTask... I20220621 17:34:03.793741 75816 cli.cc:135] SubmitTask rpc succeeded. I20220621 17:34:03.793792 75816 cli.cc:137] job_id: 100 success
3.node1和node2节点有没有这样的日志

*2.

我的启动节点没有运行，这个问题是go的版本不对么？

Communicate in English PLEASE. Primihub is distributed globally.

I replaced go1.18, but there is still a connection refused error when running。

thank you

Already correct online document, I'll close this issue.


input data format

Hi，
Very interesting with this algorithm. However, as a learner, I could not understand what input data format I should prepared. I supposed I should provide a gene list with ENTREZ ID, but in "txt" or "csv"? which path I should store them?
Looking forward to your timely reply.

A .txt file with a list of the Entrez IDs in single file works fine with the algorithm, I would go with that


xml and images

Eric, I tried using some of the png files for icons (like the nav bar) but it caused problems when adding them to the actual profile screen, so I ended up just using the android studio vectors and it solved the issue. I have uploaded those too (only home, my events, qr scan, profile) if you want to use the same ones, I feel it's easier to use since it provides the XML file already :)
Also, I checked your profile pages earlier and they seemed to be a bit incomplete based on the UI mockup, if you want, you can see how I did mine and reuse it but adapt it to your corresponding profile screen or smth like that.
That was all I could check for now, wait to see what others think :)


Connect favicons on all pages

problem description
Currently, favicon is not connected to various pages:\

About Us page
Blog page
Internship page

I will connect favicon to all pages to give the website a uniform look.

I'm a GSSoC'22 contributor.I want to solve this issue. Kindly assign this issue to me.

@SahityaRoy  I'm a GSSoc'22 contributer. Kindly assign this issue to me.


Add a recipe to glob a directory

The Brioche.glob function allows pulling in files into Brioche, grabbing a subset of inputs from the project directory. There is currently no way to do something similar for recipes themselves: you can get individual files from a directory recipe with the .get() method, but there is no way to get part of a directory. This also means there's no way to optionally get a file from a directory recipe: if the given path doesn't exist, .get() will fail
We should add a new recipe type called glob, which takes a directory recipe and a list of glob patterns as inputs, and bakes to a directory. This recipe will be exposed through a new std.glob function.
const thing = std.directory({
  bin: std.directory({
    "foo": std.file("..."),
    "bar.sh": std.file("..."),
  }),
  lib: std.directory({
    "libbaz.so": std.file("..."),
  }),
});

return std.glob(thing, ["bin/**.sh", "lib/**/*"]);
// Bakes to a directory containing the following paths:
// - bin/bar.sh
// - lib/libbaz.so

We could use this new recipe to clean up this hacky part of the Go package: https://github.com/brioche-dev/brioche-packages/blob/ce96562176d3664dfed6e292f608453492fa2806/packages/go/project.bri#L106-L114

This is needed for terraform package build.
We need to update the go package to support globing directories for go.mod files.


Publish to conan

Could we get libbloom published to the Conan repository, in order to streamline dependency management for downstream projects?
https://conan.io/center/

Sounds like a good idea. I can look into it at some point, but not sure when I'll have free time.  If anyone wants to do it meanwhile feel free, just add a note here so we all know.


When host labels are removed,existing containers that were deployed with host affinity label continues to be running on these hosts.

Server Version - build from master 06/01
Steps to reproduce the problem:
1.Have a host -h1 with label set to  "foo=bar"
2.Activate a service which has host affinity label set to "foo=bar" and global set to true -
("io.rancher.scheduler.global" = "true" and "io.rancher.scheduler.affinity:host_label" ="foo=bar"
3.Instance gets created in host1
4.Remove the label "foo=bar" from this host
Instances created on host1 continue to be in "running" state on host1.
Should we expect , the instances to be removed since the host does not have the label that is needed for the service any more ?
Or should there be a confirmation presented to the user , before making a decision on whether these containers need to be removed or not ?

Son, what should be the right behavior here?

I think I recall Darren mentioning we should be careful about stopping containers so I think the best behavior would be to prompt the user.

Perhaps this could be part of our "Trigger" feature.

Related issue #1114


[Server] S3 operations require ?x-id=OPNAME which is not compatible with existing clients

There are several operations in S3 model with an http route spec that don't seem to match existing client SDK behavior.
One example is GetObject which has this trait:
                "smithy.api#http": {
                    "method": "GET",
                    "uri": "/{Bucket}/{Key+}?x-id=GetObject",
                    "code": 200
                }

This spec requires ?x-id=GetObject, and the codegen-server will not match this operation unless this query is provided, which is not compatible to standard AWS clients (such as the AWS CLI which uses python SDK) and is also not a documented query param in the REST API docs (link).
Any idea how is this model definition compatible with existing clients?
CC @crisidev

I honestly do not know. What I believe is that the S3 model is not the best example of standard practices and we will have to review the behaviour. You are already providing a ton of help with these bug reports BTW :)
I am currently in holidays until the 10th of January and I will have to reconvene with my team mates on this before coming back with a real answer. I believe we will have to implement some special handling for this..

also worth noting that since the Rust S3 client is generated from exactly these models it should be compatible which might make testing easier for the moment

To be honest, I actually don't know. @adamthom-amzn who worked on the Typescript server codegen may know better. My guess is that an S3 client that works with all clients may need some hand written overrides.

@david-perez Since this seems like a gap in the spec that will not be able to close soon, and the server routing cannot differentiate between "similar" S3 operations without it (another example is PutObject vcs CopyObject which differ only in an http header x-amz-copy-from ...), so perhaps we can expose named RequestSpec's from the operation_registry code, and then I will be able to code these rules manually. WDYT?

@guymguym I don't understand what you mean with named RequestSpecs and coding the rules manually. Can you be more specific?

@david-perez Let me rephrase -
currently in operation_registry the server returns a aws_smithy_http_server::routing::Router instance from a OperationRegistry.
I have several problems to extend this model:

The routes vec in the router is private, so I can't modify it to tweak its order.
The request_spec.match() function is not customizable so I cannot affect how matching is done per route.
Last, for an API like S3, there are ~200 operations, and most of those have the same uri_path_regex regexp (all bucket operations, all object operations, ...) so what actually happens is that we iterate and call a bunch of the same match calls per every operation, which can be easily optimized.

So I can easily write the S3 routing logic by hand, it's simple and not too long to maintain, but I would want access to the generated route_specs - so I thought of adding the route_specs as fields to the OperationRegistry struct where each field is named after its operation and holds the route_spec that I can reuse its generated information.
BTW was there a reason not to generate a single trait for the registry where each route is an async function?
Maybe there are other ways to achieve the same through tower::Layer but I am not sure how...
Would be great to hear your thoughts! Thanks!!

@guymguym

currently in operation_registry the server returns a aws_smithy_http_server::routing::Router instance from a OperationRegistry.
I have several problems to extend this model:

The routes vec in the router is private, so I can't modify it to tweak its order.
The request_spec.match() function is not customizable so I cannot affect how matching is done per route.
Last, for an API like S3, there are ~200 operations, and most of those have the same uri_path_regex regexp (all bucket operations, all object operations, ...) so what actually happens is that we iterate and call a bunch of the same match calls per every operation, which can be easily optimized.

(1) and (2) are by design. The user should only have to define their Smithy model and not worry about the internal routing implementation.
For (3), I'm not sure I follow. Routing early-returns when the first RequestSpec matches the incoming request, so there are no unnecessary matches.
https://github.com/awslabs/smithy-rs/blob/f4d3910f227ceb4962eadac994540edb45137709/rust-runtime/aws-smithy-http-server/src/routing/mod.rs#L153-L162
If what you mean is that you're worried that "common" routes are at the end of the vector, then you're right in that most requests will do a bunch of unnecessary regex matches before being routed, and that it'd be more efficient to sort routes by how frequent they'll be hit. I don't think iterating over a 200-item vector is a performance issue; the business logic is likely orders of magnitude more time-consuming than the routing. Time incurred by matching with regexes can definitely be improved though: since the routes are static, we can use code-generated nom parsers, which are faster according to this benchmark, and which we're using to do label extraction.
Ultimately though, routing would continue to be linear in the number of routes. Routing is linear in most web frameworks I know of. The only exception being Axum, which uses the matchit router, that internally builds a radix tree, thus making routing sublinear. I briefly looked into using matchit in smithy-rs, but it wasn't easy to adapt it to Smithy's routing requirements (for instance, routing based on query parameters). I think when Smithy publishes their URI conflict resolution proposal, we should revisit the routing implementation and give sublinear routing another try, although I suspect the performance benefits will only be noticeable for a huge amount of routes.
If you run any benchmarks comparing current routing performance with any of these ideas, I'd be interested in the numbers, to see which one we should implement.

BTW was there a reason not to generate a single trait for the registry where each route is an async function?

The generated operation registry requires that when you register an operation implementation (the async function or closure), it conforms to the specific operation's input and output shapes. So the function's input and output have to be of certain types, namely, the input has to be the operation's input, and the output has to be the operation's output, or a Result in case the operation is fallible. If all you'd require in the operation registry were for operation implementations to implement a certain trait, you'd lose this type-safety.

Routing performance aside, this GitHub issue is because of the ambiguous routing that arises if you remove the ?x-id=OPNAME from the S3 model. And that you'd like a temporary workaround to be able to remove that query param and still be able to build the server SDK and for routing to not be ambiguous. We should come up with ideas to tackle that. If you'd like to discuss or improve routing performance, please open another issue.

Thanks @david-perez !!
Routing performance aside.
I don't know yet what to suggest to resolve the x-id ambiguity, it seems that S3 API is a hybrid of operations vs. resources oriented API... Perhaps looking at the manual routing I wrote for s3d would help to ignite the discussion, see here -
Parsing http path&query to op-kind enum:
https://github.com/guymguym/s3d/blob/518b19d33b63b3a6040279009564247fa3453a64/src/http.rs#L107-L173
This is the manual mapping code:
https://github.com/guymguym/s3d/blob/518b19d33b63b3a6040279009564247fa3453a64/src/resources.rs

@guymguym Can you provide a list of conflicting routes in the S3 API you'd like to see disambiguated?

@david-perez Sure I already extracted this list.
Here is all the S3 operations with x-id in their uri:
$ node -e 'm = require("./aws/sdk/aws-models/s3.json"); for (s of Object.values(m.shapes)) { t = s.traits?.["smithy.api#http"]; if (t?.uri.includes("x-id=")) console.log(t.method, t.uri); }' | sort

DELETE /{Bucket}/{Key+}?x-id=AbortMultipartUpload
DELETE /{Bucket}/{Key+}?x-id=DeleteObject

GET /{Bucket}/{Key+}?x-id=GetObject
GET /{Bucket}/{Key+}?x-id=ListParts
GET /{Bucket}?analytics&x-id=GetBucketAnalyticsConfiguration
GET /{Bucket}?analytics&x-id=ListBucketAnalyticsConfigurations
GET /{Bucket}?intelligent-tiering&x-id=GetBucketIntelligentTieringConfiguration
GET /{Bucket}?intelligent-tiering&x-id=ListBucketIntelligentTieringConfigurations
GET /{Bucket}?inventory&x-id=GetBucketInventoryConfiguration
GET /{Bucket}?inventory&x-id=ListBucketInventoryConfigurations
GET /{Bucket}?metrics&x-id=GetBucketMetricsConfiguration
GET /{Bucket}?metrics&x-id=ListBucketMetricsConfigurations

POST /WriteGetObjectResponse?x-id=WriteGetObjectResponse
POST /{Bucket}/{Key+}?restore&x-id=RestoreObject
POST /{Bucket}/{Key+}?select&select-type=2&x-id=SelectObjectContent
POST /{Bucket}/{Key+}?uploads&x-id=CreateMultipartUpload
POST /{Bucket}/{Key+}?x-id=CompleteMultipartUpload
POST /{Bucket}?delete&x-id=DeleteObjects

PUT /{Bucket}/{Key+}?x-id=CopyObject
PUT /{Bucket}/{Key+}?x-id=PutObject
PUT /{Bucket}/{Key+}?x-id=UploadPart
PUT /{Bucket}/{Key+}?x-id=UploadPartCopy

Case 1 - route based on a required http header existence
The header in these cases is x-amz-copy-source which helps to separate between copy and put:
PUT /{Bucket}/{Key+}?x-id=CopyObject  (+x-amz-copy-source)
PUT /{Bucket}/{Key+}?x-id=PutObject

PUT /{Bucket}/{Key+}?x-id=UploadPart
PUT /{Bucket}/{Key+}?x-id=UploadPartCopy  (+x-amz-copy-source)

Case 2 - route based on existence of a required query key which is also an input field
These cases were added because a required query param cannot be specified in the route URI when its value is an actual input field (like ?uploadId=123 or ?partNumber=456), and not a fixed api value (like ?list-type=2). In the smithy spec you cannot specify just a key like ?uploadId in the uri to separate those cases because that's just like ?uploadId= and will fail to route and a value is provided. Maybe the spec can allow it with ?uploadId=* ?
I extracted this list of all httpQuery & required cases, but notice that not all of these required adding x-id because for some of them there is no other operation which conflicted, but the ones that do exist in the top list like GetObject vs ListParts, or GetBucketMetricsConfiguration vs ListBucketMetricsConfigurations indeed fall in this case.
 smithy-rs  $ node -e 'm = require("./aws/sdk/aws-models/s3.json"); for ([n,s] of Object.entries(m.shapes)) if (s.type == "structure") for ([k,v] of Object.entries(s.members)) if (v?.traits?.["smithy.api#httpQuery"] && v?.traits?.["smithy.api#required"]) console.log(k, n);' | sort
Id com.amazonaws.s3#DeleteBucketAnalyticsConfigurationRequest
Id com.amazonaws.s3#DeleteBucketIntelligentTieringConfigurationRequest
Id com.amazonaws.s3#DeleteBucketInventoryConfigurationRequest
Id com.amazonaws.s3#DeleteBucketMetricsConfigurationRequest
Id com.amazonaws.s3#GetBucketAnalyticsConfigurationRequest
Id com.amazonaws.s3#GetBucketIntelligentTieringConfigurationRequest
Id com.amazonaws.s3#GetBucketInventoryConfigurationRequest
Id com.amazonaws.s3#GetBucketMetricsConfigurationRequest
Id com.amazonaws.s3#PutBucketAnalyticsConfigurationRequest
Id com.amazonaws.s3#PutBucketIntelligentTieringConfigurationRequest
Id com.amazonaws.s3#PutBucketInventoryConfigurationRequest
Id com.amazonaws.s3#PutBucketMetricsConfigurationRequest
PartNumber com.amazonaws.s3#UploadPartCopyRequest
PartNumber com.amazonaws.s3#UploadPartRequest
UploadId com.amazonaws.s3#AbortMultipartUploadRequest
UploadId com.amazonaws.s3#CompleteMultipartUploadRequest
UploadId com.amazonaws.s3#ListPartsRequest
UploadId com.amazonaws.s3#UploadPartCopyRequest
UploadId com.amazonaws.s3#UploadPartRequest

Case 3 - other POST cases
I am not sure exactly about the POST cases - some might require the x-id because of a conflict with case1/2, but there are some which I didn't understand why this was needed, such as WriteGetObjectResponse, RestoreObject, SelectObjectContent, DeleteObjects.


AOSARES1 is wrong during 2011:187 SSM dwell

Telemetry shows a value of around 110 pitch, should be 90.  This may be the case during other NSM dwells.  This has an impact on thermal modeling using these long NSM dwells for calibration.  Tool to fix HDF or post-fetch hook to fix?

AOSARES1 is an OBC parameter and therefore invalid during SSM while we're being controlled by the CPE.  (You can tell by the mnemonic name; the "A" stands for "ACS parameter" (i.e. PCAD) and the "O" stands for "per the OBC").
However, during NSM (still on OBC control), the value is still valid.

Good point.  I haven't checked how the PCAD derived params (DP_PITCH) behave during SSM, but presumably they are similarly inaccurate.  Can we (or should we) adjust the PCAD derived params to give good values at all times?  There can be a conditional in the code that looks at other values during SSM or even just hardwires to 90 deg. pitch and 0 roll.

Yes, almost every normally-used PCAD parameter (derived or not) will be inaccurate during SSM because they're almost all telemetered from the OBC.  During SSM, we look at an entirely different set of parameters sent from the OBC (6* instead of A* parameters).  They're not nearly as thorough, but they're enough to get by.  I definitely wouldn't suggest modifying the "real" (2000+) PCAD/OBC telemetry parameters.  Similarly, I'd prefer to leave the PCAD derived parameters alone during this time frame and place the onus on the engineer to interpret the data correctly.  While some of the PCAD derived parameters would have good, easy-to-calculate SSM equivalents (e.g., CSS_pitch, FSS_CSS_angle_diff), others are entirely irrelevant during SSM (e.g., maneuver angle).  Personally, I don't think it's worth the effort/confusion of adding the switch.  However, if/when 6* parameters are added to the archive, I would be interested in generating _SM versions of the derived parameters that have a SSM equivalent.  It would certainly make writing the bi-annual easier.
Another motivator is the fact that I'd really, really like to filter_bad all FSS-derived PCAD parameters when out of the FSS FOV.
As an alternative, I would suggest we generate a table of "special events" times.  Then we can filter_bad data that fall within these time ranges if we don't want them to affect our analyses.  (For example, thermal models.)  Perhaps separate tables for NSM and SSM?
-----Original Message-----
From: Tom Aldcroft<EMAIL_ADDRESS>Sent: Thursday, January 12, 2012 1:49 PM
To: Amanda Arvai
Subject: Re: [eng_archive] AOSARES1 is wrong during 2011:187 SSM dwell (#17)
Good point.  I haven't checked how the PCAD derived params (DP_PITCH) behave during SSM, but presumably they are similarly inaccurate.  Can we (or should we) adjust the PCAD derived params to give good values at all times?  There can be a conditional in the code that looks at other values during SSM or even just hardwires to 90 deg. pitch and 0 roll.

Reply to this email directly or view it on GitHub:
https://github.com/sot/eng_archive/issues/17#issuecomment-3468369


Feature request: add option for nightly development kernels

Could it be possible to add this option so that instead of only having julia-release available, we could also use julia-nightly kernels?
This would be nice because I'm already using Julia from JuliaBox almost all the time, at work I am always on the move, since julia-dev is not available I also use an account at koding.com with julia-nightly installed, but it doesn't support IJulia.
I know they are not really nightly builds but still is very useful especially to report bugs and such.

Recently done in #243

May not be deployed yet.

Cool ...it looks that way, I'll wait patiently!
Ismael Venegas Castelló
El 19/06/2015 20:11, "Viral B. Shah"<EMAIL_ADDRESS>escribió:

May not be deployed yet.
—
Reply to this email directly or view it on GitHub
https://github.com/JuliaLang/JuliaBox/issues/244#issuecomment-113690360.


2 small bugs with MatterControl

These last two bugs with MatterControl appear to mostly be fixed.

Opening files with the file icon can cause the program to crash. You must "drag and drop" the .STL files you wish to use directly into the design workspace.
Repainting the window is necessary to see the program. When the main software window opens, grab the side or corner of the window to resize it.

These two bugs appear to be completely remedied on a laptop interface in Ubuntu 20.04. The file open icon is disabled, forcing the user to drag and drop files from a file explorer window.
The resizing issue to repaint the screen looks to be fixed by painting the initial window bigger than the screen size. This forces the window to resize itself. The effect is almost invisible to the user.
Where these bugs can still be seen is on dual monitor setups, common for developers. I've tested both environments and took initiative to document the behavior. It's fixed enough for my taste, but some folks might pick on this.

Cura's last bug looks to be addressed with a new revision. 4.11 is the latest revision as of this writing. Version 4.07 had this issue.
The settings menu would disappear, reappear, and disappear as you worked through it adjusting things. You had to resize the menu to see all the options again.
Update to v4.11 or later to fix this issue. It looks to be a newer menu control that also runs faster. There are more settings available in this newer version, too.


Output dimension of FocalNet models does not match label dimension of ImageNet-22K-MS

FocalNet models with ImageNet22K output have an output dimension of 21842:
https://github.com/huggingface/pytorch-image-models/blob/59b3d86c1d69fe85ccb5bbdb2f1711eadae6e4a7/timm/models/focalnet.py#L514-L525
>>> from timm import create_model
>>> model = create_model('focalnet_large_fl3.ms_in22k', pretrained=True).eval()
>>> model.num_classes
21842

However, the associated ImageNetInfo has 21841 classes.
>>> from timm.data import ImageNetInfo
>>> in22kms = ImageNetInfo("imagenet-22k-ms")
>>> in22kms.num_classes()
21841

Expected behavior
I expected timm/data/_info/imagenet22k_ms_synsets.txt to have 21842 classes to match the dimensionality of ImageNet22K-output FocalNets, but this file only has 21841 lines. Is one output dimension meant to be a background class?

@eringrant hmm, I have to look closely, I recall this class mapping is a bit odd, they moved in1k classes to the first 1000 but there is one imagenet1k class that doesn't exist in the 22k dataset (the teddy bear class). Sooo, either I bungled handling that gap or I mixed up the synset file with another...

@eringrant I have an updated version of the 22k_ms synsets file in the linked PR above (open one, made a mistake with the first one).
If you happen to be setup to check the correctness (ie have some examples you're looking at), if the updated one appears correct please let me know. I have to look a bit more closely at the other related mappings ...

To check correctness, would you look at consistency of imagenet22k_ms_synsets.txt labels with FocalNet top-k predictions, or is there some other reference to use when validating the indices? Whatever it is, I can have a debugging look on Friday this week.

@eringrant the synset mapping is only used in naming the predictions, I compared a few predictions and found a few obvious mistakes that the PR improved, can be hard as with 22k as related classes are often next to each other and so it can look similar with that many classes..


[flowbroker][ansible] error when trying add remote node

The above error happens when I run:  curl -H "Authorization: Bearer ${JWT}" http://aya.dojot.com.br/flows/v1/node -H 'content-type: application/json' -d '{"image": "dojot/kelvin-example:v0.5", "id":"kelvin"}'
When I using docker-compose and run  curl -H "Authorization: Bearer ${JWT}" http://localhost:8000/flows/v1/node -H 'content-type: application/json' -d '{"image": "dojot/kelvin-example:v0.5", "id":"kelvin"}' everything works fine.

I tried restarting the pod, but it didn't solve the problem.
Tested in not yet published v0.4.4-rc.1 (https://github.com/dojot/ansible-dojot/commit/9b056e21c5c1340ffc2e86e1470875edaf8574b4)
Commit used to create docker img  https://github.com/dojot/flowbroker/commit/e9f48a2db7c19be5e33927b0bfd92138f0a0789c
Probably this happen at v0.5.x and development.

Fixed in v0.4.4-rc.1
Needs to be tested on v0.5.0-rc.1

Fixed in v0.5.0-rc.1


[Ad hoc metrics for OPS] Remove tooltips and add spinners

Description
Refactor https://github.com/ManageIQ/manageiq/pull/12165

[x] Add spinners when data is loading
[x] Add titles for tables in the expanded list veiw
[x] Remove tooltips that are just verbatim copy of the labels.

Screenshots
Spinners

Titles

@miq-bot add_label providers/containers,ui,refactor
@simon3z @zeari @moolitayer please review

:+1: if this was agreed with @serenamarie125
Maybe @himdel can review this for the haml/css side.

@simon3z
I think @serenamarie125 is OK with https://github.com/ManageIQ/manageiq/pull/13038
We still need @serenamarie125 review on this one.

@yaacov @simon3z I am 👍

moved to https://github.com/ManageIQ/manageiq-ui-classic/pull/27


ProjectedFields in the renderlistasstream API endpoint seem to have stopped working

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
macOS
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[X] 💥 Google Chrome
[ ] 💥 FireFox
[X] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details
SharePoint API
Describe the bug / error
We use the SharePoint renderlistasstream REST API from within our SPFx app and write CAML queries to project fields from joined tables.  These queries have run successfully for years.
These projections stopped working on Thursday on our dev tenancies, and has started impacting customer tenancies today.
Was there a published / expected change to this API that we missed, or is this a regression?
Example CAML code below.
   <Joins>
        <Join Type='LEFT' ListAlias='Company'>
          <Eq>
            <FieldRef Name='ATVCompanyLookup' RefType='Id'/>
            <FieldRef List='Company' Name='ID'/>
          </Eq>
        </Join>
      </Joins>
      <ProjectedFields>
        <Field Name='ATVCompanyLookup_ID'
          Type='Lookup'
          List='Company'
          ShowField='ID'/>
        <Field Name='ATVCompanyLookup_ATVCompanyCode'
          Type='Lookup'
          List='Company'
          ShowField='ATVCompanyCode'/>

      </ProjectedFields>

We now get just the lookup IDs but not the expanded view fields when running any query making a join and projecting fields.
Steps to reproduce
Running queries against the REST API endpoint from any browser
Expected behavior
We expected the lookup values to be projected as the named fields in the server API response.

@marcus-atvero - could you please share a minimal config and code to repro the issue.
I'm interested in lists schemas and piece of code that you're using to get the data.
Thanks!

I also have the same problem, apparently something was updated at the tenant level

The same problem occurred on German servers, but not on other servers

Can someone provide a minimal config and code snippet to repro an issue?
Thanks!

Hi, we are using PnPJS to make the query, so just pulling that together and will follow up with it.
For my example above, we have a SharePoint list with a single lookup onto another list called Company.  The single lookup is called ATVCompanyLookup.
The Company list has a text field called ATVCompanyCode
We've worked around this by adding the columns we want to the list view (which you can do manually on the Lookup column by choosing other columns to project for the lookup) and those values appear, but the projection in the CAML query to the renderListAsStream above returns the named fields, as Lookup fields with the id specified, but not the value.

We also use the pnpjs's renderListDataAsStream fun to get join items, we use the same code, but only one customer has this problem and the others don't.

Sorry, we use PnP in ReasonML so the code isn't easy to share, but the XML query is
<View>
  <Joins>
    <Join Type='LEFT' ListAlias='DLM_Placeholders'>
      <Eq>
        <FieldRef Name='ATVSupersededBy' RefType='Id'/>
        <FieldRef List='DLM_Placeholders' Name='ID'/>
      </Eq>
    </Join>
    <Join Type='LEFT' ListAlias='DLM_Revisions'>
      <Eq>
        <FieldRef Name='ATVLastRevision' RefType='Id'/>
        <FieldRef List='DLM_Revisions' Name='ID'/>
      </Eq>
    </Join>
    <Join Type='LEFT' ListAlias='DMS_Library'>
      <Eq>
        <FieldRef Name='ATVDocumentLookup' RefType='Id'/>
        <FieldRef List='DMS_Library' Name='ID'/>
      </Eq>
    </Join>
    <Join Type='LEFT' ListAlias='Confidential_DMS_Library'>
      <Eq>
        <FieldRef Name='ATVConfidentialDocumentLookup' RefType='Id'/>
        <FieldRef List='Confidential_DMS_Library' Name='ID'/>
      </Eq>
    </Join>
  </Joins>
  <ProjectedFields>
    <Field Name='LastRevision_ATVDateKey' Type='Lookup' List='DLM_Revisions' ShowField='ATVDateKey'/>
    <Field Name='LastRevision_ATVDescriptionField' Type='Lookup' List='DLM_Revisions' ShowField='ATVDescriptionField'/>
    <Field Name='LastRevision_ATVDocumentNumber' Type='Lookup' List='DLM_Revisions' ShowField='ATVDocumentNumber'/>
    <Field Name='LastRevision_ATVDocumentTitle' Type='Lookup' List='DLM_Revisions' ShowField='ATVDocumentTitle'/>
    <Field Name='LastRevision_ATVQAApprovalString' Type='Lookup' List='DLM_Revisions' ShowField='ATVQAApprovalString'/>
    <Field Name='LastRevision_ATVReceivedReference' Type='Lookup' List='DLM_Revisions' ShowField='ATVReceivedReference'/>
    <Field Name='LastRevision_ATVRenditionTypes' Type='Lookup' List='DLM_Revisions' ShowField='ATVRenditionTypes'/>
    <Field Name='LastRevision_ATVRevision' Type='Lookup' List='DLM_Revisions' ShowField='ATVRevision'/>
    <Field Name='LastRevision_ATVScaleField' Type='Lookup' List='DLM_Revisions' ShowField='ATVScaleField'/>
    <Field Name='LastRevision_ATVSizeField' Type='Lookup' List='DLM_Revisions' ShowField='ATVSizeField'/>
    <Field Name='LastRevision_ATVStatusField' Type='Lookup' List='DLM_Revisions' ShowField='ATVStatusField'/>
    <Field Name='LastRevision_ATVSuitabilityField' Type='Lookup' List='DLM_Revisions' ShowField='ATVSuitabilityField'/>
    <Field Name='LastRevision_ATVTransmittal' Type='Lookup' List='DLM_Revisions' ShowField='ATVTransmittal'/>
    <Field Name='LastRevision_ATVUploadedBy' Type='Lookup' List='DLM_Revisions' ShowField='ATVUploadedBy'/>
    <Field Name='LastRevision_Created' Type='Lookup' List='DLM_Revisions' ShowField='Created'/>
    <Field Name='LastRevision_GUID' Type='Lookup' List='DLM_Revisions' ShowField='GUID'/>
    <Field Name='LastRevision_ID' Type='Lookup' List='DLM_Revisions' ShowField='ID'/>
    <Field Name='LastRevision_Modified' Type='Lookup' List='DLM_Revisions' ShowField='Modified'/>
    <Field Name='LastRevision_Title' Type='Lookup' List='DLM_Revisions' ShowField='Title'/>
    <Field Name='ATVSupersededBy_Title' Type='Lookup' List='DLM_Placeholders' ShowField='Title'/>
    <Field Name='ATVSupersededBy_ID' Type='Lookup' List='DLM_Placeholders' ShowField='ID'/>
    <Field Name='Document_ATVFileLength' Type='Lookup' List='DMS_Library' ShowField='ATVFileLength'/>
    <Field Name='Document_ATVServerRelativeUrl' Type='Lookup' List='DMS_Library' ShowField='ATVServerRelativeUrl'/>
    <Field Name='Document_ID' Type='Lookup' List='DMS_Library' ShowField='ID'/>
    <Field Name='Document_Created' Type='Lookup' List='DMS_Library' ShowField='Created'/>
    <Field Name='Confidential_Document_ATVFileLength' Type='Lookup' List='Confidential_DMS_Library' ShowField='ATVFileLength'/>
    <Field Name='Confidential_Document_ATVServerRelativeUrl' Type='Lookup' List='Confidential_DMS_Library' ShowField='ATVServerRelativeUrl'/>
    <Field Name='Confidential_Document_ID' Type='Lookup' List='Confidential_DMS_Library' ShowField='ID'/>
    <Field Name='Confidential_Document_Created' Type='Lookup' List='Confidential_DMS_Library' ShowField='Created'/>
    <Field Name='ATVLastRevision_ATVDocumentTitle' Type='Lookup' List='DLM_Revisions' ShowField='ATVDocumentTitle'/>
    <Field Name='ATVLastRevision_ATVRevision' Type='Lookup' List='DLM_Revisions' ShowField='ATVRevision'/>
    <Field Name='ATVLastRevision_ATVQAApprovalString' Type='Lookup' List='DLM_Revisions' ShowField='ATVQAApprovalString'/>
  </ProjectedFields>
  <Query>
    <OrderBy>
      <FieldRef Name=\"ATVNumberField\" Ascending=\"True\"/>
    </OrderBy>
    <Where>
      <IsNull>
        <FieldRef Name=\"ATVHideReason\"/>
      </IsNull>
    </Where>
  </Query>
  <RowLimit Paged=\"TRUE\">100</RowLimit>
</View>

Any updates in this topic?
We have 2 tenants with this issue with CAML query with ProjectedFields using RenderListAsStream API from 2 weeks back.

@marcus-atvero @matsla - we're looking into it.
If you want to expedite the process - please, also submit a Microsoft support ticket

Hello @AJIXuMuK Any updates in this topic? This stop working from 2 month ago.

Any updates? same issue at some tenants and only when the using the REST API, not when using CSOM.

The responsible team is working on the issue.

More updates?

More updates?

Is there any update on this?


Update german translation for alaska ginseng

In german it's Igelkraftwurz

Please make any further contributions over at Crowdin. Thank you.
https://crowdin.com/project/rdr2collectorsmap
https://crowdin.com/project/rdr2rdomap


List revdeps integration testing

This tests that the correct reverse depencencies are listed. With our dummy opam-repository we add a new version of package a-1, on which b.0.0.1 and b.0.0.2 depend.
The test currently requires Docker and takes more than 2 minutes to run, as it has to go through the entire Dockerfile. The PR is a draft until this can be improved.
While running, the test pipeline can be monitored on localhost:8080.
Other refactoring is also included.

Given the number of conflicts here and the WIP to replace the CI logic for revdeps listing with a CLI tool that can list revdeps tests (and run the tests in a single worker), I'm not clear on whether we should move forward with this work. WDYT, @benmandrew and @punchagan ?


Time sync client and server

Since the NetManager uses incoming packet queue, the processing of the incoming packet may be delayed. So, I need some packet ArrivalTime in the INetEventListener.OnNetworkReceive request to be able more accurately sync the time between client and server. Typical time sync is
serverTime = packet.ServerTime + ping / 2;

I thing for the LiteNetLib NetManager I would need to correct it
serverTime = packet.ServerTime + ping / 2 + (DateTime.Now - packet.ArrivalTime);

I know the difference  (DateTime.Now - packet.ArrivalTime) is usually small (tens of ms), so it's not a blocker for me, but it would be nice to have it.

Added simple time sync with pong packet

https://github.com/RevenantX/LiteNetLib/commit/0a772486b0322def150d8b10e3e8b0a7cf5d5724


Implemented APY calculation for sJOE(successor of xJOE)

sJOE is a revenue share model that replaced xJOE. There is no receipt token such as xJOE anymore, rather the JOE is staked in a contract that rewards in USDC once per day. The USDC rewards are airdropped to the staking contract once per day and the amount depends on the trading fee revenue of the platform.
This made the APY calculation a bit more tricky than usual, because there is no definitive reward rate. Rather the staking contract keeps track of the totalAccumulatedRewards(all USDC rewards collected since the beginning of the farm). This property accRewardPerShare is written to once per day where the new rewards are added up.
         accRewardPerShare[_token] = accRewardPerShare[_token].add(
            _accruedReward.mul(ACC_REWARD_PER_SHARE_PRECISION).div(_totalJoe)
        );

Since there is no property that gives a fixed reward rate, the APY needs to be calculated based on the past rewards. TraderJoe also states on their site that they give an APR calculation based on an average of the last 7 days.
Since we don't have access to those daily reward numbers, my approach is to calculate an overall average per day by dividing the total number of accumulated rewards since beginning of the farm by the number of days that the farm exists.
What took me some time to figure out is how the ACC_REWARD_PER_SHARE_PRECISION works. It is used for scaling the rewardsPerShare based on the amount of JOE(18 dec) to the USDC value of that(6 dec). (See code snippet above)
I'm aware that the resulting APY is currently higher than what's displayed on TraderJoe, but we do not know how exactly they calculate their 7 days average and this calculation here is based on the true on-chain numbers.

They get volume for last 7 days from subgraph https://api.thegraph.com/subgraphs/name/traderjoe-xyz/exchange/graphql and calc rewards as 0.05% of it.
This will match APR pretty closely.

Thanks for the tip Roman, didn't know you can query literally their whole database over the subgraph api :smile:


[feat] easier creation of metadata / stuff

Describe the problem
Right now if you want to pass data from child to layout you do it via stuff. A common usecase is defining metatags. It can be a bit verbose to write this:
<script context="module">
  /** @type {import('@sveltejs/kit').Load} */
  export async function load({ stuff }) {
    return {
      stuff: {
        metadata: {
          description: 'page description here'
        }
      }
    };
  }
</script>

Describe the proposed solution and alternatives considered
Option 1
Take anything not in a known property and add it to stuff. Or potentially only properties whitelisted by the user. Then you could save a few lines of code:
<script context="module">
  /** @type {import('@sveltejs/kit').Load} */
  export async function load({ stuff }) {
    return {
      metadata: {
        description: 'page description here'
      }
    };
  }
</script>

The downside to this of course is that if we add any new property to the return value it's potentially a breaking change. But we might be willing to make that tradeoff if the improvement in ergonomics is deemed sufficient and we felt it was unlikely we'd introduce many new fields to the return value
Option 2
Having stuff is nice because you can control the contents based on data dynamically fetched from the server. However, much of the time that is unnecessary and the data is simply static. It could also be nice if you could write something like this in the child node:
<script context="module">
  export const metadata: {
    description: 'page description here'
  };
</script>

We could make the leaf node available to load.
Option 3
Similar to option 2, but instead of making just the leaf node available, we could make an object with the fields in each layout / child with the children overriding the parents and then make it available in load. The trickiest part of this would probably be how to refer to it and differentiate it from stuff in the API
Option 4
Create a new variable like statics that you can define outside of load that SvelteKit will make available in load. This is similar to the last option in some ways, but only works with a single SvelteKit-defined property
Importance
nice to have
Additional Information
No response

I really don't like "any unknown options get treated as such-and-such" APIs. That would include "everything that's not one of the known load return keys gets put into stuff" and "every module export from the component that's not load/ssr/prerender/etc. gets put into stuff".

Seconding Con on this one, especially as we would lose forwards compatibility since any added properties would be breaking changes. Well, I guess they wouldn't be breaking in the whitelisting case, but it'd still be a hassle for little upside.
Having direct access to the module so you can get exported data might be less troublesome, although I'm not sure whether it'd come with its own set of warts.

Yeah, I totally get the aversion to that. I've edited my post to break out of the confines of the Github issue template and more clearly delineate the four possible options I came up with. I just wanted to lay all the various options out there even if some were unlikely to be adopted for the sake of completeness. Some of the options avoid the issue you're talking about. I suspect option 4 would be the most appealing. Maybe I should have led off with that one instead of putting it last :smile: I'd love any other ideas as well.
It takes 12 lines of code on every page right now to define a page meta description, which just feels like too much. I expect we could reduce this a fair amount.

as Conduitry said, also it means adding new features (properties that will be able to return in load), will break all apps, using load function. So this is totally bleh.

Yeah, I think the first option had pretty clearly been shot down. I included all options just for the sake of completeness, but I don't think we need to focus on that one as I acknowledged the shortcomings of that solution even when I raised it.
I was thinking that statics would not be merged with stuff. I suppose it could be if that were preferred, but it wasn't what I had in mind
I was hoping including many options would spark discussion, but is seems I may have miscalculated on that


ol5: render changes features positions

Hi,
We changed openlayers version from 4.6.5 to 5.1.3.
We noticed that when first time map is rendered (with 5.1.3 version) the view looks exactly same than with old version (4.6.5) of openlayers. But when map is rendered again some features moves little bit on the screen. I made some debugging and look source code and I found the reason:
In PluggableMap.renderFrame function in version 4.6.5 there is:
    viewState = view.getState();
    var center = viewState.center;
    var pixelResolution = viewState.resolution / this.pixelRatio_;
    center[0] = Math.round(center[0] / pixelResolution) * pixelResolution;
    center[1] = Math.round(center[1] / pixelResolution) * pixelResolution;

and in 5.1.3
      viewState = view.getState();
      let focus = this.focus_;
      if (!focus) {
        focus = viewState.center;
        const pixelResolution = viewState.resolution / this.pixelRatio_;
        focus[0] = Math.round(focus[0] / pixelResolution) * pixelResolution;
        focus[1] = Math.round(focus[1] / pixelResolution) * pixelResolution;
      }

So in 4.6.5 version, rounding of 'center' is done always but in 5.1.3 version only on first time.

Thanks for reporting this. #7871 indeed introduced a regression here.


chore: centralize proto files

https://github.com/numaproj/numaflow/pull/1402

I imagine the process of introducing proto file changes would be:

A PR in numaflow repo for proto file changes.
During Go sdk development, temporarily points to the numaflow PR branch to download proto files for codegen, and raise a PR;
Merge numaflow PR;
Merge Go sdk PR.
Work on other SDKs implementation.
Add a non-blocking CI to run make proto for all the sdks, to indicate if there's drift on the codegen.

Another option is, use Go SDK repo as the the location for centralized proto files.
@vigith - WDYT?

I imagine the process of introducing proto file changes would be:

A PR in numaflow repo for proto file changes.
During Go sdk development, temporarily points to the numaflow PR branch to download proto files for codegen, and raise a PR;
Merge numaflow PR;
Merge Go sdk PR.
Work on other SDKs implementation.
Add a non-blocking CI to run make proto for all the sdks, to indicate if there's drift on the codegen.

Sounds good to me.
I think we can make the main in this URL path can be overrideable via ENV var? This will help in fetching the proto file easier for development without editing the script.

I imagine the process of introducing proto file changes would be:

A PR in numaflow repo for proto file changes.
During Go sdk development, temporarily points to the numaflow PR branch to download proto files for codegen, and raise a PR;
Merge numaflow PR;
Merge Go sdk PR.
Work on other SDKs implementation.
Add a non-blocking CI to run make proto for all the sdks, to indicate if there's drift on the codegen.

Sounds good to me.
I think we can make the main in this URL path can be overrideable via ENV var? This will help in fetching the proto file easier for development without editing the script.

Makes sense.

Could we please hold off on merging this pull request for now? I am currently making some changes to the proto files in two of my pending PRs. Merging this right now could create conflicts with those changes.

@yhl25 - can you remove the change request?

Proto Generate will be green after https://github.com/numaproj/numaflow/pull/1466 is merged.


BeaconAPI Spec Conformance

Description
Non-conformance to BeaconAPI spec.
Steps to Reproduce (Bug)
Issues with the following endpoints:

API Path
Inputs
Issue

/eth/v1/beacon/states/(state)/root
"head"
No execution_optimistic field

/eth/v1/beacon/states/{state_id}/fork
"head"
No execution_optimistic field

/eth/v1/beacon/states/{state_id}/finality_checkpoints
"head"
No execution_optimistic field

/eth/v1/beacon/states/{state_id}/validators
"head"
No execution_optimistic field

/eth/v1/beacon/states/{state_id}/committees
"head"
No execution_optimistic field

/eth/v1/beacon/states/{state_id}/sync_committees
"head"
No execution_optimistic field

/eth/v1/beacon/headers
"head"
No execution_optimistic field

Versions (Add all that apply)

Software version: teku/v22.5.0+65-ga583e7a/linux-x86_64/-debian-openjdk64bitservervm-java-17
Java version: N/A
OS Name & Version: N/A
Docker Version: N/A
Cloud VM, type, size: N/A

Thanks for raising this, I've had a look into it and there were definitely some missing.
I'm not sure if something had already changed, but states/{state_id}/validators, states/{state_id}/committees, states/{state_id}/sync_committees, beacon/headers do list execution_optimistic in their responses.
The other endpoints it as missing, they've been recently migrated to a new framework and for whatever reason it was missed.
As we transition, the documentation and code are disconnected, so I did a pass of these endpoints and the published doc does appear to include execution_optimistic, so was just a code level issue.


Fetch validators by address

The current indexer api only supports fetching by entityID, which might be harder for users to derive. This ticket should be revisited when implementing the consensus part of Oasis Explorer
For reference, oasisscan uses consensus address too

This was implemented.


Enable Dark mode

Having both light and dark modes makes the website more adaptive and easy to operate in.

can you assign  the issue please


Error in running "flutter build ios-framework" command in Android Studio on macOS

I have created a Flutter Plugin with Android Studio to make a .aar or .framework library for using in native Android or iOS projects. Actually I have created some dart classes in my project with a few methods but I encountered some problems:
First: when I run "flutter build ios-framework" command in Android Studio on macOS an error with following information occurs:
command
flutter build ios-framework
exception
FileSystemException: FileSystemException: Directory listing failed, path = '/Users/maleki/Documents/FlutterSource/flutter_module_pakat/build/ios/framework/Debug/iphoneos/Debug-iphoneos/' (OS Error: No such file or directory, errno = 2)

#0      _Directory._fillWithDirectoryListing (dart:io-patch/directory_patch.dart:39:68)
#1      _Directory.listSync (dart:io/directory_impl.dart:251:5)
#2      ForwardingDirectory.listSync (package:file/src/forwarding/forwarding_directory.dart:45:12)
#3      BuildIOSFrameworkCommand._producePlugins (package:flutter_tools/src/commands/build_ios_framework.dart:390:61)
<asynchronous suspension>
#4      BuildIOSFrameworkCommand.runCommand (package:flutter_tools/src/commands/build_ios_framework.dart:175:15)
<asynchronous suspension>
#5      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:615:18)
#6      _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:73:64)
#7      _rootRunUnary (dart:async/zone.dart:1134:38)
#8      _CustomZone.runUnary (dart:async/zone.dart:1031:19)
#9      _FutureListener.handleValue (dart:async/future_impl.dart:139:18)
#10     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:680:45)
#11     Future._propagateToListeners (dart:async/future_impl.dart:709:32)
#12     Future._completeWithValue (dart:async/future_impl.dart:524:5)
#13     Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:554:7)
#14     _rootRun (dart:async/zone.dart:1126:13)
#15     _CustomZone.run (dart:async/zone.dart:1023:19)
#16     _CustomZone.runGuarded (dart:async/zone.dart:925:7)
#17     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:965:23)
#18     _microtaskLoop (dart:async/schedule_microtask.dart:43:21)
#19     _startMicrotaskLoop (dart:async/schedule_microtask.dart:52:5)
#20     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:118:13)
#21     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:175:5)

flutter doctor
[✓] Flutter (Channel stable, v1.12.13+hotfix.7, on Mac OS X 10.14.6 18G84, locale en-US)
    • Flutter version 1.12.13+hotfix.7 at /Users/maleki/Downloads/flutter
    • Framework revision 9f5ff2306b (7 days ago), 2020-01-26 22:38:26 -0800
    • Engine revision a67792536c
    • Dart version 2.7.0

[!] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/maleki/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    ! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses

[✓] Xcode - develop for iOS and macOS (Xcode 11.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.3, Build version 11C29
    • CocoaPods version 1.7.5

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 40.2.2
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] Connected device (1 available)
    • iPhone 11 Pro Max • F80AB22B-8B96-4784-A8FA-1E64A9783DB1 • ios • com.apple.CoreSimulator.SimRuntime.iOS-13-3 (simulator)

! Doctor found issues in 1 category.

Second: when I export .aar library in Android Studio on windows and import it in a native Android project, only native java written classes and methods are accessible not the dart ones.
Please help me.

Hi @msndvlpr
can you please provide your flutter build ios-framework --verbose
thank you

Hi @msndvlpr
I see there's an open issue addressing the case you described.
Please follow up on that issue,
I'm closing the current one as duplicate.
If you disagree please write in the comments
and I will reopen it.
Thank you