[core] Compound literals issues with Clang C++ compiler on macOS

Hey I have been expiriementing with your library and I really like the minimalistic design plus the code base is understandable. I have although found an issue when trying to use Color constants in c++
 error: expected '(' for function-style cast or type construction
            ClearBackground(RAYWHITE);

Debug the issue lead me to this.
https://github.com/raysan5/raylib/blob/959d0d259146c943fe3db61fd1664169303c6394/src/raylib.h#L118
I noticed the reason as to why I was expiriencing this was due to the CLITERAL definition. I saw the comment above the conditional definition check and noticed that it will use the first case even if the compiler is not MSC C++ (ie clang/gcc) in order to fix this I changed the line 118 to read as follows
#if defined(__cplusplus) && defined(_WIN32)

Im not an expert in c++ or compilers Im assuming that the MSC C++ compiler only works in windows and that there will not be any compilation with MSC in OSX I could be wrong. However that fixed issue and im back on track expirimenting with raylib.

Hi @alexanderwanyoike, actually this issue is trickier than it seems... compound-literals support are a C99 feature and depending on the compiler, they are supported or not in C++ but also they could behave differently.
The proposed solution:
#if defined(__cplusplus) && defined(_WIN32)

would restrict it to Window but there could be some compiler in another platform that does not support compound-literals on C++. Actually, it seems they should be supported from MSVC 2013 (_MSC_VER == 1800).
I investigated a bit and it seems GCC supports them through a GNU-extension, automatic enabled and Clang support is limited...
Not sure what would be the right way to consider all possible cases... probably a per-compiler + per-version check would be required in some cases.

Investigating a bit further, compound literals are not part of C++ so proposed defined(__cplusplus) should work with any C++ compiler.

Sorry to resurrect this thread but I have hit this same issue and would like to know what the correct compiler flags are to build the 'basic window' sample. Right now I have;
clang++ -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL lib/raylib.a raylib_game.cpp -o build/raylib_game
Taken from the Working with MacOS page. This results in the following output.
+ clang++ -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL lib/raylib.a raylib_game.cpp -o build/raylib_game
raylib_game.cpp:27:25: error: expected '(' for function-style cast or type construction
        ClearBackground(RAYWHITE);
                        ^~~~~~~~
/usr/local/include/raylib.h:152:35: note: expanded from macro 'RAYWHITE'
#define RAYWHITE   CLITERAL(Color){ 245, 245, 245, 255 }   // My own White (raylib logo)
                            ~~~~~ ^
raylib_game.cpp:29:76: error: expected '(' for function-style cast or type construction
        DrawText("Congrats! You created your first window!", 190, 200, 20, LIGHTGRAY);
                                                                           ^~~~~~~~~
/usr/local/include/raylib.h:126:35: note: expanded from macro 'LIGHTGRAY'
#define LIGHTGRAY  CLITERAL(Color){ 200, 200, 200, 255 }   // Light Gray

I would like to compile in C++ to use some features from it.

Sorry to resurrect this thread but I have hit this same issue and would like to know what the correct compiler flags are to build the 'basic window' sample. Right now I have;
clang++ -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL lib/raylib.a raylib_game.cpp -o build/raylib_game
Taken from the Working with MacOS page. This results in the following output.
+ clang++ -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL lib/raylib.a raylib_game.cpp -o build/raylib_game
raylib_game.cpp:27:25: error: expected '(' for function-style cast or type construction
        ClearBackground(RAYWHITE);
                        ^~~~~~~~
/usr/local/include/raylib.h:152:35: note: expanded from macro 'RAYWHITE'
#define RAYWHITE   CLITERAL(Color){ 245, 245, 245, 255 }   // My own White (raylib logo)
                            ~~~~~ ^
raylib_game.cpp:29:76: error: expected '(' for function-style cast or type construction
        DrawText("Congrats! You created your first window!", 190, 200, 20, LIGHTGRAY);
                                                                           ^~~~~~~~~
/usr/local/include/raylib.h:126:35: note: expanded from macro 'LIGHTGRAY'
#define LIGHTGRAY  CLITERAL(Color){ 200, 200, 200, 255 }   // Light Gray

I would like to compile in C++ to use some features from it.

@JimmyDeemo Afaik, it should work... 🤔

@JimmyDeemo Afaik, it should work... 🤔

Thank you. This error seems strangly familiar...perhaps it is environmental. I'll try and get eyes on the Discord myself.

Thank you. This error seems strangly familiar...perhaps it is environmental. I'll try and get eyes on the Discord myself.

Found it! Looks like you need to tell clang to compile in C++11 mode by adding -std=c++11 to the arguments. Meaning that the following works for me;
clang++ -std=c++11 -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL lib/raylib.a raylib_game.cpp -o build/raylib_game

Found it! Looks like you need to tell clang to compile in C++11 mode by adding -std=c++11 to the arguments. Meaning that the following works for me;
clang++ -std=c++11 -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL lib/raylib.a raylib_game.cpp -o build/raylib_game

@JimmyDeemo Thank you very for investigating this issue and reporting the solution here! It would be helpful for future users! 👍

@JimmyDeemo Thank you very for investigating this issue and reporting the solution here! It would be helpful for future users! 👍

No worries @raysan5 , i've added a note here too; https://github.com/raysan5/raylib/wiki/Working-on-macOS. Hope that's formatted okay.

No worries @raysan5 , i've added a note here too; https://github.com/raysan5/raylib/wiki/Working-on-macOS. Hope that's formatted okay.


Unable to generate arch.json or .dcf from .hwh file - Vitis-AI. Docker image version: <IP_ADDRESS>0

Greetings,
I am using an ultra96 v2 board I am trying to generate a .dcf and subsequently an arch.json file with custom DPU configurations:

I used Vivado 2021.2 to create the block design with custom DPU configs (as above) and generated the system.hwh (attached as system.zip)
system.zip
However, when I attempt to generate .dcf from dlet in the latest (As of 2022-07-04) VITIS-AI-CPU (Docker image version - <IP_ADDRESS>0), I get the following error: bash: "dlet": command not found
I suspected that dlet may not be bundled in this latest Vitis-Ai, so I pulled an earlier version of Vitis AI namely: 1.2.82
Here dlet command is working, because when I run dlet -v I see this:
DLet version 1.0
Build Label: Jun 23 2020 03:34:15
Copyright @2019 Xilinx Inc. All Rights Reserved.
However, when I run dlet -f system.hwh command I get the following error:
[DLet]Failed to find DPU parameters from DPU HWH.

Can someone please help identify the issue here? Is there a problem my .hwh file, dlet version or vitis-ai version?
If this is not solve able can you please help me the a DPU Fingerprint which has the DPU configurations as mentioned above (I am mainly focused on enabling a SoftMax core)?
Is there a list of DPU Configurations and their fingerprints listed somewhere? I could not find any link or documentation listing the finger prints.

Please let me know if I need to provide any more information.
Thanks and Regards,
-AI

Hi @anirudhitagi

We won't use the dlet in the future，please update to the lastest Vitis-AI in https://github.com/Xilinx/Vitis-AI
To generate arch.json, please refer to the lastest DPUCZDX8G reference design in https://github.com/Xilinx/Vitis-AI/tree/master/reference_design, and follow the readme.
There is no list that you mentioned.

Thanks

Hi @davidxudong,
Thank you for your response. I am able to generate the arch.json file with the desired DPU configurations.
I was working with older DPU V3.4, but now after updating to the latest DPU v4.0 I am able to configure to the right version of DPU.
Thanks again!


Write a PHP program to print reverse of a string by recursion

Description
Write a PHP program to print reverse of a string by recursion
Reverse of a string is the string with characters in reverse order. For example, reverse of "GeeksQuiz" is "ziuQskeeG".
Input  : abcd
Output : dcba

How to contribute

Save the solution in print_reverse_of_a_string_by_recursion.php file
Add print_reverse_of_a_string_by_recursion.php file in print-reverse-of-a-string-by-recursion folder

!assign


Fix empty response

Continuation of #126
TODO: figure out the right test for no response vs empty response

Since response is always either a string or an object that would be falsey if there was no response, I think the check should be either
xhr.response || xhr.response === ''

or something like
typeof xhr.response !== 'undefined' && typeof xhr.response !== null

What do you mean by "no response vs empty response"?

What do you mean by "no response vs empty response"?
Empty response is when server responds and intentionally returns something we would consider "empty" in body. No response == no http body

It may be hard to distinguish. Comparing against undefined and null seems closest to what we should do, but I still have doubts - what if responseType is json and server returns null as body content? We need to return exactly that, but we'll step over to else and return responseText which is undefined or "null", I'd need to check.
I'll add some more test cases to document all edge cases I can reproduce.

Ok, here's what I did:

implemented

typeof xhr.response !== 'undefined' && typeof xhr.response !== null

with
xhr.response != null

which results in the same thing

Added tests for all edge cases I could think of and adapted them to work in FF, Chrome and Phantom

Fixed one regression regarding responseText

What's left:

Testing this branch in Safari and IEs
Disabling/tweaking testcases that will break IE due to missing or buggy support for responseType

Looking for volunteers to test this in IEs and Safari thoroughly.

resolved and released in v2.4.0


Rid-bags serialization optimization

New rid-bags serializers using varints instead of fixed size length fields.
Introduced new rid-bags serializers' abstraction layer.

Great! Is it compatible with the previous versions? Are we keeping both serializers?

Both serializers are present, so it is backward compatible. Old one is still default serializer.

