Onyx Bump 2.0.44: null -> undefined changes

@mountiny
Details

~Requires https://github.com/Expensify/react-native-onyx/pull/556 to get merged first!~
Part of the Onyx bump to 2.0.43 in https://github.com/Expensify/App/pull/42772
This PR applies all the changes needed to work with Onyx version 2.0.43. This will be mostly changing types, default values and null-handling for output by Onyx.
Fixed Issues

$
PROPOSAL:
Tests

[ ] Verify that no errors appear in the JS console

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@mountiny this should be ready for review! can we trigger QA on this?
(Note that i had to create the PR in our margelo E/App fork, because both branches or on this fork

can we trigger QA on this?

If not, i can create a combined PR, with all the changes (also from the base branch) so we can trigger QA, but still review separately

Looks we have some unrelated commits, can you clean those up?

Looks we have some unrelated commits, can you clean those up?

@s77rt done! :)

Report screen empty
https://github.com/margelo/expensify-app-fork/assets/16493223/0e43a400-7c82-4295-9f60-4c897fbb8dd6

On first render the header is missing
https://github.com/margelo/expensify-app-fork/assets/16493223/99e0cadc-8dc1-4ff3-9ae6-e8a053f8181e

First time submitting an expense getting an empty view
https://github.com/margelo/expensify-app-fork/assets/16493223/df6daa6f-a47c-4228-b1f3-57b73f89f84a

Emoji suggestion not working
https://github.com/margelo/expensify-app-fork/assets/16493223/adee3eb2-5835-43d1-9ebd-911f9b0fc7b5

Infinite loader on attachments and not loading in chats
https://github.com/margelo/expensify-app-fork/assets/16493223/9da68ebc-017a-4e50-943d-53540b88b97e

Fixing these issues in https://github.com/Expensify/react-native-onyx/pull/558

First time submitting an expense getting an empty view

Also fixed by the same change in https://github.com/Expensify/react-native-onyx/pull/558

Emoji suggestion not working

fixed!

Empty report on refresh
https://github.com/margelo/expensify-app-fork/assets/16493223/e02f91d8-6565-4a0a-89ec-d016455e28a5

Do we need to wait for https://github.com/Expensify/react-native-onyx/pull/558?

Do we need to wait for Expensify/react-native-onyx#558?

Yes, you continue doing QA on this PR, but please check out the changes from https://github.com/Expensify/react-native-onyx/pull/558? in react-native-onyx and link them locally.
You can do so, by running npm run build:watch in Onyx and run npx link publish <path_to_onyx> once in E/App

Also, once you applied the new changes from Onyx, please make sure to logout from E/App once, since some changes will only apply after the DB was cleared on log-out

After applying the onyx changes I'm not able to login (no request is sent to the server)
https://github.com/margelo/expensify-app-fork/assets/16493223/34766205-e770-421d-80bf-6f8d1a9ef76c

@s77rt I just applied the new onyx changes too, I think the login issue is due to some recently reported performance issue on BE side, see incident and more details on https://status.expensify.com.

[!note]
I'm also awaiting the performance issues to be solved so I can continue testing.

The login bug is a FE bug. The NetworkStore.hasReadRequiredDataFromStorage() promise is never resolved
https://github.com/margelo/expensify-app-fork/blob/a04f40e09e6a933488957b7f6300edd6290c1ebd/src/libs/Network/NetworkStore.ts#L33-L43

After onyx changes the report screen is empty all the time
https://github.com/margelo/expensify-app-fork/assets/16493223/d90389b4-6577-41ca-9e74-55d4b50ebd97

First time submitting an expense getting an empty view

Also fixed by the same change in Expensify/react-native-onyx#558

I can still reproduce this one

I commented out the early return mentioned in https://github.com/margelo/expensify-app-fork/pull/20#issuecomment-2148589255 in order to be able to login.

After onyx changes the report screen is empty all the time

This is not reproducible on my side:
https://github.com/margelo/expensify-app-fork/assets/56457735/568c8cfd-a1f4-4a7a-9162-13b4773319a0
The only thing I did differently (probably) is that when I was logged-out I cleared all the keys in onyx indexed db, then performed login as mentioned above.

Continuing testing...

Re-tested previously triaged ⚠ issues from https://github.com/Expensify/App/pull/42057#issuecomment-2118617952:
✅ Web - Chat - URL is not hyperlinked on chat composer
Still fixed, not reproducible!
⚠ Web - Receipt - Delete receipt is not displayed
While the Delete receipt button does show-up, the issue now is that after the date is changed (step 9.), revisiting the receipt attachment modal now shows page not found:

Video
https://github.com/margelo/expensify-app-fork/assets/56457735/72bf86eb-9661-44b4-87f9-fc807c82cc5c

✅ Web - Receipt - Its not here page is displayed when trying to replace a receipt
Still fixed, with the mention that given the same steps as above, when revisiting the receipt we still see the page not found in the attachment modal. But the Replace receipt works correctly, opening the RHP with the upload receipt UI.
✅ Web - Distance - Distance receipt only shows the map
Still fixed, not reproducible!
✅ Category - Keyboard navigation in category list is blocked when there is Recent section
Still fixed, not reproducible!
Note: Fixed by commit https://github.com/Expensify/App/pull/42057/commits/e7e73c8e1c5fea51fc7d5d626afe066b007325c1.

cc @chrispader @mountiny
Tomorrow I'll continue working on the 2nd action mentioned in Slack 🧵:

Dive into the code and take note of the components where null -> undefined change was made and check the parts of the app where these components live in order to test for bugs.

@s77rt are you sure you checked-out the changes from https://github.com/Expensify/react-native-onyx/pull/558 and they are linked correctly locally?
I'm pretty sure these issues should be fixed with the latest Onyx changes and @ikevin127 seems to not repro them either

@s77rt I just applied the new onyx changes too, I think the login issue is due to some recently reported performance issue on BE side, see incident and more details on https://status.expensify.com.

After applying the onyx changes I'm not able to login (no request is sent to the server)

I can confirm this as well, I even cleared the onyx storage completely and sometimes I get the Another login page is open. instead of the login input field:

Fixed!

@s77rt i fixed the login issue, but i cannot reproduce the rest of your reported issues.
Are you sure you checked out the Onyx changes from https://github.com/Expensify/react-native-onyx/pull/558 and linked them locally using npx link publish <path_to_onyx>?

@ikevin127 @s77rt the changes from https://github.com/Expensify/react-native-onyx/pull/558 should only be applied to this specific PR btw.
https://github.com/Expensify/App/pull/42772 can be tested as-is.

@chrispader I'm still facing same issue. For onyx I have switched to the @chrispader/fix-onyx-bump-fixes branch and linked correctly. I have also added a console log to verify I'm using the local onyx.
https://github.com/margelo/expensify-app-fork/assets/16493223/b98a0c44-e472-4c22-a4db-735ef7cd2f5e

