Please document vendor Javascript files

Hello,
I'm a new Foundation user and I would like to get to read a page explaining what are the vendor Javascripts Foundation depends on.
For instance, when downloading foundation-5.0.3.zip from http://foundation.zurb.com/develop/download.html I'm getting:
js
├── foundation
│   ├── foundation.abide.js
│   ├── ...
│   └── foundation.topbar.js
├── foundation.min.js
├── jquery.js
├── modernizr.js
└── vendor
    ├── fastclick.js
    ├── jquery.cookie.js
    ├── jquery.js
    ├── modernizr.js
    └── placeholder.js

jquery.js and modernizr.js are present two times. According to http://foundation.zurb.com/forum/posts/926-javascript-setup---which-vendor-files the ones not under vendor/ should not be used. Then, why ship them?
According also to this forum post, jquery.cookie.js is used by the Joyride addon and is indeed mentioned on http://foundation.zurb.com/docs/components/joyride.html. That being said, searching for "jquery.cookie.js" from the documentation landing page (http://foundation.zurb.com/docs/) yields no result.
Another thing that forum post says is that placeholder.js is not a dependency. I supposed a new Foundation user could be given a hint on when to use this polyfill: I guess when both targeting IE9 and Forms.  I deduced one version is copied from the other (from a directory replicating each project distribution). Nonetheless, this is confusing.
Finally, lodash! What is it? Do I need it? And when?
Thanks for reading, these were questions I asked myself when discovering your project for the first time.

The docs now contain an explanation of the js/vendor javascripts found in the bower and npm packages. The location under Sass Files instead of the Javascript page is counter-intuitive though.


Xcode 9 - Availability checks for Objective-C

A brief bug description.
Xcode 9 - Availability warnings.
Stack trace.

FSCalendarCollectionView.m:50:41: 'UISemanticContentAttributeForceLeftToRight' is only available on iOS 9.0 or newer - Enclose 'UISemanticContentAttributeForceLeftToRight' in an @available check to silence this warning
FSCalendarCollectionView.m:50:14: 'setSemanticContentAttribute:' is only available on iOS 9.0 or newer - Enclose 'UISemanticContentAttributeForceLeftToRight' in an @available check to silence this warning

Integration method.
CocoaPods
Full steps to reproduce.
Build the project in Xcode 9.
Device modal and iOS version.
iPhone 8, iOS 11
Xcode version.
Xcode 9 (9A235)
FSCalendar version.
FSCalendar 2.7.9 (from main branch)
Does this happen in the demo project? Which one? Or a link to another demo project.
Unfortunately I was not able to detect this in the demo project. My project is migrated to Swift 4, uses the recommended project settings and is targeting iOS 9+.

Hey @WenchaoD,
Would it be possible to update the library to support the latest addition of Objective-C - availability checks? Would love to see the warnings that Xcode generates removed.
Looking forward to your feedback.
Cheers,
Sasho

I've done some modification but I can't reproduce the warning either. Could you try the main branch again?

Hey @WenchaoD,
I just checked it again using the main branch, and the issue seems to be resolved. There we no warnings this time.
Thank you for looking into it, I appreciate it!
Cheers,
Sasho


terminate the goroutines gracefully and reset terminal

Fixes #3064
Fixes #3203
Signed-off-by: Chanwit Kaewkasi<EMAIL_ADDRESS>

as discussed in standup, let's please split the PR up into two so that we get proper release notes entries.


Fix for Sidebar Line - various updates

Added fix for sidebar line ( thanks René ). Updated scss to match opnsense theme changes.

@marjohn56 I missed this, is it still relevant? René pushed some changes in the meantime.

Dunno, did he push changes for rebellion?

Cannot see the line anymore so I guess it's sorted.

ok, thanks 👍


definition

[ ] I am at the right place and my issue is directly related to ROS#. General technical questions I would post e.g. at ROS Answers or Stack Overflow. For library-specific questions I would look for help in the corresponding library forums.
[ ] I have thoroughly read the Contributing Guideline and writing this issue is the right thing to do in my case.

I have a question!

[ ] I searched the Wiki, open and closed issues for an answer. I tried my best to find the answer by myself without success. I believe that the discussion we will have in this issue, and the solutions we might find, will help me, and likely other community members who have a similar problem.

Here is my question:

I found a bug!

[ ] I am using the latest ROS# version available here on the master branch.

[ ] I am adding all required information, code and data files, screenshots and log files so that you can reproduce the problem.

My OS is: windows 7

My Unity Version is: 2017.3.1f1

My ROS Distribution is:

My Build Target Platform is:

Here is my bug description:
Assets/RosSharp/scripts/UrdfComponents/UrdfInertal.cs(213,51): error CS0117:'UnityEngine.Quaternion' does not contain a definition for 'Normalize'
Perform the following steps reproduce the bug:

Observed results:

Expected results:

Relevant Code:
<!-- Insert code here. Optionally attach code or data files to this issue. -->

I have a feature request!
I want to do this:

For being able to do it, I wish ROS# had the following feature:

Hi @KTigerFIre ,
please update your Unity version to 2018.x (see Quaternion.Normalize docs for Unity 2018.2 here)
Please also make sure to thoroughly read the Platform Support section in README.md.
Please also think about a more specific title in your next issue.
If updating your Unity version solves your problem, please do not forget to close this issue.
Best,
Martin


[types][beta-5] fixed stacked scale, changed default type for data.labels

fix https://github.com/chartjs/Chart.js/issues/7821
Also changed the type for data.labels, the value can be string, Date, etc. Since not all types are known, set unknown by default.

To me it looks like stack option is missing from IChartDataset, care to add that too?
As a side note, it looks like the documentation only mentions that for Bar, while it looks like its available to all chart types (https://codepen.io/kurkle/pen/bGejbNE).

@kurkle I added stack to all dataset config.
I am not good at writing docs, but added dataset general config (Dataset Configuration) in the Data Structures


Full Documentation

Required Topics include:

[x] Usage Guidelines
[x] Development Guidelines
[x] Contribution Guidelines
[x] Weaver Design Overview
[x] ACL Basics, Formats and Management
[x] Routing and Sharding (Working & available strategies)

Added documentation, closing this.


[Question]: ValueError: The model_name argument must be provided

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
I don't use huggingface because of proxy issue. So, I tried to make local embedding as follows
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, ServiceContext
from llama_index.llms.llama_cpp import LlamaCPP

llm = LlamaCPP(
    model_path="models/llama-3-Korean-Bllossom-8B.Q2_K.gguf",
)

documents = SimpleDirectoryReader("./data/").load_data()

service_context = ServiceContext.from_defaults(llm=llm, embed_model='local')
index = VectorStoreIndex.from_documents(documents, service_context=service_context)

#Query your data
query_engine = index.as_query_engine()
response = query_engine.query("What did the author do growing up?")
print(response)

But, I got the error as follows.  How can it be resolved?
ValueError                                Traceback (most recent call last)
Cell In[15], line 10
      4 llm = LlamaCPP(
      5     model_path="models/llama-3-Korean-Bllossom-8B.Q2_K.gguf",
      6 )
      8 documents = SimpleDirectoryReader("./data/").load_data()
---> 10 service_context = ServiceContext.from_defaults(llm=llm, embed_model='local')
     11 index = VectorStoreIndex.from_documents(documents, service_context=service_context)
     13 #Query your data

File /opt/conda/lib/python3.10/site-packages/deprecated/classic.py:285, in deprecated.<locals>.wrapper_function(wrapped_, instance_, args_, kwargs_)
    283 else:
    284     warnings.warn(msg, category=category, stacklevel=_routine_stacklevel)
--> 285 return wrapped_(*args_, **kwargs_)

File /opt/conda/lib/python3.10/site-packages/llama_index/core/service_context.py:200, in ServiceContext.from_defaults(cls, llm_predictor, llm, prompt_helper, embed_model, node_parser, text_splitter, transformations, llama_logger, callback_manager, system_prompt, query_wrapper_prompt, pydantic_program_mode, chunk_size, chunk_overlap, context_window, num_output, chunk_size_limit)
    195         llm_predictor.query_wrapper_prompt = query_wrapper_prompt
    197 # NOTE: the embed_model isn't used in all indices
    198 # NOTE: embed model should be a transformation, but the way the service
    199 # context works, we can't put in there yet.
--> 200 embed_model = resolve_embed_model(embed_model)
    201 embed_model.callback_manager = callback_manager
    203 prompt_helper = prompt_helper or _get_default_prompt_helper(
    204     llm_metadata=llm_predictor.metadata,
    205     context_window=context_window,
    206     num_output=num_output,
    207 )

File /opt/conda/lib/python3.10/site-packages/llama_index/core/embeddings/utils.py:110, in resolve_embed_model(embed_model, callback_manager)
    107     cache_folder = os.path.join(get_cache_dir(), "models")
    108     os.makedirs(cache_folder, exist_ok=True)
--> 110     embed_model = HuggingFaceEmbedding(
    111         model_name=model_name, cache_folder=cache_folder
    112     )
    113 except ImportError:
    114     raise ImportError(
    115         "`llama-index-embeddings-huggingface` package not found, "
    116         "please run `pip install llama-index-embeddings-huggingface`"
    117     )

File /opt/conda/lib/python3.10/site-packages/llama_index/embeddings/huggingface/base.py:151, in HuggingFaceEmbedding.__init__(self, model_name, tokenizer_name, pooling, max_length, query_instruction, text_instruction, normalize, model, tokenizer, embed_batch_size, cache_folder, trust_remote_code, device, callback_manager, parallel_process, target_devices, **model_kwargs)
    147         raise ValueError(
    148             f"{variable} is deprecated. Please remove it from the arguments."
    149         )
    150 if model_name is None:
--> 151     raise ValueError("The `model_name` argument must be provided.")
    153 self._model = SentenceTransformer(
    154     model_name,
    155     device=self._device,
   (...)
    164     **model_kwargs,
    165 )
    166 if max_length:

ValueError: The `model_name` argument must be provided.

I have executed your code and it seems to be trying to connect to the following link: https://huggingface.co/.
Is there any way to do this without using HuggingFace embeddings?
OSError: We couldn't connect to 'https://huggingface.co/' to load this file, couldn't find it in the cached files and it looks like BAAI/bge-small-en is not the path to a directory containing a file named config.json.
Checkout your internet connection or see how to run the library in offline mode at 'https://huggingface.co/docs/transformers/installation#offline-mode'.


Add serialization for PlanNode classes

Allow serializing query plans into JSON using ISerializable framework. Use
VectorSaver to serialize vectors found in ValuesNodes.
To serialize: plan->serialize().
To deserialize:
PlanNode::registerSerDe();

auto plan = velox::ISerializable::deserialize<PlanNode>(serialized, pool());

The following plan nodes support serialization:

Aggregation
AssignUniqueId
EnforceSingleRow
Filter
HashJoin and MergeJoin
Limit
LocalMerge
Project
OrderBy
TopN
UnnestNode
Values
Window

Follow-up PRs will add serialization support to the rest of the plan nodes:

CrossJoinNode
ExchangeNode
GroupIdNode
LocalPartitionNode
MergeExchangeNode
PartitionedOutputNode
TableScanNode
TableWriteNode

Part of #4303

@pedroerp Pedro, thank you for reviewing. Update to address your comments. Looking forward to another round.


Issue 56: Add pathfinder init

This is a new draft PR aimed at addressing #56 .
The main innovation for this PR occurs here:
https://github.com/CDCgov/Rt-without-renewal/blob/ac788d04a0494e87fd66ccd8c4943437aaba1276/EpiAware/docs/src/examples/getting_started_pf.jl#L245-L291
The aim is to ultimately have _epi_aware as an _internal_method as part of a wider workflow. But for this PR it is getting this functionality available.
The current first pass behaviour is for _epi_aware to take in the information required to act on make_epi_aware; then do multipathfinder and pass the initial parameters to sample (as per this workflow).

This is just waiting on these commets -> issues if we agree they should be dealt with and then this can be merged (resolving the conversations should allow auto-merge to do this)

Once this has stabilised and we have taken it out for a spin it would be interesting to float this wrapper to Pathfinder.jl

Codecov Report
Attention: Patch coverage is 93.54839% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 96.96%. Comparing base (6fd57d8) to head (957944a).

Files
Patch %
Lines

EpiAware/src/inference-methods.jl
93.54%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #117      +/-   ##
==========================================
- Coverage   97.76%   96.96%   -0.80%
==========================================
  Files           6        7       +1
  Lines         134      165      +31
==========================================
+ Hits          131      160      +29
- Misses          3        5       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I've increased the testing for manypathfinder:

More expected failures.
Verbose fail if retries all fail.
KS test that the best pathfinder run is a good approximation to a simple normal (if it isn't then thats an obvious problem).

We discussed face to face reordering the inputs to match multipathfinder but think that has yet to happen? Once that is done and we have a new issue for falling back on more functionality from multipathfinder I think this is good to go. It also sounds like we have some confusion about the aim with the docstrings but again perhaps that needs a new issue to discuss..

I've changed the input to match manypathfinder input to multipathfinder, e.g. manypathfinder(mdl, ndraws; kwargs...) -> PathfinderResult is the current signature.

After a quick scoping, I don't have immediate plans to use more multipathfinder functionality under the hood anymore.

After a quick scoping, I don't have immediate plans to use more multipathfinder functionality under the hood anymore.

Why

After a quick scoping, I don't have immediate plans to use more multipathfinder functionality under the hood anymore.

Why

I thought that the try catch pattern in manypathfinder could be replaced by fail_on_nonfinite = false in pathfinder kwargs, but the behaviour of the Distributions.NegativeBinomial distribution constructor chucks an error if we find a NaN during warm-up. manypathfinder is resilient to that fail mode.


Restore computability of min and max on Real

This fixes a regression from #18707, effectively re-applying leanprover-community/mathlib3#9806

!bench

bors merge


Add spinner to Repo Management

Go to Repo Management.
Before:
There's an empty statepage before data loads.
After:
There's a spinner before data loads.

renderContent already does do the spinner in both the local & remote branches .. but the empty check was added before the loading check in the Remote tab.
So, better fix it there? Or remove the spinner from renderContent and keep your change around it?

@himdel Thanks :) I removed it from render to make it more consistent with other pages.

Makes sense :) But unless github cache is deceiving me, maybe you forgot to push the update? ;)