Cool, thanks. @tglman when can we enable as default all those changes by Marko?

I have a question, do we have any number form usage of both serializers?

Hi all,
we actually had a private discussion we are going to simplify this changes, so probably this PR will be closed, the performance difference in term of cpu I don't think is going to be big, in term of size we will have an average of 50% less memory for the same content.
Regards

@tglman how much time to redo this? Can we put this in v3.0 and change the impl later in some hotfix?

@tglman as I understand you do not have results of any measurements at this moment, is it possible to send numbers before and after implementation in terms of space and performance?

After conversation with @tglman we came to the conclusion that it can be done in another simpler way.


Update the Minute Repeater Chime Patterns

Minute Repeater
Coming Soon...
Specs

The work will consist of reworking the existing logic within the existing MinuteRepeater.js module
The settings object should be updated to support the existing format (until v3) but be modified to focus on accepting only two chimes.

repeater: {
  chimes: {
    hour: [string path],
    minute: [string path]
  }
}

Functionality
Most repeaters work off of two chimes.
Hours are denoted by the striking of Chime 1.
Quarter Hours are denoted by striking Chime 1 and right after striking Chime 2
Minutes are denoted by the striking of Chime 2
The two chimes representing the quarter hours should overlap when played, approximately striking chime 2 half way through chime 1's duration.

This support has been added as v2.12.0 per commit: 5c1eb20b209fa34305d96fbbb92e29148e1ef165


Update pagination component as per DAC's recommendation

Context

Changes proposed in this pull request
This also adds a margin in line with that's in the prototype
Guidance to review

Link to Trello card
https://trello.com/c/6MN53KBq/3407-fix-pagination-mark-up-and-accessible-label
Things to check

[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] API release notes have been updated if necessary
[ ] New environment variables have been added to the Azure config

This has undone the work I did to fix it. I think close this and mark as done.


[$250] Scan –"Allow location Access" modal is not displayed when submitting a scan expense via QAB

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v9.0.41-2
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:
Precondition
Make sure that location permission is disabled in your browser

Log in to the app with any account
Click on FAB > Submit Expense > Scan > Upload a receipt > Choose a recipient > Submit
Here notice that "Allow location access" modal is displayed
Click on "Not now" option > The expense is created
Now click on FAB > then click on QAB > Upload a receipt > Submit
Here notice that "Allow location access" modal is not displayed and the expense is created bypassing this process

Expected Result:
"Allow location access" modal is displayed
Actual Result:
"Allow location access" modal is not displayed, there is an inconsistency when submitting the expense through FAB and QAB
Workaround:
Unknown
Platforms:

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

Screenshots/Videos
https://github.com/user-attachments/assets/13186744-af9c-416b-8f02-52a4c6f5086a

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021843470696140504711
Upwork Job ID:<PHONE_NUMBER>140504711
Last Price Increase: 2024-10-08
Automatic offers:

DylanDylann | Reviewer | 104325716
nkdengineer | Contributor | 104325723

Issue OwnerCurrent Issue Owner: @DylanDylann

We think that this bug might be related to #wave-collect - Release 1

@VictoriaExpensify  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

Proposal
Please re-state the problem that we are trying to solve in this issue.
"Allow location access" modal is not displayed, there is an inconsistency when submitting the expense through FAB and QAB
What is the root cause of that problem?
Currently, we skip the confirmation page when a scan expense is created from QBA so it skips "Allow location Access" modal
https://github.com/Expensify/App/blob/ee11bc5ab09c42f6dbe9e0f55e25caddc6d2824a/src/pages/iou/request/step/IOURequestStepScan/index.tsx#L94-L96
What changes do you think we should make in order to solve the problem?

We should add LocationPermissionModal to the IOURequestStepConfirmation component

          const [isShowLocationPermissionModal, setIsShowLocationPermissionModal] = useState(false);
          const [startLocationPermissionFlow, setStartLocationPermissionFlow] = useState(false);

           {IsShowLocationPermissionModal && (
                <LocationPermissionModal
                    startPermissionFlow={startLocationPermissionFlow}
                    resetPermissionFlow={() => setStartLocationPermissionFlow(false)}
                    onGrant={() => navigateToConfirmationStep(file, source)}
                    onDeny={() => navigateToConfirmationStep(file, source)}
                />
            )}

Change to logic navigateToConfirmationStep function here

        const gpsRequired = transaction?.amount === 0 && iouType !== CONST.IOU.TYPE.SPLIT && file;
                 if(shouldSkipConfirmation){
                    const gpsRequired = transaction?.amount === 0 && iouType !== CONST.IOU.TYPE.SPLIT && file;
                    setIsShowLocationPermissionModal(gpsRequired)
                } else {
                    navigateToConfirmationStep(file, source);
                }

https://github.com/Expensify/App/blob/487816184680744a2ad53a03460cbbdec363c432/src/pages/iou/request/step/IOURequestStepScan/index.tsx#L261
What alternative solutions did you explore? (Optional)

Proposal Updated add minor change and result

Reproducible issue. I agree we should fix it

The solution is straightforward. @nkdengineer's proposal looks good to me, the detailed implementation will be checked carefully in the PR phase
🎀 👀 🎀 C+ reviewed

There is another issue raised that is related to this - Allow location is not shown if device time is set to 7 days in the future
@DylanDylann @nkdengineer - will your solution resolve this issue?

@VictoriaExpensify No, it is another issue

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
[@DylanDylann] The PR that introduced the bug has been identified. Link to the PR: It is new implementation, not a bug
[@DylanDylann] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: NA
[@DylanDylann] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: NA
[@DylanDylann] Determine if we should create a regression test for this bug. Yes
[@DylanDylann] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
Regression Test Proposal

Click on FAB > Submit Expense > Scan > Upload a receipt > Choose a recipient > Submit
Here notice that "Allow location access" modal is displayed
Click on "Get It" option > The expense is created
Now click on FAB > then click on QAB > Upload a receipt > Submit
Verify that: "Allow location access" modal is displayed

Do we agree 👍 or 👎

Request raised to add ^^ to testrail - https://github.com/Expensify/Expensify/issues/440022

Payment summary updated:
Contributor: @nkdengineer paid $250 via Upwork
Contributor+: @DylanDylann paid $250 via Upwork


⚠ GitHub has degraded performance

In d0ca866, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 140 ms

Resolved: GitHub performance has improved in 7a16c12.