@s77rt Try logging out, deleting all keys in Inspect > Application > IndexedDB > OnyxDB > keyvaluepairs and refresh the login page after doing that. Now login normally and you should not get the empty report screens anymore (that's what worked for me).

@ikevin127 @s77rt i just changed a lot of parts of the app and this (☝🏼) is actually what fixes a lot of issues. For me, everything works fine now. Please continue with QA and let me know if there are any other issues.
When we deploy this Bump PR, it would probably be best to force a sign-out for all users and clear the database, because a lot of data might be stale (null values in storage instead of undefined) which might cause problems.

✅ Issues reported by other testers and triaged as fixed:

[x] On first render the header is missing
[x] First time submitting an expense getting an empty view
[x] Emoji suggestion not working
[x] Infinite loader on attachments and not loading in chats
[x] Empty report on refresh
[x] Not able to login (no request is sent to the server)

⚠ Issues found today during overall app testing:

[!important]
All these were cross-tested on latest staging (v1.4.79-10) where none of them are reproducible.
They only occur on this PR with the https://github.com/Expensify/react-native-onyx/pull/558 changes applied as per https://github.com/margelo/expensify-app-fork/pull/20#issuecomment-2148402604.

[ ] Nested Thread back button navigation shows Hmm... it's not here page
Component source: ThreadDivider.tsx
Steps:

Navigate to a report and post a message.
Hover over the sent message and press Reply in thread.
Post a message within the thread.
Repeat step 2 and 3 such that you have a 3-level nested thread.
Navigate to the 2nd or 3rd level of the thread and press on the  button such that you're navigated back out of the nested thread.

Expected result: We're navigated back out of the nested thread of which  button we pressed.
Actual result: We're shown the Hmm... it's not here - You don't have access to this chat report screen.

Video
https://github.com/margelo/expensify-app-fork/assets/56457735/8a578a83-b930-431e-b3a6-c3ea71cc9e03

To be continued...

Tested again and now I'm seeing the report but the header is gone

Can you merge Onyx:main into margelo:@chrispader/fix-onyx-bump-fixes

The submit expense to a user is still empty in my testing

The split details too

@chrispader That's a great find! Indeed that was the issue!

At the moment it seems all issues with this PR are resolved. @mountiny
@s77rt issues are fixed by the instructions in the last comment
The "Going back on threads" issue reported by @ikevin127 is also reproducible on staging, as in https://github.com/Expensify/App/issues/43172
I'm gonna wait for further testing results from you guys, until then i'm gonna focus on some other tasks.

Been testing this for a while didn't find any bug yet


feat(map_based_prediction): enable lane change detection from unconnected lane

Description

TL;DR

Currently map based prediction can not generate lane change detection paths from unconnected lane(cf. see the figure below)
This PR enable to predict lane change to unconnected adjacent lane

Paths changing from the forward lane to the opposite lane are not predicted now
Therefore, cases in which the driver once moves out into the opposite lane to avoid on-street parking, etc., are not included.

Background
Current prediction path generation for on-lane object is summarized as follows:

Extract left/right/center lanelets and paths
Calculate lane change probability
Generate actual paths for possible paths

in this part.1 uses left() function, which can only get connected left lane. Also, adjacentLeft can only get same direction lane, so that we need to extract opposite lane manually. (cf. see https://github.com/fzi-forschungszentrum-informatik/Lanelet2/issues/147)
Provided algorithm flow

get left/right lanelet to create a candidate path
if left/right lanelet is empty, try to get adjacentLeft/adjacentRight lanelet
if all above are empty, try to get opposite lane

if object is trying to change lane to opposite lane, do not predict that

Links

TIER IV internal tickets

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@YoshiRi
It seems it does not work well with kashiwanoha and odaiba map.

@takayuki5168
Thanks for your check. Did it checked by the scenario simulator or psim? May be I can try with psim by myself.

@YoshiRi psim

This trouble caused by missed current lanelet estimation. This is solved in https://github.com/autowarefoundation/autoware.universe/pull/3007/commits/bb28db7afe772b28650c7e4952569567adc83be9.

@YoshiRi
When spawning the car with the k button on the planning simulator as follows, the predicted path is wired.

The path on the opposite lanelet appears which is not expected.

and its path end is unstable
and it does not have confidence.

Also on the terminal, the warning [WARN<PHONE_NUMBER>.720588538] [BigVehicleTracker]: Cannot update (measureWithPose():343) is always output when the obstacle is running.

@takayuki5168 @miursh @tkimura4 @purewater0901
this is just a friendly reminder that this PR is not active for more than 1 week.

@YoshiRi This feature was merged into main with another PR. Could you close the PR if it's okay?


Couldn't add dependency by sbt

by adding libraryDependencies += "ing.wbaa.druid" %% "scruid" % "2.1.0"
Get this error
(update) sbt.librarymanagement.ResolveException: unresolved dependency: ing.wbaa.druid#scruid_2.12;2.1.0: not found
[error] (ssExtractDependencies) sbt.librarymanagement.ResolveException: unresolved dependency: ing.wbaa.druid#scruid_2.12;2.1.0: not found

It is at Maven central: https://mvnrepository.com/artifact/ing.wbaa.druid/scruid_2.11/2.1.0
Did you set your resolvers correctly?


discover pro

foto-
https://user-images.githubusercontent.com/127048515/222980694-048c657a-18c6-4fb6-a777-17ac1c630b13.jpg
https://user-images.githubusercontent.com/127048515/222980755-906419f5-136e-4b44-a626-80c3d3f44e56.jpg
https://user-images.githubusercontent.com/127048515/222980562-0130dc1a-c1d7-48cc-9d77-bf57612f40bb.jpg
HiI should eliminate firmware conflict, could you help me.
Thank you

Can you clarify the question?

I would like to delete the firmware installed as can be seen from photo because it gives me error updates every start of the radio.

sorry if I'm unclear

I don't know if you should do swdownload cleaning or you still need to flash emergency, the error is that the integrity of the files is not correct, files are missing within that mib


Randomly displays Taylor Swift lyrics

Sorry for the quaint subject!
Anytime my Spotify desktop client plays ads, SpotifyLyrics tends to show the lyrics to Taylor Swift's "Look What You Made Me Do" (as of today). It might be a hidden hoax in your program, what do I know. ;-)
I thought it was some search algorithm returning "the most favorable current song" if there's nothing proper to search. I'm not sure though. The particular ad I captured right now is titled "Mehr erfahren" by the artist "Renault". Other artist/title combinations sometimes also get my Taylor Swift, sometimes the proper "Error: Could not find lyrics.".
This is the URL I can select from SpotifyLyrics:
https://www.musixmatch.com/lyrics/Taylor-Swift/Look-What-You-Made-Me-Do?utm_source=application&utm_campaign=api&utm_medium=musixmatch-community%3A1409608317702
(Don't get me wrong, I'm not one of her haters.)

Haha. So the program searches the window title to find the lyrics so I'm guessing when it searches musixmatch for the window title of the ad, the first result of that search is Taylor Swift for some reason.
This could be fixed by blacklisting specific ad windows titles (or perhaps a common identifier?) if someone cares to do it but I don't get ads and this isn't a huge deal so I'm personally not gonna bother.


When selecting an entry for auto-complete, ChromeVox Screenreader does not notify user of the selection made

I'm submitting a ...

[X ] bug report
[ ] feature request
[ ] other (Please do not submit support requests here (see above))

Current behavior:
When selecting an entry in an auto-complete, the screen reader reads out the entry name. Once the user hits enter, the reader simply says "entry deleted", and does not tell the user that a chip was successfully selected and added.
Expected / new behavior:
When the user hits enter, the screenreader should notify the user in some way that the chip was successfully selected and added. It would be great if the screenreader also notified the user which chip exactly was added.
Minimal reproduction of the problem with instructions:
Download and enable the Chromevox extension on a chrome browser. Go to https://material.angularjs.org/latest/demo/chips#custom-inputs, enter something into the auto-complete field, and select an auto-complete entry. This behavior was reproduced on chromevox-extension, on a chrome browser.
Angular version: 1.6.4-local+sha.617b36117
Browser: Chrome 59.0.3071.115
Anything else:
I'm a SWE at Google, and we're hitting this bug while trying to improve accessibility for an internal app we're building. My ldap is rajivprab@, if you'd like to chat further.

Wrong repo. Please reopen on https://github.com/angular/material.


Merging in a LOT of upstream changes from root winston

There are only a few changes we've made to winston.  This brings in all of the good work from main newton to our fork.
For easy compare, this is comparing my branch with winston master: https://github.com/winstonjs/winston/compare/master...HBOCodeLabs:zackb-massive
It effectively reflects the changes we made to winston relative to when we forked (which weren't that many)

@joecastro @allenarthurgay @shimeez

@jstamerj

The only place I can see these labels be provided are here: https://github.com/HBOCodeLabs/fitass/blob/master/src/logManager.coffee
Am i following this right?

@allenarthurgay yep, but those are defaults, applied to all instances everywhere

Nice.  Good to go!


Use the npm package in the next example. Confirmed that this works locally.

When I run
npm install
npm run dev

It shows an error

SyntaxError: Unexpected token '??='
    at wrapSafe (internal/modules/cjs/loader.js:1001:16)
    at Module._compile (internal/modules/cjs/loader.js:1049:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:93:18)
    at Object.<anonymous> (/Users/tqchen/github/web-llm/examples/next-simple-chat/node_modules/next/dist/telemetry/post-payload.js:17:20)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)

Is this when you're in the next example or in a regular one?

Hmm, let me try to replicate, I'd tried it yesterday and it worked with both building from source and the prebuilt package.

Huh.. just tried again and it indeed doesn't work unless you build web-llm locally. In fact, it still works if you have previously built web-llm locally and switch the dependency in package.json to the pre-built version.. I opened #140 with a bunch of details from my local runs
Unfortunately I might not have time until the weekend to look at this more closely.. for now maybe we can revert the commit that uses the prebuilt npm package in the next example?


Update vender

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Update vender
Special notes for your reviewer:
Release note:

Update vender

Coverage remained the same at 35.469% when pulling ac8a843d7a5b29618307d69c04ffdaa916d05851 on BaiHuoYu:531_11 into 2513f0227f90154a31de2dc42f26b767e18abaf8 on opensds:development.

Coverage remained the same at 35.469% when pulling ac8a843d7a5b29618307d69c04ffdaa916d05851 on BaiHuoYu:531_11 into 2513f0227f90154a31de2dc42f26b767e18abaf8 on opensds:development.

@BaiHuoYu Don't use dep ensure -u, it would update all packages forcely.


cache zip

can we cached zip file?  when i built in local. run  yarn  keycloak ,  command will download zip file again and again.

Hi @aikin-vip,
Yes this is something that I have considered at first but I didn't implement. Cost of opportunity.
If you want to submit a PR for this however I will happily review and merge it!
What trouble me though is when you say over and over again.
Are you aware that you can debug your theme outside of Keycloak?
I personally only build the theme on my dev machine before we upgrade our Keycloak server to a new major version.
The rest of the time, it is build in the CI pipeline.

Hi @garronej
Thank you for your patient explanation and answer, i will try to submit a pr.
I know I can debug the theme locally, but because of my development environment, I need to run Yarn Keyclay many times in the local area.

Hi @aikin-vip,
are you already working on a PR regarding this issue? Otherwise, I would have a look at it myself too, as I am currently facing similar issues as yourself and would love to have this feature, to enhance development time.

There is now a caching mechanism in Keycloakify v6 (6.0.0-beta.13)


Create 0000-01-02-ZackConord.md

Add intro file requested by the course.

@robert-crandall Thanks for trying!

It looks like you'll have to invite one of us as a collaborator to give us write access to this repo

Open this repo'sSettings tab (near the top of this page)
Click Manage access in the side-menu to the left
Invite a collaborator

Test

Perhaps "DevSecOps vs DevOps"

test


Tweak cdhweb qa redirect to force ssl; add equivalent redirect for prod

changes look good; if we wanted to be fancy maybe we could move the apache_extraconf block up to the top-level cdhweb settings and then use ansible's templating to fill in the changed part (hostname) based on which environment was being used (qa or prod). just an idea

tbh, felt a little weird to be using 'extraconf' at all, seems like this should just be in the main template. was just using what we'd already set up before. Agree, it would be nicer to have it in one place, easier to manage...


Miscellaneous plumbing work

Sigh, codecov seems out to lunch.  A manual check seems to indicate it has a positive opinion on this.  Much more work to do though.


Remove typing module for type hints

Fixes #123
Changes

Remove typing elements and replace them with built-in types

The type | type syntax is supported by Python 3.10 onwards and that is why the build for 3.9 is failing. I think maybe we can remove the optional type hint then or use the builds for 3.10 and above (if we do not want dependency on typing)
Personally, I think we should skip the optional type syntactic sugar and keep the 3.9 build.


Filter fixed in osm-verkehrswende-repo

FYI, I fixed and improved the filter system in https://github.com/osmberlin/www.osm-verkehrswende.org/commits/main/
I did not look into how we might keep the codebase of this stand alone version in sync with the project website. Might be easiest to copy paste the components. However, we should extract the parts that need to be configured per page. Likely the pmtiles URL mainly?

Thanks for the fixes, I already saw the commits and was thinking about applying them once I have some time.
And yes, the way I did the fork is not the best from a maintainability point of view. But it should still be pretty easy to apply.
And thanks again for your great work!

I just went through all of the commits and indeed applying them manually wasn't that hard (thanks to typescript).
And now the filters are working exactly the way they should!
I just noticed two things:
There are a lot of JS errors like layers.track markings.filter[3][0]: expected one of [==, !=, >, >=, <, <=, in, !in, all, any, none, has, !has, within], "match" found. I don't know maplibre-gl well enough to fix this (I normally don't use vector tiles), but also as I replace the background map in my code (so I don't have to worry about how to serve vector tiles), I avoid that issue.
And because of the id-change in the legend, the colors in the mapinspector are broken, but that's a simple fix you should be able to directly reuse: https://github.com/Findus23/vienna-cycling-quality/commit/13ed2d221337fac92acfb0f5c87d8b084664730c

I just went through all of the commits and indeed applying them manually wasn't that hard (thanks to typescript). And now the filters are working exactly the way they should!

Perfect, thanks!

 I don't know maplibre-gl well enough to fix this (I normally don't use vector tiles), but also as I replace the background map in my code (so I don't have to worry about how to serve vector tiles), I avoid that issue.

Yeah, this is super annoying and I don't know why it happens. I have asked about it in the maplibre Slack but no answer. And I started looking into it in https://github.com/maplibre/maplibre-style-spec/issues/555 but did not get very far. TBH I don't even understand why I cannot find any issues on it, because I think I am doing everything like I should … so it cannot be that I am the only one having those issues. 🤷  —  I am very open to suggestions :).

And because of the id-change in the legend, the colors in the mapinspector are broken, but that's a simple fix you should be able to directly reuse: 13ed2d2

Thanks, great catch, did the same in https://github.com/osmberlin/www.osm-verkehrswende.org/commit/b1d4a2998e5d1b244d65542944abeb67c92f6592


URLs are interpreted as Pairs

URLs are currently match as a Pair:
npm run gen && npm run try "http://beep.com"

> twitter-search-query-parser@ gen /.../twitter-search-query
> canopy grammar/query.peg --lang js

> twitter-search-query-parser@ try /.../twitter-search-query
> babel-node try.js "http://beep.com"

http://beep.com
[ 'And', [ [ 'Including', [ 'Pair', 'http', '//beep.com' ] ] ] ]
http://beep.com
[ 'And', [ [ 'Text', 'http://beep.com' ] ] ]
http://beep.com

Instead, they should be Text:
[ 'And', [ [ 'Including', [ 'Text', 'http://beep.com' ] ] ] ]

This is down to over-eager Pair matching — we can probably reduce the set of allowed characters in the value.

It appears I fixed this in b544bab.


conversion to CNF

Greetings, I follow your advice and do the major changes:
(1) I put every modifications in the util.CNFexpression package.
(2) I add a variable in the class to make sure it cannot be reused.
(3) For the test cases, I put them in an SQL statement instead of building expression trees.
Please let me know if there are still some improvements in the code.

Coverage increased (+0.6%) to 85.389% when pulling b208c3ea6089ebfbf75fa320e590cd023b59f27c on messfish:master into 2c0f2ff0f6c781411da9170cd305931a9426c5f7 on JSQLParser:master.

Coverage increased (+0.6%) to 85.389% when pulling b208c3ea6089ebfbf75fa320e590cd023b59f27c on messfish:master into 2c0f2ff0f6c781411da9170cd305931a9426c5f7 on JSQLParser:master.

@AnEmortalKid @messfish : good point. Writing separate tests would also remove the need for some of those helper methods.

Coverage increased (+0.6%) to 85.392% when pulling 507ca29b3e1026d2f5461533b339502bfff319f4 on messfish:master into 2c0f2ff0f6c781411da9170cd305931a9426c5f7 on JSQLParser:master.

I updated the test cases and include the expected trees in it. Please take a look.

I would merge your code. Do you mind if I use githubs squash and merge? If you would like to have control over your history, you should squash it by yourself.

Coverage increased (+0.6%) to 85.392% when pulling e911e61d8f41905be31c3dffab9f248d1b2a13fb on messfish:master into 2c0f2ff0f6c781411da9170cd305931a9426c5f7 on JSQLParser:master.

Sounds good, thanks for your approval! I don't mind if you use squash and merge since my history code is a little bit ugly...


move templates documentation to groovy-templates subproject

Locally I get this test failure (test is unrelated to changes):
groovy.text.StreamingTemplateEngineSpecification > should execute the javadoc example same as GStringTemplateEngine FAILED
groovy.lang.MissingMethodException: No signature of method: groovy.text.StreamingTemplateEngineSpecification.template() is applicable for argument
types: (java.lang.Class, java.lang.String, java.util.LinkedHashMap) values: [class groovy.lang.GString, Dear <% out.print firstname %> ${lastname},
We <% if (accepted) out.print 'are pleased' else out.print 'regret' %> to inform you that your paper entitled
'$title' was ${ accepted ? 'accepted' : 'rejected' }.

The conference committee.
        , ...]
    at groovy.text.StreamingTemplateEngineSpecification.should execute the javadoc example same as GStringTemplateEngine(StreamingTemplateEngineSpecification.groovy:248)

@paulk-asert : Just a vague guess, but maybe this is somehow related to  GROOVY-7346 MissingMethodException: No signature of method: com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl.xpath()

So the test doesn't fail on the CI server. Everything seem to indicate that the issue you are facing is directly related to Windows.

@Pascal, yep, it looks like the same symptoms:
groovy.text.StreamingTemplateEngineSpecification.EngineType.GSTRING => Class<groovy.lang.GString>
javax.xml.namespace.QName.XPathConstants.NODE => Class<groovy.util.Node>
I imagine there is some implicit assumption in PR#552 that windows case-insensitive file system is breaking. I would regard it as a blocker for the 2.5 release myself.

See my comment on #552.

This now works on Windows. Thanks! :)
I will backport the change to 2.4.X.