@himdel I didn't even commit it locally 😮  Fixed 😸


Size calculated with default height when collection is reloaded.

Describe the bug
Given a collection of items using .dynamic height, calling reloadData() causes cells to be re-sized using the default height of 150 and not their actual height.
To Reproduce
Steps to reproduce the behavior:

Download project:
MagazineLayout.zip Or visit Gist: ViewController.swift and add into a project
Once running, scroll to the bottom and lick on an item
See the scroll offset jump

Expected behavior
No change in scroll offset
Screenshots
N/A - otherwise layout is good.
Smartphone (please complete the following information):

Device/Simulator: Device and Simulator
OS: 9+
Version v1.4.5 and possibly earlier

Additional context
This does not happen when providing a static height.

@GWStuartClift thanks for the report! I gave your sample view controller a shot, and I see the jump you're talking about. Here's the problem -
When you call reloadData(), you're telling collection view and the layout to throw out all sizing information. This causes the collection view's layoutSubviews to relayout the collection view with estimated heights. For MagazineLayout, this estimatedHeight is 150. I replaced MagazineLayout with flow layout (and made TextCell subclass UICollectionViewCell), and I experienced similar issues.
In general, you shouldn't need to call reloadData - especially not when you're already scrolled down in your collection. Can you switch to using batch updates via performBatchUpdates? This will yield better performance, and you'll avoid throwing out layout sizing information.

Thank you for the quick response @bryankeller.
I initially blamed the jump on the fact that sizing the cell at the estimatedHeight of 150 was causing constraints to no longer be satisfiable. This was most easily seen when calling reloadData() in a real life project. I seem to have lost this in the process of simplifying a reproducible case and ended up blaming reloadData() instead which is in fact behaving as you've suggested.
If I apply the below patch to the project and run everything is fine until I begin to scroll and suddenly get the familiar unsatisfiable constraint spam. Should I open a separate issue or am I going wrong somewhere?
diff --git a/MagazineLayoutRepro/ViewController.swift b/MagazineLayoutRepro/ViewController.swift
index ecf53fe..38fdc54 100644
--- a/MagazineLayoutRepro/ViewController.swift
+++ b/MagazineLayoutRepro/ViewController.swift
@@ -91,6 +91,7 @@ final class TextCell: MagazineLayoutCollectionViewCell {
             label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor),
             label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor),
             label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor),
+            label.heightAnchor.constraint(equalToConstant: 30)
             ])
     }
 }

@GWStuartClift Since you're embedding this label in a collection view, the cell should not have a required height. We solve this in the Airbnb app by lowering the constraint priority of the bottomAnchor constraint for the view we're pinning to the cell's edges.
As UICollectionView self-sizes items, the items will first receive their estimatedHeight before receiving their preferred height. Your item's subviews should have a constraint set up that will accept this estimated height.

Righto, that was the conclusion I had come to but it's good to know that it's the accepted solution here.
I'll close this issue, thank you for the discussion.

we resolved this issue with like this
roundedCornerView.snp.makeConstraints {
      $0.top.right.left.equalToSuperview()
      $0.bottom.lessThanOrEqualToSuperview()
}

if your stackview height is not correct, you need add any other element to end of your view

Hello fellows, We resolved this issue with @varol
We have 2 solutions. You can use which one is good for you.

First one is to update layout for 150 height cells. You can put it to base class and it will be solved from base for all cells which has problem. But you have to think that if you have 150 height normally, layout will update to unnecessary twice.

open func collectionView(_ collectionView: UICollectionView, willDisplay cell: UICollectionViewCell, forItemAt indexPath: IndexPath) {
        if cell.frame.size.height == 150 {
            DispatchQueue.main.async {
                collectionView.collectionViewLayout.invalidateLayout()
                collectionView.layoutIfNeeded()
            }
        }
    }

Second one is to calculate to cell height. You have to calculate cell height by hand.

class CardIconFreeTextLabelVM: MagazineCellDataType {

    var sizeMode: MagazineLayoutItemSizeMode {
        return MagazineLayoutItemSizeMode(widthMode: .fullWidth(respectsHorizontalInsets: true),
                                          heightMode: .static(height: cellHeight))
    }

    let title: String
    let iconName: String

    var cellHeight: CGFloat = 0

    init(title: String, iconName: String) {
        self.title = title
        self.iconName = iconName

        heightCalculator()
    }

    var diffHash: Int {
        return .zero
    }

    func heightCalculator() {
        let mainInset = UIEdgeInsets(top: 12, left: 12, bottom: 12, right: 12)
        let screenWidth = UIScreen.main.bounds.width

        let iconWidth: CGFloat = 20
        let mainStackViewInset = UIEdgeInsets(top: 12, left: 16, bottom: 12, right: 16)
        let mainStackViewSpacing: CGFloat = 4

        var height: CGFloat = mainStackViewInset.top + mainStackViewInset.bottom
        height += title.height(withConstrainedWidth: screenWidth - (mainInset.left + mainInset.right + mainStackViewInset.left + mainStackViewInset.right + iconWidth + mainStackViewSpacing), font: TextStyle.paragraphBody2.font)

        cellHeight = height
    }

    func configurator() -> CellConfigurator {
        return CardIconFreeTextLabelConfigurator(item: self)
    }
}

extension String {
    func height(withConstrainedWidth width: CGFloat, font: UIFont, numberOfLines: Int = 0) -> CGFloat {
        let label =  UILabel(frame: CGRect(x: 0, y: 0, width: width, height: .greatestFiniteMagnitude))
        label.numberOfLines = numberOfLines
        label.text = self
        label.font = font
        label.sizeToFit()

        return label.frame.height
    }
}


Revisit SwiftUI error handling

The current implementation on macOS indirects the error in a way that makes it hard to work out where in the application the error will be handled.

I've been slowly moving errors into the view-model objects which makes things much clearer.


Reorganize code

This moves code away from tasks.go to more specific files.
It should make it easier to find all code related to a certain task type.

:+1: LGTM


net: TestUnixAndUnixpacketServer flaky on linux

https://build.golang.org/log/09fce21c31d8c4435fb99a4f7c0e8a1bb2bf900f and
https://build.golang.org/log/faa4560674d8e7d406b7031bfe985db237b9860a:
--- FAIL: TestUnixAndUnixpacketServer (0.00s)
    server_test.go:197: #3: EOF
FAIL
FAIL	net	8.796s

See previously #13205 (CC @bradfitz).

/cc @mikioh

Here's one on linux-amd64-jessie:
https://build.golang.org/log/3845a3972f455aadd7d2a606928e7ba68d8fd2fd

linux-s390x-ibm: https://build.golang.org/log/895e752f114ea5e0b3e13598c5615957274122a6