[AutoRelease] t2-redis-2024-06-25-68177(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/5294
Live test fail, detailed info is in pipeline log(search keyword FAILED)!!!
https://dev.azure.com/azure-sdk/internal/_build?definitionId=1022

/check-enforcer override


Bug: surrealdb adds nodejs as a dependency

Describe the bug
surrealdb has isows as dependency, which depends on ws, which depends on nodejs code:

surrealdb -> isows -> ws -> nodejs

isows is supposed to detect the environment in a smart way, but it first imports ws unconditionally (wtf?):
This can go unnoticed in environments that do not actually run the ws code, but can be a problem in more strict ones.
I have been trying to deploy a project to Cloudflare Workers using SST-ion and, there, ws is not accepted.
This issue has been discussed with the SST developers as well: discord message
Steps to reproduce

Start an SST-ion project with Cloudflare.
Add surrealdb as dependency.
Run sst dev

Alternatively, check my reproducible (commit 17faf94) containing the steps above.
Workaround
If we kill isows, the deployment works fine. However, using esbuild plugins disables SST's hot reload on dev mode.
SurrealDB version
irrelevant
JavaScript SDK version
1.0.0-beta.20
Contact Details
No response
Is there an existing issue for this?

[X] I have searched the existing issues

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey @zvictor, the isows does not actually import the ws dependency unconditionally. The exports property in their package.json file dictates if the "index" file or "native" file gets imported, which is how it achieves it's functionality: https://github.com/wevm/isows/blob/b81c110ca748c8aec18f79565bc626d3c59d35ad/src/package.json#L22-L30
This might be an issue in SST, but I'm not sure about it. I don't have time to look into this right away, but I hope this gives some initial clues

That's a good point! I had checked their ./package.json but didn't notice a ./src/package.json as well. My bad!
If proper exports are defined, I believe its the bundler responsability to filter out non desirable files.
I will bring this question back to SST developers (we have been discussing this issue on their Discord).

There is a need for changes in both isows and SST, but there is nothing to be done here.
Thanks for the help and all the hard work @kearfy !

Amazing @zvictor, thank you!


Add GetCollectionType to Edit-In Excel API

Summary
The issue
We have received this issue: https://github.com/microsoft/ALAppExtensions/issues/21940 where the programmer wants to move all of the filters from one field to another. The only thing missing for this capability is that we should be able to dynamically detect if the filter is a AND or OR expression, this is not possible in the current implementation.
Expected behavior
We should expose the "Edit in Excel Filter Collection Type" property on the filter through the API, such that  clients of the API can dynamically detect what collection type the filter has.
Work Item(s)
Fixes AB#498510

Just putting this here, adding
    "preprocessorSymbols": [
        "CLEAN25"
    ]
``` to the `app.json` seems to compile fine.

Just putting this here, adding
    "preprocessorSymbols": [
        "CLEAN25"
    ]

to the app.json seems to compile fine.

which just goes to show: compilation is not enough :-P


Theme is not changing by given steps.

We have deployed openedx on azure using microsoft stamp deployment. We deployed the ficus release. We want to change the themes. We have followed all the steps but it is not working. We have followed also the openedx documentation. but  the theme is not changing. We are not getting any error while doing the steps you have given.

I never try openedx on azure using microsoft stamp deployment.
but it should work if the configuration files is in the same location as normal deployment.

Hey Thank you Dede!!, We have successfully applied theme by putting the files in the location you have mentioned.


SQLite3 Savepoints for Faster Reorgization Handling?

We should keep a rolling savepoint or two, maybe 20 and 30 blocks back, so that reorgs can just reset to them and continue from there, rather than re-parsing everything.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/10049089-sqlite3-savepoints-for-faster-reorgization-handling?utm_campaign=plugin&utm_content=tracker%2F494307&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F494307&utm_medium=issues&utm_source=github).

Working on this...

See #758


21273 - Added alert for businesses in the process of being dissolved

Issue #: /bcgov/entity#21273
Description of changes:

Added an alert for businesses that are in the process of being dissolved
Misc. Fixes
Unit test fixes

Designs followed: https://preview.uxpin.com/4648cf2627971eb4281b7ccc7c1258224b3d8084#/pages/164129752/simulate/sitemap
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the PPR license (Apache 2.0).

/gcbrun

/gcbrun

Temporary Url for review: https://registry-search-dev--pr-261-a4qv92k2.web.app

/gcbrun

You can search for "BC0878513" for a business that's in the process of being dissolved.

Temporary Url for review: https://registry-search-dev--pr-261-a4qv92k2.web.app

Nice work 👍


Add has-error to GroupOptions only if errorCssClass is defined

Smal correction to #891

Thank you!


The system cannot find the file specified.-System.Memory, Version=<IP_ADDRESS>

I have downloaded code from Docs/aspnetcore/host-and-deploy/windows-service/samples/2.x/AspNetCoreService/
and, while running it in visual stuido 2017, I get below error
Could not load file or assembly 'System.Memory, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b1d2ddd51'. The system cannot find the file specified."
General
We use issues to drive the discussion for changes to
existing topics and the creation of new topics.
This template offers some suggestions to consider
when creating an issue.
Issues with Existing Topics
If the issue is a simple typo or similar correction, just submit a PR.
Otherwise, let us know what's wrong or what we should improve. Include a
link to the topic.
Requests for new Topics

Write a short paragraph describing what the topic will cover.

Write an outline of the proposed topic contents.

Where would you put the topic in the Table of Contents.

If you know who should review the issue, notify them by including @githubID in the issue description.

Resolved after updating .NET Core 2.1 SDK!


Apple ipad 4 in Chrome default scrollbar is visible. what could be the reason? And how to fix?

It helped me
.nano-content {
margin-right: -19px;
padding-right: 19px;
}


Style not render properly

Almost all element, style not render properly.
Please Help.
"dependencies": {
    "native-base": "^2.0.12",
    "react": "15.4.2",
    "react-native": "0.42.0"
 }

Tutorial:

Error:

@jeffreyho92 Can you share the use-case for this

I have the same problem with you   and the error is Warning: Failed prop type: Invalid prop style of type number supplied to Styled(Content), expected object.

I have the same problem,when I use
var styles=StyleSheet.create({})
but when I use
var styles={}
the warning gone

StyleSheet.create is not yet supported by NativeBase. This is a duplicate of #510, #525, #527 and #557

So this will be supported?


build fails when running cmake .

Describe the bug
build fails when running cmake from the main source directory with the following error:
[ 74%] Linking CXX static library ifp.a
Error: IFP 0038 used 2 times
cmamake[2]: *** [src/ifp/src/CMakeFiles/ifp.dir/build.make:157: src/ifp/src/ifp.a] Error 1

Expected Behavior
build passes
Environment
N/A

To Reproduce
cmake .
make

Relevant log output
This is likely due to `find_message.py` inspecting generated files for similar error messages, see:

IFP 0038 InitFloorplan.i:62        No design is loaded. ERROR https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/home/proppy/src/github.com/The-OpenROAD-Project/OpenROAD/src/ifp/src/InitFloorplan.i#L62
IFP 0038 InitFloorplanTCL_wrap.cxx:1792 No design is loaded. ERROR https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/home/proppy/src/github.com/The-OpenROAD-Project/OpenROAD/src/ifp/src/CMakeFiles/ifp.dir/InitFloorplanTCL_wrap.cxx#L1792

@proppy I only see the message in one place:
src/ifp/src/InitFloorplan.i:    logger->error(utl::IFP, 38, "No design is loaded.");

Could you try a clean build? Might be a caching issue.

stale


Template shape is not recomputed when walls change

For example, opening/closing a door has no effect on the templates shape until the template is moved or refreshed by something else.

Yeah, I just noticed that and don't know what the hell happened to it. I had it updating correctly before...

Fixed in v0.6.5.


Update random_number integer instruction for #play

play method works with negative integers too. So the instruction for the random number changed from positive integer to integer.

Thanks for taking the time to bring this to our attention and make this change.

Happy to Contribute.


[core] How to pass secrets to lilypad modules?

The idea here is to have an open discussion on how to give modules some inputs that are considered sensitive.

I think we need to look at the big picture here.
The request comes from "how would we run lilypad build on the lilypad network". I still have some concerns with that, like running a build to fix the network when it's down.
But perhaps the real question is, "how does a module invoker (do we have a better term for that?) provide secrets to the module runner at runtime". It seems like a ws callback (or https) could be a practical solution. We could define this url in the module spec so that there's a standard way for module authors and module invokers to achieve that.

This needs to start at the client side when the job is requested and signed using the module requesting the user wallet or an on-chain encryption service.
The actors in the process, the job initiator, will need to easily pass unencrypted inputs, which are then encrypted and sent to the network to be processed. The RP selected to run the job then decrypts the input. Once the job is run, the output is encrypted and sent back to the requestor. The validator can then decrypt the results to validate the job.
As a side note, this process would need to be light and fast so that it doesn't take up too much processing time and is easy enough for a requesting user to pass inputs.

@developersteve that was my initial thought too, but the job initiator doesn't know who's going to run the job so maybe I'm missing how they'd decrypt it?

@developersteve that was my initial thought too, but the job initiator doesn't know who's going to run the job so maybe I'm missing how they'd decrypt it?

Ahhh true, and if we wait until the deal is agreed to get the public address and send the encrypted secrets, at that point in time we might have to do it via a ws callback.

running a build to fix the network when it's down
I'd definitely go with an approach that has a plan b: keep the github actions that can deploy around but these can only be triggered manually, if the Lilypad network cannot run the CI+CD pipeline, we can always manually trigger the github action as a fallback.

https://infisical.com might be an option to investigate


use eslint to enforce .js extensions with relative import paths

An eslint plugin which fixes https://github.com/solana-labs/wallet-adapter/issues/546
It should autofix code with eslint --fix or on save with eslint plugins installed etc
https://user-images.githubusercontent.com/601961/187097384-08ef458c-234f-464b-bb5d-58139b39aac1.mov
You might want to give it a better name and publish it as an npm package if it's going to be shared amongst multiple repos, I put it in here as a starting point for convenience
I think it should cover all types of import and exports. I just pasted some code in https://astexplorer.net then copied the node type names

Holy shit, this is incredible

Externalized to https://github.com/solana-labs/eslint-plugin-require-extensions. Thank you so much!


Coercion

Hi, thanks for writing this library! I like the cleanliness of the code and it appears to be wicked fast 🔥
Have you thought about adding type coercion? It's the only thing keeping me from switching from my current validator. I'd be willing to collaborate on this if it's something you think makes sense in the library.

Hi @sberan, thanks for the comment!
Are you talking about this kind of coercion? Cannot find, does it have an official documentation or it should follow ECMAScript specification?
Yes, I think this could be a next feature (~2-3 months) to implement after releasing draft-06 support + fix resolution bugs.

@korzio that's precisely what I'm after. There is no spec I'm aware of either unfortunately. I will investigate further 👍


Reduce battery bank range

Is your feature request related to a problem? Please describe.
I live in a community with houses pretty close to each other.
Describe the solution you'd like
I'd like to reduce the range such that I'm only powering my appliances and not everything within 20 tiles.
Describe alternatives you've considered
Moving the bank in any direction still leaves me in range of others
Additional context

Is it possible to use the safehouse boundary instead of a radius?

not possible with Project Zomboid v.41.


Download Filename and Tooltip to Download

@thienlnam Can you please review this?
Details

Added fileName to the download function
Added Tooltip to the download icon

Fixed Issues

$ https://github.com/Expensify/App/issues/4601
$ https://github.com/Expensify/App/issues/4870
$ https://github.com/Expensify/App/issues/4868
Tests

Screenshot attached for tooltips in Web and Desktop
Filename will be tested once pushed to staging

QA Steps

We need to test if the fileName that is downloaded is same as the filename shown in the preview
Need to verify that Tooltip is visible for the download icons

Tested On

[x] Web
[] Mobile Web
[x] Desktop
[ ] iOS
[ ] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

🚀 Deployed to staging by @sketchydroide in version: 1.0.88-3 🚀

platform
result

🤖 android 🤖
cancelled 🔪

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
success ✅

🚀 Deployed to production by @roryabraham in version: 1.0.88-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

This has been deployed to production and is now subject to a 7-day regression period.
If no regressions arise, payment will be issued on 2021-09-08.  :confetti_ball:

🚀 Deployed to production by @roryabraham in version: 1.0.90-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Access to prometheus metrics forbidden after upgrading from v4 to v5

The below RBAC used to give users access to prometheus metrics in v4 but after upgrading to v5 the users are forbidden from accessing the metrics. Have there been any changes between v4 and v5 that could be causing this? Any help with this would be much appreciated!
kind: ClusterRole
metadata:
  name: metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
- nonResourceURLs:
  - /metrics
  verbs:
  - get
  - list
  - watch

kind: Role
metadata:
  name: metrics-reader
  namespace: system
rules:
- apiGroups:
  - ""
  resourceNames:
  - prometheus-server:http
  - prometheus-server:80
  - 'http:prometheus-server:'
  - prometheus-server
  resources:
  - services
  - services/status
  - services/proxy
  verbs:
  - list
  - watch
  - get

These are the related errors I found from running Lens in debug mode:
warn: PrometheusLens: failed to list services: services "prometheus" not found
warn: PrometheusLens: failed to list services: services "prometheus" not found
warn: PrometheusLens: failed to list services: services "prometheus-server" not found
warn: PrometheusLens: failed to list services: services "prometheus-server" not found
info: using helm as prometheus provider
error: [Metrics]: metrics not available

And here are the details about the error (modified for clarity):
{
    "error": {
        "name": "StatusCodeError",
        "statusCode": 403,
        "message": "403 - {\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"services \\\"prometheus-server:80\\\" is forbidden: User \\\"app-maintainer:EKSGetTokenAuth\\\" cannot create resource \\\"services/proxy\\\" in API group \\\"\\\" in the namespace \\\"system\\\"\",\"reason\":\"Forbidden\",\"details\":{\"name\":\"prometheus-server:80\",\"kind\":\"services\"},\"code\":403}",
        "error": {
            "kind": "Status",
            "apiVersion": "v1",
            "metadata": {},
            "status": "Failure",
            "message": "services \"prometheus-server:80\" is forbidden: User \"app-maintainer:EKSGetTokenAuth\" cannot create resource \"services/proxy\" in API group \"\" in the namespace \"system\"",
            "reason": "Forbidden",
            "details": {
                "name": "prometheus-server:80",
                "kind": "services"
            },
            "code": 403
        },
        "response": {
            "statusCode": 403,
            "body": {
                "kind": "Status",
                "apiVersion": "v1",
                "metadata": {},
                "status": "Failure",
                "message": "services \"prometheus-server:80\" is forbidden: User \"app-maintainer:EKSGetTokenAuth\" cannot create resource \"services/proxy\" in API group \"\" in the namespace \"system\"",
                "reason": "Forbidden",
                "details": {
                    "name": "prometheus-server:80",
                    "kind": "services"
                },
                "code": 403
            },
            "request": {
                "uri": {
                    "protocol": "http:",
                    "slashes": true,
                    "auth": null,
                    "host": "localhost:63243",
                    "port": "63243",
                    "hostname": "localhost",
                    "hash": null,
                    "search": null,
                    "query": null,
                    "pathname": "/api-kube/api/v1/namespaces/system/services/prometheus-server:80/proxy/api/v1/query_range",
                    "path": "/api-kube/api/v1/namespaces/system/services/prometheus-server:80/proxy/api/v1/query_range",
                    "href": "http://localhost:63243/api-kube/api/v1/namespaces/system/services/prometheus-server:80/proxy/api/v1/query_range"
                },
                "method": "POST",
                "headers": {
                    "Host": "079d7da4b66d9219fe0de198ac254367.localhost:63243",
                    "content-type": "application/x-www-form-urlencoded",
                    "accept": "application/json",
                    "content-length": 2449
                }
            }
        }
    }
}

The first set of errors seem to indicate that Lens cannot locate the prometheus-server service in the system namespace, but the detailed error message shows the request being sent to the correct endpoint namespaces/system/services/prometheus-server:80 but receiving a 403 Forbidden error.

We have started to experience this also after folks started to upgrade to v5

Same issue here! Lens seems to be trying to create resources, and that's not a permission we're willing to give...

Similar issue here. In v4, I could grant permission to see metrics with this - it's probably overpermissive, but my aim in this case was to grant read-only access to cluster resources and see metrics, not necessarily to grant least privileges:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cluster-metrics-reader
rules:

apiGroups: ["metrics.k8s.io"]
resources: ["*"]
verbs: ["get", "watch", "list"]
apiGroups: ["coordination.k8s.io"]
resources: ["*"]
verbs: ["get", "watch", "list"]
apiGroups: ["monitoring.coreos.com"]
resources: ["*"]
verbs: ["get", "watch", "list"]

However, in v5, a user with these permissions can't see metrics in Lens. Like @Yann-J I really don't want to grant permission to create or change any k8s resources.

Still not working with latest lens 6.2.6

For me this works with lens v2023.3.171731-latest:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: some-really-cool-name
rules:
  - apiGroups:
      - ""
    resources:
      - "namespaces"
      - "nodes"
    verbs:
      - "get"
      - "list"
      - "watch"
  - apiGroups:
      - "apiextensions.k8s.io"
    resources:
      - "customresourcedefinitions"
    verbs:
      - "get"
      - "list"
      - "watch"
  - apiGroups:
      - ""
    resources:
      - "services/proxy"
    resourceNames:
      - "prometheus-operated:9090"
    verbs:
      - "get"
      - "list"
      - "watch"
      - "create"
      - "update"
      - "patch"
      - "delete"
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - "list"

probably not the best solution, since the service account can see all services, but sufficient for me.
note also: nodes and customresourcedefinitions are optional

with OpenLense 6.5.2 this works for me
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-prometheus-proxy-creator
rules:
- apiGroups: [""]
  resources: ["services/proxy"]
  resourceNames: ["prometheus-operated:9090"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["list"]

I've got it working with slightly less verbs (code below is terraform)
  rule {
    api_groups  [""]
    resources  = ["services/proxy"]
    resource_names = ["prometheus-operated:9090"]
    verbs      = ["get", "list", "watch", "create"]
  }

  rule {
    api_groups = [""]
    resources = ["services"]
    verbs = ["list"]
  }


muntjac-soc firmware build issue

Hi, I'm getting firmware build issue from compiling unwinding during building the firmware for muntjac-soc. I tried to set different release version and commit version of unwinding, still build fails.
error[E0433]: failed to resolve: could not find video in the crate root
--> src/fmt.rs:26:46
|
26 |         if let Some(fbcon) = unsafe { crate::video::get_fbcon() } {
|                                              ^^^^^ could not find video in the crate root

I forget to cfg it with has_display. A fix has been pushed. Can you retry?

Hi, thanks, I just retried, the error seems to disappear. But another error appeared regarding linking the bootloader. I'm building the genesis 2 board by the way.
error: linking with /home/yue/repo/muntjac/muntjac-soc/firmware/../build/linker failed: exit status: 1
|
= note: LC_ALL="C" PATH="/home/yue/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/yue/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/yue/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/tools/modelsim/modelsim_dlx/bin:/tools/verilator/v4.210/bin:/home/yue/intelFPGA/20.1/modelsim_ase/bin:/home/yue/Documents/riscv/lowrisc-toolchain-gcc-rv32imcb-20240206-1/bin:/home/yue/Documents/bluespec/bsc-2023.07-ubuntu-20.04/bin/:/tools/Xilinx/Vitis/2022.2/bin/:/tools/Xilinx/Vivado/2022.2/bin/:/home/yue/.cargo/bin:/home/yue/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" VSLANG="1033" "/home/yue/repo/muntjac/muntjac-soc/firmware/../build/linker" "/tmp/rustcw3assH/symbols.o" "/home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/bootloader-9e052eecca060d1f.bootloader.e2946d6e6a55e1b1-cgu.5.rcgu.o" "--as-needed" "-L" "/home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps" "-L" "/home/yue/repo/muntjac/muntjac-soc/genesys_2/build/release/deps" "-L" "/home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/build/bootloader-be22c16e02a4970d/out" "-L" "/home/yue/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/riscv64imac-unknown-none-elf/lib" "-Bstatic" "-lfoo" "/home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib" "-Bdynamic" "-z" "noexecstack" "-L" "/home/yue/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/riscv64imac-unknown-none-elf/lib" "-o" "/home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/bootloader-9e052eecca060d1f" "--gc-sections" "-O1" "-Tlinker.ld" "--eh-frame-hdr"
= note: riscv64-linux-gnu-ld: -march=rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0: unsupported ISA subset `z'
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.06.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.10.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.11.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.12.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.13.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.14.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.15.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.00.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.01.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.02.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.03.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.04.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.05.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.07.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.08.rcgu.o)
riscv64-linux-gnu-ld: -march=: ISA string must begin with rv32 or rv64
riscv64-linux-gnu-ld: failed to merge target specific data of file /home/yue/repo/muntjac/muntjac-soc/genesys_2/build/riscv64imac-unknown-none-elf/release/deps/libcompiler_builtins-f8635da2e44ebe0b.rlib(compiler_builtins-f8635da2e44ebe0b.compiler_builtins.804125e885f6555f-cgu.09.rcgu.o)
warning: bootloader (bin "bootloader") generated 4 warnings
The following warnings were emitted during compilation:
warning<EMAIL_ADDRESS>src/entry.S: Assembler messages:
warning<EMAIL_ADDRESS>src/entry.S:4: Warning: Unrecognised .option directive: arch,+zicsr
warning<EMAIL_ADDRESS>error: could not compile bootloader (bin "bootloader") due to 1 previous error; 4 warnings emitted