It's not clear how to change the page title from the default template

Version
4.2.2
Environment info

Environment Info:

  System:
    OS: macOS 10.15.2
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 12.16.1 - ~/.nvm/versions/node/v12.16.1/bin/node
    Yarn: Not Found
    npm: 6.13.4 - ~/.nvm/versions/node/v12.16.1/bin/npm
  Browsers:
    Chrome: 80.0.3987.116
    Firefox: 67.0.4
    Safari: 13.0.4
  npmGlobalPackages:
    @vue/cli: 4.2.2

Steps to reproduce
Use this preset:
{
  "useTaobaoRegistry": false,
  "presets": {
    "website-template": {
      "useConfigFiles": true,
      "plugins": {
        "@vue/cli-plugin-babel": {},
        "@vue/cli-plugin-typescript": {
          "classComponent": true,
          "useTsWithBabel": true
        },
        "@vue/cli-plugin-router": {
          "historyMode": false
        },
        "@vue/cli-plugin-eslint": {
          "config": "base",
          "lintOn": [
            "save"
          ]
        }
      },
      "cssPreprocessor": "node-sass"
    }
  }
}

What is expected?
Maybe find a *webpack* file with a title key for which to change the value?
What is actually happening?
The project is created with an index.html file containing <title><%= htmlWebpackPlugin.options.title %></title>, but with no indication of where is that title property defined.

