Breadcrumb blank when page is in a subfolder

Our razor pages web application is starting to grow so we added subfolders to the Pages directory. So far everything seems to be rendering fine but we're having issues with the last breadcrumb showing blank.
Pages
-> Clients
----> Index.html
Index.html

Hello, I would need a bit more info to try & figure out what's happening, especially how the breadcrumbs are created/configured.

Sure thing - The root index is in the main Pages folder which is where the Default BreadCrumb is defined. Any new pages made in the main Pages folder pick up the BreadCrumb service accordingly. If I make a subfolder in Pages like Clients, the page renders but the BreadCrumb section only shows the Default BreadCrumb.
The only options I set for the BreadCrumb service is this:
            services.AddBreadcrumbs(GetType().Assembly, options =>
            {
                options.TagClasses = "";
                options.OlClasses = "breadcrumb";
                options.LiClasses = "breadcrumb-item";
                options.ActiveLiClasses = "breadcrumb-item active";
            });

Is there anything else needed on my end to describe the problem? I would love to use this nifty tool in my project

If you inspect the breadcrumbs part in your website, how many <li> elements do you find?

Just one, the Default BreadCrumb

Would it be possible for you to create a small repo that reproduces the issue please?

I'm closing this since it's been a while, feel free to re-open if you still have the issue.


Add WeekendJam archive playlist to repertoire

Hi!
The Estuary WeekendJams have been a weekly collaborative, improvised livecoding institution since late 2020 - we started recording them early 2021 and archiving on my personal yt channel before moving to the eulerroom channel just over a year ago.
The eulerroom playlist will be the final home for this archive, I'm in the process of transferring 2.5 years of videos across from my personal channel.
I think this would be good to link in "Repertoire" in the README.md:
https://www.youtube.com/playlist?list=PLMBIpibV-wQLvP7jitjnV9E61DfV11235
I compiled some youtube stats in this spreadsheet
We have run over 160 jams, with participation from over 60 unique livecoders in the 3+ years it's been running

Thanks for the suggestion to include this, I will!


[SINGA-290] Fix SWIG version for Python 2

For Python 2, the minimal version of SWIG should be 3.0.8

It failed to work with 3.0.8. Hence, I set it to 3.0.10..


Allow non-string as Banner.Message children prop

The Banner.Message currently only accept string as children, and wraps the string inside a  element. We would like the ability to express richer styling-structure (lists, links etc) in the Banner.Message.children. Would it be possible to change the Banner.Message to accept ReactNode  as children instead of just string, and not have it nested inside a Typography.
Describe the solution you'd like
I want to be able to express things like this:
<Banner>
  <Banner.Message>
    <List>
      <List.Item>My first thing</List.Item>
      <List.Item>My second item</List.Item>
    </List>
  </Banner.Message>
</Banner>

Today the above give typescript errors, and also the list would get wrapped inside a Typography element.
Describe alternatives you've considered
Today we can force non string elements into the Banner.Message.children, but the non-string element would still get nested inside Typography.

Ref https://equinor.slack.com/archives/CJT20H1B9/p1730197485058199

What about add a new prop boolean to <Banner.Message /> called asChild
if asChild is fasle then <Banner.Message /> will wrap the children in a Typography
if asChild is true then then  <Banner.Message /> will return the children
Then the user would be able to use any kind of element they want.

The most "forgiving" way might be to check if props.children is a string, and then wrap it in Typography, otherwise just render props.children.
This would make this change non-breaking for existing code. The negative would be the (maybe) surprising special handling of the 'string' case.

The issue with checking if children is a string and only wrapping it in that case is that it could create a breaking change.
Since the styling properties of Typography are inherited, users might already rely on the styles provided by the Typography component. Conditionally applying the wrapper could disrupt these inherited styles for existing implementations.
Using an asChild prop would avoid this issue, allowing developers to opt into the behavior only when needed and preserving backward compatibility for all other cases.

Another solution could be to not use Banner.Message. Looking at the implementation, Banner.Message only wraps children in a Typography component and sets the variant to body_long, so you could directly use your own component in place of Banner.Message if needed.

This might well be a solution we could explore. But I guess the downside of this is that we are walking somewhat outside the established API of the Banner component, and thus might break in the future due to unreleted changes. Might be a an OK price to pay for now.

Given that Banner.Message is literally just a Typography with nothing added I would agree that you should just not use it if you need html content. Just make sure to replace it with an outermost div since the grid expects 1-3 children (grid-template-columns: ${$hasIcon ? 'min-content 1fr auto' : '1fr auto'};)


Add an option to move the account buttons in the sidebar back to top

Checklist

[x] I have used the search function to see if someone else has already submitted the same bug report.
[x] I will describe the problem with as much detail as possible.

App
K-9 Mail
App version
8.1
Where did you get the app from?
F-Droid
Android version
14
Device model
Pixel 8
Steps to reproduce
In the new sidebar design, the account icons are always visible on the left, reducing the space in the sidebar for folder names quite a bit. In the old design with the accounts at the top (scrolling out of view when looking for a folder), the space was better used, at least on phones (I did not compare it on table devices).
It would be nice to have an option to use the old design. Then one could either have the accounts to the left (probably useful if you switch between accounts often) or to the top, which is useful if you switch less often and want more space for the sidebar content.
Expected behavior
Design since 8.0.
Actual behavior
Previous design.
Logs
No response

While I understand that you preferred the old design, maintaining two different drawer layouts and implementations would be quite a bit of work that would take away from other important projects. For those who don't switch accounts often, there is an option to hide the accounts sidebar. For those who do so more often they'd likely keep it enabled and switch as needed. I'd like us to avoid too many settings, as each new settings requires migrations, extra testing for both states, etc.
 I appreciate that you've taken the time to file this issue, but since we can't bring back the old design as is I'm going to close this one.

I just thought I am probably not the only one (and someone has to open the bug) and as the old implementation is probably still usable, there would only need to be a switch.
Perhaps you could look into making the current implementation take up less space? What about having the account icons in a rectangle at the top left, and freeing up the space below the rectangle? The current sidebar is mostly empty here, and probably for most people who only have 2-3 accounts.

For those who don't switch accounts often, there is an option to hide the accounts sidebar.

I was looking for such an option and couldn't find it in the settings or on a long press in the sidebar. Where can I find it? And how do you switch accounts afterwards? I have multiple accounts, but I switch between them only about twice a day and not all the time, so the toggles are a waste of space for me most of the time, but I still need to be able to access them in some way when I need to switch.

Oh, how could I have missed that ...
Another idea: What about using the account names as headers for collapsible folder lists? Then you would have all accounts in the sidebar without needing a secondary sidebar to switch between them, could collapse the accounts that are currently not needed, and would have the same amount of space to show the account name as to show the folder names. It would also be closer to Thunderbird on the desktop, which also uses collapsible lists.

We're going to tackle folder hierarchy in 2025, collapsible folder lists and putting the account header on top is certainly something we could consider as part of that to save space. I'll make a note of this while we explore it. I appreciate the suggestion!


Add embargoed/award number options to create dandiset page

Adds checkbox to embargo a new dandiset + a text field to enter the award number in.
Resolves #995

This should probably be targeted to an embargo-mvp feature branch. Thoughts on that @dchiquito?