What's the version of the RISC-V GCC toolchain are you using?  riscv64-linux-gnu-gcc --version should report it. I think it's very likely that you're using a very old toolchain.

Yes, you were right, the gcc installed from sudo apt-get install gcc-riscv64-linux-gnu was quite an old version, was 2019. I had to build it from source, using that one successfully compiled. Thanks for your help and your great works on Muntjac. I really like it.

Hi, I got another issue which is about building rootfs.img, I've tried to build it on multiple Ubuntu machines all failed, getting the same error. Haven't got fixed yet, would be appreciate if you could please look into it.
I: content of /etc/apt/sources.list:
deb http://deb.debian.org/debian-ports/ unstable main
E: apt-get update didn't download anything
I: Updating apt sources
chroot: failed to run command ‘apt-get’: No such file or directory
I: Install additional packages
chroot: failed to run command ‘apt-get’: No such file or directory
I: Patching
sed: can't read /tmp/tmp.hYKtvdPVjJ/usr/bin/which.debianutils: No such file or directory
I: Unmounting rootfs image

Debian has recently moved riscv64 from port to their officially supported arch. I have updated the URL in the latest commit. Can you try again?

Hi, thanks for looking into it. I just pulled and tried it again. But got a different error. I looked it up on the web, tried all the solutions they suggested, seemed not fixed the issue.
Initializing machine ID from random generator.
Failed to take /etc/passwd lock: Invalid argument
dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of cron-daemon-common:
cron-daemon-common depends on systemd | systemd-standalone-sysusers | systemd-sysusers; however:
Package systemd is not configured yet.
Package systemd-standalone-sysusers is not installed.
Package systemd-sysusers is not installed.
Package systemd which provides systemd-sysusers is not configured yet.
dpkg: error processing package cron-daemon-common (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
systemd
cron-daemon-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: run_chroot failed: E: /usr/sbin/chroot /tmp/tmp.2AXAoZP5Uh env --unset=APT_CONFIG --unset=TMPDIR apt-get --yes install -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false libpam-modules systemd debian-archive-keyring iproute2 readline-common iputils-ping vim-tiny mawk apt-utils passwd cron-daemon-common e2fsprogs login sensible-utils kmod fdisk dmidecode tzdata ifupdown adduser nftables less mount nano systemd-sysv gpgv logrotate netbase udev procps init apt cpio vim-common tasksel-data libpam-modules-bin isc-dhcp-common whiptail debconf-i18n cron isc-dhcp-client libpam-runtime debconf failed

I tried to run the script today and I can't reproduce any issues.


Add Expr support to ControlFlowOp representation

Summary
This commit allows IfElseOp and WhileLoopOp to have a condition that is an Expr typed Bool(), and SwitchCaseOp to have a target that is an Expr.  It does not fully add support to resolving these new allowed values into the control-flow builder interface (that will come later).
Details and comments
Close #10224.
Depends on #10332.  Same consideration about release note.
Originally I was doing the control-flow builder interface as part of this commit as well since there's very little additional work needed to make that work.  In practice, though, being able to test the builder interface requires a bunch of the DAGCircuit-related bits to be working as well, so I've split it off.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

465 of 495 (93.94%)  changed or added relevant lines in 18 files are covered.
9 unchanged lines in 4 files lost coverage.
Overall coverage increased (+0.09%) to 86.033%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/classical/types/ordering.py
36
37
97.3%

qiskit/circuit/controlflow/switch_case.py
8
9
88.89%

qiskit/dagcircuit/dagcircuit.py
9
11
81.82%

qiskit/circuit/classical/types/types.py
44
48
91.67%

qiskit/circuit/classical/expr/expr.py
102
111
91.89%

qiskit/circuit/classical/expr/constructors.py
142
155
91.61%

Files with Coverage Reduction
New Missed Lines
%

qiskit/circuit/controlflow/switch_case.py
1
94.08%

crates/qasm2/src/lex.rs
2
91.14%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
2
90.18%

crates/accelerate/src/sabre_swap/layer.rs
4
97.32%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
72061

Relevant Lines:
83760

💛  - Coveralls

Now rebased on top of main.


[UI] add apps to processes, configuration menu, per process configuration

This PR groups processes to their packages application in the process screen. Additionaly, the configuration screen is split into preset, global and per process configuration. This way, we can configure eBPF programs either for individual processes, apps or globally.
New Configuration Menu:

New combined apps and processes menu, clicking an entry will take you to the old configuration screen.

Could you add the added library to the dependencies in our team document.
Apart from that we should eventually get all package information in our backend this looks good!

Done.


Can't seem to load superslides from Ajax link

I look at the superslides html file with the modifications I've made and it loads perfectly fine.
I have linked it using jquery as an ajax link and it breaks it, is there some javascript modifications I am missing?
$("ol#nav li a").live("click", function(){
var page = $(this).attr('href');
$('#content').load('content/' + page + '.html');
return false;
});
This is the script which loads the pages, any help would be greatly appreciated!

Firstly .live() has been deprecated as of 1.7 and removed as of 1.9. Is it possible that you're using a newer version of jQuery? What exactly is or is not happening? Are you getting an error in the console?


Translate concepts/overview/working-with-objects/namespaces/ in Japanese

This is a Feature Request

Problem:
No concepts/overview/working-with-objects/namespaces.md in Japanese.
Proposed Solution:
Copy a file from en contents to content/ja/docs/concepts/overview/working-with-objects/namespaces.md and translate it into Japanese.
Page to Update:
https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/namespaces/

/language ja


any ETA on custom controls support ?

I want to have controls on top of video (overlay) and looks like I cannot do this with non-custom controls  ?
So I tried using HTML custom ones, works fine, except I dont receive callbacks like:
MixerInteractive.GetButton("BUTTON_ID").
So is there an ETA for this feature ?
Thanks.
Nicolas

Yea if you want to go on video (and it's not just mouse input), then you need to use custom controls.
Actually, if you want the MixerInteractive.GetButton("BUTTON_ID") API to work with a custom control, it's possible. You just need to make sure your giveInput() call on the JavaScript side matches the format of a button event. There's an example of the button message in this section of the protocol doc: https://dev.mixer.com/guides/mixplay/protocol/specification#input

Cool thanks for lead, I had hard time finding this info as this is my first try at custom controls. Will dig into this. Thanks.

No worries! We're always glad to help and it's always good to know which parts of our documentation could be more discoverable :) Thank you for posting the issue!

Hi,
Here is a recap of what I found hard to understand and stuff that can "fail" silently and have dev guessing .. at least me ;-)
In CDK/HTML Mode: by default the controls in the Schema have the property disabled: false:
I had to change to true to have them work.
In CDK/HTML Mode: by default in the JS file which get DOM buttons events to resend them to MixerInteractive, the DOM events used are  .onclick, and logically then creates a mixer.socket.call with event:'click', but from what I understood later, click is not used internaly in MixerInteractice, and in fact in Mixer for Unity the code handles mainly: mousedown, mouseup.
Once I changed the event type to mousedown events worked with MixerInteractive.GetButton("...") in Unity/C#.
Last small detail:
In the roadmap file Custom Controls is market as planned but not done, so It can be though that it is normal that it does not work. but now as I got at least the events working I'm confused, what Custom Controls support means ?
https://github.com/mixer/interactive-unity-plugin/blob/master/roadmap.md
Hope it helps.
and thanks for the support.
Nicolas