It's calculated from the name field in package.json. For multi-page apps, it's the title field in the page options (inside the pages field).

pages field of what object? Or, in what file? router/index.ts?

It's explained here: https://cli.vuejs.org/config/#pages

If you use the vue-pwa plugin, then the name is set within your site.webmanifest file

If you use the vue-pwa plugin, then the name is set within your site.webmanifest file

Holy shit, two years have passed, and now you still can't change the title.

@weiliang903, see if this helps you.

did we ever figure out how to change the title?  Especially for a page that has route params like /product/:id where depending on the id, each page might have a different title?

All I want is to change my localhost300 title in my browser. Why is this so hard? Seriously vue?

While you are figuring this out, can you check vueuse npm package, there should be a hook to change your title.

On 9 Aug 2023, at 20:34, vtonu @.***> wrote:
All I want is to change my localhost300 title in my browser. Why is this so hard? Seriously vue?
—
Reply to this email directly, view it on GitHub https://github.com/vuejs/vue-cli/issues/5199#issuecomment-1672029212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC7PWY5BTSZOYYOKNNNDPX3XUPQ2RANCNFSM4KXTT5WA.
You are receiving this because you commented.

how the hell we remove the name key in package.json from the title


Review of DBMS-specific functions and common functions

All descriptions using Expression have been moved to a DMBS-specific project,
but there may be some processing that can be shared.

There were some things that could be shared, but they were too small, so we decided not to do so.
However, I didn't do anything completely; I only did some filing.
I think it will be a little easier when porting to other DBMS in the future.
Details of the reason for the rejection:
If the table name is omitted, there is logic to calculate it from the type name, but depending on the DBMS, the snake case may not be the best.
Parameter identifier is DMBS dependent.
Function is DMBS dependent.
Taking these into consideration, only a few things can be shared, and it is extremely inconvenient to use without a DMBS-specific library.


Can not start GPS mission

Hello, I am trying to launch the GPS mission example with 1 drone named: drone0
./launch_as2.bash -n drone0
I had launch my PX4 simulation without docker and I can see all mavros topic.
Then I launch the web guy:
"python3 as2_interface.py --uav_list drone0 --sim_mode true --use_sim_time true
And all goes well, until the get origin phase, because I get from the GUI window this output:
Initializing Aerostack UI logger: 1
Message recived: {"message": {"from": 0, "to": 1, "type": "basic", "header": "handshake", "status": "response", "payload": {"response": "success", "id": 1}}}
[INFO] [1728381474.783576072] [drone0.drone0_interface]: Starting drone0
[INFO] [1728381475.294579330] [drone0.drone0_interface]: drone0 interface initialized
[WARN] [1728381505.376917796] [drone0.drone0_interface]: Origin services not ready
Running info publisher