I think it wouldn't really be an issue to just leave this PR unmerged until we're ready to release embargo (we can merge the other PRs without breaking anything, since users wouldn't be able to create embargoed dandisets without this PR).
The only reasons I think we'd want a separate branch is to close this PR (just to keep the PR list shorted), or so we have a branch that we can easily check out to create embargoed dandisets for development purposes. We can always just check out this branch create-embargoed-dandiset, so I don't see a great reason for a feature branch.

I think it wouldn't really be an issue to just leave this PR unmerged until we're ready to release embargo (we can merge the other PRs without breaking anything, since users wouldn't be able to create embargoed dandisets without this PR).
The only reasons I think we'd want a separate branch is to close this PR (just to keep the PR list shorted), or so we have a branch that we can easily check out to create embargoed dandisets for development purposes. We can always just check out this branch create-embargoed-dandiset, so I don't see a great reason for a feature branch.

I agree if this is the only branch in the frontend that will be needed for embargo MVP. This is a complex enough venture that I'm not comfortable standing by such a claim.
There's a subtle reason to prefer merging PRs that are ready to go, rather than just leaving them hanging out: it reduces uncertainty in what is a rather sprawling set of coordinated tasks that need to land together to get the MVP done. That is, we don't have to go hunting for unmerged PRs when we are ready to deliver. This is more of a PHB concern than an engineer one, so I'll defer to you guys, but even so my advice is to get it merged (somewhere) if possible.

I've wrapped the embargo UI elements in a v-if=false so we can merge this before we combine the repos, as @roni and I discussed.


Colors phase 2

Nice to have/future developments:

[x] cielab(l, a, b)
[ ] Perceptually uniform color interpolation PoC

[x] with ramp
[ ] with blend

[ ] HSLuv PoC
[ ] cielaba

cc @makella

after talking with @rochoa we'll reopen this as needed.


Performance Improvement for StartUp API

Proposed changes
If list of trusted applications is provided by caller then use it instead of making an OS call.
Describe what this PR is trying to do.
During OneAuth/MSAL Startup on Mac, multiple calls are made to Sec* APIs like SecTrustedApplicationCreateFromRequirement, SecTrustedApplicationCreateFromPath (file:MOAUtil.m) etc... These APIs are heavy on IO and impacts performance. In current changes, if list of trusted applications is sent by caller then use them instead of querying them again. This change improves the performance by appox 15% in local dev environment.
How to verify impact: accessCreateWithChangeACL API uses the trusted application list to make another OS call. If any error, it logs the error code. We can track the error code in production to see if any spike in error.
ADO#1852918
Type of change

[ ] Feature work
[x] Bug fix
[ ] Documentation
[ ] Engineering change
[ ] Test
[ ] Logging/Telemetry

Risk

[ ] High – Errors could cause MAJOR regression of many scenarios. (Example: new large features or high level infrastructure changes)
[ ] Medium – Errors could cause regression of 1 or more scenarios. (Example: somewhat complex bug fixes, small new features)
[x] Small – No issues are expected. (Example: Very small bug fixes, string changes, or configuration settings changes)

Additional information

@SunandaChowdhary I feel this change will not be required in Identitycore, once we implement lazy init of MSAL in OneAuth
Product Backlog Item 1853513: No IO operations or keychain access during OneAuth Startup.
As I said earlier the major bottleneck is in building ACL in OneAuth SDK, so once we remove that we need to initialize MSAL lazily so this change will be no-op.

@SunandaChowdhary I feel that this change will not be required here, since our real bottleneck is building ACL in OneAuth SDK. Once we initialize ACL and MSAL lazily out of main thread(out of OneAuth init), this change will be no-op. Product Backlog Item 1853513: No IO operations or keychain access during OneAuth Startup

Hi Shakul, By doing lazy initialization, the problem of boot performance is only masked. The issue of using KeyChain persists. As per our last team discussion, For versions > 10.15 we should not use Sec* APIs and hence any keychain access at all. Hence for short term lazy initialization is fine but actual solution would be to remove the code which we no longer need to call.

Accidentally closed the pull request, hence re-opening it.

@SunandaChowdhary, @githubursul, is this PR still needed? If not, please close.


chore(docs): Remove 'yellow paper' reference from protocol specs

Edits a couple of lines on the landing page of the protocol specs to remove reference to "yellow paper".

Docs Preview
Hey there! 👋 You can check your preview at https://66227e387c3c8811b78c0902--aztec-docs-dev.netlify.app


[Polkadot Wiki Migration] Thousand Validators Programme

This page was migrated from https://wiki.polkadot.network/docs/thousand-validators

The program is being rebranded and has new rules FYI https://docs.google.com/document/d/1TC5CHywEohV2BT4i1UFOV7ig9rwjTrSrYZr07kNvsLs/edit#heading=h.sp1cecwuwmp4

As far as I know, the 1kv program has been completely redone and renamed, and is something now called "Decentralized Nodes" and operates completely differently, so this entire page should likely be removed/rewritten by someone from W3F.

Closing this since the program has been replaced with the Decentralized Nodes Program


doc: clarify what a subsystem is

Clarify what a subsystem is, this has been missing the docs.
Signed-off-by: Anas Nashif<EMAIL_ADDRESS>

I won't block, but as a maintainer of the device model I'll keep insisting that device driver classes should not be considered subsystems in the Zephyr context.

That is a rather odd statement. If the project as a whole regard these as subsystems, a single maintainer cannot just decide to disregard that. We need consistency in the use of our glossary.

I won't block, but as a maintainer of the device model I'll keep insisting that device driver classes should not be considered subsystems in the Zephyr context.

That is a rather odd statement. If the project as a whole regard these as subsystems, a single maintainer cannot just decide to disregard that. We need consistency in the use of our glossary.

I guess it should be fine if expressed as an opinion.


fix(si): Change SI container restart policy

Currently, we had a restart policy of on-failure BUT this causes us to
try and start containers on system boot as docker doesn't keep track
of the previous state - https://github.com/moby/moby/issues/35166#issuecomment-338211235
This means that we will continually hit this problem and the containers
may fail to start due to ordering issues
Fixes: #2802

bors merge

bors retry

bors retry

bors retry


Support Gitlab/Github repos as mirrored repository

Request details
Gitlab uses this Maven configuration for authentication:
    <server>
      <id>my-gitlab</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>XXXXXXXXXXXX</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>

In our setup we would need this kind of configuration: Providing a http-header as an alternative to username/password. This would fit to Gitlab's "Private-Token" as well as to repositories using "Authorization" header like Github:
      <configuration>
        <httpHeaders>
          <property>
            <name>Authorization</name>
            <value>Bearer XXXXXXXXXXXXXXXXXXXX</value>
          </property>
        </httpHeaders>
      </configuration>

You should be able now to define custom authentication methods as follows:

It'll be available in the next release, but you can also test this using our snapshots builds for Docker/standalone JAR when CI will finish publication tasks.

Whow! You're faster than light 👍 . I will test it for sure, thanks!


Publish documentation to Swift Package Index

As a developer integrating Pillarbox I want to be able to browse the documentation also in a web browser.
Acceptance criteria

Pillarbox documentation is published on Swift Package Index.

Hints
See https://swiftpackageindex.com/add-a-package.
Tasks

[x] Publish documentation on Swift Package Index.

Pillarbox is now available on the Swift Package Index and its documentation as well.


unmet dependency libicuXx

sudo apt install mssql-cli
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mssql-cli : Depends: libicu52 but it is not installable or
                      libicu55 but it is not installable or
                      libicu57 but it is not installable or
                      libicu60 but it is not installable
E: Unable to correct problems, you have held broken packages.

Linux  4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

similar to #204

Thanks for sharing. We need to update our Linux distribution here.
Are you able to install via pip install mssql-cli for now? This should unblock you until this gets fixed.

Thanks for the hint. I'll try.
I'm not blocked by this issue anyway, just wanted to report.

We don't have plans to support Debian 4, so I'm going to close this.


hashCode for polynomial does not work

scala> Polynomial("(1)").##
res1: Int = -135076863

scala> Polynomial("(1)").##
res2: Int = 776699639

scala> Polynomial("(1)").##
res3: Int = 797295762

scala> Polynomial("(1)").##
res4: Int = 639834089

Both PolyDense and PolySparse use arrays internally. So the hashCode method generated for case classes is not sufficient. Also, hashCode would have to be implemented in such a way that both PolyDense and PolySparse representations of the same polynomial return the same hash code.
At the very least, hashCode needs to be implemented to be 0 to fulfill the equals/hashCode contract.

Just to provide some insights, I have found this thread in Scala-User about case classes and hashcode involving arrays. The workaround suggested by Jason Zaugg is to use scala.collection.mutable.WrappedArray,  which offers access to the raw array but provides structural equality. For PolySparse, the exponentials, the exp first parameter, would be a WrappedArray[Int]. For the coefficients, I do not know how to create the appropriate WrappedArray[C] instances. I would leave that parameter untouched, just going only for the exponentials.

@pleira: Interesting, thanks!
I think for our case, we should come up with a hashing algorithm that just uses the coefficient and exponents, to easily ensure that sparse and dense hash to the same thing.
We should also ensure that "constant" polynomials hash to the constant coefficient's hash code.

@pleira I think using wrapped arrays would be inefficient, because they are another level of indirection. And as @non mentioned, we will need to implement hashCode for PolyDense and PolySparse anyway.
Why do constant polynomials have to have the same hashCode as the scalars? Is there cooperative equality between constant polynomials and scalars?

Currently there is (again to support things like == 0). We could choose not to support that, but it's not a lot of work (IMO at least) so I will probably try to do it.

I am not sure if this is even possible. At least PolyDense does not have a typeclass instance that could be used to get the value for Polynomial.zero.hashCode, and the zero polynomial is encoded as a polynomial with zero exponents and coefficients, so we don't have a value to call hashCode on...
At the very least, the representation of Polynomial.zero would have to be changed to have a constant value of the zero element. On the plus side, this would also solve #409

@rklaehn yeah, we'd have to go the other way and "ignore" 0s in dense polynomials. Doing this is pretty sketchy, since it'll only work for numbers that support "cooperative equality", but we do it with Complex...

This points to the more annoying problem of having universal equality + hashCode baked in to start :\

So I have gone ahead and made a best effort to support universal equality and hashCode as they would need to be done to be consistent. Definitely let me know what you think.

Exactly. Having equals and hashCode always drives you to an object oriented style, which in this case would mean capturing the type classes on creation (or at least something that lets you find out if something is zero).

As @rklaehn implies this approach is somewhat unprincipled. Alternate approaches that I see are:

Capture Eq and Semiring at construction time for all polynomials.
Hack PolyDense to track zero-ness explicitly (maybe via a bitset or something).
Give up on universal equality / hash code working consistently
Simplify or redesign polynomial (e.g. give up on dense polynomials to allow structural comparisons)

Wouldn't it be enough to capture Semiring? All we need is a way to figure out if things are zero.
Yuck!
I think even if you give up on universal equality / hash code you still need a way to figure out if something is zero
Then you would have to make sure that sparse polynomials never contain zero coefficients. Is that the case?

Yes, you are right that (1) only requires a Semiring. And also that (4) is not sufficient. I feel like the PR we have in now might be the best option, but I'm definitely interested in your opinions.

I think the PR is a good compromise for now. It just seems imprecise to use == 0 to check if something is zero. But if somebody is using Eq, everything will work fine. And if you want to use equals/hashCode you must make sure that your T has zero.hashCode == 0 and zero == 0.

Great. Well, if @tixxit signs-off then I will merge this. We definitely need to fix this for 0.9.2.


feat: rename new remote api action and add associated model class

Is this adding or improving a feature or fixing a bug?
Part of adding new remote API action to support MS workflow
What's the new behavior?
No new behavior at this moment
How does this change work?

Does this fix any issues or need any specific reviewers?
Fixes: #
Reviewers: @

@msft-paulkim  - Is this a dead PR?  Can it be deleted.


Provide helm chart

Feature Suggestion
// A succinct description of how you want to achieve the desired behavior.
// If you have looked at the code and know exactly what code changes are needed then please consider submitting a pull request instead.
Provide a helm chart for quicker and easier deployments on Kubernetes.
Impact
// A succinct description of why you want the desired behavior specified above.
The desired behavior will allow me to ...
Deploy N amount hummingbot instances in a highly available kubernetes cluster
Additional context
Add any other context or screenshots about the feature request here.
If this is wanted by the community I can pitch in some resources to make this happen. I did notice on
https://github.com/CoinAlpha/hummingbot/issues/1964#issuecomment-650802147 setting ENV vars is possible on the container which can help with helm conditionals and bypassing the TUI startup. Considering configuration is done mostly through yml this should fairly easy to accomplish.
┆Issue is synchronized with this Clickup task by Unito

any update?

https://artifacthub.io/packages/helm/devopscare-helm-charts/hummingbot
try this one. https://github.com/DevopsCare/artifacts/tree/master/charts/hummingbot

@anthr76 Hi Antony, do you have any updates on this PR? We are going to have weekly dev calls, you could present this idea to the community!

@klpanagi today we talked about helm chart haha! other people is interested on this so probably we can evaluate the implementation

This is too old guys.
It uses the coinalpha/hummingbot dockerhub image, does not have support for latest versions (configs, envs etc), does not include gateway support, external db neither a message broker.

Yeah I know, but the idea is here we have to tweak the variables
On Sun, 2 Apr 2023 at 19:14 Konstantinos Panayiotou <
@.***> wrote:

This is too old guys.
It uses the coinalpha/hummingbot dockerhub image, does not have support
for latest versions (configs, envs etc), does not include gateway support,
external db neither a message broker.
—
Reply to this email directly, view it on GitHub
https://github.com/hummingbot/hummingbot/issues/2972#issuecomment-1493452633,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIZJOSEZKO4UJ7FTOB46VWLW7H24TANCNFSM4X6MZKBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

This is too old guys.
It uses the coinalpha/hummingbot dockerhub image, does not have support for latest versions (configs, envs etc), does not include gateway support, external db neither a message broker.

I'm open to PRs.


Unindent testitems thanks to new JuliaFormatter

Codecov Report
Patch and project coverage have no change.

Comparison is base (e867e60) 82.39% compared to head (0c9e609) 82.39%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #57   +/-   ##
=======================================
  Coverage   82.39%   82.39%
=======================================
  Files          20       20
  Lines         409      409
=======================================
  Hits          337      337
  Misses         72       72

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

useless


Basic question about the quantitation algorithm

Hi!
I would like to ask about the background of the MoFF quantitation algorithms as I could not find a publication explaining it. The MS1 quantitation algorithms I knew so far (i.e. XPRESS, ASAPRatio, FeatureFinder in OpenMS) were all based on integration of the whole area of a MS1 peak. If I get it right, MoFF works instead solely with the highest value (= the apex) of a peak.
Is this commonly used for peak quantitation? How does this approach compare to the mentioned algorithms?

Hi,
yes you had the right intuition.
moFF gets only the apex of each annotated feature given in input. For each feature (rt,mz,charge,mass) moFF extracts the XiC just using the monoisotopic mass of the peptides.
In a paper that will be available soon in Nature Methods, we compare moFF and MAxQuant intensities showing really high correlation coefficient. Also from the quantitative perspective for the match-between-run, moFF finds matched features as much as MaxQuant does. As soon the paper will be online I will update the readme information.

Cool, I am eagerly waiting for some tutorial for the match-between-runs-part of MoFF! I cannot use MQ and this seems to be very powerful.


test: pkg/certificate/providers/config.go test NewCertificateProvider()

In pkg/certificate/providers/config.go, the unit test coverage is low for the NewCertificateProvider() func. See highlighted lines below.

It would help to add a test for correct creation of the new certificate provider.

Consolidated in #3425


Bits for base address 0x41580, frame 38

Following 46 bits reported as missing for Litex:

{ unknown_bit = "004015a6_2_16", unknown_segment = "0x00401580", unknown_segbit = "38_80" }
{ unknown_bit = "004015a6_2_20", unknown_segment = "0x00401580", unknown_segbit = "38_84" }
{ unknown_bit = "004015a6_67_16", unknown_segment = "0x00401580", unknown_segbit = "38_2160" }
{ unknown_bit = "004015a6_67_20", unknown_segment = "0x00401580", unknown_segbit = "38_2164" }
{ unknown_bit = "004015a6_6_16", unknown_segment = "0x00401580", unknown_segbit = "38_208" }
{ unknown_bit = "004015a6_6_20", unknown_segment = "0x00401580", unknown_segbit = "38_212" }
{ unknown_bit = "004015a6_71_16", unknown_segment = "0x00401580", unknown_segbit = "38_2288" }
{ unknown_bit = "004015a6_71_20", unknown_segment = "0x00401580", unknown_segbit = "38_2292" }
{ unknown_bit = "004015a6_10_16", unknown_segment = "0x00401580", unknown_segbit = "38_336" }
{ unknown_bit = "004015a6_10_20", unknown_segment = "0x00401580", unknown_segbit = "38_340" }
{ unknown_bit = "004015a6_14_16", unknown_segment = "0x00401580", unknown_segbit = "38_464" }
{ unknown_bit = "004015a6_14_20", unknown_segment = "0x00401580", unknown_segbit = "38_468" }
{ unknown_bit = "004015a6_79_16", unknown_segment = "0x00401580", unknown_segbit = "38_2544" }
{ unknown_bit = "004015a6_79_20", unknown_segment = "0x00401580", unknown_segbit = "38_2548" }
{ unknown_bit = "004015a6_18_16", unknown_segment = "0x00401580", unknown_segbit = "38_592" }
{ unknown_bit = "004015a6_18_20", unknown_segment = "0x00401580", unknown_segbit = "38_596" }
{ unknown_bit = "004015a6_83_16", unknown_segment = "0x00401580", unknown_segbit = "38_2672" }
{ unknown_bit = "004015a6_83_20", unknown_segment = "0x00401580", unknown_segbit = "38_2676" }
{ unknown_bit = "004015a6_22_16", unknown_segment = "0x00401580", unknown_segbit = "38_720" }
{ unknown_bit = "004015a6_22_20", unknown_segment = "0x00401580", unknown_segbit = "38_724" }
{ unknown_bit = "004015a6_87_16", unknown_segment = "0x00401580", unknown_segbit = "38_2800" }
{ unknown_bit = "004015a6_87_20", unknown_segment = "0x00401580", unknown_segbit = "38_2804" }
{ unknown_bit = "004015a6_26_16", unknown_segment = "0x00401580", unknown_segbit = "38_848" }
{ unknown_bit = "004015a6_26_20", unknown_segment = "0x00401580", unknown_segbit = "38_852" }
{ unknown_bit = "004015a6_91_16", unknown_segment = "0x00401580", unknown_segbit = "38_2928" }
{ unknown_bit = "004015a6_91_20", unknown_segment = "0x00401580", unknown_segbit = "38_2932" }
{ unknown_bit = "004015a6_30_16", unknown_segment = "0x00401580", unknown_segbit = "38_976" }
{ unknown_bit = "004015a6_30_20", unknown_segment = "0x00401580", unknown_segbit = "38_980" }
{ unknown_bit = "004015a6_95_16", unknown_segment = "0x00401580", unknown_segbit = "38_3056" }
{ unknown_bit = "004015a6_95_20", unknown_segment = "0x00401580", unknown_segbit = "38_3060" }
{ unknown_bit = "004015a6_34_16", unknown_segment = "0x00401580", unknown_segbit = "38_1104" }
{ unknown_bit = "004015a6_34_20", unknown_segment = "0x00401580", unknown_segbit = "38_1108" }
{ unknown_bit = "004015a6_99_16", unknown_segment = "0x00401580", unknown_segbit = "38_3184" }
{ unknown_bit = "004015a6_99_20", unknown_segment = "0x00401580", unknown_segbit = "38_3188" }
{ unknown_bit = "004015a6_38_16", unknown_segment = "0x00401580", unknown_segbit = "38_1232" }
{ unknown_bit = "004015a6_38_20", unknown_segment = "0x00401580", unknown_segbit = "38_1236" }
{ unknown_bit = "004015a6_42_16", unknown_segment = "0x00401580", unknown_segbit = "38_1360" }
{ unknown_bit = "004015a6_42_20", unknown_segment = "0x00401580", unknown_segbit = "38_1364" }
{ unknown_bit = "004015a6_46_16", unknown_segment = "0x00401580", unknown_segbit = "38_1488" }
{ unknown_bit = "004015a6_46_20", unknown_segment = "0x00401580", unknown_segbit = "38_1492" }
{ unknown_bit = "004015a6_55_16", unknown_segment = "0x00401580", unknown_segbit = "38_1776" }
{ unknown_bit = "004015a6_55_20", unknown_segment = "0x00401580", unknown_segbit = "38_1780" }
{ unknown_bit = "004015a6_59_16", unknown_segment = "0x00401580", unknown_segbit = "38_1904" }
{ unknown_bit = "004015a6_59_20", unknown_segment = "0x00401580", unknown_segbit = "38_1908" }
{ unknown_bit = "004015a6_63_16", unknown_segment = "0x00401580", unknown_segbit = "38_2032" }
{ unknown_bit = "004015a6_63_20", unknown_segment = "0x00401580", unknown_segbit = "38_2036" }

are solved by:

LIOB33.IOB_Y1.38_16 38_16
LIOB33.IOB_Y1.38_20 38_20

These bits seem to be IOB related.

These bits are the SLEW.FAST bits for IOSTANDARD SSTL135.  I'm working on a fuzzer update to 030 to support SSTL135.

@litghost
There is around 160 bits that can't be solved with the SLEW defined as:

RIOB33.IOB_Y0.SLEW.SLOW 38_106 38_110 39_105 39_109
RIOB33.IOB_Y1.SLEW.SLOW 38_18 38_22 39_17 39_21

but they solve if we have them separately:

RIOB33.IOB_Y0.SLEW.38_106 38_106
RIOB33.IOB_Y0.SLEW.38_110 38_110
RIOB33.IOB_Y0.SLEW.39_105 39_105
RIOB33.IOB_Y0.SLEW.39_109 39_109
RIOB33.IOB_Y1.SLEW.38_18 38_18
RIOB33.IOB_Y1.SLEW.38_22 38_22
RIOB33.IOB_Y1.SLEW.39_17 39_17
RIOB33.IOB_Y1.SLEW.39_21 39_21

It seems that the SLEW bits don't work the RIOBs because bit 39_21 is not there:

...
RIOB33_X43Y19.IOB_Y1.SLEW.38_18
RIOB33_X43Y19.IOB_Y1.SLEW.38_22
RIOB33_X43Y19.IOB_Y1.SLEW.39_17
...

That is what is said in https://github.com/SymbiFlow/prjxray/issues/965#issuecomment-514235039, anyways this is fixed in #970

@litghost after #970 there are still 6 bits, seems 3 per site that are or used to be part of the solution for the DRIVE, SLEW, IOSTANDARD features:

38_04
{ unknown_bit = "004015a6_67_4", unknown_segment = "0x00401580", unknown_segbit = "38_2148" }
{ unknown_bit = "004015a6_71_4", unknown_segment = "0x00401580", unknown_segbit = "38_2276" }
{ unknown_bit = "004015a6_79_4", unknown_segment = "0x00401580", unknown_segbit = "38_2532" }
{ unknown_bit = "004015a6_83_4", unknown_segment = "0x00401580", unknown_segbit = "38_2660" }
{ unknown_bit = "004015a6_91_4", unknown_segment = "0x00401580", unknown_segbit = "38_2916" }
{ unknown_bit = "004015a6_95_4", unknown_segment = "0x00401580", unknown_segbit = "38_3044" }
{ unknown_bit = "004015a6_55_4", unknown_segment = "0x00401580", unknown_segbit = "38_1764" }
{ unknown_bit = "004015a6_59_4", unknown_segment = "0x00401580", unknown_segbit = "38_1892" }

38_06
{ unknown_bit = "004015a6_67_6", unknown_segment = "0x00401580", unknown_segbit = "38_2150" }
{ unknown_bit = "004015a6_71_6", unknown_segment = "0x00401580", unknown_segbit = "38_2278" }
{ unknown_bit = "004015a6_79_6", unknown_segment = "0x00401580", unknown_segbit = "38_2534" }
{ unknown_bit = "004015a6_83_6", unknown_segment = "0x00401580", unknown_segbit = "38_2662" }
{ unknown_bit = "004015a6_91_6", unknown_segment = "0x00401580", unknown_segbit = "38_2918" }
{ unknown_bit = "004015a6_95_6", unknown_segment = "0x00401580", unknown_segbit = "38_3046" }
{ unknown_bit = "004015a6_55_6", unknown_segment = "0x00401580", unknown_segbit = "38_1766" }
{ unknown_bit = "004015a6_59_6", unknown_segment = "0x00401580", unknown_segbit = "38_1894" }

38_120
{ unknown_bit = "004015a6_70_24", unknown_segment = "0x00401580", unknown_segbit = "38_2264" }
{ unknown_bit = "004015a6_78_24", unknown_segment = "0x00401580", unknown_segbit = "38_2520" }
{ unknown_bit = "004015a6_82_24", unknown_segment = "0x00401580", unknown_segbit = "38_2648" }
{ unknown_bit = "004015a6_86_24", unknown_segment = "0x00401580", unknown_segbit = "38_2776" }
{ unknown_bit = "004015a6_94_24", unknown_segment = "0x00401580", unknown_segbit = "38_3032" }
{ unknown_bit = "004015a6_54_24", unknown_segment = "0x00401580", unknown_segbit = "38_1752" }
{ unknown_bit = "004015a6_58_24", unknown_segment = "0x00401580", unknown_segbit = "38_1880" }
{ unknown_bit = "004015a6_62_24", unknown_segment = "0x00401580", unknown_segbit = "38_2008" }

38_122
{ unknown_bit = "004015a6_70_26", unknown_segment = "0x00401580", unknown_segbit = "38_2266" }
{ unknown_bit = "004015a6_78_26", unknown_segment = "0x00401580", unknown_segbit = "38_2522" }
{ unknown_bit = "004015a6_82_26", unknown_segment = "0x00401580", unknown_segbit = "38_2650" }
{ unknown_bit = "004015a6_86_26", unknown_segment = "0x00401580", unknown_segbit = "38_2778" }
{ unknown_bit = "004015a6_94_26", unknown_segment = "0x00401580", unknown_segbit = "38_3034" }
{ unknown_bit = "004015a6_54_26", unknown_segment = "0x00401580", unknown_segbit = "38_1754" }
{ unknown_bit = "004015a6_58_26", unknown_segment = "0x00401580", unknown_segbit = "38_1882" }
{ unknown_bit = "004015a6_62_26", unknown_segment = "0x00401580", unknown_segbit = "38_2010" }

38_14
{ unknown_bit = "004015a6_2_14", unknown_segment = "0x00401580", unknown_segbit = "38_78" }
{ unknown_bit = "004015a6_67_14", unknown_segment = "0x00401580", unknown_segbit = "38_2158" }
{ unknown_bit = "004015a6_6_14", unknown_segment = "0x00401580", unknown_segbit = "38_206" }
{ unknown_bit = "004015a6_71_14", unknown_segment = "0x00401580", unknown_segbit = "38_2286" }
{ unknown_bit = "004015a6_10_14", unknown_segment = "0x00401580", unknown_segbit = "38_334" }
{ unknown_bit = "004015a6_14_14", unknown_segment = "0x00401580", unknown_segbit = "38_462" }
{ unknown_bit = "004015a6_79_14", unknown_segment = "0x00401580", unknown_segbit = "38_2542" }
{ unknown_bit = "004015a6_18_14", unknown_segment = "0x00401580", unknown_segbit = "38_590" }
{ unknown_bit = "004015a6_83_14", unknown_segment = "0x00401580", unknown_segbit = "38_2670" }
{ unknown_bit = "004015a6_22_14", unknown_segment = "0x00401580", unknown_segbit = "38_718" }
{ unknown_bit = "004015a6_87_14", unknown_segment = "0x00401580", unknown_segbit = "38_2798" }
{ unknown_bit = "004015a6_26_14", unknown_segment = "0x00401580", unknown_segbit = "38_846" }
{ unknown_bit = "004015a6_91_14", unknown_segment = "0x00401580", unknown_segbit = "38_2926" }
{ unknown_bit = "004015a6_30_14", unknown_segment = "0x00401580", unknown_segbit = "38_974" }
{ unknown_bit = "004015a6_95_14", unknown_segment = "0x00401580", unknown_segbit = "38_3054" }
{ unknown_bit = "004015a6_34_14", unknown_segment = "0x00401580", unknown_segbit = "38_1102" }
{ unknown_bit = "004015a6_99_14", unknown_segment = "0x00401580", unknown_segbit = "38_3182" }
{ unknown_bit = "004015a6_38_14", unknown_segment = "0x00401580", unknown_segbit = "38_1230" }
{ unknown_bit = "004015a6_42_14", unknown_segment = "0x00401580", unknown_segbit = "38_1358" }
{ unknown_bit = "004015a6_46_14", unknown_segment = "0x00401580", unknown_segbit = "38_1486" }
{ unknown_bit = "004015a6_55_14", unknown_segment = "0x00401580", unknown_segbit = "38_1774" }
{ unknown_bit = "004015a6_59_14", unknown_segment = "0x00401580", unknown_segbit = "38_1902" }
{ unknown_bit = "004015a6_63_14", unknown_segment = "0x00401580", unknown_segbit = "38_2030" }

39_113
{ unknown_bit = "004015a7_1_17", unknown_segment = "0x00401580", unknown_segbit = "39_49" }
{ unknown_bit = "004015a7_66_17", unknown_segment = "0x00401580", unknown_segbit = "39_2129" }
{ unknown_bit = "004015a7_5_17", unknown_segment = "0x00401580", unknown_segbit = "39_177" }
{ unknown_bit = "004015a7_70_17", unknown_segment = "0x00401580", unknown_segbit = "39_2257" }
{ unknown_bit = "004015a7_9_17", unknown_segment = "0x00401580", unknown_segbit = "39_305" }
{ unknown_bit = "004015a7_74_17", unknown_segment = "0x00401580", unknown_segbit = "39_2385" }
{ unknown_bit = "004015a7_13_17", unknown_segment = "0x00401580", unknown_segbit = "39_433" }
{ unknown_bit = "004015a7_78_17", unknown_segment = "0x00401580", unknown_segbit = "39_2513" }
{ unknown_bit = "004015a7_17_17", unknown_segment = "0x00401580", unknown_segbit = "39_561" }
{ unknown_bit = "004015a7_82_17", unknown_segment = "0x00401580", unknown_segbit = "39_2641" }
{ unknown_bit = "004015a7_21_17", unknown_segment = "0x00401580", unknown_segbit = "39_689" }
{ unknown_bit = "004015a7_86_17", unknown_segment = "0x00401580", unknown_segbit = "39_2769" }
{ unknown_bit = "004015a7_25_17", unknown_segment = "0x00401580", unknown_segbit = "39_817" }
{ unknown_bit = "004015a7_90_17", unknown_segment = "0x00401580", unknown_segbit = "39_2897" }
{ unknown_bit = "004015a7_29_17", unknown_segment = "0x00401580", unknown_segbit = "39_945" }
{ unknown_bit = "004015a7_94_17", unknown_segment = "0x00401580", unknown_segbit = "39_3025" }
{ unknown_bit = "004015a7_33_17", unknown_segment = "0x00401580", unknown_segbit = "39_1073" }
{ unknown_bit = "004015a7_98_17", unknown_segment = "0x00401580", unknown_segbit = "39_3153" }
{ unknown_bit = "004015a7_37_17", unknown_segment = "0x00401580", unknown_segbit = "39_1201" }
{ unknown_bit = "004015a7_41_17", unknown_segment = "0x00401580", unknown_segbit = "39_1329" }
{ unknown_bit = "004015a7_45_17", unknown_segment = "0x00401580", unknown_segbit = "39_1457" }
{ unknown_bit = "004015a7_49_17", unknown_segment = "0x00401580", unknown_segbit = "39_1585" }
{ unknown_bit = "004015a7_54_17", unknown_segment = "0x00401580", unknown_segbit = "39_1745" }
{ unknown_bit = "004015a7_58_17", unknown_segment = "0x00401580", unknown_segbit = "39_1873" }
{ unknown_bit = "004015a7_62_17", unknown_segment = "0x00401580", unknown_segbit = "39_2001" }

@litghost after #970 there are still 6 bits, seems 3 per site that are or used to be part of the solution for the DRIVE, SLEW, IOSTANDARD features:

Ya I was debugging that yesterday.  Haven't gotten a bead on it yet.

Closed? So do we have the missing bits or not yet?

Closed wrong issue.

Remaining bits were related to IN_TERM, solved in #983.  Only remaining are in #966

All bits in this frame are solved by current or pending PR's.


Realm randomly crashes on deleteObject

I see randomly crashes in our application while using deleteObject. This happened in 1.1.0 version and it still happens after updating to 2.6.2. Here is crash log which is always the same:
#31. Crashed: com.ipos.queue.events
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000038

0  Realm                          0x100c3a624 RLMDeleteObjectFromRealm + 40
1  Realm                          0x100ca0d84 -[RLMRealm deleteObject:] + 24
2  Ipos                            0x1000dce18 __34-[MMSocketConnection deleteEvent:]_block_invoke (MMSocketConnection.m:215)
3  Realm                          0x100ca0564 -[RLMRealm transactionWithBlock:error:] + 64
4  Realm                          0x100ca051c -[RLMRealm transactionWithBlock:] + 24
5  Ipos                             0x1000954b0 -[MMRealmServiceBase performSyncTransactionBlock:] (MMRealmServiceBase.m:66)
6  Ipos                            0x1000dcd5c -[MMSocketConnection deleteEvent:] (MMSocketConnection.m:217)
7  libdispatch.dylib              0x18707a9e0 _dispatch_call_block_and_release + 24
8  libdispatch.dylib              0x18707a9a0 _dispatch_client_callout + 16
9  libdispatch.dylib              0x187088ad4 _dispatch_queue_serial_drain + 928
10 libdispatch.dylib              0x18707e2cc _dispatch_queue_invoke + 884
11 libdispatch.dylib              0x187088fa8 _dispatch_queue_override_invoke + 344
12 libdispatch.dylib              0x18708aa50 _dispatch_root_queue_drain + 540
13 libdispatch.dylib              0x18708a7d0 _dispatch_worker_thread3 + 124
14 libsystem_pthread.dylib        0x1872831d0 _pthread_wqthread + 1096
15 libsystem_pthread.dylib        0x187282d7c start_wqthread + 4

What can be the reason of such crash?
Expected Results
Application doesn't crash
Actual Results
Application randomly crashes on deleteObject
Steps to Reproduce
Cannot reproduce, just see it in crash logs of enterprise application
Version of Realm and Tooling
It presents in 1.1.0 and 2.6.2 without object server
Xcode version: 8.3.2
iOS/OSX version: 10.3.1

My suspicion based on the crashing offset and exception code is that this happens when -[RLMRealm deleteObject:] is passed a nil object (RLMDeleteObjectFromRealm + 40 looks like it could be the dereference of object->_realm, with 0x0000000000000038 being the offset of the _realm ivar on RLMObjectBase). -[RLMRealm deleteObject:] can only be called with non-nil objects.

@bdash thanx for the answer I will put a condition to check if object is nil though it should not be nil by our algorithm. I think this issue can be closed at least for now.

Maybe it's smarter to make this a nop ?


Sensor fault detection

Pull Request for ML-Crate 💡
Issue Title: End-to-end Sensor Fault Detection #644

Info about the related issue (Aim of the project) : The Sensor Fault Detection system is designed to monitor sensors and detect any faults. It uses advanced algorithms to ensure the accuracy and reliability of sensor data.
Name: Damodar Yadav
Email ID for further communication<EMAIL_ADDRESS>GitHub ID: https://github.com/daemonX10
Idenitfy yourself: SSOC'24 contributor

Closes: #644
Describe the add-ons or changes you've made 📃\

Make the Model for Predication of condication of Sensor , it's good/Bad  need replacement or not . I used various model for this and xgboost model out perform other and then done hyperparameter tunning.
Create PipeLine for data Ingestion , Data transformation , Model evaluation , Predication
Created Web app using Flask , django and Tailwind css  and more

What sort of change have you made:

[   ] Bug fix (non-breaking change which fixes an issue)
[✓] New feature (non-breaking change which adds functionality)
[   ] Code style update (formatting, local variables)
[   ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[   ] This change requires a documentation update

How Has This Been Tested? ⚙
Describe how it has been tested
Describe how have you verified the changes made
Checklist: ☑

[✓] My code follows the guidelines of this project.
[✓] I have performed a self-review of my own code.
[✓] I have commented my code, particularly wherever it was hard to understand.
[✓] I have made corresponding changes to the documentation.
[✓] My changes generate no new warnings.
[✓] I have added things that prove my fix is effective or that my feature works.
[✓] Any dependent changes have been merged and published in downstream modules.

@abhisheks008 changes done . i have make new folder for web part and remaining dataset , model and notebook along with image in main folder

In the web app folder create a README file (template: https://github.com/abhisheks008/ML-Crate/blob/main/.github/web-app-readme-template.md) and put a demonstration video of the working of the web app. Also attach the same video in the README so that others can view that easily.

@abhisheks008  done those change in web readme file

Just copy the demo video from your local system and paste the same inside the README so that it can be embedded inside the README and can also be viewed easily.
@daemonX10

that video is available in img folder already @abhisheks008

Although it is available in the img folder, we can not view that video directly. That's why I told you to do so in the above comment.

@abhisheks008  added direct video embedding in readme

Video is not visible. @daemonX10

i have 2 things to ask...

this is for local right??? how about web service deployment....it would be nice if you do that after submitting and completing on this...ofc on render or.. vercel..

i would like to know theway of it's working...it must be really frustating to make.. because of tons of errors...right?

i have 4 things to ask...

this is for local right??? how about web service deployment....it would be nice if you do that after submitting and completing on this...ofc on render or.. vercel..
i would like to know theway of it's working...it must be really frustating to make.. because of tons of errors...right?
what are it's limitations.. ?
what's the best accuracy with val_loss?

@daemonX10 will explain this very well, as he is the one who is developing the whole thing. About the web app part, it is hosted in local. As a beginner when you are building a college project, locally hosted web app is enough, because majority of the college students used to take help from this project repository.

Video is not visible. @daemonX10

i have 4 things to ask...

this is for local right??? how about web service deployment....it would be nice if you do that after submitting and completing on this...ofc on render or.. vercel..
i would like to know theway of it's working...it must be really frustating to make.. because of tons of errors...right?
what are it's limitations.. ?
what's the best accuracy with val_loss?

Local deployed, i have deployed multiple projects on render, you could ask me, although i have added all steps in Readme and the reason i don't deployed it, cause i not that much complex project.
2. NO, it's a simple project nothing more
3. Limitation, train on small dataset,
4. Val_loss check notebook

@abhisheks008  see, i have added video

@daemonX10  to upload a video.. first go to any code issue tab.. in there from your local upload the video in chatbox...then github will provide a link..paste that in your readme note...

@daemonX10 to upload a video.. first go to any code issue tab.. in there from your local upload the video in chatbox...then github will provide a link..paste that in your readme note...
to check if your work or not.. go to file changed... in that .. go the the desired file... and click on 3 dots in right cornor of that particular...then view file...and then you can see what is visible to public
also... when used xgboost well..there is no issue in using decision tree..but it's no use when using xgboost...as it is the upgraded version of that

Upload the video as mentioned @daemonX10

https://github.com/abhisheks008/ML-Crate/assets/115637298/7712a38e-94b3-4463-ba65-c34f3e3a484d
updated this src link

Still the video is not visible.

Do check now @abhisheks008, it showing

Hi @daemonX10 have you registered in the OSLead portal?

 Check out the announcement channel of the SSOC Discord server and register yourself in OSLead for leader board.

 Check out the announcement channel of the SSOC Discord server and register yourself in OSLead for leader board.
@daemonX10

Hi @daemonX10 have you done the needful?

I'm forgot that, can you give me link please

@abhisheks008


Option for Deleting Intermediate files from Working Directory

Hi,
I am trying to process some data ~300 DWI files approx. 24 GB in size. But the working directory is blowing up the memory way too much (>=1.5TB). Is there a way to remove/ delete the intermediate files from the working directory once they are not needed?
This is the command I am running:
qsiprep-docker ~/data ~/output --output-resolution 1.2  --fs-license-file $FREESURFER_HOME/license.txt -w ~/working --use-syn-sdc --force-syn --denoise-method patch2self --unringing-method mrdegibbs --no-b0-harmonization --nthreads 60
Thanks in advance!

Ping @mattcieslak


Allow localisation scopes to be customised

Now form builder configuration #73 and localisation #69 are merged into the version 1.1.0 branch, allowing for custom localisation scopes can be added should be fairly straightforward.
Currently the scope is hardcoded to:
['helpers', context, @object_name, @attribute_name].join('.')

Which expects a locales file in the following format:

helpers:
  label:
    person:
      name: Who goes there?
      cv: Tell us about your employment history
      favourite_colour: What is your favourite colour?
      photo: Upload a recent passport photo
  fieldset:
    person:
      favourite_colour: To which colours are you most partial?
      born_on: What is your date of birth?
      projects: What do you do all day at work?
  hint:
    person:
      name: Enter your full name including middle names, nicknames and aliases
      favourite_colour: |-
        Yes, there are plenty of options but please pick the one you enjoy most
      cv: Where did you work? What did you do?
      photo: Make sure your face is clear and you are looking at the camera
      born_on: Check your birth certificate or passport
      projects: If you cannot remember check with your teammates or manager

It would appear that the final two elements in the array @object_name, and @attribute_name would need to remain the same, but switching the beginning (in our case, helpers and context) should be possible.
There is an existing project that would benefit from this functionality, see this PR.

[ ] Add configuration options for customising the localisation schema, it should take an array of symbols
[ ] Ensure the customisation can work independently for contexts (labels, hints and fieldsets)
[ ] Add tests that cover all the new functionality
[ ] Document the configuration

cc @luke-slowen - will this do the trick for you guys?

Sorry Peter, have you mentioned the right person? Or, if you are looking for an architecture perspective, can you be more specific in the ask please?

Sorry, autocompletion failed :man_facepalming:
@leeky

@peteryates Sounds great! This would allow us to configure the labels to use the ActiveRecord i18n scope and use your default for the others.
Thanks again :tada:

@leeky Excellent
Just to keep you in the loop, there's now a beta version of the gem that comes with i18n, a huge refactor and some other goodies.

Merged into the 1.1.0 branch
Documented here, beta release here cc @leeky


fix[admin]  job name display error

fix[admin]  job name display error

Hi. Thanks to your pr.
How to reproduce problems?
What is your purpose?

Theoretically, submitted tasks should not be associated with the name of the task table, it should be same with flink.


Getting an error in all gallery methods show(), showNext(), canShowPrev(), etc

I'm using ngx-gallery library, version 5.10.0, in an Angular 7 project, but I can't access the component in my TypeScrip file, for that reason all the method throw 'undefined' error.
The gallery is working as expected in the Frontend, it shows the images and the next and previous icons are working as expected in the html. I went through all the resolve issues in this section that had the same error and I try all the solutions (that are very straight forward) but nothing work.
My code TS component file:
@ViewChild("buttonsNavigationGallery") buttonsNavigationGallery: NgxGalleryComponent;
public galleryImages: NgxGalleryImage[]=[];
async ngOnInit(): Promise {
for(let i=0; i< 5; i++){
let newImages = this.galleryImages.slice(0, this.galleryImages.length);
newImages.push({
small:  "some url",
medium:   "some url",
big:   "some url",
description: "Image #" + (i + 1)
});
this.galleryImages = newImages;
}
}
showNext(): void {
this.buttonsNavigationGallery.showNext();
}
HTML
<button (click)="showNext()">Show Next
<ngx-gallery [options]="galleryOptions"   [images]="galleryImages" #buttonsNavigationGallery>
ERROR:
ProductDamageComponent.html:70 ERROR TypeError: Cannot read property 'showNext' of undefined
at NgxGalleryComponent.showNext (ngx-gallery.umd.js:1687)
at ProductDamageComponent.showNext (productDamage.component.ts:249)
at Object.eval [as handleEvent] (ProductDamageComponent.html:70)
at handleEvent (core.js:19545)
at callWithDebugContext (core.js:20639)
at Object.debugHandleEvent [as handleEvent] (core.js:20342)
at dispatchEvent (core.js:16994)
at core.js:17441
at HTMLButtonElement. (platform-browser.js:993)
at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:421)
This is a similar issue, but the solution didn't work for me.
https://github.com/lukasz-galka/ngx-gallery/issues/160
I dont use Angular CLI

I'm closing this issue, I reinstall the library and now is working.


seems that property "-webkit-font-smoothing" is not working

Hello!
seems that   -webkit-font-smoothing property is not ordered correctly with the other typo props but at the end.

according to the readme at https://github.com/hudochenkov/stylelint-order/blob/master/rules/properties-order/README.md
...
Where font-smoothing is the unprefixed version of proprietary browser property -webkit-font-smoothing.
...

the config should just contain unprefixed variants in the group definitions.

Hmm, thanks for reporting. I published a fix with v5.4.2. Please let me know if you encounter any issues.

now it's fixed - thanks for fast reaction!


Split test_main to speed up test suite

Codecov Report

Merging #129 (ba0179c) into main (95b58c7) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #129   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            9         9
  Lines          640       640
=========================================
  Hits           640       640

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 95b58c7...ba0179c. Read the comment docs.


Table Browser cannot add column description

Table Browser does not display column descriptions and errors occur when manually adding comments.
version:cdh hue4.3.0

/var/log/hue/runcpserver.log：
1:34:07 PM	ERROR	exception
Internal Server Error: /hue/
Traceback (most recent call last):
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/lib/python2.7/site-packages/Django-1.11-py2.7.egg/django/core/handlers/exception.py", line 41, in inner
response = get_response(request)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/lib/python2.7/site-packages/Django-1.11-py2.7.egg/django/core/handlers/base.py", line 249, in _legacy_get_response
response = self._get_response(request)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/lib/python2.7/site-packages/Django-1.11-py2.7.egg/django/core/handlers/base.py", line 187, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/lib/python2.7/site-packages/Django-1.11-py2.7.egg/django/core/handlers/base.py", line 185, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/build/env/lib/python2.7/site-packages/Django-1.11-py2.7.egg/django/utils/decorators.py", line 185, in inner
return func(*args, **kwargs)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/desktop/core/src/desktop/views.py", line 97, in hue
'cluster': clusters[0]['type'] if clusters else None
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/desktop/core/src/desktop/lib/django_util.py", line 223, in render
return render_json(data, request.GET.get("callback"), status=status)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/desktop/core/src/desktop/lib/django_util.py", line 298, in render_json
json = encode_json(data, indent)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/desktop/core/src/desktop/lib/django_util.py", line 270, in encode_json
return json.dumps(data, indent=indent, cls=Encoder)
File "/usr/lib64/python2.7/json/init.py", line 250, in dumps
sort_keys=sort_keys, **kw).encode(obj)
File "/usr/lib64/python2.7/json/encoder.py", line 209, in encode
chunks = list(chunks)
File "/usr/lib64/python2.7/json/encoder.py", line 434, in _iterencode
for chunk in _iterencode_dict(o, _current_indent_level):
File "/usr/lib64/python2.7/json/encoder.py", line 408, in _iterencode_dict
for chunk in chunks:
File "/usr/lib64/python2.7/json/encoder.py", line 408, in _iterencode_dict
for chunk in chunks:
File "/usr/lib64/python2.7/json/encoder.py", line 442, in _iterencode
o = _default(o)
File "/opt/cloudera/parcels/CDH-6.2.0-1.cdh6.2.0.p0.967373/lib/hue/desktop/core/src/desktop/lib/django_util.py", line 76, in default
return json.JSONEncoder.default(self, o)
File "/usr/lib64/python2.7/json/encoder.py", line 184, in default
raise TypeError(repr(o) + " is not JSON serializable")
TypeError: <desktop.appmanager.DesktopModuleInfo object at 0x7f54ba035310> is not JSON serializable

I have encountered this problem  too, has that problem been solved?

This should be fixed in latest Hues. 4.7 was released last week https://gethue.com/blog/hue-4-7-and-its-improvements-are-out/

Unfortunately, I also encountered this problem today. Is there any solution besides upgrading?


Setting layout_method='noise_adaptive' fails in generate preset passmanager

Environment

Qiskit version: 1.1
Python version:
Operating system:

What is happening?
pm = generate_preset_pass_manager(backend=backend,
                                  optimization_level=3,
                                  layout_method='noise_adaptive')

TranspilerError: 'Invalid plugin name noise_adaptive for stage layout'
but the docs say I can do it here https://docs.quantum.ibm.com/api/qiskit/0.43/qiskit.transpiler.preset_passmanagers.generate_preset_pass_manager
How can we reproduce the issue?
run above
What should happen?
it should work
Any suggestions?
No response

The noise adaptive layout method was removed in qiskit 1.0. The docs you linked were from qiskit 0.43 when it was a valid option.

Yeah, I just noticed that I was taken to a old version of the docs in the search.  Thanks


[HUDI-6434] Fix illegalArgumentException when do read_optimized read in Flink

Change Logs
when do read_optimized read in Flink on a table that contains log files only, illegalArgumentException will be threw；Actually we should get an empty set.
Impact
N/A
Risk level (write none, low medium or high below)
N/A
Documentation Update
N/A
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

Flink generate log files at the first data written on MOR, I'm puzzled with this as spark generate base file first, I want to know the consideration @danny0405

@hudi-bot run azure

I'm puzzled with this as spark generate base file first

Because Spark uses BloomFilter index, with wich a base file metadata is maintained for all the new inserts.

The test failure is located in hudi-utilities, should not be caused by this change: https://dev.azure.com/apache-hudi-ci-org/apache-hudi-ci/_build/results?buildId=18093&view=logs&j=9273dbcb-a208-5cd0-5541-8b9925cb3da0&t=55ef67e2-6f87-5746-60ad-7ddc97e935ed

I'm puzzled with this as spark generate base file first

Because Spark uses BloomFilter index, with wich a base file metadata is maintained for all the new inserts.

Can we align flink‘s logic to spark to generate base file on the first write, recently I use spark and flink to write to the same hudi table, some conflict occurs as the differents of the first write logic

No, Flink has not supportted BloomFilter Index yet.

First align flink‘s logic to spark to generate base file on the first write resolve many engine conflicts and makes logic consistent,
Second, the change will not affect flink's current functionality

You are right, for the first file of each data bucket, we can write parquet direcly.

The DeltaCommitWriteHandleFactory can be tweaked for the purpose, I'm wondering what's the engine conflicts you are talking about?

sry to reply late
engine conflicts:
v0.12.2 when spark insert overwrite a partition after flink write the log files only bucket in this partition,
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-client/hudi-client-common/src/main/java/org/apache/hudi/io/HoodieMergeHandle.java#L160 throws, but I found it was fixed in the master
other consideration:
If align the first create base file logic, many codes can be simplified, like:
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-client/hudi-spark-client/src/main/java/org/apache/hudi/table/action/commit/BaseSparkCommitActionExecutor.java#L362
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/action/compact/CompactionExecutionHelper.java#L63
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/table/format/mor/MergeOnReadInputFormat.java#L200
etc.
what's your opinion, looking forward to your reply

The DeltaCommitWriteHandleFactory can be tweaked for the purpose, I'm wondering what's the engine conflicts you are talking about?

sry to reply late
engine conflicts:
v0.12.2 when spark insert overwrite a partition after flink write the log files only bucket in this partition,
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-client/hudi-client-common/src/main/java/org/apache/hudi/io/HoodieMergeHandle.java#L160 throws, but I found it was fixed in the master
other consideration:
If align the first create base file logic, many codes can be simplified, like:
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-client/hudi-spark-client/src/main/java/org/apache/hudi/table/action/commit/BaseSparkCommitActionExecutor.java#L362
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/action/compact/CompactionExecutionHelper.java#L63
https://github.com/apache/hudi/blob/b95248e011931f4748a7a9fbb8298cbbb71bda88/hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/table/format/mor/MergeOnReadInputFormat.java#L200
etc.
what's your opinion, looking forward to your reply

That's true. Actually it is even more friendly for Hive query engine too, just a little late for 0.14.0 release because I'm scared for introducing protential bug, we can make the first file slice with parquets once we have enough test cases in production for backing up the confidence.

That's true. Actually it is even more friendly for Hive query engine too, just a little late for 0.14.0 release because I'm scared for introducing protential bug, we can make the first file slice with parquets once we have enough test cases in production for backing up the confidence.
Totally agreed, I modified the logic in my local envirment, seems tests works fine, should I submit a pr or wait for v0.14.0

That's true. Actually it is even more friendly for Hive query engine too, just a little late for 0.14.0 release because I'm scared for introducing protential bug, we can make the first file slice with parquets once we have enough test cases in production for backing up the confidence.

Totally agreed, I modified the logic in my local envirment, seems tests works fine, should I submit a pr or wait for v0.14.0

I would prefer we fix it after 0.14.0

ok


Separate headers

This change will let wasm2c use separate RT header files (and no actual runtime for now) in no-sandbox mode.
Floating point operations are still missing.
But the result lets us successfully compile, e.g., the gzip benchmark from specint2000.
The new arrangement of included headers avoids pulling in system libraries to avoid type conflicts between wasm2c-generated function signatures and the original signatures in those header files.

Let's merge this for now and then iterate further, fleshing out the headers and various bits and pieces, as needed.


Fix thread safety analysis warning from new Clang version

The TlsSessionKeyLoggerCache constructor is annotated with
  ABSL_EXCLUSIVE_LOCKS_REQUIRED(g_tls_session_key_log_cache_mu)

and in TlsSessionKeyLoggerCache::Get it gets called indirectly by:
  grpc_core::MutexLock lock(g_tls_session_key_log_cache_mu);
  ...
  cache = grpc_core::MakeRefCounted<TlsSessionKeyLoggerCache>()

New Clang versions started to analyze the constructor call in
grpc_core::MakeRefCounted, and since it cannot reason across function
boundaries it does not know that the lock is held at that point:
  ../../third_party/grpc/src/src/core/lib/gprpp/ref_counted_ptr.h:335:31:
  warning: calling function 'TlsSessionKeyLoggerCache' requires holding mutex
  'g_tls_session_key_log_cache_mu' exclusively [-Wthread-safety-analysis]
    return RefCountedPtr<T>(new T(std::forward<Args>(args)...));
				^
  ../../third_party/grpc/src/src/core/tsi/ssl/key_logging/ssl_key_logging.cc:121:26:
  note: in instantiation of function template specialization
  'grpc_core::MakeRefCounted<tsi::TlsSessionKeyLoggerCache>' requested here
	cache = grpc_core::MakeRefCounted<TlsSessionKeyLoggerCache>();
			   ^
  1 warning generated.

This change avoids the warning by calling the constructor directly.

@markdroth It seems I am not allowed to merge this PR...it says "The base branch restricts merging to authorized users...You’re not authorized to merge this pull request.".
Does the access setup change in the past few months?

The repo is locked right now due to test flakiness.  We'll unlock it when we've addressed the flakes.

This change can't affect flakiness and it blocks updating a compiler update in Chromium. Any chance you could merge this change now?


Some Improvements

Fixed the gh search to support Github Search syntax.
Support different TTL for the cache of repo/org/pull
Add an option that search all the PR you are involved (regardless the organisation)
Parameterise the actions in the workflow.
Support fetching multiple pages when caching user_repo, org, pull_request

@edgarjs any more comment I can help with?

Thank you for your changes @ileodo. They have been merged and published in 3.1.0


Onboarding Slides for Apollos

Acceptance Criteria

[ ] It should [SPEC_DETAIL]

Context
Given [CONTEXT] when [ACTION] then [RESULT]
UI Screenshot or Wireframe (optional)

@FrankGrand I don't remember what this issue is for?

@IsaacHardy  This is to add the 'onboarding slides' to Apollos for first time app opens.

Needs new assets from design to reflect Apollos UI changes.

@burkeshartsis or @conrad-vanl Do we have components to build out a slider for this already? What if we used something like https://github.com/Jacse/react-native-app-intro-slider?

Yeah @richarddubay, that could work. We do have a horizontal slider in the app, but it's a little different.


ctrlf-search-history : make persistent?

It would be nice to have ctrlf-search-history persistent across emacs sessions. Maybe "prescient"? Or can you recommend a third party package to enable this?

savehist-mode takes care of this. closed.

savehist-mode takes care of this. closed.

Seems like a nice pointer to add to the README, if someone so desires.

Seems like a nice pointer to add to the README, if someone so desires.


Upgrade lager version to 2.2.0

Please don't merge this. I just committed #21, so if you want to pin to 2.2.0 at least rebase off master.

@mrallen1 I was trying to disrupt as little as possible by sticking to the 2.1 branch.  Are you wanting me to take all of master over to 2.1 as well?

Ah, I didn't notice the merge target. nvm :hushed: Sorry for the noise.

+1 ce8b587


Check for non-permissive licences in CI

Non-permissive open source licenses such a GPLv2 in dependencies cause a level of confusion as to whether they require websites to make their source code available. Because of the grey-area, we should ensure there are no non-permissive licences in any of our dependencies.
TinyMCE 7 switched from an MIT license to a GPLv2 license. While it would be unexpected for a dependency to chance its licence in a minor release, and we do use ^ carets for our dependencies, we have less visibility over dependencies of dependencies which could more easily go up majors with no input from our side.
Because of this we should add a CI logic in sink that validates there are no non-permissive (i.e copyleft) opensource licences in the installed dependencies
After merging create a new 1.3 branch and manually release 1.3.0
Notes

https://www.npmjs.com/package/license-checker could be used for npm dependencies
It may make sense to check composer deps in sink, and npm deps in individual modules

Acceptance criteria

[ ] A list of non-permissive licenses is created
[ ] New CI logic runs looking for non-permissive licenses
[ ] The entire build will fail if this logic fails so that we have visibility of it in rhino
[ ] This logic runs for all supported versions of Silverstripe
[ ] All installed composer and npm dependencies are checked i.e. the root composer.lock and every package.lock e.g. admin, asset-admin, etc

PRs

https://github.com/silverstripe/gha-run-tests/pull/44

Note that some packages may come with multiple licenses, e.g.
https://github.com/nette/schema/blob/2073a5a4156aa8f2849f2e81e2b743f338ed3f45/composer.json#L6
In those cases so long as an appropriately permissive license is available, the CI job should not fail.

My bad, sorry

PRs merged


Jacoco HTML report displays wrong "created with" version

To summarize the issue, the toolVersion setting is not respected, such that the generated report shows that it was created by a different version of JaCoCo. I also posted this on the JaCoCo project. It it not clear if this is a JaCoCo defect or a Gradle Plugin defect.
Expected Behavior
Generated report should show "Created with JaCoCo " (in this case <IP_ADDRESS>602180812)
Current Behavior
Generated report shows this Created with... text but it is for a newer version than specified in the plugin. (in this case <IP_ADDRESS>905082037)
Context
We validate all the software we use in our projects, and although we configured our project with the validated version, the output causes confusion - is the expected version used? These are questions we need solid answers or fixes for.
Steps to reproduce

Configure Gradle such that jacoco plugin toolVersion is set to <IP_ADDRESS>602180812 and the JaCoCo classpath is set to the same. This will look something like:buildscript {
    repositories {
    maven {
        url = 'https://maven.google.com/'
    }
    jcenter()
    google()
    }
    dependencies {
        classpath 'org.jacoco:org.jacoco.core:<IP_ADDRESS>602180812'
    }
}
apply plugin: 'jacoco'
jacoco {
    toolVersion = '<IP_ADDRESS>602180812'
}

Create a task of type JacocoReport to configure the inputs:afterEvaluate {
    project.task([type: JacocoReport], 'jacocoTestReport') {
        group 'verification'
        dependsOn ['test']
        reports {
            xml.enabled = true
            html.enabled = true
            csv.enabled = true
        }

        sourceDirectories = project.files(project.java.sourceSets.main.java.srcDirs)
        classDirectories = project.files(project.fileTree(dir: project.javaCompile.destinationDir, excludes: jacocoFileFilter))
        executionData = project.files(project.fileTree(dir: project.buildDir, includes: ['jacoco/*.exec''])
    }
}

Run the jacocoTestReport task created above

Your Environment

Windows 10
Gradle 5.6.2

Hi I'm running into a similar problem like this and in my case it seems like Jacoco settings within gradle are being ignored. I have way of reproducing it, it is simple enough. You will need the following setup (may be reproducible with some variance):

Windows 10 10.0 amd64
Android Studio 4.1.1
Gradle 6.7
Kotlin 1.3.72
Groovy 2.5.12
Ant Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM 15.0.1 (Oracle Corporation 15.0.1+9-18)

Create a new project in Android Studio and select Kotlin as a language.
Setup Jacoco following the gradle guide
Have either a phone connected / emulator running, ready to be used for instrumented tests.
In the the terminal run:
gradlew createDebugCoverageReport
Wait until the report gets generated (running with no tests)
Check if the 'Created with JaCoCo' on the bottom right of the report matches what is defined within build.gradle


Jinja2 v3

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Bump Jinja2 major version to 3, following https://github.com/cylc/cylc-flow/pull/4877

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.

(Note version or build number not tweaked here, as yet).

Converting to a draft to be on the safe side...

FYI we dropped the idea or raising PRs to the feedstock repo for dep changes. The PR templates now tell you to update setup.cfg (and conda-environment.yml if present) on the repo. Updating deps on the feedstock is now part of the release process.
Why we dropped PRs:

You end up with multiple PRs which all have to be merged with the release branch.
Testing doesn't make sense and will likely fail because CI is running against the older release.
We need to check deps match at release time anyway.


[Urgent] add MIT license

WHAT DOES THIS PR DO?

Adds the MIT OSI license
An open source initiative license is needed needed on any repo that will participate in Google Summer of Code.

ARE THERE ANY RELATED PRs?

https://github.com/airqo-platform/AirQo-frontend/pull/1033

@Baalmart @sserurich @Priscilla-AL
Please review this license


Introduce configurable delay

Added following parameters to RouterConfig

MinDelay
MaxJitter

Added a test for delay feature
Resolves #30

Codecov Report

Merging #31 into master will increase coverage by 0.05%.
The diff coverage is 83.33%.

@@            Coverage Diff            @@
##           master     #31      +/-   ##
=========================================
+ Coverage   81.74%   81.8%   +0.05%
=========================================
  Files          15      15
  Lines        1386    1407      +21
=========================================
+ Hits         1133    1151      +18
- Misses        174     177       +3
  Partials       79      79

Impacted Files
Coverage Δ

vnet/router.go
78.34% <83.33%> (+0.66%)
:arrow_up:

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 27a0614...01ef117. Read the comment docs.

@Sean-Der If you could review my changes per your feedback, that would be appreciated.


Bootstrap 4 custom templates still required?

With bootstrap 4 about to go to beta imminently.. it seems a good point to check whether some earlier workaround fixes for the earlier alpha stages are still required..
the custom bootstrap templates look to have been fixed upstream in django crispy forms.
Can these now be removed?
The css fix for the navbar, is this now also redundant?

@yunti we welcome contribution efforts of all sorts to help us keep the project up-to-date with the modern ecosystem. If you feel the capacity to implement the proposed changes feel free to send a PR. It will be reviewed by the Core team once we have time.


Using boost.mysql in dynamic libraries may cause crashes

Triggered an unprocessed exception: write access permission conflict.
N is null ptr.

There will not be such issues when using in a static library.

I am very confused and hope to receive an answer.

A possible cause for your problem is having different versions of your libraries in the DLL you're building and in your main. Check that:

You're using the same standard library for both your main and your DLL. MSVC comes with different standard library versions that are not compatible with each other.
You're using different configuration switches for your main and your DLL. For instance, defining a BOOST_ASIO_XXXX macro on one, and not the other.

If that doesn't solve the problem, I'd need more information to investigate.

Any news on this? Was the issue solved?

Closing this now.


Query params are defined as any

Expected Behavior
I would expect anything defined with a zod schema to be defined per that schema, such as in the zsa library.
Actual Behavior
Currently, using the code below, invoicePath comes out as any despite it being defined as a string in my schema.
Steps to Reproduce the Problem
import { createSafeRoute } from 'next-safe-route';

import { z } from 'zod';

const querySchema = z.object({
	invoicePath: z.string(),
});

export const GET = createSafeRoute()
	.query(querySchema)
	.handler(async (_, context) => {
		const { invoicePath } = context.query;
		...
	});

Specifications

Version: 0.0.19
Platform: NextJS 14.2.5
Subsystem: N/A

@bduff9 Hey, just released v0.0.20, could you check if this is still an issue? Thanks!


wip remote

Do you have anything else to add here? Maybe we can close this one.

Actually not now. I have made another PR with added .proto file. Want to start using protobuf messages instead defined types and then continue to work with remote.


Using tt_lib.tensor.transpose on q_heads and k_heads sharded on L1 is failing

Describe the bug
Using tt_lib.tensor.transpose on q_heads and k_heads sharded on L1 is failing
To Reproduce
git checkout 912cf343a1610609daa31f7ea95fd455b06a71b1
Run this file: https://github.com/tenstorrent-metal/tt-metal/blob/model-team/llama2-sprint/models/demos/llama2_70b/tests/perf/test_llama_attention_optimized.py
with this command:
pytest -svv  models/demos/llama2_70b/tests/perf/test_llama_attention_optimized.py::test_LlamaAttention_inference[BFLOAT16-DRAM-llama-2-70B-32-1-0.98-8]
Comment out line 256-261 where we put qheads and kheads back to DRAM.
Or create a tensor with below shape, dtype and memory layout and transpose dim 1 and 2.
-> q_heads = tt_lib.tensor.transpose(q_heads, 1, 2)
(Pdb) q_heads.shape()
Shape([1, 8, 32, 128])
(Pdb) q_heads.dtype()
<DataType.BFLOAT16: 0>
(Pdb) q_heads.memory_config()
tt::tt_metal::MemoryConfig(memory_layout=TensorMemoryLayout::HEIGHT_SHARDED,buffer_type=BufferType::L1,shard_spec=tt::tt_metal::ShardSpec(shard_grid={[(x=0,y=0) - (x=7,y=0)]}, shard_shape={32, 128}, shard_orientation=ShardOrientation::ROW_MAJOR, halo=false))

(Pdb) k_heads.shape()
Shape([1, 1, 32, 128])
(Pdb) k_heads.memory_config()
tt::tt_metal::MemoryConfig(memory_layout=TensorMemoryLayout::HEIGHT_SHARDED,buffer_type=BufferType::L1,shard_spec=tt::tt_metal::ShardSpec(shard_grid={[(x=0,y=0) - (x=0,y=0)]}, shard_shape={32, 128}, shard_orientation=ShardOrientation::ROW_MAJOR, halo=false))

Expected behavior
FAILED models/demos/llama2_70b/tests/perf/test_llama_attention_optimized.py::test_LlamaAttention_inference[BFLOAT16-DRAM-llama-2-70B-32-1-0.98-8] - RuntimeError: TT_FATAL @ tt_eager/tt_dnn/op_library/pad/pad_op.cpp:543: input_tensor.memory_config().memory_layout == TensorMemoryLayout::INTERLEAVED
E           RuntimeError: TT_FATAL @ tt_eager/tt_dnn/op_library/pad/pad_op.cpp:543: input_tensor.memory_config().memory_layout == TensorMemoryLayout::INTERLEAVED
E           info:
E           Pad does not currently support sharding
E           backtrace:

FYI @caixunshiren @cglagovich @mtairum

A few questions:
What do you want/expect the sharding to be after the transpose?
Do you expect the output to be in RM layout, or padded to tile?

@kevinmiTT11 is this still an issue?

@tarafdarTT No are not block by this anymore

@kevinmiTT11 can I close then?

probably still a bug but not blocking since we moved to another implementation, would be nice to support padding a sharded tensor? So P3 might be a good tag for it.


allow spectrumlike from bins to understand tstart and stop

The writing of PHAs and creation of plugins from time series was not properly keeping track of time. It has been fixed

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@a0db679). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #249   +/-   ##
=========================================
  Coverage          ?   75.92%
=========================================
  Files             ?      136
  Lines             ?    14652
  Branches          ?        0
=========================================
  Hits              ?    11125
  Misses            ?     3527
  Partials          ?        0


Added special semantic coloring for consts, readonly properties, and enums.

This PR depends upon https://github.com/jdinhify/vscode-theme-gruvbox/pull/80 because it requires semantic highlighting to be enabled.
The examples below demonstrate the changes to how constant/read-only tokens are colored. This is similar to how the modern built-in VS Code themes behave. Implementation taken from the Dark+ built-in theme. Colors taken from the original Gruvbox palette.
Before

After

@kronodeus looks like the change to overall semantics token in #83 affected how these look.
Could you please have a look again and see if you want to readjust 🙏
A suggestion is that try to use brighter colours to provide more contrast, the dark blue on dark background seems a bit lacking in contrast and make it somewhat hard to read as the result.
Bright colours for dark theme below
red2 fb4934
green2 b8bb26
yellow2 fabd2f
blue2 83a598
purple2 d3869b
aqua2 8ec07c
orange2 fe8019


[Bug] Variable content is not shown if WITH statements are used

Describe the bug
When debugging code that is part of a 'WITH Record' statement, the field values of the referenced record are not shown while hovering the field, although they are listed in the variables tab.

Versions:

Unfortunately this is a lack from the Debug Adapter Protocol that we use to communicate with the Debugger Client in VsCode.
I have requested an enhancement. Let's see how far we get with that.
https://github.com/microsoft/vscode-debugadapter-node/issues/137


Lowercase clouddns solver key

Per the latest cert-manager, the cloudDNS solver key should be lowercase.
Signed-off-by: Suhaib Malik<EMAIL_ADDRESS>

@wallrj I'm not tracking. It shows json:"cloudDNS,omitempty". The example in the documentation shows clouddns.

Are we talking about this page: https://cert-manager.io/docs/configuration/acme/dns01/google/

The correct key name is cloudDNS.

This PR was changing the example YAML, rather than the clouddns in the introductory sentence.
The example YAML is correct.

@wallrj Just checked against my own deployment, the current is correct; my mistake.


HTML5 text artifacts for pixel fonts

When targeting HTML5, there are artifacts around zoomed-in text, but only on some devices. I've updated to the latest files from this repository and the issue persists.
https://community.openfl.org/t/html5-text-artifacts/13514
https://community.openfl.org/t/html5-blurry-font-issue/12712/6
One one computer, the text renders normally:

On another computer, it renders with visual noise:

It may have to do with HiDPI settings (values > 1) and possibly for just pixel fonts, but I am uncertain. I'm willing to test any changes or suggestions!

I'm not sure but;
I guess while OpenFL draws better on high resolution screens; It draws worse on low resolution screens.

The text is still blurry even with the new PR, but only on Chromium-based browsers. Firefox scales things smoothly, but there's a heavy blur with Chrome:

Within CanvasTextField, the new code dynamically sets the scale as follows:
var pixelRatio = (renderer.__pixelRatio > 1) ? (renderer.__pixelRatio * 2) : renderer.__pixelRatio;
However, with a pixelRatio of 1, Chrome still is applying some kind of upscaling and resulting in the image above. When I try setting the CanvasTextField to instead use var pixelRatio = 3;, the text no longer had any artifacts at any scaled resolution.

I'm not sure why "3" seems to be the magic number, as anything less than that is still blurry in Chrome and anything more is overkill. I'm happy to hear any thoughts on this.

Are you sure the problem is not the font?

Yes, it's like that with every font

Also, something to note - when resizing the page in the browser, the texts resolution stays the same - the means upscaling the page will make text look really low quality.
Thought I'll mention this because it might be related to the same problem

Yes, I've tried a couple different pixel fonts and they all exhibit the problem with the pixelRatio. What further complicates things is that each browser upscales differently and there are further differences depending on which OS the browser is running and the display type (Retina / HiDPI).
Here are the results for different pixelRatio tests on Chromium-based browsers on Windows:
pixelRatio = 1

pixelRatio = 2

pixelRatio = 3

The minimum scale that smooths out scaling artifacts for blocky fonts is a value of 3. In the first version, you can see artifacts on both sides of the text glyphs. With a scale of 2, you can see it smooths out one side but there is still an scaling problem on the other. When scaling to 3, both sides are smoothed out and the text renders with crisp edges.
I think allowing the user to pass a compiler flag, something like openfl_crisp_text, to render text with crisp edges is a possible solution. Within CanvasTextField, I added the new define:
...
if (textField.__dirty || graphics.__softwareDirty)
{
            #if openfl_crisp_text
            var pixelRatio = 3;
	    #elseif (openfl_disable_hdpi || openfl_disable_hdpi_textfield)
	    var pixelRatio = 1;
            #else
            var pixelRatio = renderer.__pixelRatio;
	    #end

	    var width = Math.round(graphics.__width * pixelRatio);
            var height = Math.round(graphics.__height * pixelRatio);
...

With this code, adding the define openfl_crisp_text forces the text to render with sharp edges on all platforms I tested. These include Windows (Firefox, Chrome), macOS (Firefox, Chrome, Safari) and macOS with Retina display (Firefox, Chrome, Safari).
Does this sound like an acceptable fix or should we go a different direction?

Just wondering - after a window resize, is the text still crisp?
(resizes with ctrl +/-)

Just wondering - after a window resize, is the text still crisp?
(resizes with ctrl +/-)
Zooming with the browser did not affect the text blur or other graphics.

The main issue with text specifically is that the actual graphic texture is being stretched out and when relying on Chromium's renderer, it creates a streaking effect on either side of the text. You can see the problem happening here as well: https://community.openfl.org/t/html5-blurry-font-issue/12712


Hwo to get fullpath?

I get only a relative path (in getattr & write operations 'path' argument), so when I try to copy file NOT FROM the myfuse.py run directory, I get runtime errors..
How can I pass a fullpath argument, so that proper file copy can be held?

@paulo-raca Thanks, it was my bad - I was using fullpath for os.stats(fullpath) - it needs absolute path of file.
BTW, is there any way to get the file stats from data param? Couldn't find any other way to get them..


Enum values are not checked when using sqlite driver

When using the sqlite driver:
var model = db.define('MyModel', {
  thing: { type: 'enum', values: ['myValue'], required: true }
});

model.create({ thing: 'invalidValue' }, function (err, created) {
  // This succeeds... but it shouldn't
});

I realise that enum types are not available in SQLite – but surely the ORM should be verifying it, not the driver!

I whole heartedly agree. There are other problems with the current enum situation - namely that once created they can be difficult to change or drop.
I use a different approach alltogether:
THINGS = ['cat', 'dog']

# properties
thing:                    { type: 'text', defaultValue: 'cat',  required: true  }
# validations
thing: orm.validators.insideList(THINGS, "Invalid thing")

It's much easier to work with and I don't have so many columns in the table for space to be a problem.


Add docs to wheel_slip_parameters_cmd.proto

🦟 Bug fix
Fixes https://github.com/ignitionrobotics/ign-msgs/pull/205#discussion_r823099955.
Summary

Add docs to wheel_slip_parameters_cmd.proto.
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[x] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

Merging with a failing ABI checker because the first version of the message hasn't been released yet.

This pull request has been mentioned on Gazebo Community. There might be relevant details there:
https://community.gazebosim.org/t/new-ignition-releases-2022-03-25-fortress-edifice-citadel/1343/1


what's the difference brtween depth raw and aligned depth?

Hi, to start realsense camera there some launch files, just want to what is the difference between the demo_depath.launch and the aligned_depth.launch?
Should I just using aligned depth rather the raw? does they have big differences.

@doronhi I noticed that with new librealsense-2.18.1 and realsense-2.1.4 ros, camera/color/image_raw is aligned with camera/depth/image_raw_rect but not with camera/alignedalinged_depth_to_color/image_raw ? Do you have any idea about why ?

I assume the times in your graph show the published time and not the timestamp in the messages header.
realsense2_camera is built on top of librealsense. librealsense's syncer synchronizes the images from the depth sensor and the color sensor, therefor they are published on the same time.
aligned_depth_to_color (or to any other sensor) requires some extra work at is published a bit later. It has the same time stamp in its header as the original images it is based on.
You can check out the code in base_realsense_node.cpp, function publishAlignedDepthToOthers.

@doronhi Thank you.


gelu tanh approx

Proposed changes
add tanh approximation for gelu function to match the implementation in torch and jax
Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING document
[x] I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have updated the necessary documentation (if needed)

This is nicely done @gathierry but as discussed I don't think we need yet another gelu approximation.
If you are able to show some numerical differences from your pretrained model usign the different gelus that would be very interesting. If it is in fact noticeably smaller for the tanh approximation perhaps we could replace the fast approximation with it.


Document comment widget obscures find widget

VS Code Version: 1.43.0
OS Version: Windows 10

The document comment widget obscures the editor find widget. They both have z-index of 10. I think the find widget should be higher.


Add a route to catch "404 Not Found" errors

There is no need for this. Slim throws HttpNotFoundException if no route is matched when routing has been performed.

CORS Pre-Flight route break Slim default behavior. Now you get 405 Method not allowed. Must be one of: OPTIONS instead of 404 Not found if no route is matched.

@AntoninoM90 I guess @l0gicgate didn't think about that behaviour which @eugene-borovov explained, you could make a new PR. But I'm also not very sure about this catch either because then you'd get 404 instead of 405 for other routes where you really should get 405. So I think I'd make some checking and open a new PR here and for the docs which checks if it return 404 or 405 depending on if the allowed route is OPTIONS or something else.


Add Task Completion status to UI

TODO
The Task object should be made immutable - so that this will be updated
Closes #62
Closes #61

Codecov Report
Base: 39.82% // Head: 40.04% // Increases project coverage by +0.22% :tada:

Coverage data is based on head (02cda0f) compared to base (3c747b4).
Patch coverage: 0.00% of modified lines in pull request are covered.

:exclamation: Current head 02cda0f differs from pull request most recent head 0096a96. Consider uploading reports for the commit 0096a96 to get more accurate results

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #112      +/-   ##
============================================
+ Coverage     39.82%   40.04%   +0.22%
- Complexity      452      532      +80
============================================
  Files           137      131       -6
  Lines          2541     2934     +393
  Branches        323      405      +82
============================================
+ Hits           1012     1175     +163
- Misses         1463     1679     +216
- Partials         66       80      +14

Impacted Files
Coverage Δ

src/main/java/seedu/address/ui/TaskListPanel.java
0.00% <0.00%> (ø)

...java/seedu/address/logic/commands/RootCommand.java
33.33% <0.00%> (-16.67%)
:arrow_down:

...java/seedu/address/logic/commands/FindCommand.java
11.11% <0.00%> (-8.89%)
:arrow_down:

...ava/seedu/address/logic/commands/ThemeCommand.java
16.66% <0.00%> (-8.34%)
:arrow_down:

...a/seedu/address/logic/commands/AddLinkCommand.java
8.69% <0.00%> (-6.69%)
:arrow_down:

...a/seedu/address/logic/commands/AddTeamCommand.java
8.69% <0.00%> (-6.69%)
:arrow_down:

...eedu/address/logic/commands/DeleteTaskCommand.java
9.09% <0.00%> (-6.30%)
:arrow_down:

...du/address/logic/commands/DeleteMemberCommand.java
9.09% <0.00%> (-6.30%)
:arrow_down:

...java/seedu/address/logic/commands/EditCommand.java
14.28% <0.00%> (-5.72%)
:arrow_down:

...seedu/address/logic/commands/AddPersonCommand.java
8.82% <0.00%> (-5.47%)
:arrow_down:

... and 47 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.