Thank you for the feedback. I will share it with the team.
I'll also update the roadmap right now. Custom controls are supported.


Remove / prefix from vhost when parsing

See https://www.rabbitmq.com/uri-spec.html

@tyilo thanks for your contribution. Please check and fix the CI error

I haven't touched the lines it complains about.
Also, I wouldn't know how to fix https://github.com/gftea/amqprs/actions/runs/5666704166/job/15361926189?pr=104

you can fix the clippy error in ci/builds, the codecov error is not related to your change

@gftea should be fixed now.


GetBenchmark stats now returns the snapshot

@fassadlr please fix tests

@noescape00 fixed 👍

What is the purpose of those changes?
Also I think those changes shouldn't be in NodeStats.cs.

@noescape00 OK so the idea here is that instead of returning strings from each component, we return an stats or snapshot object that we can then use to interrogate. This way we can add to the snapshot object more easily for reporting without having to constantly append to the string when we want stats.

@noescape00 OK so the idea here is that instead of returning strings from each component, we return an stats or snapshot object that we can then use to interrogate. This way we can add to the snapshot object more easily for reporting without having to constantly append to the string when we want stats.

Right now all 3 types of stats are used only for logging to the console.
I think if we need to collect snapshots it shouldn't be done in node stats but instead in a different component.
This way we can add to the snapshot object more easily for reporting without having to constantly append to the string when we want stats
Could you please elaborate on this? I didn't quite understand what you mean

What we should do is have public perf counters on every component that needs display stats.
Then the collection of those stats can happen in an external component without polluting internally any code targeting a specific outputs (like console in this case)

Closing this PR it should be rpelaced with a PR that create a perf counter instead


Make all space previews work

To make space previews work, m.room.guest_access {guest_access: "can_join"} and m.room.history_visibility {history_visibility: "world_readable"} events need to be sent in all (sub)spaces.
This was partially done in https://github.com/matrix-org/conference-bot/pull/88, but that PR neglected to set m.room.guest_access for auditorium subspaces.
TODO: check if m.room.history_visibility is actually required to make space previews work.

@squahtx Do you know why m.room.guest_access is needed? I'm looking through Synapse (and the spec... which is underspecified :/) and can't see where it comes into play.