TestUnixAndUnixpacketServer makes use of transponder function for the echo server. After some investigation I noticed that the test become stable if connection is not closed. I basically commented the below defer c.Close() line.
https://github.com/golang/go/blob/a6a7b148f874b32a34e833893971b471cd9cdeb7/src/net/mockserver_test.go#L222-226
I am not sure why this is happening. In theory the Close should take care of flushing all the data of socket before actually closing it.
Is it possible that for really unlucky cases the connection gets closed before the client is able to read the data?

https://build.golang.org/log/2c48966d096d8f0799059c471d75445fd89f8c1e

Just seen on linux-amd64 TryBot wit https://golang.org/cl/226497 for release-branch.go1.14: https://storage.googleapis.com/go-build-log/17d3b934/linux-amd64_9d353879.log

2020-04-22T14:14:34-e93d5b5/linux-mips64le-mengzhuo
2020-04-22T11:37:03-a45ea55/linux-mips64le-mengzhuo
2020-04-18T20:01:46-f5291cf/linux-mips64le-mengzhuo
2020-04-08T20:57:26-a036185/linux-mips64le-mengzhuo
2020-02-26T23:27:55-12cd55c/linux-mips64le-mengzhuo
2020-02-24T01:50:28-402ea9e/linux-amd64-sid
2020-01-22T15:24:05-6718cb6/linux-mips64le-mengzhuo
2020-01-09T17:28:58-957259b/linux-386
2019-11-19T19:14:25-8608733/linux-mips64le-mengzhuo
2019-11-05T16:29:31-f0390ff/linux-386-sid
2019-10-28T16:56:52-6afabe2/linux-mips64le-mengzhuo
2019-09-30T15:43:34-5f1aeae/linux-amd64-fedora
2019-06-21T21:02:09-1803ab1/linux-s390x-ibm
2019-05-30T12:01:18-2ae793e/linux-amd64-jessie
2019-05-02T14:44:05-19f5c23/linux-amd64-race


[python3] vcpkg cmake wrappers must not used find_dependency