If I try to launch the gps mission with:
python3 mission_gps.py -n drone0
I get the following output:
Start mission
Arm
Arm success: True
Offboard
Offboard success: True
Take Off
Take Off success: True
Run mission
Go to with keep yaw [40.4405287, -3.6898277, 5.0]
[ERROR] [1728382046.990914959] [drone0.drone0_interface]: Trying to get origin: service not available
Traceback (most recent call last):
  File "/home/ctrazzi/aerostack2_ws/src/project_mavlink/mission_gps.py", line 173, in <module>
    success = drone_run(uav)
  File "/home/ctrazzi/aerostack2_ws/src/project_mavlink/mission_gps.py", line 98, in drone_run
    success = drone_interface.go_to.go_to_gps_point(goal, speed=SPEED)
  File "/home/ctrazzi/aerostack2_ws/install/as2_python_api/lib/python3.10/site-packages/as2_python_api/modules/go_to_gps_module.py", line 182, in go_to_gps_point
    return self.__go_to(waypoint[0], waypoint[1], waypoint[2],
  File "/home/ctrazzi/aerostack2_ws/install/as2_python_api/lib/python3.10/site-packages/as2_python_api/modules/go_to_gps_module.py", line 110, in __go_to
    return self.start(pose=msg, speed=speed, yaw_mode=yaw_mode,
  File "/home/ctrazzi/aerostack2_ws/install/as2_python_api/lib/python3.10/site-packages/as2_python_api/behavior_actions/go_to_behavior.py", line 66, in start
    pose_stamped = self.__get_pose(pose)
  File "/home/ctrazzi/aerostack2_ws/install/as2_python_api/lib/python3.10/site-packages/as2_python_api/behavior_actions/go_to_behavior.py", line 111, in __get_pose
    return self.__get_pose(geopose)
  File "/home/ctrazzi/aerostack2_ws/install/as2_python_api/lib/python3.10/site-packages/as2_python_api/behavior_actions/go_to_behavior.py", line 113, in __get_pose
    lat0, lon0, h0 = self.__drone.gps.origin
TypeError: cannot unpack non-iterable NoneType object

And this is the Gazebo window:

How can i make the get origin service avaiable? I had already try to change the waiting time from 3s to 30s (in case was a latency problem) but nothing has changed

Hi @Cristian-wp,
The GPS was disabled by default. Please check this commit, which should enable it: https://github.com/aerostack2/project_mavlink/commit/5a6a46ee537e8954a11343f224022a3a669850ef
If this doesn't solve the issue, you can verify if the service is available by running ros2 service list and checking for the state estimator services.

Yes I had figured out few miutes before your answer, thank you!


[SF Symbols Search] ...

Extension
https://www.raycast.com/peteschaffner/sf-symbols-search
Description
Whatever symbol you choose, it just copies a square with a question mark to the clipboard.
Steps To Reproduce
Mac OS Sanoma
MBA M2 2022
Raycast
Current Behaviour
Whatever symbol you choose, it just copies a square with a question mark to the clipboard.
Expected Behaviour
copie the right file to clipboard

I'm sorry this is causing you issues. Unfortunately I'm no longer maintaining the extension, but the first thing that comes to mind is to ask if you have the SF Symbols.app installed on your computer?

Hi,
Sorry to hear. Doing other Raycast stuff?
And: i feel silly. Installed the app and now it works ☺.
Thanks!
Op vr 16 feb 2024 om 09:43 schreef Pete Schaffner @.***

:

I'm sorry this is causing you issues. Unfortunately I'm no longer
maintaining the extension, but the first thing that comes to mind is to ask
if you have the SF Symbols.app installed on your computer?
—
Reply to this email directly, view it on GitHub
https://github.com/raycast/extensions/issues/10786#issuecomment-1947969387,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BF34P66PBFAHGD3DM3QLF2TYT4LZTAVCNFSM6AAAAABDLTPT5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXHE3DSMZYG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Oh great, glad that fixed it!
Not really doing anything else Raycast-related at the moment. I do think I will return to this plugin one day though as I really need/want it! I hit a wall earlier on with this extension that made it difficult to do updates that could be distributed via the store. I plan on looking back into it though to see if there have been any changes that could resolve the issue I had.

On Feb 16, 2024, at 09:49, rmbults @.***> wrote:
Hi,
Sorry to hear. Doing other Raycast stuff?
And: i feel silly. Installed the app and now it works ☺.
Thanks!
Op vr 16 feb 2024 om 09:43 schreef Pete Schaffner @.***

:

I'm sorry this is causing you issues. Unfortunately I'm no longer
maintaining the extension, but the first thing that comes to mind is to ask
if you have the SF Symbols.app installed on your computer?
—
Reply to this email directly, view it on GitHub
https://github.com/raycast/extensions/issues/10786#issuecomment-1947969387,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BF34P66PBFAHGD3DM3QLF2TYT4LZTAVCNFSM6AAAAABDLTPT5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXHE3DSMZYG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub https://github.com/raycast/extensions/issues/10786#issuecomment-1947979450, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADEOA7NJYQYTKXCNPXOGL3YT4MSJAVCNFSM6AAAAABDLTPT5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXHE3TSNBVGA.
You are receiving this because you were mentioned.


Fixed submessage_size calculation on last data_frag <1.9.x>[7535]

Wireshark complains when the length of a fragment is not multiple of 4 bytes. This usually happens on the last fragment, as the fragment size is usually multiple of 4.

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

Reuilding after changes on base branch

Build status:

Linux
Mac
Windows


[FormRecognizer] consistency issues

Recognizer

[x] rename all url parameters of the xxxxxFromUrl() methods to have proper prefixes like .NET has
[x] rename beginRecognizeForms() to beginRecognizeCustomForms()
[x] add confidence on ReceiptType
[ ] add pageNumber to FieldText
[x] rename FormElement type to FormContent
[ ] PageRange. Is there a precedent already set in storage?
[x] standardize naming around FormField.fieldLabel
Training
[x] rename parameter blobContainerUrl to trainingFilesUrl
[x] rename parameter useLabels to useTrainingLabels
[x] add an interface definition FormRecognizerError instead of using imported ErrorInformation
[x] rename method getModel() to getCustomModel()
[x] rename limit to customModelLimit and coun to customModelCount in AccountProperties

Needs follow up

[ ] Regarding Info/Properties suffix, find precedent in Azure SDK. See if we can align across langs or follow lang specific naming.
Resolved: Get/list is language specific
[.NET will find a precedent in the Azure SDK, other langs will follow precedent from own language] --> Rename method to Get/ListCustomModels(), Keep type name CustomFormModelInfo

[ ] CustomFormModel.models -> ?? (Anne to consider more descriptive name)

[ ] Follow language precedent with regard to the name of Code/ErrorCode
JS generally use Error.code instead of Error.errorCode

PR #8808


🚀 Feature: Implement a generic S3 adapter

🔖 Feature description
A generic S3 adapter not dissimilar from what's already implemented. The main difference would be a more easily customizable host option, and a toggle for using path based buckets and subdomain based buckets as not all S3 compatible servers use one over the other (Path deprecation notice)
🎤 Pitch
Creating a generic adapter would allow the use of multiple different providers without having to create an adapter for each. (e.g. Digital Ocean Spaces, AWS S3, MinIO, Backblaze, etc.)
This would allow for upstream projects (i.e. appwrite) to allow user customizable storage locations set to any S3 API compliant service instead of being vendor-locked to one specific.
This would also satiate #25's requirements.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Adding some references for how to use the AWS CLI with S3 compatible providers:

Backblaze

uses endpoint URL for region and path for bucket
bucketname in endpoint should also be supported

Wasabi

uses endpoint URL for region and path for bucket
does also support virtual-style requests according to the API Guide

Cloudflare

uses endpoint URL for region and path for bucket
virtual-style is also supported

MinIO

uses endpoint URL for region and path for bucket
virtual-style is also supported

I might be able to work on this as generic S3-comptabile functionality is something I'd like to see in appwrite. I've already provided #75 which addresses #37 for MinIO as that's a current need I had - but if you have any guidance on how you'd like to see this implemented it would definitely be appreciated.

@haymaker it would be good to create a new adapter for now so we don't interfere with the others. Have you used the S3 CLI tool (or something similar) with a S3 compatible provider?

I have, just not in the context of doing so for significant testing against any particular provider.
Would you prefer a generic adapter that extends the current S3 adapter and implements a URI-style parameter for the endpoint variable via method overloading? This seems like the better approach as it would cover providers that use either the host/bucket or subdomain schemes while limiting code duplication.

@haymaker, just like how you use the S3 CLI tool with the other S3 compatible providers, I think it would be good for the adapter to behave the same way.

FYI @stnguyen90 - PR #76 is open to address this :-)

@stnguyen90 - are there any issues I need to address with this?

Please add Ionos S3 adapter as well, thank you.


Cleanup + optimization

I just added some simple cleanups + optimization.
The only thing I'm not 100% sure about is moving static public String lastVisited = ""; in src/main/java/com/api/jsonata4java/expressions/ExpressionsVisitor.java. Either way, it doesn't make sense to me that lastVisited is a global state.

Thank you very much. I've accepted all  of your changes. You are correct that the lastVisited should not have  been static. It is used to track state in a similar way the  jsonata.js does -- we use  a  different parsing strategy in Java which has  caused some difficulties (specifically on the array processing...). If we  do need to track when external functions are called by logging their identity in the lastVisited we can add a setter in ExpressionsVisitor.


CIFAR10 accuracy

Hi Spijkervet,@Spijkervet
have you tried more epochs for your experiment settings, like 500 epochs,
the result from the paper has shown that even 256 batchsize could achieve about 93% accuracy for 500 epochs traning.
However, my implementation can only got ~89.5% accuracy even with 512 batchsize.
Best,
Chen

I also don't get the reported accuracy. Even with the code and pretrained weights from @Spijkervet I do not get the reported test accuracy claimed in this repo: only 75% compared to the reported 83% for CIFAR10. I wonder if the lars optimizer has something to do with it. I have really tried to get it working but I end up with "nan" values for my training loss.

Hi chen, if you used the code which is shared by Spijkervet? Why i only achieved nearly 65% acc on CIFAR-10. It seems that used 128 batch size train the representation may lead to acc decrease.

Hi chen, if you used the code which is shared by Spijkervet? Why i only achieved nearly 65% acc on CIFAR-10. It seems that used 128 batch size train the representation may lead to acc decrease.

I havent tried Spijkervet implementation. In my implementations, epoch num is more important compared to batchsize. However, I cannot get better result than 90% with resnet18 in all settings.


Use django-axes and Django password validators for custom password logic

This PR does two things:

Removes our custom login lockout functionality and adds the django-axes library to handle that functionality.
Moves our custom password requirements to Django's AUTH_PASSWORD_VALIDATORS  functionality.

Previously, our password validation happened within a subclass of the Django validator form, which required us to have a view that overrides Django/Wagtail's password change views. By using AUTH_PASSWORD_VALIDATORS, we can remove the custom views and form, and the URL overrides, and rely on Django to always check passwords through configured validators.
Note: django-axes uses hours for its AXES_COOLOFF_TIME setting, and previously we were using seconds for our similar LOGIN_FAIL_TIME_PERIOD. This change will require a corresponding change to our Ansible playbooks that set that environment variable.
How to test this PR

Use an incorrect password 5 times at http://localhost:8000/admin/login and confirm that you receive an account lockout.

Use the "Forgotten password?" link to reset your password. This will print the contents of the email it would send to your console. Attempt to reset your password to confirm that:

12 characters are required
A capital letter is required
A lowercase letter is required
A number is required
A special character is required

Checklist

[x] PR has an informative and human-readable title
[x] Changes are limited to a single goal (no scope creep)

Snyk is complaining that django-axes lets in a potentially old version of setuptools, but I'm a bit loath to pin setuptools in our requirements. @chosak any thoughts?


issue rolling the latest version to the sdk repo

I don't know if this is the same issue as previously or a subsequent one, but we're seeing an issue on the roll:

for `pkg-linux-release-try`
```
/============================================================================================\
| native_toolchain_c/test/cbuilder/cbuilder_test broke (Pass -> RuntimeError, expected Pass) |
\============================================================================================/
--- Command "vm" (took 14.000993s):
DART_CONFIGURATION=ReleaseX64 CHROME_PATH=/b/s/w/ir/cache/builder/sdk/third_party/browsers/chrome/chrome/google-chrome out/ReleaseX64/dart-sdk/bin/dart --enable_asserts --sound-null-safety -Dtest_runner.configuration=unittest-asserts-release-linux --ignore-unrecognized-flags --packages=/b/s/w/ir/cache/builder/sdk/.dart_tool/package_config.json /b/s/w/ir/cache/builder/sdk/third_party/pkg/native/pkgs/native_toolchain_c/test/cbuilder/cbuilder_test.dart
exit code:
255
stdout:
00:00 +0: Langauge.toString
00:00 +1: CBuilder executable (debug, auto_pic)
00:00 +2: CBuilder executable (release, auto_pic)
00:00 +3: CBuilder dylib (dry_run, auto_pic)
00:00 +4: CBuilder dylib (auto_pic)
00:01 +5: CBuilder executable (debug, pic)
00:01 +6: CBuilder executable (release, pic)
00:01 +7: CBuilder dylib (dry_run, pic)
00:01 +8: CBuilder dylib (pic)
00:02 +9: CBuilder executable (debug, no_pic)
00:02 +10: CBuilder executable (release, no_pic)
00:02 +11: CBuilder dylib (dry_run, no_pic)
00:02 +12: CBuilder dylib (no_pic)
00:02 +13: CBuilder build mode defines (debug, enabled)
00:03 +14: CBuilder build mode defines (debug, disabled)
00:03 +15: CBuilder build mode defines (release, enabled)
00:03 +16: CBuilder build mode defines (release, disabled)
00:03 +17: CBuilder define (with_value)
00:03 +18: CBuilder define (without_value)
00:04 +19: CBuilder flags
00:04 +20: CBuilder includes
00:04 +21: CBuilder std
00:04 +22: CBuilder compile c++
00:06 +22 -1: CBuilder compile c++ [E]
ProcessException: Full command string: '/b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang -fno-PIC -fno-PIE -z notext -x c++ -l stdc++ -DRELEASE -DNDEBUG /b/s/w/ir/cache/builder/sdk/third_party/pkg/native/pkgs/native_toolchain_c/test/cbuilder/testfiles/hello_world_cpp/src/hello_world_cpp.cc -o /b/s/w/ir/x/t/DJIJPG/hello_world_cpp'.
Exit code: '1'.
For the output of the process check the logger output.

FINER: 2023-09-14 09:35:48.703602: Using compiler /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang from config[c_compiler.cc].
FINER: 2023-09-14 09:35:48.703886: Trying to recognize file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang.
INFO: 2023-09-14 09:35:48.703989: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang --version.
FINE: 2023-09-14 09:35:48.730770: Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 6d667d4b261e81f325756fdfd5bb43b3b3d2451d)
FINE: 2023-09-14 09:35:48.731153: Target: x86_64-unknown-linux-gnu
FINE: 2023-09-14 09:35:48.731316: Thread model: posix
FINE: 2023-09-14 09:35:48.731451: InstalledDir: /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin
FINE: 2023-09-14 09:35:48.733223: Tool instance file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang is likely Tool(Clang).
FINER: 2023-09-14 09:35:48.733445: Looking up version with --version for ToolInstance(Clang, null, file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang).
INFO: 2023-09-14 09:35:48.733647: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang --version.
FINE: 2023-09-14 09:35:48.763285: Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 6d667d4b261e81f325756fdfd5bb43b3b3d2451d)
FINE: 2023-09-14 09:35:48.763879: Target: x86_64-unknown-linux-gnu
FINE: 2023-09-14 09:35:48.764012: Thread model: posix
FINE: 2023-09-14 09:35:48.764107: InstalledDir: /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin
FINE: 2023-09-14 09:35:48.765945: Found version for ToolInstance(Clang, 17.0.0, file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang).
INFO: 2023-09-14 09:35:48.767082: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang -fno-PIC -fno-PIE -z notext -x c++ -l stdc++ -DRELEASE -DNDEBUG /b/s/w/ir/cache/builder/sdk/third_party/pkg/native/pkgs/native_toolchain_c/test/cbuilder/testfiles/hello_world_cpp/src/hello_world_cpp.cc -o /b/s/w/ir/x/t/DJIJPG/hello_world_cpp.
SEVERE: 2023-09-14 09:35:50.811588: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:50.811985: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-797995.o
SEVERE: 2023-09-14 09:35:50.812048: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:50.812105: >>>               /b/s/w/ir/x/t/hello_world_cpp-797995.o:(.eh_frame+0xD939)
SEVERE: 2023-09-14 09:35:50.812416:
SEVERE: 2023-09-14 09:35:50.812500: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:50.812560: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-797995.o
SEVERE: 2023-09-14 09:35:50.812618: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:50.812716: >>>               /b/s/w/ir/x/t/hello_world_cpp-797995.o:(.eh_frame+0xD961)
SEVERE: 2023-09-14 09:35:50.812880:
SEVERE: 2023-09-14 09:35:50.812950: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:50.813009: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-797995.o
SEVERE: 2023-09-14 09:35:50.813090: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:50.813156: >>>               /b/s/w/ir/x/t/hello_world_cpp-797995.o:(.eh_frame+0xD989)
SEVERE: 2023-09-14 09:35:50.813304:
SEVERE: 2023-09-14 09:35:50.813528: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:50.814261: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-797995.o
SEVERE: 2023-09-14 09:35:50.814509: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:50.814664: >>>               /b/s/w/ir/x/t/hello_world_cpp-797995.o:(.eh_frame+0xD9B1)
SEVERE: 2023-09-14 09:35:50.814916:
SEVERE: 2023-09-14 09:35:50.815179: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:50.815341: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-797995.o
SEVERE: 2023-09-14 09:35:50.815446: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:50.815550: >>>               /b/s/w/ir/x/t/hello_world_cpp-797995.o:(.eh_frame+0xD9D9)
SEVERE: 2023-09-14 09:35:50.819750: clang: error: linker command failed with exit code 1 (use -v to see invocation)
00:06 +22 -1: CBuilder cppLinkStdLib
00:06 +22 -1: CBuilder compile c++
FINER: 2023-09-14 09:35:50.858603: Using compiler /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang from config[c_compiler.cc].
FINER: 2023-09-14 09:35:50.859030: Trying to recognize file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang.
INFO: 2023-09-14 09:35:50.859383: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang --version.
FINE: 2023-09-14 09:35:50.887976: Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 6d667d4b261e81f325756fdfd5bb43b3b3d2451d)
FINE: 2023-09-14 09:35:50.889038: Target: x86_64-unknown-linux-gnu
FINE: 2023-09-14 09:35:50.889213: Thread model: posix
FINE: 2023-09-14 09:35:50.889346: InstalledDir: /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin
FINE: 2023-09-14 09:35:50.891643: Tool instance file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang is likely Tool(Clang).
FINER: 2023-09-14 09:35:50.892069: Looking up version with --version for ToolInstance(Clang, null, file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang).
INFO: 2023-09-14 09:35:50.893125: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang --version.
FINE: 2023-09-14 09:35:50.921416: Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 6d667d4b261e81f325756fdfd5bb43b3b3d2451d)
FINE: 2023-09-14 09:35:50.922054: Target: x86_64-unknown-linux-gnu
FINE: 2023-09-14 09:35:50.922142: Thread model: posix
FINE: 2023-09-14 09:35:50.922211: InstalledDir: /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin
FINE: 2023-09-14 09:35:50.923904: Found version for ToolInstance(Clang, 17.0.0, file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang).
INFO: 2023-09-14 09:35:50.924734: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang -fno-PIC -fno-PIE -z notext -x c++ -l stdc++ -DRELEASE -DNDEBUG /b/s/w/ir/cache/builder/sdk/third_party/pkg/native/pkgs/native_toolchain_c/test/cbuilder/testfiles/hello_world_cpp/src/hello_world_cpp.cc -o /b/s/w/ir/x/t/OMMIQZ/hello_world_cpp.
SEVERE: 2023-09-14 09:35:52.047245: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.048070: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.048268: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.048415: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD939)
SEVERE: 2023-09-14 09:35:52.048668:
SEVERE: 2023-09-14 09:35:52.048823: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.049016: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.049171: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.049299: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD961)
SEVERE: 2023-09-14 09:35:52.049482:
SEVERE: 2023-09-14 09:35:52.050300: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.050553: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.050697: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.050804: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD989)
SEVERE: 2023-09-14 09:35:52.050879:
SEVERE: 2023-09-14 09:35:52.050948: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.051037: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.051103: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.051185: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD9B1)
SEVERE: 2023-09-14 09:35:52.051248:
SEVERE: 2023-09-14 09:35:52.051339: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.051407: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.051468: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.051529: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD9D9)
SEVERE: 2023-09-14 09:35:52.054473: clang: error: linker command failed with exit code 1 (use -v to see invocation)
00:07 +22 -2: CBuilder cppLinkStdLib [E]
ProcessException: Full command string: '/b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang -fno-PIC -fno-PIE -z notext -x c++ -l stdc++ -DRELEASE -DNDEBUG /b/s/w/ir/cache/builder/sdk/third_party/pkg/native/pkgs/native_toolchain_c/test/cbuilder/testfiles/hello_world_cpp/src/hello_world_cpp.cc -o /b/s/w/ir/x/t/OMMIQZ/hello_world_cpp'.
Exit code: '1'.
For the output of the process check the logger output.

FINER: 2023-09-14 09:35:50.858603: Using compiler /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang from config[c_compiler.cc].
FINER: 2023-09-14 09:35:50.859030: Trying to recognize file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang.
INFO: 2023-09-14 09:35:50.859383: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang --version.
FINE: 2023-09-14 09:35:50.887976: Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 6d667d4b261e81f325756fdfd5bb43b3b3d2451d)
FINE: 2023-09-14 09:35:50.889038: Target: x86_64-unknown-linux-gnu
FINE: 2023-09-14 09:35:50.889213: Thread model: posix
FINE: 2023-09-14 09:35:50.889346: InstalledDir: /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin
FINE: 2023-09-14 09:35:50.891643: Tool instance file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang is likely Tool(Clang).
FINER: 2023-09-14 09:35:50.892069: Looking up version with --version for ToolInstance(Clang, null, file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang).
INFO: 2023-09-14 09:35:50.893125: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang --version.
FINE: 2023-09-14 09:35:50.921416: Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 6d667d4b261e81f325756fdfd5bb43b3b3d2451d)
FINE: 2023-09-14 09:35:50.922054: Target: x86_64-unknown-linux-gnu
FINE: 2023-09-14 09:35:50.922142: Thread model: posix
FINE: 2023-09-14 09:35:50.922211: InstalledDir: /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin
FINE: 2023-09-14 09:35:50.923904: Found version for ToolInstance(Clang, 17.0.0, file:///b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang).
INFO: 2023-09-14 09:35:50.924734: Running /b/s/w/ir/cache/builder/sdk/buildtools/linux-x64/clang/bin/clang -fno-PIC -fno-PIE -z notext -x c++ -l stdc++ -DRELEASE -DNDEBUG /b/s/w/ir/cache/builder/sdk/third_party/pkg/native/pkgs/native_toolchain_c/test/cbuilder/testfiles/hello_world_cpp/src/hello_world_cpp.cc -o /b/s/w/ir/x/t/OMMIQZ/hello_world_cpp.
SEVERE: 2023-09-14 09:35:52.047245: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.048070: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.048268: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.048415: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD939)
SEVERE: 2023-09-14 09:35:52.048668:
SEVERE: 2023-09-14 09:35:52.048823: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.049016: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.049171: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.049299: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD961)
SEVERE: 2023-09-14 09:35:52.049482:
SEVERE: 2023-09-14 09:35:52.050300: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.050553: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.050697: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.050804: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD989)
SEVERE: 2023-09-14 09:35:52.050879:
SEVERE: 2023-09-14 09:35:52.050948: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.051037: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.051103: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.051185: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD9B1)
SEVERE: 2023-09-14 09:35:52.051248:
SEVERE: 2023-09-14 09:35:52.051339: ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
SEVERE: 2023-09-14 09:35:52.051407: >>> defined in /b/s/w/ir/x/t/hello_world_cpp-5efcad.o
SEVERE: 2023-09-14 09:35:52.051468: >>> referenced by hello_world_cpp.cc
SEVERE: 2023-09-14 09:35:52.051529: >>>               /b/s/w/ir/x/t/hello_world_cpp-5efcad.o:(.eh_frame+0xD9D9)
SEVERE: 2023-09-14 09:35:52.054473: clang: error: linker command failed with exit code 1 (use -v to see invocation)
00:07 +22 -2: Some tests failed.
</details>

These are new tests, I made a roll yesterday.
@blaugold can you follow the steps to reproduce this locally on clang 17 and submit a fix?
I've tried to change the GitHub CI to clang 17, but that doesn't work unfortunately. https://github.com/dart-lang/native/issues/131#issuecomment-1720742490

@blaugold I've merged a CI job which exercises the failures (clang 17), so you can test the fix against the CI here without having to go through the Dart SDK checkout. https://github.com/dart-lang/native/pull/135

Roll fixed. And we've added a clang 17 bot to the CI, so hopefully we wont break the Linux pkg bots again.


Problem with setting opacity for custom frame

Before the new update I was able to create a custom frame with 3 different opacities. Now I cannot.

Thank you for the feedback!
This was caused by an issue with macOS Sonoma.
I've released ShowyEdge 5.7.0, which addresses the issue, so please try the latest version.


Language File

Hi Karim,
I think you should translation files on your project. I want your query translate to turkish.

Hi,
thanks for the suggestion, but I don't think that's a good idea. Yes, SRL is human readable, but with other languages comes other grammar and syntax. In the end, this will probably be a unmaintainable monster.

Ok, but keep in mind ^^
Amazing work Thank you

Agree with Karim. You don't see any programming language that has syntax in multiple natural languages. It doesn't make a lot of sense!


Feature/automated docker release

Regarding issue #37:
Created a separate workflow file which is only to be triggered when there is a push happening in main (which will only happen when a PR is being merged from develop).
In this workflow, a docker image will be released with the correct tag.

I just ran the tests without the main condition, and instead of a docker image with the tag test, the one with tag 0.5.7 was updated.


feat(linter/import) check module import in no_duplicates

We should use requested_modules instead of loaded_modules because loaded_modules only contains successfully resolved modules.

#2771  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Dunqing and the rest of your teammates on  Graphite

@overlookmotel Hi, the time to run the benchmark is now very fast, thanks for the effort you put in! But it seems to be a bit unstable, I've found incorrect benchmark regressions in a couple of PRs, not sure what's causing that!


[HOLD for payment 2024-07-10] [LOW] [Performance] Fix onyx mocking for reassure

After updating Onyx to a later version here: https://github.com/Expensify/App/pull/42772, the mocking for Onyx has to be updated in the reassure tests, as otherwise, they will fail.
We have disabled the tests after confirming the regressions are not manifesting in the product.
Discussing in this slack thread. Let's figure out how to fix the onyx mocking and update the tests with it cc @chrispader @OlimpiaZurek
Issue OwnerCurrent Issue Owner: @kadiealexander

Hi. I'm Olimpia from Callstack. I would like to work on this issue.

Thanks

Daily Update: It looks like the issue with increasing render count after removing null values from the cache in onyx is likely due to more frequent state updates and re-renders. The Jest environment makes things worse by handling mocks, asynchronous operations, and state updates differently than in a real application, leading to excessive rendering.
I have found that simplifying the tests by breaking the scenarios into smaller parts and testing the performance of smaller pieces of the component could solve this problem.  This will ensure that each part of the scenario addresses specific state updates, making it easier to manage and understand the impact of each update on component render counts.
So the next step is to change these tests according to the above conclusions. I should have my PR ready at the beginning of next week.

@OlimpiaZurek still on track to get a PR up in next day?

I've been working on a different task recently. I'll come back to this tomorrow. The PR should be ready by Wednesday.

@kadiealexander handing over in prep for parental leave 🙏 this one is still waiting on getting a PR up, but Olimpia should have this done today 👍

I believe this is now completed and we do not have anything else actionable.
Thank you @OlimpiaZurek


Only responds to label 77

In the process of converting my initial program into a class, a major bug arose. The class now only responds to label 77 or responds to all labels with 77. I don't know why.

The state was not being reset after the end byte was read.


Upgrade dependencies and plugins

Codecov Report

Merging #88 into master will decrease coverage by 0.37%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #88      +/-   ##
==========================================
- Coverage   91.92%   91.55%   -0.38%
==========================================
  Files          62       52      -10
  Lines         991      876     -115
  Branches       45       42       -3
==========================================
- Hits          911      802     -109
+ Misses         80       74       -6

Impacted Files
Coverage Δ

core/shared/src/main/scala/cron4s/expr/parts.scala
0% <0%> (-66.67%)
:arrow_down:

...d/src/main/scala/cron4s/lib/javatime/package.scala
50% <0%> (-8.34%)
:arrow_down:

core/shared/src/main/scala/cron4s/expr/nodes.scala
77.04% <0%> (-4.53%)
:arrow_down:

...c/main/scala/cron4s/validation/NodeValidator.scala
100% <0%> (ø)
:arrow_up:

.../cron4s/testkit/gen/ArbitraryCronFieldValues.scala
100% <0%> (ø)
:arrow_up:

...ain/scala/cron4s/testkit/CronDateTimeTestKit.scala
100% <0%> (ø)
:arrow_up:

...main/scala/cron4s/testkit/discipline/package.scala
0% <0%> (ø)
:arrow_up:

...e/shared/src/main/scala/cron4s/expr/CronExpr.scala
100% <0%> (ø)
:arrow_up:

...main/scala/cron4s/testkit/gen/CronGenerators.scala
100% <0%> (ø)
:arrow_up:

...n/scala/cron4s/testkit/gen/ArbitraryEachNode.scala

... and 9 more

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 da5b524...25ef3dc. Read the comment docs.


Bug/Maintenance in/for configuration templates

This is a bug report and a discussion (hopefully) at the same time.
This module offers 2 templates (one .erb and one .epp) for configurations and a parameter in the certificate::x509 class to change the configuration file to be used (defaults to: openssl/cert.cnf.erb). This works perfectly fine as long as one uses the .erb template. However as soon as someone wants to change the path-parameter to use the cert.cnf.epp template instead, syntax errors occure. This is caused by the use of the template function (which does not allow epp template files; the appropriate function for epp-templates would be epp() ).
This bug could surely be fixed by specialcasing based on the file-ending or similar means, but in my opinion this doesnt tackle the underlying issue of how the configuration file is managed. Is there a reason to allow users to exchange templates accross modules?
In my opinion this is bad practice and should someone need a very custom configuration file, we should either expand our template to be generic enough for all use-cases, or the user can generate this file themselfes and pass it through the cnf parameter of the same class. Albeit I am not sure if there should be a check added to only manage the cnf file if the cnf-parameter is empty.
At the same time it seems the templates have diverged in their features and functionalities, this is bad for maintainability.
In my opinion the steps to correct this bug and improve maintainability, we should merge the features of the two templates into one template (probably best done in one .epp template), use the correct function for rendering the template and possibly get rid of the cnf_tpl parameter as cross referencing templates from other modules seems wrong on a very basic level.
In the end there should only exist one template (that provides all functionalities/configuration options a user needs) and all features someone suggest get added to this one template to ensure this is maintainable.
Maybe a maintainer can provide some thoughts, if this would be appreciated? I can provide code/tests and documentation should the changes be wanted.

After gathering some more insight, I would advocate for moving configuration management in the certificates::x509 class from a file resource with the erb template to a openssl::configs resource.
This would remove the last dependency on the cert.cnf.erb template (which could therefore be removed), and would make the cnf_tpl parameter in the certificates::x509 class no longer supported, (but keeps most of the features the parameter can provide by enabling them through the openssl::configs class.