I can't remember, I'm afraid. It may be to satisfy logic on Element Web?

Guest access allows anonymous viewers to view the room, as they otherwise would get told to go away (slightly awkward because an authenticated user could see the room, but guest users would be declined 🤷 )

agh, it doesn't do custom state events indeed, boo :(


optimizing theme

Why:
Closes:

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

Hello @sajjadhossain67 👋 ! Unfortunately, we are unable to accept contributions to the files you are attempting to modify, per the automated messages 💛
If you're issues to pick up, take a look at our help wanted section to find open issues you can work on ✨


Remove rom-support dependency

Now use dry-initializer + dry-core instead :tada:

@solnic this makes specs fail on MRI 2.2 because [ROM::SQL::Function.new(Object.new)].flatten hangs on indefinitely (obviously due to def to_ary presence). .flatten with no args is called in rom-mapper. I tried to remove flatten and rom-mapper's tests still pass :-/ . Replacing flatten with flatten(1) also works. WDYT?

@flash-gordon thanks for help, I wrapped this up and merged

@solnic so we need a disclaimer at rom-support's page that it has been decommissioned?

Yes we do
Cheers
Piotr
On 5 Jan 2017, 5:03 AM +0100, Nikita Shilnikov<EMAIL_ADDRESS>wrote:

@solnic (https://github.com/solnic) so we need a disclaimer at rom-support's page that it has been decommissioned?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/rom-rb/rom-repository/pull/44#issuecomment-270559004), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAEKqOA7cm5C8lEqx3mCXrVkiJXvvdlks5rPGuAgaJpZM4LZLMy).


Give FormField's anonymous inner div a className.

See issue: https://github.com/xh/hoist-react/issues/2884
It turns out that anonymous div is serving the necessary function of breaking out of flexbox for unsizeable children, so I couldn't remove it entirely. Instead, I gave it an explicit class name that hopefully helps clarify the intentions there.
Hoist P/R Checklist
Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

[x] Caught up with develop branch as of last change.
[x] Added CHANGELOG entry, or determined not required.
[x] Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
[x] Updated doc comments / prop-types, or determined not required.
[x] Reviewed and tested on Mobile, or determined not required.
[x] Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

Thanks for the detailed look Anselm - I've just pushed an update with the requested changes


css to go with marketplace search change

Small tweak to move the .page-content div down a smidge. Helps to align it with the bottom of the red nav bar.

:+1:


Fixes Swift code coverage crashing when you put closures into for-each statement iterator

Fixes rdar://problem/26277119

@swift-ci test


Consider hostctl for hosts management in quick-install

https://guumaster.github.io/hostctl/ is a specialized tool that focuses on managing host entries in a reversible manner. While still modifying host state, it does so (easily) reversibly. — for ./quick-install.
Breadcrumb trail: https://github.com/numtide/devshell/issues/27

Yeah, this is interesting. It is adding another dependency but is probably a better way of doing things, especially for the client end.

Also, I see it supports windows, which is nice!

If you would be willing to give github.com/numtide/devshell a try, I could be plugging together a prototype that would have unrivalled UX, and only ever two bootstrap dependencies:

curl -L https://nixos.org/nix/install | sh
a nix command to fetch devshell binary, later a normally distributed binary of the devshell command

Showcase:

→ wrapped hostctl — nix-shell
→ fed by devshell.toml — nix-shell

Helm is now the only supported way to deploy Trow


macOS: Context menu resets mouse cursor

This is a problem with Flutter and needs to be fixed in the engine. Cocoa is correctly calling cursorUpdate: on FlutterView when returning from context menu but Flutter doesn't restore the cursor.


Lazyloading support

Hello John,
I tweeted you about this and wanted a few more characters to have this discussion :)
I'd be interested in lazy loading the WordPress plugin JS so that I can have more control over what single version of jQuery gets loaded that will work with all of my stuff, so that mediaelement's jQuery dependency does not create a race condition with the jQuery I'm already lazyloading, and so that I have a nice system that works nicely with my PJAX content loader which requires manual invocation/reinitilization.
I have this working now with some modifications, but I'm wondering if would you be amenable to some sort of setting that prevents autoloading of mediaelement via the WordPress plugin, or at least documenting this? I wanted to get your feelings on this before simply pull requesting my patches.
BTW, the latest WP plugin seems to be missing the bigplay.svg file...

Did you succeed? Any code for lazy loading media element in Wordpress?

Now that MediaElement.js is part of the Wordpress core, you'd need to make
a change there to affect this.
On Sat, Jan 16, 2016 at 1:39 PM, Marc Tönsing<EMAIL_ADDRESS>wrote:

Did you succeed? Any code for lazy loading media element in Wordpress?
—
Reply to this email directly or view it on GitHub
https://github.com/johndyer/mediaelement/issues/913#issuecomment-172249027
.

--
John Dyer - http://j.hn/


Remove Boost.Program_Options dependency

It's to big for what we need, and does not do the job well. Maybe it's my fault, don't care, custom argument parsing is simple enough to implement by myself

Required by #63


StorageString Library

Motivation
Description
The current String interface is only supported in the heap. This does not allow for any persistent storage within the contract itself. There should be a StorageString based on the StorageVec in order to allow users to save their string.
Motivation
Some use cases require strings to be stored.

Currently blocked by https://github.com/FuelLabs/fuels-rs/issues/602

In light of https://github.com/FuelLabs/sway-libs/issues/82, this should also use the Bytes type to remove extra padding


Add client functions

Add quit function
Handle unexpected socket closing from client side : Catch IOException within Messaging.respond block and log.

Note: Don't merge

@rumeshmadhusanka need active server list to generate room list.

Added list, who and messaging functionalities.


[Hub Generated] Review request for Microsoft.Network to add version stable/2020-11-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@jielichen, please also fix the linter issue in the PR.

@jielichen, please also fix the linter issue in the PR.

@lirenhe I updated one linter issue related to my changes.
Other issues is not related to changes. Probably I'll leave it.

create another pr for new api version 2022-05-01 instead of change the existing version of 2020-11-01


Reduce use of Any

This pr is an initial suggestion, please let me know if you feel this is the right direction! Closes #4
After having a better look at the code, and the code of the other sdks, I no longer agree with my conclusion in https://github.com/laysakura/beam/issues/4#issuecomment-1501012735 regarding SERIALIZED_FNS for the following reasons:

The beam runtime expects a worker to be able to receive requests and run operators based on those requests. The content of such a request can of course not be known at compile time, so we cannot (only) use generics to abstract over the different types of operators that such a request might ask us to run. We cannot use (just) enums either, since users are expected to be able to implement custom transforms. As far as I can tell, this forces us to use trait objects (dynamic dispatch).
There has been discussion about serializing DoFns and sending them on the wire: https://github.com/apache/beam/issues/21089#issuecomment-1374882616. This corresponds to what is done for python in
https://github.com/apache/beam/blob/f5f7a471321c903174b452a1982c5183a79ac6bc/sdks/python/apache_beam/transforms/core.py#L1757
and typescript in
https://github.com/apache/beam/blob/f5f7a471321c903174b452a1982c5183a79ac6bc/sdks/typescript/src/apache_beam/transforms/pardo.ts#L158-L161
I wasn't able to find a the location in the java sdk where similar things happen, but based on the docs and how the DoFn class is marked Serializable, I imagine it must be the same. However, the go sdk apparently goes out of its way to only encode function name and type
https://github.com/apache/beam/blob/f5f7a471321c903174b452a1982c5183a79ac6bc/sdks/go/pkg/beam/core/runtime/graphx/serialize.go#L212-L232
and then uses reflection to resolve the function at runtime rather than serializing/deserializing the function itself
https://github.com/apache/beam/blob/f5f7a471321c903174b452a1982c5183a79ac6bc/sdks/go/pkg/beam/core/runtime/symbols.go#L86-L103
I like the idea of avoiding serialization/deserialization of the actual closures, and a simple way seems to be to just store all the closures in a static at pipeline generation time (and of course generate the pipeline both on workers and the pipeline builder), and then only serialize/derserialize the key.

What this pr holds:

Reduce use of Any and Box and hide any use behind newtypes for some measure of type safety. In particular, process used to take a WindowedValue which would put every single input element in a box
https://github.com/laysakura/beam/blob/f7df217e9a9c166521cbbcc5fe612ed1a6c95d4e/sdks/rust/src/worker/operators.rs#L269-L275
This now uses DynamicWindowedValue
https://github.com/dahlbaek/beam/blob/5609a5ac85f0a31a9aeaf0082b0aa7d9c5bdcd70/sdks/rust/src/worker/operators.rs#L270-L271
which still causes dynamic dispatch to resolve the underlying type, but avoids the box.
Removes one use of unsafe
I made some changes to avoid returning iterators (in the internal code, not directly exposed to the end user). For example, in
https://github.com/dahlbaek/beam/blob/5609a5ac85f0a31a9aeaf0082b0aa7d9c5bdcd70/sdks/rust/src/internals/serialize.rs#L51-L59
I pass in receivers instead of returning an iterator. I made this choice because the type of the iterator is known inside the definition of process_dyn, but it is not known at the call site of process_dyn.

Todo

[ ] Code reorganization: I didn't pay much attention to code layout and liberally sprinkled pub in places I needed it.
[ ] We should probably use some type of more stable key in the static maps holding dofns and key extractors. Perhaps https://doc.rust-lang.org/stable/std/any/struct.TypeId.html would be a better alternative.