Describe the bug
find_dependency must only be used in cmake package config files. The wrappers neither provides the interface variables nor the call stack for return().
Affected ports:
$ git grep "find_dependency"  ports/*/vcpkg-cmake-wrapper*
ports/curlpp/vcpkg-cmake-wrapper.cmake:find_dependency(CURL)
ports/libuv/vcpkg-cmake-wrapper.cmake:find_dependency(Threads)
ports/python3/vcpkg-cmake-wrapper.cmake:            find_dependency(ZLIB)
ports/python3/vcpkg-cmake-wrapper.cmake:            find_dependency(Iconv)
ports/python3/vcpkg-cmake-wrapper.cmake:            find_dependency(Intl)

Alternatives:

plain find_package
a future vcpkg_find_dependency

The issue is still present in curlpp and python3.

The issue is still present in python3.


refactor: Rewrite project from jQuery to React

Implemented datavzrd's web part into react

Wrongly force pushed and deleted files from fork sorry about it.

@CanOzk I just had a quick look into the example report and i think the filtering doesnt work properly after a page change. Besides that it already looks very nice! Great work!

Probably I should return to first page and update the pagination when filtering, I'll take a look into that then let you know about it.


use of expl_noise

Couldn't find the usage of expl_noise in actual td3 implementation

Oh yeah, expl_noise is an artifact from the original TD3 github. It's not used by TD3+BC.


refactor: update typescript and related packages

Sorry @azinoviev I missed this PR. Most changes should be already included in v5. Thanks for the contribution!


Sorry about that. Just a typo.


Proposal Creation Wizard: Role Assignment Overview Screen missing Date, Duration, Deferral & Commitment (S)

Reproduce:
1.- Try to create a Generic contribution and go all the way to the Review step
2.- go out of the process without publishing
3.- Return to proposal creation and try to create a role assignemnt proposal
Expected behaviour:

Experienced behaviour:

@arsenijesavic now we have a new bug where the start date is missing, see:
https://dao.hypha.earth/hypha/proposals/30777
https://dao.hypha.earth/hypha/proposals/30919

Are all those bugs connected? Should we schedule a frontend dev call later or tomorrow with @jmgayosso and @pugakn  and try to figure this out? There seem to be many related bugs here

Yes, it is!

@arsenijesavic can you test please?


Support $dynamicAnchor and $dynamicRef

Motivation
These keywords are defined in the JSON Schema 2020-12 dialect.
Release notes: https://json-schema.org/draft/2020-12/release-notes
These are useful for representing generics: https://json-schema.org/blog/posts/dynamicref-and-generics
Specification of dynamic scope rules: https://json-schema.org/draft/2020-12/json-schema-core#name-lexical-scope-and-dynamic-s
Proposed solution
Schemas containing $defs generate types that include the defs as members. If the schemas contain $dynamicAnchor, they create protocols with associated types instead of concrete types with type aliases. The schema of the dynamic-anchored types are used as the type constraint for the associated types.
Dynamic reference schemas (those containing the $dynamicRef keyword) refer to associated types and may supply generic parameters using their own $defs and $dynamicAnchor keywords.
Alternatives considered
Avoid generating protocols / associated types, and instead always generate concrete types, treating dynamic refs/anchors as template instantiation.
Additional information
This would depend on support in OpenAPIKit. Upstream issue filed: https://github.com/mattpolzin/OpenAPIKit/issues/359

Thanks @brandonbloom - I'll mark this one as blocked, until the OpenAPIKit support is landed.

I wonder, have you also considered generating generic types, instead of protocols? From my reading of the specification, that might be the closest representation in Swift to the requested feature.

I've begun exploring this in OpenAPIKit. I've only thought on it for a few minutes so far, but I wanted to make sure to extend an invitation for help deciding how to integrate these new references into OpenAPKit if anyone over here has thoughts; I know it isn't always possible to comment directly on third party repositories, I will do my best to coordinate any conversation that happens split between the two disparate GitHub issues.
My initial thinking is I cannot simply support an additional key and boolean property on the JSONReference type since that type is deeply integrated with knowledge about how $ref tags behave and $dynamic-ref tags have different semantics and rules -- even that assumption is up for discussion.

I wonder what the minimum support for a generic type would be here. Basically, knowing that a type is generic over N types, and OpenAPIKit filling them in.
Re references, in 3.1 there's OpenAPI.Reference, maybe that's where some of it could be added?

OpenAPI.Reference may not quite fit the needs here since that type wraps a reference and adds description/summary overriding; it does manage to introduce different behavior compared to JSONReference, but since it was introduced to support the OpenAPI-specific extensions to $ref it isn't currently supported within JSONSchema (it's used everywhere outside of JSONSchema, though).

Fair enough - yeah maybe a way to make progress here would be to first identify the minimum work needed to support the simple List<T> use case, and generalize from there.

@brandonbloom do you have an example or two of OpenAPI documents that take advantage of $dynamicRef? I'm curious if they tend to use local $defs within the json-schemas or if (being OpenAPI Documents) they tend to put the $dynamicAnchors inside the #components/schemas which would be my instinct personally.

I wonder, have you also considered generating generic types, instead of protocols? From my reading of the specification, that might be the closest representation in Swift to the requested feature.

I considered it briefly & perhaps discarded it prematurely. The reasons I was immediately drawn to protocols is because generics use positional type parameters, which don't have a clean mapping to the dynamicRef concept as far as I can tell. Associatedtypes seem more similar to what the local $defs look like.

do you have an example or two

Examples from Github: https://github.com/search?q=("%24dynamicRef"+OR+"%24dynamicAnchor")+(path%3A**%2F*.yaml+OR+path%3A**%2F*.yml+OR+path%3A**%2F*.json)&type=code

I was moreso curious if you had examples that motivated you to request the feature; if it turns out that OpenAPIKit support for dynamic reference use-cases does not come all at once, I'd like to prioritize support for those situations that are most pressing for consumers of OpenAPI documents (as opposed to json-schema more broadly). It's fine if not.

maybe a way to make progress here would be to first identify the minimum work needed to support the simple List<T> use case, and generalize from there.

In that vein, I have begun to brainstorm what exactly OpenAPIKit tells a consumer beyond "here's a dynamic reference." That's the bare minimum (and net addition to OpenAPIKit): Parsing $dynamicRef, $dynamicAnchor, and $defs. Beyond that, when OpenAPIKit hits a $dynamicRef, that might be something the Swift generator wants to turn into a protocol or generic type, but since OpenAPIKit uses value types to represent JSONSchema, it cannot use a reference to represent an infinitely recursive structure (like a tree or a list of lists).
That leads me to the question of what non-referential representation would be most helpful to the Swift generator. One potential answer is that OpenAPIKit could surface the $id of the dynamic anchor that a given $dynamicRef points to (this assumes the anchored schema has an $id) -- that would save the Swift generator from needing to crawl the schema to calculate the dynamic context itself. Maybe that's enough for the Swift generator to then create a type declaration for the anchor schema and store it under its $id to then later refer to that type when hitting a $dynamicRef that OpenAPIKit says resolves to the given $id.
In reality, dynamic anchors do not always have $ids, so if the above strategy makes sense even superficially, we'd need to come up with the desirable canonical way of identifying schemas (possibly even an algorithm where $id is preferred and the key of an entry in $defs is a fallback, etc.).

It's possible this idea is flawed because there's no inherent need to uniquely and globally identify dynamically referenced schemas: if you are actively crawling the json-schema and tracking the dynamic context, you don't need globally unique you just need to look at the current local dynamic context. Another idea is OpenAPIKit could surface that dynamic context as easily accessible for any given $dynamicAnchor, though my gut says that doing so would necessitate some form of cycle detection and avoidance.

I was moreso curious if you had examples that motivated you to request the feature

I'm using it in a schema I'm developing. The simplest example is that I have a generic-type for a pagination container. In TypeScript notation:
type Page<Item> = {
  items: Item[];
  next: string | null;
}

This is then parameterized by each type of resource I'm returning, something like:
type FriendPage = Page<Friend>;

I already generate my schemas programmatically, so I'm working around the lack of support for this feature by treating generic types like macros and expanding them template-programming style. Since my schema generation is already parameterized, I can emit dynamic refs/anchors for validators that support them and then erase the generic types and emit specialized schemas as needed for other output targets.

bare minimum (and net addition to OpenAPIKit): Parsing

Although it also does not yet support dynamic refs/anchors, a newer Go library for OpenAPI specs has a two-level model: https://pb33f.io/libopenapi/model/ -- This roughly corresponds to a concrete parse tree and an abstract document object model. I'm not sure if that maps to your design at all, but that seems natural to me.

That's good context, @brandonbloom - let's focus on this simple example first: generic pages. @mattpolzin what's the first version of your approach you could see supporting this? I'd prefer us to build this incrementally, based on real-world needs.

I've got work ahead of me just to properly represent $dynamicRef in the AST of OpenAPIKit, though nothing about that will be overly complex. But beyond the first step of being able to actually parse/encode/expose $dynamicAnchor and $dynamicRef, the next step for me will be to offer a function that under the hood crawls the AST looking for a $dynamicAnchor matching a given $dynamicRef. This will allow me to offer to downstream libraries some function that says "what is the resolved state of this $dynamicRef I am looking at right here?" I'll be able to answer e.g. Friend. Before going further (e.g. offering the ability to ask OpenAPIKit "what are all the possible specializations of Item in Page<Item>?"), I think we already need to address the question of what to do about recursion. We may not need to handle cycles to handle Page<Friend>, but if we design this feature around that subset of use-cases we may for example decide that  Friend can be a fully resolved JSONSchema which will then mean we need to break that contract as soon as we want to handle recursion later.
This is what lead me to the questions I posed above (https://github.com/apple/swift-openapi-generator/issues/547#issuecomment-2016882759).

It may help me to get the 10,000 ft view of how the generator handles other existing recursive cases it already handles -- for one thing, to help me understand where division of labor will happen for this new feature, so I am not trying to solve problems that the Swift Generator will want to write its own code for anyway.
Would you be able to link me to the relevant code and possibly give me any description you think might help me grok it quickly? I don't have time to become an expert in the whole generator codebase, so trying to be pragmatic 😄

Sure, please check this out first, and I can answer any followups: https://swiftpackageindex.com/apple/swift-openapi-generator/1.2.1/documentation/swift-openapi-generator/supporting-recursive-types

Thanks. Even easier than reading the code! So, I am thinking that the easiest path forward is possibly for OpenAPIKit to facilitate the swift generator using roughly the same code (at the very least the same strategy) as it uses today to handle recursion via Components lookup to also handle dynamic references.
Dynamic references may also lead to recursion just like regular references, so the difference of course is that dynamic references change depending on where in the schema they live. So, today OpenAPIKit offers a lookup function on Components that allows resolving non-dynamic local references. Newly needed is a lookup function that handles dynamic refs. That's already an interesting problem to consider (looking forward to thinking on it) because OpenAPI documents kind of have two different potential contexts to consider: there's the immediate json-schema context and its $defs (starting wherever the nearest parent in the AST goes from being an OpenAPI object to a json-schema) but there's also the Components object's schemas that I think might reasonably be considered part of the dynamic context for every single json-schema in the whole document.
I think this is where I want to get to first in OpenAPIKit: parse/serialize/export dynamic refs and anchors and expose a lookup function that behaves much like the current one but understands dynamic context and can find anchors as well as local paths. There's no small chunk of work there because in addition to the dynamic context being new we've previously not needed to handle $defs or local path (outside of Components Object) lookup.
While I am working on that, which feels like important foundation, we can continue to discuss what gaps are left RE the swift generator's eventual goals. Maybe that's enough for the swift generator to handle the rest, or maybe OpenAPIKit also exposes some form of "give me all the ways this ref could resolve in the document" function a la the question of what possible specializations a generic type can have.

This sounds in line with what I was thinking, @mattpolzin. I'm happy to wait for the foundational pieces to land in OpenAPIKit, and then try to integrate them in the generator, and if we feel there are additional conveniences needed, we can take it from there.

FYI, there might be further changes in the upcoming OpenAPI v4: https://www.openapis.org/blog/2023/12/06/openapi-moonwalk-2024


ButtonGroup doesn't add "btn-group" to ButtonDropdown

https://svelte.dev/repl/103a4efed9a34756af12895bcd9e03f8?version=3.20.1

I was having the same problem too. I thought that by adding <ButtonDropdown group=true> it will fix the problem.
I went on and investigated a little more. It turns out on src/Dropdown.svelte, this line:

{...props} also has class in it (from parent ButtonDropdown), and it overrides class={classes}. I think the solution will be either: remove the {...props} (I see no use of it anyway, I think???) OR apply {...props} to the element before setting its class attribute (this one is much easier).

Sorry for the long delay, this was corrected in v4.0.0.
The real looks to work correctly now: https://svelte.dev/repl/103a4efed9a34756af12895bcd9e03f8?version=3.20.1


mixer_test (E2E): TestGlobalCheckAndReport is flaky

See https://docs.google.com/spreadsheets/d/1SC6KBUc8zYqcEEGfIZJOTbpDuePr7TAS2SWIfjkrIio/edit#gid=0
Out of the 44 test runs in the past week, TestGlobalCheckAndReport tests failed over 30% of time and they passed afterward without requiring any fix. The problem is observed in all the three test suites.
Please help fix this ASAP, because:

we run the same tests in release qualification and this can block automated daily releases.
this generates a lot of noise which hides the real problem and delays action from dev oncall.

OOO, so my ability to help debug is limited.
TestGlobalCheckAndReport is a super simple test -- that had been fairly stable. It sends a single request to the demo app, and expects to see that request in the metrics.
It has also been (in previous periods) a bellwether test that exposes systematic issues with Istio in general (and not specific to Mixer). Debugging the test might well start outside of Mixer.
Looking at this test log, it appears that there were no new requests observed by the system.
I1207 18:46:35.449] --- FAIL: TestGlobalCheckAndReport (36.33s)
I1207 18:46:35.449] 	mixer_test.go:257: Establishing metrics baseline for test...
I1207 18:46:35.449] 	mixer_test.go:259: prometheus query: istio_request_count{destination_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local"}
I1207 18:46:35.449] 	mixer_test.go:271: Baseline established: prior200s = 2.000000
I1207 18:46:35.449] 	mixer_test.go:272: Visiting product page...
I1207 18:46:35.449] 	mixer_test.go:282: prometheus query: istio_request_count{destination_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local",response_code="200"}
I1207 18:46:35.450] 	mixer_test.go:294: Got request_count (200s) of: 2.000000
I1207 18:46:35.450] 	mixer_test.go:295: Actual new requests observed: 0.000000
I1207 18:46:35.450] 	mixer_test.go:299: prometheus values for istio_request_count:
I1207 18:46:35.450] 		istio_request_count{destination_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", destination_version="v1", instance="istio-mixer.mixer-test-84de0d851524459eabea50f858:42422", job="istio-mesh", response_code="200", source_service="ingress.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", source_version="unknown"} => 2 @[1512672389.376]
I1207 18:46:35.450] 		istio_request_count{destination_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", destination_version="v1", instance="istio-mixer.mixer-test-84de0d851524459eabea50f858:42422", job="istio-mesh", response_code="200", source_service="unknown", source_version="unknown"} => 4 @[1512672389.376]
I1207 18:46:35.451] 		istio_request_count{destination_service="reviews.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", destination_version="v1", instance="istio-mixer.mixer-test-84de0d851524459eabea50f858:42422", job="istio-mesh", response_code="200", source_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", source_version="v1"} => 2 @[1512672389.376]
I1207 18:46:35.451] 		istio_request_count{destination_service="details.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", destination_version="v1", instance="istio-mixer.mixer-test-84de0d851524459eabea50f858:42422", job="istio-mesh", response_code="200", source_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", source_version="v1"} => 2 @[1512672389.376]
I1207 18:46:35.451] 	mixer_test.go:246: Bad metric value: got 0.000000, want at least 1.000000

Comparing that to a successful run:
I1207 05:33:40.019] --- PASS: TestGlobalCheckAndReport (30.38s)
I1207 05:33:40.019] 	mixer_test.go:257: Establishing metrics baseline for test...
I1207 05:33:40.019] 	mixer_test.go:259: prometheus query: istio_request_count{destination_service="productpage.mixer-test-ed58ee520c7a49bc85392b2885.svc.cluster.local"}
I1207 05:33:40.019] 	mixer_test.go:271: Baseline established: prior200s = 1.000000
I1207 05:33:40.019] 	mixer_test.go:272: Visiting product page...
I1207 05:33:40.019] 	mixer_test.go:282: prometheus query: istio_request_count{destination_service="productpage.mixer-test-ed58ee520c7a49bc85392b2885.svc.cluster.local",response_code="200"}
I1207 05:33:40.020] 	mixer_test.go:294: Got request_count (200s) of: 4.000000
I1207 05:33:40.020] 	mixer_test.go:295: Actual new requests observed: 3.000000

The big difference appears to be the observed prior200s. The successful run has 1, which is the expected value. I'm not clear on why the failed run has 2.
Data for failed run after new request:
istio_request_count{destination_service="productpage.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", destination_version="v1", instance="istio-mixer.mixer-test-84de0d851524459eabea50f858:42422", job="istio-mesh", response_code="200", source_service="ingress.mixer-test-84de0d851524459eabea50f858.svc.cluster.local", source_version="unknown"} => 2 @[1512672389.311]

looks identical to the data recorded afterwards for a successful one:
istio_request_count{destination_service="productpage.mixer-test-ed58ee520c7a49bc85392b2885.svc.cluster.local", destination_version="v1", instance="istio-mixer.mixer-test-ed58ee520c7a49bc85392b2885:42422", job="istio-mesh", response_code="200", source_service="ingress.mixer-test-ed58ee520c7a49bc85392b2885.svc.cluster.local", source_version="unknown"} => 2 @[1512624819.85]

So, I'm not sure how the metric appears to be pre-populated in advance of the actual request being placed.
Is it possible that the new caching stuff is short-circuiting Report() @mandarjog ?  Maybe we aren't seeing the count get incremented (and the precall count of 2 reflects some retry or bad config state)?

@mandarjog is mentioning in a different channel that there appears to be a config issue, in which Mixer is losing adapter config and closing handlers on occasion. That might be related.

It seems there is no flakiness on this test case, did you guys solve this issue?

It is possible that the fixes related to config deletion (or others) resolved this. But it was not intentionally resolved. 😄 .

/close
Still good to know. You guys rock!


BREAKING(ini): move reviver to 2nd argument in parse()

What's changed
This PR replaces ParseOptions with reviver (the function previously defined as ParseOptions.reviver). As a result, the ParseOptions interface has been removed as it's no longer used anywhere.
Motivation
This change was made to simplify working with parse(), as having a whole options object was extraneous, given it only included one property.
Migration guide
To migrate, move the reviver function from options.reviver to the 2nd argument of parse().
import { parse } from "@std/ini/parse";
import { assertEquals } from "@std/assert";

function reviver(
  key: string,
  value: string,
  section?: string,
): number | Date | string {
  if (section === "section Foo") {
    if (key === "date") {
      return new Date(value);
    } else if (key === "amount") {
      return +value;
    }
  }
  return value;
}

const iniText = `
[section Foo]
date = 2012-10-10
amount = 12345
`;

- const parsed = parse(iniText, { reviver });
+ const parsed = parse(iniText, reviver);

assertEquals(parsed, {
  "section Foo": {
    date: new Date("2012-10-10"),
    amount: 12345,
  },
});

This doesn't seem a reasonable change to me. The current form is already conformant to the style guide.
This change suggests using the exceptional pattern when additional options don't seem possible in the future, as described below.
https://docs.deno.com/runtime/manual/references/contributing/style_guide/#exported-functions%3A-max-2-args%2C-put-the-rest-into-an-options-object.

An optional parameter that's not in an options object might be acceptable if there is only one, and it seems inconceivable that we would add more optional parameters in the future.

However parse is relatively complex function. I think it's very possible for us to add options in the future. The current form prepares for such future development. This change makes such future change difficult.


[runtime] Clean up symbol exports in casting and class introspection.

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - c902aab8164d02178acdaa905c491e86b68ae7c2

@swift-ci please test macos


Fix: Support functions that return error in attributes

My attempt at fixing #492
Tried to follow guidance on the original issue the best I could, let me know if I need to change something.
To ease the review, I created 2 commits, one with my fix and another with the new generated files.
Note: I didn't changed href attributes ad they require SafeUrl and also didn't changed script attributes.

Thanks a lot for this great contribution. I rebased it, and merged it in https://github.com/a-h/templ/pull/584


added logic to allow defer of replay of tp logs

Best to get approval for @jonnypress before merging.


Interface CSP over UART on PIC 24FJ256GA110 with no operating system

I am using a PIC 24FJ256GA110 without an operating system. Is there any reference code I can use as a starting point to write the driver for the GOMSpace transceiver?
Also if someone has advice on how to do this it would be greatly appreciated as I am fairly new to the CSP.

hi,
GomSpace has no experiences with running CSP without an OS. We mainly run on 32 bit MCUs with FreeRTOS.
But I think it should be doable by mainly implementing src/arch/* APIs on your platform. There will of course be room for improvements in form of optimisation.

Hi @jeremyjallam. Not sure if you can use LibCSP without an OS. However, for the SUCHAI I nanosatellite we used the PIC24FJ256GA110 with FreeRTOS and LibCSP. Please check the repo and feel free to use the code if it is useful for you: https://github.com/spel-uchile/SUCHAI

CSP is no longer dependent on tasks since the router is now callable from an event loop.
Semaphores and mutexes are not needed when you run OS less.
The only requirement would be queues, which can very easily be implemented using a ring buffer.
So with a little work, CSP will run fine without an os.


website: add git repo metadata to result view page

Each result has a metadata.txt file which contains repo and commit info like https://github.com/moby/buildkit-bench/blob/gh-pages/result/20240915-010636/metadata.txt
It would be handy to display this information on each result page: https://moby.github.io/buildkit-bench/#/result/20240916-110219
Bonus: we could also find the related PR based on the commit.

With #103 we now need to use the gha-event.json payload instead of old metadata.txt.


vm.max_map_count is too low

Hi Paulo,
Despite of initcontainer config, I sometimes have floowing error message in my containers (here on data persistant node in statefulset)
Do you know from what it could come from ?

ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2017-09-29T09:33:20,559][INFO ][o.e.n.Node               ] [es-data1-0] stopping ...
[2017-09-29T09:33:20,605][INFO ][o.e.n.Node               ] [es-data1-0] stopped
[2017-09-29T09:33:20,606][INFO ][o.e.n.Node               ] [es-data1-0] closing ...
[2017-09-29T09:33:20,624][INFO ][o.e.n.Node               ] [es-data1-0] closed

I run ES on top of 1.7.6 K8S cluster

Maybe the initcontainer failed? I honestly don't know.

Think I just ran into this myself on GKE.  Same error.

This seems a duplicate of https://github.com/pires/kubernetes-elasticsearch-cluster/issues/85.


Fixing 2176

These patches solve the problem of launching the test correctly, but do not address the memory access violations that occur. These could be merged in, independently of the greater fix.
I do not know how to progress with the sanitizer errors and double deletions mentioned in #2176

I'd have preferred to have a proper fix for the ipv6 address comparison instead of just removing them. Could you please try to explain what's wrong and perhaps what would have to be done in order to properly fix this?

The ipv6 comparison is actually just comparing strings. the correct fix would be to convert them back into ipv6 addresses and compare the binary versions. I implemented this, but the fix was specific for ipv6 and would fail for ipv4, so we need to check what type of addresses they are first and convert them accordingly. Since the underlying address objects that provided the strings must be available somewhere, I decided not to spend time on thins ans just comment the checks out. As you mentioned, they have never triggered until now and are not serving any useful purpose.

@hkaiser I have added a cleanup_ip_address function that takes a string containing an ipv4 or ipv6 address and attempts to convert it into a "standardized" address string. It's a bit of a waste of CPU, but it is only called in Debug mode. I hope that addresses your concerns.

@biddisco Thanks, this looks fine. I think we shouldn't worry about wasting cycles in Debug code.

@hkaiser I realized that the inet_xxx functions would not compile under windows, so I have added  a couple of (untested) snippets I found on stack overflow. I'm on the train and my connection is poor - coulf you trigger a windows build of this and I'll check results later.

@biddisco see http://hermione.cct.lsu.edu/builders/hpx_msvc_12_boost_1_57_windows_x86_64_debug/builds/786 and http://hermione.cct.lsu.edu/builders/hpx_msvc_14_boost_1_59_dev_windows_x86_64_debug/builds/490

LGTM, thanks!

Don't merge this. I think there is a problem with the ip address checks and i have not got around to looking at it again. Once I've double checked it, I'll report back.

I spent some time experimenting and have found that on my mac when I have the VPN to the office open, I get ipv6 addresses that are incorrectly compared by the current code - and this causes the test to fail.
The patches included do a ipv6 cleanup, but there's a catch. When I use the boost::asio::detail::socket_ops::inet_pton and pton functions - they are too clever and convert the ip address to and from the binary descrition, preserving the %en0 suffix (link-local zone index - I don't fully understand it).
if I use the standard inet_pton and inet_ntop I get this
cleanup 1 fe80:5::bae8:56ff:fe40:c3d0   = fe80:5::bae8:56ff:fe40:c3d0
cleanup 2 fe80::bae8:56ff:fe40:c3d0%en0 = fe80:5::bae8:56ff:fe40:c3d0

but when I use the boost asio functions, I get
cleanup 1 fe80:5::bae8:56ff:fe40:c3d0   = fe80:5::bae8:56ff:fe40:c3d0
cleanup 2 fe80::bae8:56ff:fe40:c3d0%en0 = fe80::bae8:56ff:fe40:c3d0%en0

So I am leaving the linux inet_pton functions in, but using the boost asio functions for windows and have added a comment in the source code pointing to this #issue in the event that anyone ever find a problem on windows with ipv6 addresses and looks at it.
In summary : without these patches, the test fails for me on OSX (when the VPN is used and we have an ipv6 address) . With them it passes.

Thanks John!

It says the checks failed, but actually they passed and the build timed out just before finishing.


Parser docs examples

I've found it a bit tricky to understand the primitives of the parser. My goal here is to add some examples for new people to have a decent, self-contained place to get started. Also, I'd be nice for more experienced people to have a good reminder of what the function does.

I love these code quality improvements @roboteng :) Just a few nits

@Anton-4, Thanks for the feedback, and thanks for looking at this! I'll clean it up some more before I make it a real PR

@Anton-4 , Thanks!
These are already tests! cargo test compiles and runs each example. So as long as we're testing this crate, these are guaranteed to be compiler-checked, and passing. That's what the # do in the examples. Those lines are included in the tests but excluded in the example. Also, sorry for the 1000+ line PR

Also, sorry for the 1000+ line PR

No problem :)

These are already tests!

Aha, I didn't realize that. Currently, I still think regular tests would be better for these reasons:

Our CI does not run when changes are made to rust comments, so breaking changes could go unnoticed.
Rust-analyzer seems to work poorly on the code when it is embedded like this.
We currently do not generate rust HTML docs for our crates, so regular tests would be roughly equally visible.
I'm not sure if the imports could be simplified compared to what they are right now but they definitely could be if we used regular tests.

What do you think?
Also, no big deal, but it's not necessary to merge every time the update button appears.

... so breaking changes could go unnoticed.

I agree, this would be bad. If we do pull out the code into full tests, I think that should be automated, so it doesn't fall behind, in a similar manner.

Rust-analyzer seems to work poorly on the code when it is embedded like this.

rustc/cargo does some preprocessing to allow things like allowing unused variables and imports. I know these examples aren't as minimal as they could be. I could, at the very least, manually go through and clean them up. We could probably add some annotations to have those emit warnings so the examples could stay clean.

We currently do not generate rust HTML docs for our crates, so regular tests would be roughly equally visible

I'm not sure what other people's normal flow is, but I normally use the docs/examples in my editor (VSCode). Docs are generated on the fly when I hover over a function, no HTML/browser needed. I've also manually run the cargo doc command locally to get the docs that docs.rs would normally provide, but that takes a little more setup.

I can start working on removing unused things in the examples, and see if there's a way to ensure that CI always checks the docs are up to date with source. Would it be possible to run CI on example code changes? Otherwise, I can see if there's a way to extract the examples in a way that will flag for the usual warnings/errors. I'd like to avoid having copy/pasted code sitting alongside the code, as that seems more susceptible to getting out-of-date.

I looked at the check for running tests, and it's just a big regex. It seems doable to change it so that it would consider lines like "/// ```" as 'non-comment' so that CI would still run if a new example were added. However, it seems much trickier to detect changes that don't include the start/end of the example code... It's better than no check at all, but it's still not a guarantee.

If we do pull out the code into full tests, I think that should be automated

With "that should be automated", do you mean the conversion from examples in doc comments to normal tests?

Docs are generated on the fly when I hover over a function

Yeah I do that too, but I forgot about it here :smile:. I do think that if the docs are as large as they are in this case I prefer to go-to-def and read them full size instead of in the pop-up.

I'd like to avoid having copy/pasted code sitting alongside the code

Do you mean have the same code duplicated in the doc comments and as a normal test?

I want to back up a bit and make sure we're on the same page.
The problem is making sure that code examples always stay up to date with the source code. As far as we know, this general problem hasn't been solved yet in main.
Background / Context
When code blocks are written in docs, they serve two function:

Shown in the docs as a code example
Embedded in other code, and ran as a test

This means that there is a mechanism to keep example code up to date with the source code its documenting.
When cargo test is run on a project all doc tests are included in that. However, since the roc repo has a lot of tests, we only run tests if needed. Right now, that means a change to rust source code, excluding comments.
The implication is that PR's like this one that only have comments don't trigger cargo test. Examples could get out of sync with source code.
Ideal solution
Every time a doc-test/example is added or changed, it is tested and is always kept up to date with its source code.
Possible solutions
These are ones I could think of that seemed somewhat reasonable. There are probably others tat I haven't thought of, and would be willing to look in to.
Current solution
Writing docs in the same file as the source code.
This doesn't meet our requirements because tests are only run if the PR contains changes to (rust) files that aren't only comments.
Change CI to run tests if /// ```  is present
This would (probably) only require changing some regex in the CI yaml. This would be able to run tests on new examples added, but wouldn't trigger tests on a change to examples.
This is probably the simplest solution.
Use #[doc = ] for all the docs
We can use the include_str!() macro to move the docs form inline to their own files. We would put docs that we want compile checked into files with .doc.md extension (or similar). We could then add extension to trigger tests. This would cut down on excessive tests but would still give some false positives.
However, rust-analyzer seems like it can't process the include_str!() macro, and doesn't show that content
Use #[doc = ] for only the doc-test part of the docs
Similar to the above approach, but we only put doc-tests in their own files. This would ensure that the false positives are cut down for the most part.
These would be close to .rs files, but would have a few differences:

No main function
# at the start of some lines
non-standard formatting, to make the examples look good. (E.G. not indenting the body of a function)

This is probably the one I'd prefer, if our current solution doesn't cut it.
Use a custom macro that is more flexible than include_str!
Some of the above solutions use include_str!(), but we could write our own macro that's better! I'm not 100% sure on all the details, but I'm pretty sure we could write a proc macro to solve all of our problems... but also have a proc macro...
This is probably overkill

What do you think about these? I'm open to suggestions, and let me know if I'm offbase anywhere!

I appreciate your structured approach @roboteng!
We can get rid if the "ignore comment changes" in CI, it's nice to have but it does not come up often that a PR only changes comments.

What do you think about combining  "Success Case" and "Error Case" examples into one? We could use rust comments // success case: and // error case: inside the example instead and reduce the lines of code significantly.

In CI, we can make it run for changes to lines with /// but still skip it for //. That seems like the best trade-off overall.

I think I've made that change correctly, but it's regex, so who knows...
I'll work on condensing the examples. I don't think there's a big difference in splitting them out, so I'll combine them 😄

Thanks for your feedback @Anton-4, it's helped make this PR clearer and more consistent!
I've gone through and updated as you've suggested

Thanks you very much @roboteng! I'll try to review in the coming days.


Autoscaling should enable max requests per minute setting

Describe the feature
Ability to set up maxRequestsPerMinute or similar option in the autoscaledPoolOptions.
Motivation
Concurrency cannot really be used to control how many requests will hit the target website because it depends on if the request takes 0.1 sec or 10 sec. This is a nice feature to handle blocking or not overloading target website.
Constraints
How it will work with other limits, I guess it will scale down either on concurrency or RPM, just depending on what comes first. But not sure how we would include it somehow to the metrics, etc.
cc @petrpatek if you have more ideas

I did something similar patching the internals. using a semaphore, you can treat RequestQueue internally as a stream, that you can pause/resume at will. the right way would to actually use streams, since it's battle tested for back-pressure and can be piped/written into/to


Clean up -x task exclusions in ci.yml

At the moment, ci.yml contains many gradle task invocations with long exclusion lists like this:
         build test -Dbuild.snapshot=false
          -x integrationTest
          -x spotlessCheck
          -x checkstyleMain
          -x checkstyleTest
          -x spotbugsMain

This is because the jacoco plugin enforces explicit incoming dependencies from all test tasks. This will however also cause the execution of these "through the backdoor" if only a single test task is supposed to be executed.
It would be nice if a solution could be found to avoid that.
See also the conversation in this PR: https://github.com/opensearch-project/security/pull/2861#discussion_r1236935754

Right now in #2861 we have one task exclusion:
    - name: Build and Test
      uses: gradle/gradle-build-action@v2
      with:
        arguments: |
          ${{ matrix.gradle_task }} -Dbuild.snapshot=false
          -x test

Simplest fix is to remove this line: tasks.jacocoTestReport.dependsOn(test) but this will break creating coverage from only starting "jacocoTestReport" task

👍 has my blessing

[Triage] Thank you @nibix for filing this issue. Seems like removing the jacoco line is the preferred option for the time being. Marking this issue as help wanted and good first issue.

Closing after #2935 merged.


Adding JSX (React) as an option for the view engine in express

The Express official docs list react as an option for the view engine using the express-react-views module.
This pull request adds jsx as an option for the view engine from the CLI using --view = jsx.
Commits have been made for -

Adding CLI support for jsx.
Default jsx templates
Tests to validate its working.
Updated README to include jsx

Builds are failing on older versions of nodejs. It is passing fine otherwise.

Thank you! Do not worry about the failing older Node.js versions for this, as it does pass fine on the newer versions. I am adding a method to target a given Node.js version for the upcoming version, so this template would just fit in by requiring a minimum target version.

That would be great! Thanks for the update.

why express doesnt add jsx support?


Default pom entry in mvnrepository includes an errant  line

In 4.11.1 in mvnrepository you will get an errant line with <scope>test</scope> which makes eclipse unhappy (breaks the classpath)
`

<groupId>com.ibm.fhir</groupId>

<artifactId>fhir-client</artifactId>

<version>4.11.1</version>

<scope>test</scope>

`
Works fine without the  line

Really not sure where that site is getting this  line from.
https://search.maven.org/artifact/com.ibm.fhir/fhir-client/4.11.1/jar lists it properly:
<dependency>
  <groupId>com.ibm.fhir</groupId>
  <artifactId>fhir-client</artifactId>
  <version>4.11.1</version>
</dependency>


Latest working version

merge this version and use it for the release, you can add the stuff you added to the release as well such as the alternative download link

this is the source of the release I made in my fork


Is cifar10 num_samples correct?

https://github.com/PyTorchLightning/pytorch-lightning-bolts/blob/ecbb82a057c9be6caa06b0b8885743db8a1a752a/pl_bolts/datamodules/cifar10_datamodule.py#L98
The self.num_samples = 60000 - val_split may be wrong, the dataset indeed contains 60000 examples, but it includes the test set too, which size is 10000.
So I think the correct size would be 50000 - val_split
I checked it with val_split=5000, and the train_length here is 50000:
https://github.com/PyTorchLightning/pytorch-lightning-bolts/blob/ecbb82a057c9be6caa06b0b8885743db8a1a752a/pl_bolts/datamodules/cifar10_datamodule.py#L122
the len(dataset_train) is 45000 (not 55000) here:
https://github.com/PyTorchLightning/pytorch-lightning-bolts/blob/ecbb82a057c9be6caa06b0b8885743db8a1a752a/pl_bolts/datamodules/cifar10_datamodule.py#L123
It may affects the SimCLR performance, it is used here:
https://github.com/PyTorchLightning/pytorch-lightning-bolts/blob/ecbb82a057c9be6caa06b0b8885743db8a1a752a/pl_bolts/models/self_supervised/simclr/simclr_module.py#L400
after here:
https://github.com/PyTorchLightning/pytorch-lightning-bolts/blob/ecbb82a057c9be6caa06b0b8885743db8a1a752a/pl_bolts/models/self_supervised/simclr/simclr_module.py#L136
So it influences the lr schedule.

@ananyahjha93 mind have a look? :]


no new_#{association} in insertion template using standard Rails forms

The field name in data-association-insertion-template should be  something like project[tasks_attributes][new_tasks][done] but got project[tasks_attributes][done].
Rails' fields_for overwrites child_index option here.
https://github.com/rails/rails/blob/master/actionview/lib/action_view/helpers/form_helper.rb#L2189

Sorry, we misused the gem without real model association.


Have to click twice in list to see record in "Information"

Describe the bug
See https://devtopia.esri.com/WebGIS/solutions-web-development/issues/132
Expected Behavior
I expect to click on the record once.
Reproduction Steps & Sample
https://solutions.mapsdevext.arcgis.com/apps/instant/manager/index.html?appid=8f514804a9cc475a8a9c0675cab2489e
Click on a record in the list by clicking in the check box.
Uncheck the record.
Check the record again. Now the information is activated in the "Information" screen on the left.
Other Relevant Info
No response

@avezina not seeing this with the latest PR

I can no longer reproduce this issue.

No reproducible in qa


[ENH] initialize rust

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

Current dependencies on/for this PR:

main

PR #1499   👈

This stack of pull requests is managed by Graphite.


missing runtime deps from installer

Currently the only way to get GCC for Windows is through installing 8gb of Visual Studio

Currently the only way to get GCC for Windows is through installing 8gb of Visual Studio

either install with "tdm gcc" or install WSL2 (WSL2 Ubuntu should install gcc automatically)

Sadly that is also incorrect. these particular libraries need to be bundled either alongside the exe, or inside it,

These errors occur because Processhitman requires specific C++ runtime libraries that are not present on the system because Processhitman does not include them in the static linking process. I'm currently working on a Pull request that fixes this and a couple of other things.


Bump version after boost update

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


HP.HPSupportAssistant version <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Duplicate of #12836

This seems quite interesting and may be useful to HP users..


Bump version to 0.15.3

We need this for Iris, as we can't test against the new masked-array function without a distinct version for conda to grab onto.

Can you just use git master for now? We'll probably push a release in a week or two? I'm not 100% against a release now, but we held off on releasing with the masked array stuff just so it could get tested on master for a bit. This is how I'd do it on travis:
conda install -c conda-forge dask  # Get dask and all dependencies
pip install git+https://github.com/dask/dask --upgrade --no-deps  # Upgrade to dask master

Also note, if you're working locally, you need to pull tags as well, since we use versioneer for versioning. So if you have an old remote, you need to run.
$ git pull upstream master --tags  # where upstream is https://github.com/dask/dask.git
$ python -c "import dask;print(dask.__version__)"
0.15.2+13.gb1ff826

Until we tag a new release the version will be 0.15.2+commit_stuff. To check if it's after the last release (and thus for masked array support) you can use distutils.version.LooseVersion.
In [3]: import dask

In [4]: from distutils.version import LooseVersion

In [5]: dask.__version__
Out[5]: '0.15.2+13.gb1ff826'

In [6]: LooseVersion(dask.__version__) > '0.15.2'
Out[6]: True

Can you just use git master for now?
We'll probably push a release in a couple weeks.

Yes, that's fine.  We will test against latest-master for now.

Sounds good. I'm going to close this for now then.


Getting an exception when trying to create component dynamically

Hello Simon,
I have such an issue - when I try to add a component dynamically and property of this component marked as [PrimaryEntityIndex] I get this exception:
"InvalidCastException: Cannot cast from source type to destination type."
(if it is not marked, everything works fine)
Is it the intentional behavior or bug?
public sealed class MyComponent : IComponent {
	[PrimaryEntityIndex]
	public bool value;
}

IComponent component = entity.CreateComponent(componentIndex, ComponentsLookup.componentTypes[componentIndex];
entity.AddComponent(componentIndex, component);

Thank you

Hi @VirtualMaestro,
I just tested and everything worked as expected
var entity = contexts.game.CreateEntity();
const int componentIndex = GameComponentsLookup.My;
var component = entity.CreateComponent(componentIndex, GameComponentsLookup.componentTypes[componentIndex]);
entity.AddComponent(componentIndex, component);

Console.WriteLine("entity.hasMy: " + entity.hasMy);

I couldn't reproduce your issue. Did it work out for you in the meantime?


Attempting to add Spyder to an Anaconda venv would require me to downgrade Tensorflow

Issue Report Checklist

[X] Searched the issues page for similar reports
[X] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[X] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[NA] Could not reproduce inside jupyter qtconsole (if console-related)
[NA] Tried basic troubleshooting (if a bug/error)

[NA] Restarted Spyder
[NA] Reset preferences with spyder --reset
[NA] Reinstalled the latest version of Anaconda
[NA] Tried the other applicable steps from the Troubleshooting Guide

[x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
Attempting to add Spyder to an Anaconda venv would require me to downgrade tensorflow, from 2.7 to 2.4.
What steps reproduce the problem?

create a new virtual environment in Anaconda ( I am running Anaconda 4.11.0)
install tensorflow-gpu 2.7 (from conda-forge)
command an installation of spyder

What is the expected output? What do you see instead?

I expect to install spyder without downgrading tensorflow.
Instead I see a warning that tensorflow, tensorflow-base, tensorflow-estimator and tensorflow-gpu must all be downgraded from 2.7.0 to 2.4.1 if I want to install spyder.  A few other packages are marked for downgrade as well; cudatoolkit, cudnn, h5py, hdf5, icu, importlib-metadata, libfortran-ng, and nccl
Therefore I choose not to install spyder, until I can resolve this issue.

Paste Traceback/Error Below (if applicable)
NA
Versions

Spyder version: not yet installed on this venv
Python version: 3.9.7
Qt version: not yet installed on this venv
PyQt version: not yet installed on this venv
Operating System name/version:  Ubuntu 21.10

Dependencies

NA

Hey @jjl2, thanks for reporting. You're probably mixing conda-forge and defaults packages because when I try to install both Tensorflow and Spyder in the same environment, I can do it without problems with the following command:
mamba create -n bar -c conda-forge spyder tensorflow python=3.9

Mamba is a replacement for conda, which is much faster and consumes less memory. You can read about it here. And the versions of Spyder and Tensorflow I get with it are 5.2.2 and 2.6.2, respectively. I don't know why tensorflow 2.7.0 is not pulled, but even doing
mamba create -n bar -c conda-forge tensorflow python=3.9

gives me the same version. I can only get Tensorflow 2.7 when using Python 3.10.

Since this is easily solvable with Mamba and using a new environment, and it's really not a problem we can solve here, I'm going to close this issue.

Thanks for your reply @ccordoba!  I'm back on track.  You're right, this doesn't appear to be a Spyder issue, it's an Anaconda repository issue.
I am in fact using mamba, but since I only discovered it last week I didn't want to assume that it is widely used.  Mamba is MUCH better than the conda solver.
I followed your suggestions, and I got both Spyder and Tensorflow 2.7.  I don't know why I didn't have your Python 3.10 problem.
The new venv has other broken dependencies, but your example should help me correct that.
I thought that the whole point of Anaconda was to correct these kind of incompatibility problems?  I don't understand why only the conda-forge repo has certain versions of packages, and why conda would automatically choose a package in the default repo if it's going to force downgrades of packages from conda-forge.

I don't understand why only the conda-forge repo has certain versions of packages

Conda-forge packages are maintained by the community, so that's why they are more up to date. The packages in the defaults channel are uploaded by Anaconda, the company, but (unfortunately) they are taking way too much time to do that lately.

and why conda would automatically choose a package in the default repo if it's going to force downgrades of packages from conda-forge.

You always need to pass the -c conda-forge option to all your conda/mamba commands to avoid that. Your other option is to configure them to use Conda-forge by default, as described here:
https://conda-forge.org/docs/user/tipsandtricks.html


Is the CAA module generic?

Is this CAA module only applicable to this paper? What about other methods that are not attention mechanisms?

Theorectically it is generic for different usages, since the input of CAA is NxC while the output is also NxC (N can be a flaten form of WxH).
We have only tested it on poin cloud classification/segmentation/detection, as presented in the paper.


fix showing login screen to the logged-in user issue

Fixes #345
Changes:
if the user is already logged-in before, directed the user to Chat screen without going to the login screen to avoid showing login screen to the logged-in user
GIF for the change:

@chashmeetsingh @SIMRAN1 Please review


[Question] Is possible hide DragView when panel expended?

im trying open fragment onslide its work perfectly, but when panel expended DargView still appear on top toolbar.

Im set layout Visibility gone when panel expended its work but when orientation changed layout reappear. Any Ideas?
sorry for my english.

When orientation is changed, onCreate is called. So inside onCreate, check if the panel is expanded or not, and if expanded, set the visibility to gone.


Arduino graphics library support in backend

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@fd8fc6a). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             dev       #8   +/-   ##
======================================
  Coverage       ?   58.54%
======================================
  Files          ?       79
  Lines          ?     2991
  Branches       ?        0
======================================
  Hits           ?     1751
  Misses         ?     1240
  Partials       ?        0

Continue to review full report at Codecov.

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


Method to go back to the previous layout

Required for https://github.com/CartoDB/cartodb/issues/10472.
This PR implements a new method so that we can go back to the previous layout:
this.layoutModel.goBack();

Take a look at the tests for a better understanding of how it works...
I did some refactoring and nextStep and prevStep are now using goToStep internally.
Also, @matallo discovered that nextStep was always going to the last step and it always triggered positionChanged even if the position didn't change (I removed this).
We could potentially use this in many "back" buttons that we display in the left side panel.
@xavijam would you please take look? Thanks 💋

cc: @javierarce

I'm not sure either :/  That trigger is captured in the stack-layout-view.js
    this._removeOldStackView();
    this._genNewStackView(_.flatten(opts));
  },

so I think that in that particular case, we just forgot to add a condition to avoid the triggering.

We'll soon know if the event was indeed required... 😛 . Thanks guys!


Mihin covid 19

This patch introduces an attribute "Ventilator Reason" which is assigned by "Septic Shock" and "Respiratory Failure", two paths which lead to the "Ventilation" procedure.

This patch works in my environment and avoids my GMF's unresolved reason exception

@jeffeastman, I can't merge this, you are deleting three of the covid19 submodules in this PR.

Really? Clearly not my intent. Investigating...

On Apr 6, 2020, at 11:26 AM, Jason Walonoski<EMAIL_ADDRESS>wrote:
@jeffeastman https://github.com/jeffeastman, I can't merge this, you are deleting three of the covid19 submodules in this PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/synthetichealth/synthea/pull/699#issuecomment-609863427, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB3NFDJ33PM5BWXIYTKK5TRLHYCZANCNFSM4MBBMODQ.

Closing because of new pull request


Feature/sg 000 add adapter

Introduction of Adapter logic
Why Do We Need This?
We aim to allow seamless integration with SG for users who are already using DG.
Solution (updated)
If the user doesnt want to set anything in advance (in such case he will be asked questions) OR if he already has a cache (from DG or previous run)
val_loader = DetectionDataloaderAdapterFactory.from_dataset(
    dataset=train_set,
    config_path="<path>",
    batch_size=10,
    drop_last=True,
)

If the user wants to set in advnace some parameters, he can still use DetectionDataConfig

adapter_config = DetectionDataConfig(images_extractor=lambda sample: sample[0], labels_extractor=voc_format_to_bbox, cache_path=analyzer.data_config.cache_path)
train_loader = DetectionDataloaderAdapterFactory.from_dataset(
    dataset=train_set,
    adapter_config=adapter_config,
    batch_size=10,
    drop_last=True,
)

Now, the same is possible if the user already has a dataloader.
val_loader = DetectionDataloaderAdapterFactory.from_dataloader(
    dataloader=train_loader,
    config_path="...",
)

Notebook
https://colab.research.google.com/drive/1clgfrdCrg5cWSl7nrjY0zVndz06SIC0P?usp=sharing

Thanks for the Colab notebook. It really helpful to see how the intended usage.
I have few comments regarding the notebook, nothing critical or wrong, more a suggestsions:

DetectionDataloaderAdapterFactory / SegmentationDataloaderAdapterFactory - may I suggest DataAdapterForDetection / DataAdapterForSegmentation ?

adapter_cache_path argument name may be a bit confusing to users non familiar with internals and one may assume we will store some data samples in that location. Perhaps if we rename this argument as "config_path" that would be clearer to the user.

As you can see, the labels are normalized (0-1). This is all right, but it is not the format expected by SuperGradients.
Actually this was ❓❓❓ moment for me, why that dataset also normalize masks and how SG denormalize them and why. Lost the track why we modify targets. Maybe should have been explained a bit better. Usually in segmentation datasets we don't normalize targets so maybe in notebook we should show a more common use case?

For the questions that has fixed number of options to choose from, perhaps we can show some love to user and heuristicaly pick a default option (Which will be chosen if user just hit Enter):

--------------------------------------------------------------------------------
Which dimension corresponds the image channel?
--------------------------------------------------------------------------------
Image shape: torch.Size([1, 3, 512, 512])
Options:
[0] | 0
[1] | 1 [Suggested value, Enter to accept]
[2] | 2
[3] | 3

Sure, heuristics may not handle ALL use cases but would certainly save some time in 90% of the cases.

yolonas_recipe = load_recipe(config_name="coco2017_yolo_nas_s", overrides=[f"arch_params.num_classes={20}", "training_hyperparams.max_epochs=1", "training_hyperparams.mixed_precision=False"])

As we've already asked user about number of classes when creating adapter data loader, we should be able to pull this information from that instance:
yolonas_recipe = load_recipe(config_name="coco2017_yolo_nas_s", overrides=[f"arch_params.num_classes={train_loader.adapter_config.num_classes}", "training_hyperparams.max_epochs=1", "training_hyperparams.mixed_precision=False"])

DetectionDataloaderAdapterFactory / SegmentationDataloaderAdapterFactory - may I suggest DataAdapterForDetection / DataAdapterForSegmentation ?

Not fundamentally against the change, but I have a small concern; DataAdapterForDetection.from_dataset(dataset=...) It's not clear that this generates a dataloader. DetectionDataloaderAdapterFactory was not 100% explicit but with the name it's already a bit more intuitive.
We could change the method to convey this idea, for instance DataAdapterForDetection.build_dataloader_from_dataset, but I can't find a good name. here build_dataloader_from_dataset sounds bad, especially when we think about the from_dataloader version which would be build_dataloader_from_dataloader.
Eventually, my point is I would like the name (of class and method combined) to include the info that this builds a "dataloader which adapts X for a task Y" with X (dataset/dataloader).
Any idea of better naming? Or do you think it's fine to not refer to dataloader?

adapter_cache_path argument name may be a bit confusing to users non familiar with internals and one may assume we will store some data samples in that location. Perhaps if we rename this argument as "config_path" that would be clearer to the user.

Yeah I wasnt too sure about whether to simplify or to be more explicit. But I think you're right, with the context it is (relatively) clear that the config_path is that of the current object (i.e. adapter)

For the questions that has fixed number of options to choose from, perhaps we can show some love to user and heuristicaly pick a default option (Which will be chosen if user just hit Enter):

That's an interesting idea. I will create a task for this, and maybe to include this idea to other questions (if possible/useful).

As we've already asked user about number of classes when creating adapter data loader, we should be able to pull this information from that instance:
yolonas_recipe = load_recipe(config_name="coco2017_yolo_nas_s", overrides=[f"arch_params.num_classes={train_loader.adapter_config.num_classes}", "training_hyperparams.max_epochs=1", "training_hyperparams.mixed_precision=False"])

Good point, i'll change that

Note: the build fails because we did not release yet the latest DG version.
We need to first release DG, and then update the requirements.txt


Build error and/or app failures when using Delphi 12.1 for certain demos - Android only

For certain demos in Kastri, use has been made of Post Build events to modify the resulting AndroidManifest.xml which is deployed with the application. In Delphi 12.1, changes in the build process for Android apps has broken this process, so if you are building the project for the first time, you may see the error:
[Exec Error] The command "..\..\Tools\manifestmerge AndroidManifest.merge.xml Android64\Debug\AndroidManifest.xml
" exited with code 1.

This is because AndroidManifest.xml is not generated until deploy time, so manifestmerge fails due to the missing file.
Unfortunately, Delphi 12.1 regenerates AndroidManifest.xml every time the app is deployed, so manifestmerge cannot be used. This means that manifest entries required by Kastri demos that need them will need to be added manually to AndroidManifest.template.xml. In addition, this file is not created until the first deployment of an application.
I am in the process of updating the readme files for each of the affected demos, which are:

AndroidGeofence
AppUpdate
Biometric
CrossPlatformLocation
FCMRebooted
FirebaseAnalytics
FirebaseCloudMessaging (legacy demo - please use FCMRebooted)
GoogleSignIn
NotificationListenerService
SpeechRecognition

The updated readme files will have instructions for editing AndroidManifest.template.xml manually

I have now released Codex 2.3.1, which deals with this issue. If you have Delphi 12.1 and the feature required a Build Event to merge the manifest, install Codex 2.3.1, remove the Build Event from the Project Options and it should now merge from AndroidManifest.merge.xml in the project folder when the app is deployed.


Weight sensor does not update

System Health details
System Information

version
core-2024.4.3

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.12.2

os_name
Linux

os_version
6.1.73-haos-raspi

arch
aarch64

timezone
Europe/Berlin

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
4908

Installed Version
1.34.0

Stage
running

Available Repositories
1402

Downloaded Repositories
16

Home Assistant Cloud

logged_in
true

subscription_expiration
5. Juni 2024 um 02:00

relayer_connected
true

relayer_region
eu-central-1

remote_enabled
true

remote_connected
true

alexa_enabled
false

google_enabled
false

remote_server
eu-central-1-7.ui.nabu.casa

certificate_status
ready

instance_id
7b6439d4a36b4bd39c2df2716617fb42

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 12.2

update_channel
stable

supervisor_version
supervisor-2024.04.0

agent_version
1.6.0

docker_version
25.0.5

disk_total
58.0 GB

disk_used
45.4 GB

healthy
true

supported
true

board
rpi4-64

supervisor_api
ok

version_api
ok

installed_addons
File editor (5.8.0), Z-Wave JS (0.5.0), Advanced SSH & Web Terminal (17.2.0), Mosquitto broker (6.4.0), Spotify Connect (0.13.0), openWakeWord (1.10.0), ESPHome (2024.4.0), Music Assistant BETA (2.0.0b137), Home Assistant Google Drive Backup (0.112.1), Zigbee2MQTT (1.36.1-1)

Dashboards

dashboards
6

resources
9

views
9

mode
storage

Recorder

oldest_recorder_run
14. April 2024 um 19:57

current_recorder_run
19. April 2024 um 02:47

estimated_db_size
640.38 MiB

database_engine
sqlite

database_version
3.44.2

Spotify

api_endpoint_reachable
ok

Checklist

[X] I have enabled debug logging for my installation and pasted in the debug logs below.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of currently previous issues..

Describe the issue
The weight sensor does not get updated. It always says "unknown". On my phone the sensor gets updates and shows the correct weight it gets from vesync.
Integration Version
v1
Reproduction steps

Install Google Fit integration
Check weight data
Find no data

Debug logs
2024-04-19 03:09:59.092 DEBUG (MainThread) [custom_components.google_fit] Fetching data for account<EMAIL_ADDRESS>2024-04-19 03:09:59.093 DEBUG (MainThread) [custom_components.google_fit] Verifying account access token
2024-04-19 03:09:59.093 DEBUG (MainThread) [custom_components.google_fit] Successfully retrieved existing access credentials.
2024-04-19 03:10:00.679 DEBUG (MainThread) [custom_components.google_fit] Skipping API query for infrequently updated sensor 'Height'
2024-04-19 03:10:00.679 DEBUG (MainThread) [custom_components.google_fit] Skipping API query for infrequently updated sensor 'Weight'
2024-04-19 03:10:00.679 DEBUG (MainThread) [custom_components.google_fit] Skipping API query for infrequently updated sensor 'Body Fat'
2024-04-19 03:10:00.680 DEBUG (MainThread) [custom_components.google_fit] Skipping API query for infrequently updated sensor 'Body Temperature'
2024-04-19 03:10:02.711 DEBUG (MainThread) [custom_components.google_fit] No float data points found for derived:com.google.blood_glucose:com.google.android.gms:merged
2024-04-19 03:10:02.930 DEBUG (MainThread) [custom_components.google_fit] No float data points found for derived:com.google.hydration:com.google.android.gms:merged
2024-04-19 03:10:03.179 DEBUG (MainThread) [custom_components.google_fit] Finished fetching google_fit data in 4.087 seconds (success: True)
2024-04-19 03:11:13.037 DEBUG (MainThread) [custom_components.google_fit] Setting up Google Fit integration from configuration b767c19b08743793fb83705f80c1ecf6
2024-04-19 03:11:13.041 DEBUG (MainThread) [custom_components.google_fit] Attempting to create OAuth2 session
2024-04-19 03:11:13.041 DEBUG (MainThread) [custom_components.google_fit] Initialising Google Fit Authentication Session
2024-04-19 03:11:13.041 DEBUG (MainThread) [custom_components.google_fit] Checking OAuth2 session is valid.
2024-04-19 03:11:13.041 DEBUG (MainThread) [custom_components.google_fit] Verifying account access token
2024-04-19 03:11:13.042 DEBUG (MainThread) [custom_components.google_fit] Creating Google Fit data access coordinator.
2024-04-19 03:11:13.042 DEBUG (MainThread) [custom_components.google_fit] Setting up Google Fit Coordinator. Querying every 5 minutes (every 60 minutes for less frequently used sensors).
2024-04-19 03:11:13.080 DEBUG (MainThread) [custom_components.google_fit] Requesting initial sensor value fetch.
2024-04-19 03:11:13.080 DEBUG (MainThread) [custom_components.google_fit] Fetching data for account<EMAIL_ADDRESS>2024-04-19 03:11:13.081 DEBUG (MainThread) [custom_components.google_fit] Verifying account access token
2024-04-19 03:11:13.081 DEBUG (MainThread) [custom_components.google_fit] Successfully retrieved existing access credentials.
2024-04-19 03:11:14.818 DEBUG (MainThread) [custom_components.google_fit] Querying infrequently updated sensor 'Height'
2024-04-19 03:11:15.118 DEBUG (MainThread) [custom_components.google_fit] Querying infrequently updated sensor 'Weight'
2024-04-19 03:11:15.308 DEBUG (MainThread) [custom_components.google_fit] No float data points found for derived:com.google.weight:com.google.android.gms:merge_weight
2024-04-19 03:11:15.308 DEBUG (MainThread) [custom_components.google_fit] Querying infrequently updated sensor 'Body Fat'
2024-04-19 03:11:15.560 DEBUG (MainThread) [custom_components.google_fit] Querying infrequently updated sensor 'Body Temperature'
2024-04-19 03:11:15.754 DEBUG (MainThread) [custom_components.google_fit] No float data points found for derived:com.google.body.temperature:com.google.android.gms:merged
2024-04-19 03:11:17.746 DEBUG (MainThread) [custom_components.google_fit] No float data points found for derived:com.google.blood_glucose:com.google.android.gms:merged
2024-04-19 03:11:17.950 DEBUG (MainThread) [custom_components.google_fit] No float data points found for derived:com.google.hydration:com.google.android.gms:merged
2024-04-19 03:11:18.199 DEBUG (MainThread) [custom_components.google_fit] Finished fetching google_fit data in 5.118 seconds (success: True)
2024-04-19 03:11:18.213 DEBUG (MainThread) [custom_components.google_fit] Integration setup successful.

Hi @xteaun,
Is this only true of the weight sensor?

No. It was the same for Blood sugar, I think, and possibly for other sensors. However, I only used the weight sensor in HA. Now, I have deleted the integration, because it did not work for me and additionally always needed re-authentication.