Discussion

It seems like parts of the worker code is in a stub state
https://github.com/laysakura/beam/blob/f7df217e9a9c166521cbbcc5fe612ed1a6c95d4e/sdks/rust/src/worker/sdk_worker.rs
It is not entirely clear to me to what extent this part of the code base is exercised in tests, so maybe it would make sense to add a test or two before making these changes to how the internal representation of a pipeline is serialized/deserialized.

Great job, @dahlbaek! Before I make any comments to your codes, I would like to respond to your description first.

The beam runtime expects a worker to be able to receive requests and run operators based on those requests. The content of such a request can of course not be known at compile time,

I understand that, but

so we cannot (only) use generics to abstract over the different types of operators that such a request might ask us to run.

I think it is still possible to use generics. Let me use an analogy to explain: Suppose a program takes input lines from stdin as i32 type. If an input is 42\n, then it is converted into 42i32. However, if another input is abc\n, the program has several choices, such as ignoring the line, returning Err, or panicking.

I like the idea of avoiding serialization/deserialization of the actual closures, and a simple way seems to be to just store all the closures in a static at pipeline generation time (and of course generate the pipeline both on workers and the pipeline builder), and then only serialize/derserialize the key.

Thank you for the thorough investigation. I also like and agree with the idea, but we need to be aware that creating artifacts (for both launcher and runners) and deployments will become more difficult.

[ ] Code reorganization: I didn't pay much attention to code layout and liberally sprinkled pub in places I needed it.
[ ] We should probably use some type of more stable key in the static maps holding dofns and key extractors. Perhaps https://doc.rust-lang.org/stable/std/any/struct.TypeId.html would be a better alternative.

I agree that both are important. Could you create issues for them? We can fix them in other PRs.

It is not entirely clear to me to what extent this part of the code base is exercised in tests,

I'm not sure either. Maybe the current tests only run DirectRunner, which doesn't call SDK worker.

so maybe it would make sense to add a test or two before making these changes to how the internal representation of a pipeline is serialized/deserialized.

I completely agree. If you feel comfortable doing so, could you do it in this PR?

Quick note on the serialization piece, I don't think it's feasible to reconstruct the pipeline during execution with FnAPI. The contract between FnAPI executors and their runner (e.g. Flink, Dataflow) does not start the binary with the same flags and may not have the same environment context available as during the initial graph construction.
I was looking into typetag and serde_traitobject to function as alternatives for the SERIALIZED_* maps that are currently used. Both have their upsides and downsides, but typetag won't be feasible because of https://github.com/dtolnay/typetag/issues/1, which prohibits the generation of tag names for generic traits.
With serde_traitobject the serialized representation depends on TypeID (build id, trait type id, struct type id), which makes it non-portable across different builds (e.g. starting a pipeline on from M1 Macs and executing on x86 servers), which the Go SDK goes through great lengths to support but that does not have to be an initial goal. The other downside is that it relies on nightly features, which isn't a showstopper but a minor annoyance perhaps.

I think it is still possible to use generics. Let me use an analogy to explain: Suppose a program takes input lines from stdin as i32 type. If an input is 42\n, then it is converted into 42i32. However, if another input is abc\n, the program has several choices, such as ignoring the line, returning Err, or panicking.

That's true, though if we want to match an input string to a generic type (possibly implemented outside of the sdk code, i.e. in user code), without dynamic dispatch, then I think it has to happen via a macro or some other type of code generation 🤔

Quick note on the serialization piece, I don't think it's feasible to reconstruct the pipeline during execution with FnAPI. The contract between FnAPI executors and their runner (e.g. Flink, Dataflow) does not start the binary with the same flags and may not have the same environment context available as during the initial graph construction.

Ah, I hadn't considered that it might not be reasonable to build the pipeline at runtime on the workers. I guess this would be an issue whenever the shape of the pipeline is in any way affected by input arguments, which would not be uncommon. So if we still want to pursue this direction, we would probably have to go the path of explicit registration of fns.

With serde_traitobject the serialized representation does not generate a giant enum to distinguish types, but it depends on TypeID (build id, trait type id, struct type id), which makes it non-portable across different builds (e.g. starting a pipeline on from M1 Macs and executing on x86 servers, the binaries would have different build and type ids), which the Go SDK goes through great lengths to support but that does not have to be an initial goal. The other downside is that it relies on nightly features, which isn't a showstopper but a minor annoyance perhaps.

I suppose this would be the goto option, matching the behavior of most of the other sdks as well as frameworks like spark. I think it would be a shame to have the rust sdk require nightly though, and it would be pretty cool to be able to claim a feature like the ability to run mixed amd64/arm64 clusters on aws.

typetag won't be feasible because of dtolnay/typetag#1, which prohibits the generation of tag names for generic traits.

Hmm, I wonder if we could do something with a macro of our own? For instance, I notice that the go sdk suggests (or requires?) that you register dofns in your init. If we ignore the convenience factor for now, suppose we provided a macro that you could use like this
trait DoFn: Default { ... }

#[derive(Serialize, Deserialize)]
struct DoFn1 { ... }
impl DoFn for DoFn1 { ... }

#[derive(Serialize, Deserialize)]
struct DoFn2 { ... }
impl DoFn for DoFn2 { ... }

register!{
  DoFn1;
  DoFn2;
}

and then it would generate a simple enum
#[derive(Serialize, Deserialize)]
enum Payload {
  DoFn1(DoFn1),
  DoFn2(DoFn2),
}

I suppose this would be very unergonomic, ruling out any direct use of closures in a pipeline

My opinion is that we should first aim for putting something together that can run in a distributed manner. In that case, the serde_traitobject direction seems like the one that will get us to that state first. Then we could always revisit the idea of using macros/annotations to avoid the dynamic dispatch, boxing and runtime serialization of fns later.
In that case, I think one could consider the content of this pr a step in the right direction. It removes some unnecessary boxing at the element-level, and introduces some patterns for creating trait objects (that we can use at runtime) from the generic types used a pipeline construction. For instance, at pipeline construction time, the user implements
https://github.com/dahlbaek/beam/blob/903c0c20df7b1b57577bfd2f8d35c5af8a64609f/sdks/rust/src/transforms/pardo.rs#L31-L39
but at runtime we will be using
https://github.com/dahlbaek/beam/blob/903c0c20df7b1b57577bfd2f8d35c5af8a64609f/sdks/rust/src/internals/serialize.rs#L44-L48
@sjvanrossum @laysakura WDYT?

I guess this would be an issue whenever the shape of the pipeline is in any way affected by input arguments, which would not be uncommon. So if we still want to pursue this direction, it seems we would have to go the path of explicit registration of fns, do you agree?

Likely, although I do see how everything would be so much simpler if we could reliably reconstruct the pipeline graph on remote environments.

I'm not up to speed on how close something like serde_traitobject is to being able to run on stable.

Those nightly features seem pretty far away. Anything that might provide or be abused to resemble RTTI is under heavy debate it seems.
The registration mechanism from the Go SDK, but with macros to hide the ugly machinery would be good. We can use typetag's underlying registrar https://github.com/dtolnay/inventory or https://github.com/dtolnay/linkme (modern alternative?) to mimic Go's init functionality.

@dahlbaek @sjvanrossum In this post, I will write about serialization.

My opinion is that we should first aim for putting something together that can run in a distributed manner.

I strongly agree. I also agree with setting up follow-up tasks.

In that case, I think one could consider the content of this pr a step in the right direction. It removes some unnecessary boxing at the element-level, and introduces some patterns for creating trait objects (that we can use at runtime) from the generic types used at pipeline construction time.

I also think this is good progress, so I will review this pull-request first. Sorry for keeping you waiting.

@sjvanrossum I didn't know about dtolnay/inventory and dtolnay/linkme. Seems cool. With one of these, it seems like FnAPI executors and runners can build and use the same DoFn in separate environments.
However, unfortunately, I don't have enough knowledge about how the runners build and deploy user-defined DoFns in the Go SDK (and so in the future Rust SDK). Can you register follow-up tasks that also take build and deployment into account?

https://github.com/dtolnay/inventory or https://github.com/dtolnay/linkme (modern alternative?)

dtolnay/inventory's README says:

Inventory is built on the ctor crate which provides module initialization functions for Rust similar to attribute((constructor)) in C. ...
For a different approach to plugin registration that does not involve life-before-main, see the linkme crate.

If we can assume that FnAPI executors and runners can use libc (which I think we can), I think it's okay to use dtolnay/inventory.

@dahlbaek

That's true, though if we want to match an input string to a generic type (possibly implemented outside of the sdk code, i.e. in user code), without dynamic dispatch, then I think it has to happen via a macro or some other type of code generation 🤔

If I misunderstood, I apologize. However, I don't think macros or code generation are necessary. I think we can force users
to define user-defined types and logics to convert input strings into the types in the same user codes via ElemType trait.
If there are still concerns that cannot be resolved in the response that you write later, I will create a separate issue 👍

I made a posts that contained a misunderstanding. I'll rewrite them later.

@dahlbaek

That's true, though if we want to match an input string to a generic type (possibly implemented outside of the sdk code, i.e. in user code), without dynamic dispatch, then I think it has to happen via a macro or some other type of code generation 🤔

I understand your perspective now. My main mistake was assuming that FnAPI executors could use the same binary (i.e., the same user-defined types) as pipeline developers.
Therefore, I agree with your original statement, and I will close issue #4.

@dahlbaek

My opinion is that we should first aim for putting something together that can run in a distributed manner.

I think one could consider the content of this pr a step in the right direction.

I completely agree with these points.
I'll review this PR as soon as possible.

@sjvanrossum, I was not aware of dtolnay/inventory and dtolnay/linkme. They seem interesting.
Would you be able to register any follow-up tasks along with your current proposed solutions?
Of course, @dahlbaek may also contribute additional ideas in the comments.

https://github.com/dtolnay/inventory or https://github.com/dtolnay/linkme (modern alternative?)
dtolnay/inventory's README says:
Inventory is built on the ctor crate which provides module initialization functions for Rust similar to attribute((constructor)) in C. ...
For a different approach to plugin registration that does not involve life-before-main, see the linkme crate.

If we can assume that callers of Runner API can use libc (which I think we can), I think it's okay to use dtolnay/inventory.

I wrote,

My main mistake was assuming that the FnAPI executors could use the same binary and user-defined types as pipeline developers.

However, I am unsure whether this was a misunderstanding or not. After reading https://beam.apache.org/documentation/sdks/go-cross-compilation/, it appears that both the SDK and FnAPI executors can use the same binary, allowing them to share statically-typed pipelines.
@dahlbaek @sjvanrossum, what do you think about whether the Rust SDK should assume that the SDK and FnAPI executors share the same binary?

My understanding is that we can assume that the worker and pipeline builder share the same binary, but we cannot assume that the worker receive the same input arguments when started as the pipeline builder received. So the issue is that the binary does noes actually hold a materialized pipeline, but only a pipeline builder. The pipeline builder can be statically typed, but the actual materialized pipeline is only known at runtime, and its concrete type can therefore not be known in advance.
I wonder if it would be possible to add optional input arguments for the worker protocol that any sdk may or may not populate 🤔 if we could have such a feature merged upstream, then we could feed the pipeline construction arguments to the workers, and have them materialize the pipeline at runtime.

My understanding is that we can assume that the workers and pipeline builder share the same binary, but we cannot assume that the workers receive the same input arguments when started as the pipeline builder received...

I've clearly understood what you say. Thanks!

I wonder if it would be possible to add optional input arguments for the worker protocol that any sdk may or may not populate 🤔

Unfortunately, this sounds inadequate. Say the user binary has code like:
let pipeline = if (hostname == 'my-laptop) {
  ...
} else {
  ...
}

So I mean, input arguments are not the only factor to make pipelines different.
Now I'm considering the following things:

Dynamic dispatch would be necessary at least for SDK workers
For SDK side (user programs), we might be able to support statically-typed pipelines, which are converted into the dynamic  pipeline DAGs used in runners and SDK workers

So I mean, input arguments are not the only factor to make pipelines different.
Now I'm considering the following things:

Dynamic dispatch would be necessary at least for SDK workers
For SDK side (user programs), we might be able to support statically-typed pipelines, which are converted into the dynamic  pipeline DAGs (protobuf representation) used in runners and SDK workers

Agreed. While obviously malformed, if remotes could reconstruct the pipeline graph by running main, they could also switch or omit ptransforms based on any silly dynamic variable (e.g. hostname, UUID,  RNG) used during construction. The remote might fail to reconstruct the PTransform because its assigned ID is either different or not present.
I've got some ideas to work around typetag's limitations which involve a derive macro and dropping the blanket trait implementation for DynamicDoFn. I'll add an issue about it when I get the chance tonight. 😃


BIGTOP-3627. Update the puppet deploy readme doc

When I deploy components according to the Readme doc, I find an error occur

Then, I find such a issue to discribe it
https://issues.apache.org/jira/browse/BIGTOP-3088
The issue has been fixed, but the doc haven't updated, so I make this commit to fix the gap.

@vivostar
The cause seems to be pinning the version of puppetlabs-stdlib is insufficient in bigtop_toolchain::puppet_modules. You should fix the manifest rather than README.md.
Since the puppetize.sh belonging to bigtop_toolchain covers installation of Puppet itself, the README of puppet-deploy does not assume to use it. bigtop_toolchain::puppet_modules is the class for installing only puppetlabs-stdlib to the environment in which puppet is already installed.

for my record:
We are pinning puppetlabs-stdlib to 4.12.0 only for CentOS 7, CentOS 8 and Fedora 33 in puppetize.sh.
I got following error on Debian 11 on which puppet-module-puppetlabs-stdlib is already installed. If puppet-module-puppetlabs-stdlib is not installed, it works.
$ puppet apply --modulepath=~/srcs/bigtop -e "include bigtop_toolchain::puppet_modules" --debug --verbose
...
Debug: Executing: 'puppet module install puppetlabs-stdlib --version 4.12.0'
Notice: /Stage[main]/Bigtop_toolchain::Puppet_modules/Exec[install-puppet-stdlib]/returns: Notice: Preparing to install into /home/admin/.puppet/etc/code/modules ...
Notice: /Stage[main]/Bigtop_toolchain::Puppet_modules/Exec[install-puppet-stdlib]/returns: Error: Could not install module 'puppetlabs-stdlib' (v4.12.0)
Notice: /Stage[main]/Bigtop_toolchain::Puppet_modules/Exec[install-puppet-stdlib]/returns:   Module 'puppetlabs-stdlib' (v5.0.0) is already installed
Notice: /Stage[main]/Bigtop_toolchain::Puppet_modules/Exec[install-puppet-stdlib]/returns:     Use `puppet module upgrade` to install a different version
Notice: /Stage[main]/Bigtop_toolchain::Puppet_modules/Exec[install-puppet-stdlib]/returns:     Use `puppet module install --force` to re-install only this module
Error: 'puppet module install puppetlabs-stdlib --version 4.12.0' returned 1 instead of one of [0]
Error: /Stage[main]/Bigtop_toolchain::Puppet_modules/Exec[install-puppet-stdlib]/returns: change from 'notrun' to ['0'] failed: 'puppet module install puppetlabs-stdlib --version 4.12.0' returned 1 instead of one of [0]

If puppetlabs-stdlib 4.12.0 cause isuses for recent Debian/Ubuntu, I will file a follow-up JIRA.


Clock drifts in 1.1.2

Describe the bug
The clock in the VM does not stay in sync with the underlying OS (macOS). I did not see this issue in 1.1.1.
Steps to reproduce
Start finch on macOS with just one docker image in the vm, running sleep infinity.
The Mac should be running on mains power.
The Mac should be allowed to sleep when the display is off.
Wait a "few" (2-3?) days.
Run date and you will see the clock has drifted.
Expected behavior
Clock to always stay "relatively" accurate/synced to underlying OS/hardware.
Screenshots or logs
This morning the clock was about 17 minutes out.
Additional context
Here is my finch.yaml:
cpus: 3
memory: 4GiB
creds_helpers:
    - ecr-login
vmType: vz
rosetta: false

To help debug the issue as quickly as possible, we recommend generating a support bundle with finch support-bundle generate and attaching it to this issue. This packages all Finch-related configs and logs into one file.

finch-support-20240304094329.zip
Finch support bundle from this morning. Clock on VM is about 11 minutes 30 seconds out.

Duplicate of #248

Duplicate of #248

Duplicate of #248


no-unsafe-any raises errors on import statements that are not typed as "any"

Bug Report

TSLint version: 5.0.0
TypeScript version: 2.2.2
Running TSLint via: CLI: tslint test.ts --type-check --project tsconfig.json

TypeScript code being linted
import * as ts from "typescript";

// Prevent TypeScript from complaining about ts being unused.
console.log(ts.getCommentRange);

with tslint.json configuration:
{
    "rules": {
        "no-unsafe-any": true
    }
}

I've tried with the following two tsconfig.json:
{
  "compilerOptions": {}
}

and:
{
  "compilerOptions": {
    "rootDir": ".",
    "noEmitOnError": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "skipDefaultLibCheck": true,
    "noUnusedParameters": true,
    "noUnusedLocals": true,
    "skipLibCheck": true,
    "strictNullChecks": true,
    "target": "es5"
  }
}

Actual behavior
The error:
test.ts[1, 21]: Unsafe use of expression of type 'any'.

Expected behavior
No error. I don't see why the imported symbols are somehow considered to be of type any. They obviously aren't since the IDE is able to perform completion that uses TypeScript type information.

Same issue here: it warns for every expression at the first line of each method
ERROR: src/pathfinding/pathfinding.spec.ts[16, 12]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[16, 12]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[16, 12]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[16, 35]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[16, 12]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[16, 12]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[20, 22]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[20, 22]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[20, 22]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[20, 45]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[20, 22]: Unsafe use of expression of type 'any'.
ERROR: src/pathfinding/pathfinding.spec.ts[20, 22]: Unsafe use of expression of type 'any'.
[...]

This is the code it's complaining about:

this should be fixed in tslint >=5.1.0, can you try that out?


Add hook for manipulating cloud-init data

What this PR does / why we need it:
This adds a new hook so cloud-init data can be manipulated before the ISO is written out to the launcher pod. This allows anyone to write a sidecar to add, alter, delete, etc of cloud-init data.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

Add hook for manipulating cloud-init data

ci test please

@davidvossel any chance you can take a look?

@davidvossel sorry, was out of the office last days. Taking a look.

ci test please

Thanks!


⚠ Mobitopup has degraded performance

In cf1b1ce, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4363 ms

Resolved: Mobitopup performance has improved in 686f15c.


correct docs for char in rescript about unicode

Would you add: since compiler 10.0 somewhere.
As the docs are shared.